Subject: 'A' bit problem statement

From: "David Allan" <[email-masked]>
Date: Tue, 15 Jul 2003 05:28:33 -0400

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

---

From: Loa Andersson <[email-masked]>
Date: Wed, 16 Jul 2003 09:47:47 +0200

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.
> 
> 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.
> 
> 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.
> 
> 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]

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 17 Jul 2003 11:19:49 -0400

In message <[email-masked]>, "
> 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.

> 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 top label vs. prepending with  the router alert label.

#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