The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <0536FC9B908BEC4597EE721BE6A35389014CFD14@i2km07-ukbr.domain1.system
host.net>, neil.2.harrison@bt.com writes:
> > 
> > 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.

There is no intention to list all possible defects.  This is not the
ITU.

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

If you like we can change the prior sentence to:

   MPLS-ping is intended to detect forwarding faults which result in
   traffic failing to flow to the intended destination.

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

MIBs don't tell you what to do when you get a trap either.  That would
be out of scope.

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

MPLS-ping is never going to be all things to all people.  MPLS-ping
will compliment existing management capabilities provided by the MIB
(there is one MIB if I read a parallel thread correctly - and I dare
not get that wrong and risk provoking the wrath of the MIB doctors).

In the interest of making forward progress I suggest you put your
deployment experiences in the protocol experiences document when the
document advances from PS to DS.

Curtis