The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <4B6D09F3B826D411A67300D0B706EFDE84A480@nt-exch-yow.pmc-sierra.bc.ca
>, Shahram Davari writes:
> Curtis,
> 
> > 
> > LSP Ping does not require an RSVP-TE reverse path.  The ICMP echo
> > reply is delivered to the IP address of the sender.  Its and IP
> > packet.  It doesn't need an LSP but if one is there it can use it.
> > 
> > Curtis
> > 
> 
> I think you need to read the LSP-Ping draft one more time. I didn't say that
> The ICMP echo reply needs RSVP-TE reverse path, rather the LSP-ping response 
> requires
> RSVP-TE reverse path. The reason is that it needs a disjoint path from the no
> rmal
> IP hop-by-hop path, in order to determine that the ICMP-echo response path wa
> sn't at fault.
> 
> -Shahram


The reverse path for LSP-ping is the path needed to send a RESV
message back to the ingress.  A RESV is a type of RSVP packet which is
IP and does not need to and generally does not flow through an LSP.

Nowhere is a RSVP-TE reverse path specified for the ICMP (it is
explicitly stated otherwise) or for the LSP-ping reply.
The only use of the word reverse is:

   If the ingress LSR does not receive ICMP ECHO_REPLY messages from the
   egress for a long period of time, it is likely that there is an LSP
   failure on either the forward path (from ingress to egress) or the
   reverse path (from egress to ingress), or both.

This does not state that an RSVP-TE reverse path is needed.  The
reverse path is IP.

The first paragraph in "4.2. Procedures at the egress LSR" states:

   When the egress LSR receives an ICMP ECHO_REQUEST message, it handles
   the message according to the procedures defined in [ICMP] (this is
   irrespective of whether the message is used for an LSP liveliness
   test or not).  It is possible that the ICMP processing is entirely
   done by the hardware or in the IP fast data path, thus, the initial
   ICMP "ping" messages have little impact on control plane's
   performance.

The egress instructions for the LSP-Ping reply are:

   At the LSR's that support LSP-ping, the Resv messages that carry the
   LSP_ECHO object MUST be delivered upstream immediately.

   Note that an intermediate LSR using RSVP refresh reduction [RSVP-
   REFRESH], the new or changed LSP_ECHO object will cause the LSR to
   classify the RSVP message as a trigger message.

Note that this is an ordinary RESV message.  If this path back to the
sender did not exist, the RSVP-TE signaling used to set up the LSP
would fail.  This signaling does not go into a reverse RSVP-TE LSP.

The reverse path for either response is therefore an IP path.

I think you may need to reread the drafts.

Curtis