The MPLS WG Archive

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

Curtis,



> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]
> Sent: Tuesday, December 18, 2001 11:09 AM
> To: Shahram Davari
> Cc: 'curtis@fictitious.org'; Ping Pan; Ash, Gerald R (Jerry), ALCTA;
> mpls@UU.NET
> Subject: Re: MPLSOAM BOF meeting draft minutes 
> 
> 
> 
> 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.

I know it is IP, but it actually follows the LSP, otherwise how could
you do label distribution?

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


By RSVP reverse path I meant RESV path, not a reverse LSP. Again I
repeat LSP-ping REQUIRES RSVP-TE because it uses RESV path.

> 
> I think you may need to reread the drafts.

Nice try!

-Shahram

> 
> Curtis
>