The MPLS WG Archive

[Loa Andersson <loa@pi.se>]

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: loa@pi.se