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

From: Shahram Davari <[email-masked]>
Date: Mon, 16 Jul 2001 11:32:40 -0700

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: Eric Gray <[email-masked]>
Date: Mon, 16 Jul 2001 15:55:06 -0400

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