The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Dec> msg00264



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

MPLSOAM BOF meeting draft minutes

  • From: Curtis Villamizar <curtis@workhorse.fictitious.org>
  • Date: Tue, 18 Dec 2001 12:06:13 -0500
  • cc: "'curtis@fictitious.org'" <curtis@fictitious.org>, Ping Pan <pingpan@juniper.net>, "Ash, Gerald R (Jerry), ALCTA" <gash@att.com>, mpls@UU.NET


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.

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

> > I think you may need to reread the drafts.
> 
> Nice try!

Thank you.

> -Shahram

Curtis