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

From: Shahram Davari <[email-masked]>
Date: Tue, 17 Jul 2001 10:35:54 -0700

George,

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

Sure. But I am talking about the time period before we start sending
LSP-ping and receiving LSP-Echo. I am talking about the time period
during which we are sending ICMP-ping and receiving ICMP-Echo. Since
ICMP-ping/Echo is not a trigger for refresh RESV, then during this
time interval you rely on the usual 30 sec/hop refresh. Therefore if 
during this interval both the RESV path and reverse LSP fail, we
will notice a missing ICMP-Echo but we have no knowledge that the RESV
 path has failed unless we wait for another refresh RESV message or may
 be trigger an early RESV message (using methods other than LSP-ping!!). Because
if we use LSP-ping to cause an early RESV message, and we don't receive that
RESV message, then we won't know whether the failure was in forward LSP
or in RESV path.

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

---

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

Shahram -

> RESV message, then we won't know whether the failure was in forward LSP

So your scenario is that the RSVP control plane and the reverse data
plane fail at the same time?  And the control plane fails in a way
that the headend is not notified quickly?  Is this a case worth
worrying about?  Yes the LSP-tunnel ping will fail.  The operator will
get notified that there is a problem.  And he does indeed have a
problem...having an alarm go off for the wrong reason is much better
than no alarm.

And unless you're trying to do some form of non-stop forwarding over
the failure of an intermediate node, then one can argue that you do
have a problem with the LSP under test as well.

And if are doing some form of non-stop forwarding then the operations
staff should be aware of it and know to look for problems in the
control plane as well.

...George