The MPLS WG Archive

[Curtis Villamizar <curtis@laptoy770.fictitious.org>]

In message <FFFC48AEAA5F7447929F4F0D93FCC12D02B922F6@zcard031.ca.nortel.com>, "
David Allan" writes:
> 
> During today's MPLS session it was clear that more discussion/clarification
> was required on the problem space addressed by the I-D.
> 
> There is two aspects to the problem discussed in the draft.
> 
> 1) Mixing e2e path testing with adjacency fault detection has coorindation
> problems when failures occur. If I have an LSP hierarchy that I am pinging
> at some low level, and a failure occurs, some number of the pings will be
> affected, and a response/alarm management will be hard to synchronize as
> ping sources are not local to the fault (and the fault may also be detected
> locally, e.g. link failure). IMHO this is an artifact of the delta between
> using ping to reactively to check routing policy vs. using ping proactively
> to detect data plane failures.

Prioritize alarms and there is no problem.  There will be one link
failure detected that indicates a problem for the NOC to investigate.
LSPs will reroute and all ping errors should promptly go away.

The pings serve a different purpose.  In theory they should not be
needed, but if there is no link fault and a ping stops working, there
is a forwarding plane failure somewhere that needs attention.  If this
is not an extremely rare situation, get new routers.

> 2) Reserved labels define functions instead of forwarding. Fate sharing
> between functions and LSPs is useful. Currently ECMP breaks fate sharing
> between LSPs and LSP functions defined by reserved labels. 

Give up already.  ECMP is deployed and the providers that use it have
no plans to stop using it.

> The answer to #1 is to try to localize detection of data plane problems, the
> ability to do the equivalent of the router alert label that fate shares with
> the LSP is one potential mechanism that could be used to increase locality
> in detecting data plane problems. Specific data plane flows could be
> inspected for consistency by intermediate LSRs as they were forwarded down
> the path. 
> 
> The answer to #2 is to provide an alternative to reserved labels for LSP
> functions, the MPLS/PW PID is a candidate for doing this. The 'A' bit was
> one example of providing such functionality by defining a replacement for
> router alert. A side note is that there is a much higher liklihood of
> commonality of forwarding of a solution that had the label of interest as
> the top label vs. prepending with  the router alert label.
> 
> Comments?
> 
> cheers
> Dave

#1 is a non-problem.

I'm not sure what you perceive to be the problem in #2.  Could you be
more specific.  Router-alert for MPLS defeats the fast forwarding and
also does not test forwarding because it does not take the same path.

Curtis