Subject: RE: 'A' bit problem statement

From: [email-masked]
Date: Wed, 16 Jul 2003 17:50:10 +0100

Hi Dave....I see you are still battling away against the real the underlying
problems.....for which you have my admiration, but I could only agree to
such a position on the basis that it is recognised that we providing a
temporary fix to a fundamentally broken architectural problem.....ultimately
we have to get rid of the stuff that is broken and then we don't need the
fixes.
 
Please see some further remarks below.  regards, Neil

-----Original Message-----
From: David Allan [mailto:[email-masked]]
Sent: 15 July 2003 10:29
To: [email-masked]'
Subject: 'A' bit problem statement

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. 

NH=> The simple short-term fix to the problems mp2p creates I believe is as
follows:
-    mp2p merging in any co pkt-sw technology forwarding means we lose sight
of the source, and architrecturally this should tell us this is a deprecated
topology in such a mode......BTW, IP *never* uses merging it is always
muxing because it belongs to the cnls mode where each/every pkt has a SA/DA
and so is fully resolvable.  So unless the *immediate* client is IP (but
then there is little value-add from MPLS LDP variety here IMO) there are
always p2p LSPs (in one form or another) above the mp2p LSPs......this is a
forced consequence of the mp2p merging to effect demerging.  
-    so run some decent fault management continuously on the p2p LSPs (like
Y.1711) and if this shows a problem then:
    * check the L1 trails.....if these show a correlated fault then
done....but if these show 'clear', then
    * wheel-out more complex ad hoc tools like LSP-Ping to go hunting
through the mp2p LSPs.

Note - I am actually happy to live with LSP-Ping, and the fact its virtually
impossible to define any meaningful defect states (entry/exit criteria and
consequent actions) or QoS behaviour for a mp2p entity, in the
*short-term*....we have it and have to live with it.  But that does not mean
I have to keep building on it and pretending its all fine for the future
too.....long-term this (and other architectural errors like PHP) simply have
to go.  So I won't accept kludge on kludge from here on it, like the latest
PID fix and the further PW OAM proposals.....this last one is an elastoplast
too far.  MPLS could/should have an important future which adds value to
services providers......if all one does is try and replicate the IP layer
(which you can't anyway as MPLS uses co pkt-sw forwarding mode) we are never
going to realise the protential on MPLS.  Maybe that is what some people
want?

2) Reserved labels define functions instead of forwarding.  

NH=> Agreed.  This is not a good solution IMO......however, what do you do
when the header is functionally deficient?....also see later remark.
 Fate sharing between functions and LSPs is useful. Currently ECMP breaks
fate sharing between LSPs and LSP functions defined by reserved labels.  

NH=> Agreed.  And when one considers the ethernet VPLS stuff over this there
will be a request to *turn-off* the ECMP since one cannot tolerlate
uni-directional failings here....and ECMP creates a richer environment for
this.  Bottom line is load-sharing is OKish within a *single* layer network
(like IP) but it will lead to problems if done over >1 layer network (ie
MPLS).  And of course it has, ergo the PID kludge.  Right answer of course
is to introduce proper p2p TE capabilities to bypass the SPF/IGP routes in a
known/consistent manner.

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. 

NH=> Dave I agree.....however, if we can one-day recognise mp2p merging as
'bad' then maybe we could properly set the OAM indicator where it really
should functionally reside....as part of the header.....say using the TTL
field which would now be effectively redundant (8 bits is way overkill
anyway).  In the meantime, I could live with your proposal if (i) it was
recognised as a fix to a problem lying elsewhere, with the ultimate goal of
removing the real problem at some stage and (ii) we simply use the PID
without the other CW stuff (which I regard as largely irrelevant for a
properly engineered/architecturally-valid MPLS network.....but if the Seq.
No. stuff stays then it *must* have entry/exit defect states and consequent
actions associated with it fully specified, it is unacceptable to leave this
open-ended IMO speaking as an operator).

Comments? 

cheers 
Dave

---

From: "David Allan" <[email-masked]>
Date: Thu, 17 Jul 2003 13:37:16 -0400

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

> From: Curtis Villamizar [mailto:[email-masked]] 
> Sent: Thursday, July 17, 2003 11:20 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: [email-masked]'
> Subject: Re: 'A' bit problem statement 
> 
> 
> 
> In message 
> <[email-masked]
> 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.
> > 
> > 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 
> 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
>