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

From: Shahram Davari <[email-masked]>
Date: Mon, 16 Jul 2001 13:57:06 -0700

Hi Eric,

> -----Original Message-----
> From: Eric Gray [mailto:[email-masked]]
> Sent: Monday, July 16, 2001 4:20 PM
> To: Shahram Davari
> Cc: 'Ping Pan'; 'Yakov Rekhter'; [email-masked]'
> Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt
> 
> 
> Shahram,
> 
>     It's one thing to use ping to check the integrity of a link,
> and quite another to use it as an 'alive' protocol.  Isn't there
> a better approach than this?

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.
2) It can't be applied to LDP and CR-LDP and static configured LSPs.

Yours,
-Shahram 

> 
> --
> Eric Gray
> 
> You wrote:
> 
> > Hi Eric,
> >
> > > -----Original Message-----
> > > From: Eric Gray [mailto:[email-masked]]
> > > Sent: Monday, July 16, 2001 3:55 PM
> > > To: Shahram Davari
> > > Cc: 'Ping Pan'; 'Yakov Rekhter'; [email-masked]'
> > > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt
> > >
> > >
> > > Shahram,
> > >
> > >     I was just talking to someone (off-line) about something
> > > that is obliquely related to this.
> > >
> > >     Your suggestion will not work because the ping in the reverse
> > > direction traverses an equally long LSP with (presumably) an
> > > equal probability of a return path failure.
> >
> > But I don't care about return path failure of the reverse 
> LSP, because
> > in the method that I suggested, the ingress LSR checks to 
> see whether
> > it is receiving the ICMP (not ECHO) messages over the 
> reverse LSP periodically,
> > and if it is, it means that the reverse LSP is fine.
> >
> > Example:
> >
> >  /---E----\
> > A----B----C
> >  \---D----/
> >
> > Ingress LSR: A
> > Egress LSR: C
> > Forward LSP: ABC
> > Reverse LSP: CDA
> > Return of the reverse LSP: AEC
> >
> > 1)LSR A sends ICMP over ABC, and the ICMP Echo comes back 
> through CDA
> > 2)LSR B sends ICMP over CDA, and the ICMP Echo comes back 
> through AEC
> > 3)LSR A checks to see whether it is receiving any ICMP from 
> C, regardless
> > of the status of the return LSP of the reverse LSP (i.e. AEC)
> > 4)If so Any failure to receive ICMP Echo from C for LSP=ABC 
> is due to
> > reverse path (CDA) failure.
> >
> > Yours,
> > -Shahram
> >
> >   Therefore, there is an
> > > issue with non-terminating recursion in LSP integrity checking.
> > >
> > >     If you could reduce the length of the LSP by at least one hop
> > > in each successive recursion, the recursion would terminate.  I
> > > think this is may be the under-lying advantage to the approach
> > > suggested earlier by Eric Rosen: if you send a ping response
> > > using UDP, the integrity 'recursion' is terminating as long as
> > > the UDP packet does not immediately (as in at the output port
> > > of the responder) get injected into an LSP.  Even if the UDP
> > > packet is subsequently injected inbto an LSP that terminates
> > > at the original ping sender, this LSP is going to contain 
> (at least
> > > one) fewer hops than the LSP being verified by the original ping
> > > - and this LSP's integrity is presumably testable by a similar
> > > means.
> > >
> > >     Admittedly, there is the pathological case in which 
> each return
> > > LSP is at least as long as the LSP being verified - but this seems
> > > like an extreme exception and brings the alleged integrity of the
> > > control plane into serious doubt as well. So, if you assume that
> > > each LSP integrity checking 'ping' response starts out as a plane
> > > old UDP message that might be injected subsequently into a
> > > 'shorter' LSP, the integrity checking recursion will terminate and
> > > the ultimate integrity of the original LSP can be verified.
> > >
> > > --
> > > Eric Gray
> > >
> > > You wrote:
> > >
> > > > Ping,
> > > >
> > > > Thanks for your reply. I have a fundamental question:
> > > >
> > > > If all you are looking for is whether the reverse path is
> > > functional or not why not do the following:
> > > >
> > > > By running periodic ICMP pings over the reverse path, the
> > > ingress LSR could find whether the reverse path is functional
> > > or not. This can be done by the ingress LSR checking whether
> > > it is receiving reverse' path ICMP pings regularly that have
> > > source addresses equal to the destination address of the
> > > forwarding path ICMP Ping. And therefore can find whether a
> > > failed ICMP ping over the forwarding path is due to
> > > forwarding path failure or reverse path failure.
> > > >
> > > > What is wrong with this approach as compared to LSP-ping.
> > > >
> > > > -Shahram
> > > >
> > > > > -----Original Message-----
> > > > > From: Ping Pan [mailto:[email-masked]]
> > > > > Sent: Monday, July 16, 2001 12:23 PM
> > > > > To: Shahram Davari
> > > > > Cc: 'Yakov Rekhter'; [email-masked]'
> > > > > Subject: Re: I-D ACTION:draft-pan-lsp-ping-00.txt
> > > > >
> > > > >
> > > > > Shahram Davari wrote:
> > > > > >
> > > > > > Hi Yakov,
> > > > > >
> > > > > > Good suggestion. However, I think due to periodic
> > > > > transmission of ping packets, and due
> > > > > > to possibility of many LSPs being pinged at the same time,
> > > > > the processing overhead of UDP/IP
> > > > > > is large and may limit the scalability.
> > > > >
> > > > > Shahram,
> > > > >
> > > > > That's why we choose a two-step ping: ICMP ping's 
> followed by LSP
> > > > > ping's. Normally, the ingress sends the regular ICMP
> > > ping's to check
> > > > > LSP's. Only when there is no reply on ICMP ping's, LSP-ping
> > > > > messages are
> > > > > sent to detect if the failure is on the forwarding or the
> > > reverse LSP.
> > > > > The reason for using UDP is to allow the egress LSR's to
> > > regulate the
> > > > > LSP-ping traffic.... Don't think there is a scalability
> > > problem here.
> > > > >
> > > > > > Using another reserved label for Ping
> > > > > > (or OAM packets in general) could eliminate the use of
> > > > > UDP/IP and could reduce the processing burden at
> > > > > > the egress LSR.
> > > > > >
> > > > >
> > > > > How? At egress, ping packets need to be processed anyway. You
> > > > > still have
> > > > > to somehow limit the amount of probing traffic.
> > > > >
> > > > > BTW, I will add the idea of using Explicit IPv4 NULL for
> > > > > non-IP traffic
> > > > > in the next version.
> > > > >
> > > > > - Ping
> > > > >
> > >
>

---

From: Ping Pan <[email-masked]>
Date: Mon, 16 Jul 2001 15:00:50 -0700

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

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