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 12:06 PM
> 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 
> <4B6D09F3B826D411A67300D0B706EFDE84A487@nt-exch-yow.pmc-sierra.bc.ca
> >, Shahram Davari writes:
> > 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?
> 
> So you agree that a RSVP-TE LSP in the reverse direction is not needed
> and that if the path did not exist for the RESV signaling to return to
> the ingress, then the LSP signaling would fail and we would have clear
> control plane indication of failure.  Good.  We're making progress.


I never said reverse LSP is needed in the first place.

> 
> > > 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.
> 
> And since the RESV Path must exist for the LSP to remain signaled you
> have no valid argument pertaining to the lack of a reverse path.
> Good.  We're making progress.

Your assumption: "RESV Path must exist for the LSP" is wrong. What about LDP, CR-LDP, BGP or even
configured LSPs that don't have RESV path. I think you are assuming everybody
MUST use RSVP-TE.

-Shahram


> 
> > > I think you may need to reread the drafts.
> > 
> > Nice try!
> 
> Thank you.
> 
> > -Shahram
> 
> Curtis
>