Subject: RE: I-D ACTION:draft-pan-lsp-ping-00.txt

From: Shahram Davari <[email-masked]>
Date: Tue, 17 Jul 2001 07:52:47 -0700

Yakov,

> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Tuesday, July 17, 2001 9:59 AM
> To: Shahram Davari
> Cc: Dave Cooper; [email-masked]'
> Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt 
> 
> 
> Shahram,
> 
> > > > If by better approach you mean the refresh RESV messages, 
> > > > it may not be the a better approach. 
> > > > The LSP ping relies on the fact that if you are receiving 
> > > > refresh RESV messages, then the reverse 
> > > > RSVP path MUST be fine. Therefore if you send an LSP-ping 
> > > > and you don't receive the reply, the forwarding path 
> must be down.
> > > > 
> > > > So it is using refresh RESV message as "alive" protocol. 
> > > > This I argue is not the best choice, because:
> > > > 
> > > > 1) Refresh frequency may not be good enough, specially when 
> > > > refresh reduction is used. So when you
> > > > think that the RSVP reverse path is fine, it might in fact 
> > > > be down, because your information might 
> > > > not be up to date.
> > > 
> > > Shahram,
> > > 
> > > Not true. In the draft, it says:
> > > 
> > > ...
> > > 6.3. Procedures for the intermediate LSR's
> > > 
> > >    At the LSR's that support LSP-ping, the Resv messages that 
> > >    carry the LSP_ECHO object must be delivered upstream 
> immediately.
> > > 
> > >    At LSR's that use RSVP refresh reduction, a Resv 
> message that carries
> > >    an LSP_ECHO object should be considered as a trigger 
> message, and
> > >    should be processed according to the procedures 
> defined in [RSVP-
> > >    REFRESH].
> > > ...
> > 
> > I am talking about a different issue. Assume that at time "t" the
> > RESV refresh (with interval "T") is received by the ingress LSR.
> > Now assume that at time "t+x" in which t+x<t+T, both the reverse
> > LSP and the RESV path fail (this can happen for example if both
> > the RESV message and the reverse LSP are transmitted from the same
> > line-card in the egress LSR and that line-card fails). The 
> information
> > that you have at time t+x is that there is a failure, but the RESV
> > path is fine. So you start sending LSP-ping and you don't receive
> > any LSP-ECHO, therefore you reach to a false conclusion that the
> > forward LSP is down.
> 
> If you don't receive any LSP-ECHO then you may conclude that either
> the forward LSP is down, or the control channel used by RSVP 
> (or to be more precise by RESV) to set up the LSP is down. 
> 

Which is a useless information, because the whole point of the LSP-ping was to
find whether the fault is in forward LSP or not ! 

-Shahram

> Yakov.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 17 Jul 2001 08:03:52 -0700

Shahram,

> find whether the fault is in forward LSP or not !

Notice what the draft says:

   In the case where an LSP has failed to deliver user traffic, and the
   failure cannot be easily detected by the MPLS control plane (and
   specifically, RSVP-TE component), 

So we do assume that the RSVP-TE control plane is up and running fine
otherwise there would be no point of even sending icmp msg over failed
LSP. Having this in mind not receiving of LSP_ECHO in RSVP RESV msg IMHO
clearly identifies the failure of forward LSP under test.

R.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 17 Jul 2001 11:42:54 -0400

>clearly identifies the failure of forward LSP under test.

         Just to clarify the assumption made above. If the control
plane is down, you should be notified pretty quickly that this
is the case by one of the signaling protocols.

         --Tom