The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Title: RE: 'A' bit problem statement

Curtis:

1) Alarm prioritization is a good suggestion, I'll think about it. Although it is still hard to delegate anything if the reporting NE is not local to the problem.

2) no-one is suggesting not using ECMP.

3) I agree with the statement RA does not follow the same path.

cheers
Dave

> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@laptoy770.fictitious.org]
> Sent: Thursday, July 17, 2003 11:20 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: 'mpls@UU.NET'
> Subject: Re: 'A' bit problem statement
>
>
>
> In message
> <FFFC48AEAA5F7447929F4F0D93FCC12D02B922F6@zcard031.ca.nortel.c
> om>, " 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
>