The MPLS WG Archive

[neil.2.harrison@bt.com]

Hello Robert....
> > one can detect the failure in the 1st place....so this does imply a
> > continuous detection process, 
> 
> Agree !
NH=> Good....at least we have 1 item of common ground now.
> 
> > and the Ping draft does not adequately address
> > this, 
> 
> Why not ? The continutiy of detection is provided by a 
> continues regular
> ICMP msg on all tested LSPs.
NH=> You should speak to my operational people about how much they love ICMP
as a detection/diagnostics tool even for IP......I'll introduce you to one
this week at IETF.  We wanted something much better for MPLS.  BTW - ICMP is
an IP layer OAM function.  If I extrapolate this cross-layer use of OAM
notion I could use any cient layer to detect defects on any server layer
(plenty of combinations possible here).  Point is this is not a correct arch
approach...I mean are you now going to say to the the people who manage OTNs
that fault detection starts with ICMP/IP then MPLS then SDH then OTN (say
using some combination of G.709 and/or LMP)?  Further, the client and server
layers can be owned by different domains operators/customers.....and it is
simply bad practice to expect to use a client layer OAM function to fault
manage a server layer network.
> 
> > nor does it cater for the mismerging case.
> 
> Yes, but I believe that this is due to the preference of the least cpu
> consumption as much as possible. It is not so rear that icmp 
> can be even
> processedon the line cards these days. Dealing with mpls 
> deployments for
> a last few years I have never seen a mismerged LSP ;).
NH=> Well if you can't detect it this is hardly surprising is it?  I have
already heard about cases of misdelivered VPN traffic.  Misconfigurations
(via human or HW/SW faults/bugs) of swapped/misbranching traffic have
happened in other technologies and they will happen again.  If we can find a
reasonably simply way to protect/detect/handle these events we should do so
now.....its harder to go back later and fix things. 

Broken 
> -- yes but
> not mismerged. So I am not sure how important that case is.
> 
> > Note - In order to be sure one can differentiate 
> outgoing/return status in
> > the Ping draft one needs to ensure diversity of the 
> data-plane of both
> > directions (and in case of return direction, I am talking about the
> > data-plane aspect of the control-plane here....since even a 
> control-plane
> > must have some data-plane).
> 
> That is in fact the good trick of ping's draft :). As the LSP 
> under test
> is up (the LSP-ping packets has arrived at the tail/sink of an LSP and
> intial ICMP failed) the failure is in the return data path somewhere
> from tail to head. So if the LSP is up the path taken by RSVP RESV msg
> must be up. Therefor appending the LSP_ECHO object into the 
> RESV msg for
> me seems as a quite clever way of making sure that the head will be
> notified of successful delivery of LSP-ping to the tail and therefor
> about OK condition for the LSP.
NH=> Having only just returned for a couple of weeks leave I have not had
time to properly discuss with colleagues here all possible scenarios.......I
saw some of the questions from Shahram last week on the list and maybe we
can also discuss further this week.  What I was saying above is that it
could be highly likely that both LSP directions fail together (and I am not
sure whether ICMP could be returned or not here under all cases) or perhaps
just the return LSP direction fails (for whatever reason, be this a
data-plane or control-plane (ie SW) misfunction)......so how are these
differentiated?  Seems in latter case outgoing LSPs have not failed and
should not be taken down, whereas in former case they have and should
be....we need to differentiate these cases wrt to appropriate consequent
actions.  However, I remain to be convinced that the scheme works correctly
under all defect cases. 
> 
> > NH=> Fine and thanks....hopefully we can now start to home 
> in a mutually
> > satisfactory solution.
> 
> Would be too great to happen ! My goal would be to at least understand
> well all of the proposals on the plate ;).
NH=> My goal too......and its clear from the questions I have seen raised
that people don't fully grasp all the nuances yet.  IMO a significant
problem here is (i) lack of agreed problem statement, (ii) (stemming from)
insufficient operator input on exactly what is required and (iii)
insufficient/poor and explanations in drafts.  Hopefully see you later this
morning.  Regards, Neil