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

From: Shahram Davari <[email-masked]>
Date: Tue, 17 Jul 2001 08:36:20 -0700

Hi,

> -----Original Message-----
> From: Robert Raszuk [mailto:[email-masked]]
> Sent: Tuesday, July 17, 2001 11:04 AM
> To: Shahram Davari
> Cc: 'Yakov Rekhter'; Dave Cooper; [email-masked]'
> Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt
> 
> 
> Shahram,
> 
> > > 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 !
> 
> 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. 

So let me see if I understand this correctly. What you are trying to say is that
first we select an LSP for connectivity test. Then we check to see that we are receiving
the RESV messages with refresh interval "T". Then we run ICMP-ping messages until we don't receive ICMP-Echo back. At this time we wait for a period of "T" to see whether we receive another RESV message or not. If we don't, this means that the RESV path is down, otherwise the RESV path is fine and we can now run LSP-ping. And if we don't receive LSP-Echo back, this means that the forward LSP is down. Right?

If this is correct then you probably have noticed the delay time "T" between detecting a failure and isolating it to the forward LSP. My point was that this time interval may
be large specially when refresh reduction is used.

-Shahram

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: Robert Raszuk <[email-masked]>
Date: Tue, 17 Jul 2001 08:51:05 -0700

Shahram,

As Thomas just said for failure of control plane we will use RSVP Tear
msgs (case of unprotected lsp by frr) so the head will know immediately
of the failure.

> the RESV messages with refresh interval "T". Then we run ICMP-ping messages 
> until we don't receive ICMP-Echo back.

In your description I don't see why waiting for reception of next rsvp
resv msg is required for triggering the ICMP test in the first place.

R.

> Shahram Davari wrote:

---

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

Shahram,

Why are you talking about the refresh interval here? Did we write a
single word that defines the timing intervals in the draft? No!

Shahram Davari wrote:
> first we select an LSP for connectivity test. Then we check to see that we are 
> receiving the RESV messages with refresh interval "T". Then we run ICMP-ping messages
> until we don't receive ICMP-Echo back. At this time we wait for a period of "T" to see 
> whether we receive another RESV message or not. 

Maybe, maybe not. Another situation is to send the LSP-ping packets
immediately while monitoring the LSP states.

> If we don't, this means that the RESV path 
> is down, otherwise the RESV path is fine and we can now run LSP-ping. And if we don't 
> receive LSP-Echo back, this means that the forward LSP is down. Right?
> 
> If this is correct then you probably have noticed the delay time "T" between detecting 
> a failure and isolating it to the forward LSP. My point was that this time interval may

T is an independent parameter.

- Ping

---

From: George Swallow <[email-masked]>
Date: Tue, 17 Jul 2001 12:41:09 -0400

> If this is correct then you probably have noticed the delay time "T"
> between detecting a failure and isolating it to the forward LSP. My
> point was that this time interval may be large specially when refresh
> reduction is used.

Refresh reduction defines a trigger message.  The presence of a new or
changed LSP_ECHO object will cause an immediate refresh.  So without
refresh reduction it could take 30 secs / hop (default).  With refresh
reduction it should be very responsive.

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824