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

From: Shahram Davari <[email-masked]>
Date: Tue, 17 Jul 2001 06:42:25 -0700

Hi Ping,

> -----Original Message-----
> From: Ping Pan [mailto:[email-masked]]
> Sent: Monday, July 16, 2001 6:01 PM
> To: Shahram Davari
> Cc: Dave Cooper; [email-masked]'
> Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt
> 
> 
> Shahram Davari wrote:
> > 
> > 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.

Yours,
-Shahram

> Since a RESV message contains a new object, LSP_ECHO, the RESV is a
> trigger message, and must be forwarded immediately on the links that
> support refresh reduction. In fact, using exponential backoff 
> timers and
> ack-extension defined in RFC2961, trigger messages can be 
> delivered fast
> and reliably to the next hop. In other words, the LSP-ping replies go
> back to the headend LSR pretty fast.
> 
> - Ping
>

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 17 Jul 2001 06:58:59 -0700

Shahram,

> > > and you don't receive the reply, the forwarding path must be down.
> > > 
> >    carry the LSP_ECHO object must be delivered upstream immediately.
> > 
> >    At LSR's that use RSVP refresh reduction, a Resv message that carries
> 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. 

Yakov.

---

From: Ping Pan <[email-masked]>
Date: Tue, 17 Jul 2001 09:05:18 -0700

Shahram,

First, if RSVP-TE detects a failure inside the network, it must send
error messages to notify the ingress LSR's. Second, we only determine
the forwarding LSP is down if the ingress does not receive the
echo-replies via RESV.  In your example, if the failure takes place at
t+x, the ingress would either know it via PathErr, or by the fact that
no replies from the egress AFTER t+x.

LSP-ping works fine here.

- Ping