The MPLS WG Archive

[neil.2.harrison@bt.com]

Hi Curtis,  please see below.  regards, Neil
Curtis Villamizar wrote 12 December 2002 17:29

<snipped>
> > > DA=> I'm FAR from throwing my hands up in the air..... ;-) Just 
> > > trying to move
> > > the mountain (and some thinking). 
> > > 
> > > If I did not make it clear, for figuring out what went wrong 
> > > once yoou know
> > > somthing is wrong,
> > NH=> This is an important point.  The discussion would have 
> a far clearer
> > basis for comment/analysis if we first identified/agreed 
> all the failure
> > conditions we want to detect, and the consequent actions 
> that must be
> > activated on such.  Discussing nuances of ECMP and the 
> rights/wrongs of the
> > LSP-Ping protocol without having this clear separation of 
> (i) detection and
> > (ii) diagnostics as a bsis for discussion is not very helpful IMO.
> > <snipped to end>
> 
> 
> OK.  I think the following summarizes the intent.
> 
>    MPLS-ping is intended to detect forwarding faults
NH=> These are not defined anywhere that I know of except in Y.1710/1711.

> in an MPLS LSP
>    and isolate the fault to the LSR at which traffic stops flowing.
NH=> Not all defects will lead to traffic stopping flowing, eg traffic being
leaked out of an LSP due to unintended replication.

>    No attempt is made to determine that cause of the fault or diagnose
>    problems any further.
NH=> I think LSP-Ping does actually try and give some indications of the
nature of the defect, eg if the egress the pkt arrives at is a valid egress
or not for a given FEC.  However, no consequent actions are
specified......like telling affected client layers.

>  Since MPLS-ping "echo request" packets are
>    injected no further upstream than the ingress LSR, faults at the
>    ingress related to classifying and directing packets and
>    encapsulating them for placement in the LSP are not detected.
>    Since the MPLS-ping "echo request" packets are extracted no further
>    downstream than the egress LSR, faults at the egress in
>    decapsulating and directing traffic further are not detected.
>    Persistent faults in transiting the LSP, regardless of their cause,
>    can be detected and isolated to one or two LSR.
> 
> The document doesn't explicitly state what I have above but it only
> talks about detection and isolation.  For example:
> 
>    There are two parts to this
>    document: information carried in an MPLS "echo request" and "echo
>    reply" for the purposes of fault detection and isolation; and
>    mechanisms for reliably sending the echo reply.
> 
> If Kireeti adds this to the document we don't need to enumerate all
> possible faults before getting started.  I personally think it is
> obvious enough that it doesn't need to be stated but it won't hurt to
> add it.  If this doesn't satisfy you, please explain in greater detail
> what you would like to see discussed or in the document.
NH=> I am not sure we can actually do much more than this in the case of
mp2p (you can for p2p) due to the nature of the construct.  However, some
attempt should have been made to identify all the possible types of defect
to at least understand if these can be detected (or the limitations) and
what consequent actions should be taken (or the limitations).  These are
given in Y.1710 and simple solutions are given for the p2p case, and
draft-nadeau-ip-basedtool-requirements-00.txt also starts to identify these
too.  Further, if detects are to be detected/handled consistently (between
vendors/operators) then there should be deterministic behaviour of the
detection devices used.  This is a also a pre-cursor requirement for
defining consistent SLAs (where these are required by operators/customers),
as things like availability SLAs (though what this could posssibly mean in a
mp2p construct beats me) and up-state QoS SLAs are dependent on having
consistent defect detection/handling in the 1st place.  I don't think any of
this is simple (or even possible?) for mp2p constructs.