The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Title: RE: [I-D ACTION:draft-pan-lsp-ping-00.txt]

Eric:

I do agree that a useful OAM echo request contains an identifier of the ingress (level specific), some form of correlation I.D. (for matching responses) and a means of identifying the specific LSP (or as you note for LDP, the LSP's raison d'etre). Your "off the cuff" description requires the sort of flexibility we believe any useful OAM messaging solution will require and incorporated into our OAM messaging draft (draft-azad-mpls-oam-messaging).

However, I am not a fan of a hop-by-hop return along the control path. To date we've have seen an interesting menagerie of OAM return paths:

        - each LSP inherently has a reverse NHLFE mapping (the reverse notification tree approach/chang).
        - each LSP has an ingress IP address carried in the OAM messaging (ping, bonica) which maps to either control or

        payload level return.
IMHO all these approaches have questionable scaling, and/or limited applicability.

I'd like to suggest that the most useful/scalable return path definition fits squarely between the two approaches brought forward to date. OAM messaging carries an ingress identifier that the recipient can map to an FEC and hence to user plane connectivity back to the ingress. I can envision scenarios where depending on a robust control plane has advantages once a suspected problem is being escalated, but as a first line of defence, it will fall over very quickly.

cheers
Dave

-----Original Message-----
From: Eric Rosen [mailto:erosen@cisco.com]
Sent: Monday, July 23, 2001 12:34 PM
To: Ping Pan
Cc: mpls-list
Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt]

Having now been convinced of the  need to have the echo response travel back
along the path  of label distribution, piggybacking it  on the control plane
messages  does  seem  to  make  sense.   The alternative  is  to  devise  an
independent transport  method which follows the control  plane reverse path.
This  is probably  more complicated,  given that  we have  only  two control
planes.

So here's my  off-the-cuff suggestion for doing the same  kind of thing with
LDP. 

The LSP-ping message  should be able to carry an  echo object which contains
(a) an  identifier of  the ingress,  and (b) an  LDP FEC  TLV.  (And  also a
sequence number,  I think, to aid  in matching responses  to requests.)  The
LDP FEC  TLV is the one  corresponding to the  LSP on which the  LSP-ping is
being sent.

When the LSP-ping message reaches  the egress, the echo object is extracted,
and given to LDP to be treated as an attribute (TLV) of the FEC it contains.
The egress then  sends a label mapping message for  that FEC, containing the
echo object.  This should  be sent to each LDP peer to  which the egress has
previously distributed  a label  (most likely the  implicit NULL  label) for
that FEC.  The egress then forgets about the response TLV.

When a  label mapping  message for  a particular FEC  is received,  and that
message contains an echo response TLV, then:

- if the  mapping message is not  from the next  hop for that FEC,  the echo
  response TLV is ignored;

- if the mapping message IS from the next hop for that FEC,

  * if the  LSR is not the ingress  node identified in the  echo object, the
    LSR  sends a label  mapping message  for that  FEC, containing  the echo
    object, to each LDP peer to  which it has previously distributed a label
    for that FEC  (except the one from which it  received this message); the
    LSR then forgets about the TLV.

  * if the LSR is the ingress node identified in the echo object, it matches
    the echo object  up to a particular LSP-ping and  treats the LSP-ping as
    having been properly responded to.

This procedure  is little different than  the procedure used to  pass up the
MTU or path vector TLVs upstream.   As in the RSVP-TE scheme, if the control
plane is operating properly, the TLV will make it upstream properly.

This works  fine in the  multipoint-to-point case, at  least as long  as one
isn't pinging an egress from several  ingresses at once.  To handle the case
where there  are multiple outstanding  pings (from different  ingresses), we
either need to allow multiple echo  TLVs in a mapping message, or perhaps we
only need to define which of several  echo TLVs is the one which gets passed
upstream.