Subject: RE: Invitation to discussion on 'A' bit problem statement

From: "David Allan" <[email-masked]>
Date: Wed, 16 Jul 2003 05:09:51 -0400

To elaborate slightly on yesterday's email, attached are the powerpoint
slides I'll be using in PWE3 today.

Dave

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]] 
> Sent: Wednesday, July 16, 2003 3:48 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: [email-masked]'
> Subject: Invitation to discussion on 'A' bit problem statement
> 
> 
> Dave,
> 
> thanks for do this quick.
> 
> Working Group,
> 
> I would like comments on this over the next 4 weeks (this 
> "long" period because it falls into the vacation period in 
> Northern Europe (July) and the vacation period in the rest of 
> Europe and the US (August), ending Friday August 15th. This 
> discussion is initiated as a result of the discussion at the 
> wg meeting in Vienna. Dave was asked to send a shart problem 
> statement to the list, as a basis for this discussion. We 
> want to find out whether there is a wg consensus to take this 
> up as a work item.
> 
> The related draft is "<draft-allan-mpls-a-bit-00.txt>".
> 
> I would like to see the pros, cons and don't care opininons.
> 
> Add "pro", "con" or "don't care" to the response to the 
> subject line, e.g.:
> 
>     Invitation to discussion on 'A' bit problem statement - don't care
> 
> /Loa
> 
> David Allan wrote:
> > 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.
> > 
> > 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.
> > 
> > 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
> > 
> 
> 
> -- 
> /Loa
> 
> mobile + 46 739 81 21 64
> email: [email-masked]
> 
>