Subject: RE: LSP-ping

From: Shahram Davari <[email-masked]>
Date: Wed, 18 Jul 2001 06:17:59 -0700

Hi Eric (Gray),

Thanks for your explanation. I fully understand that LSP-ping is not used as alive protocol. As I understand it, this draft suggests ICMP-ping is used as alive protocol, in the forward direction. My suggestion was simply to use the same method (ICMP-ping) as alive protocol for the reverse direction too.

I understand that this may require running ICMP-ping from every egress router to all relevant ingress routers, but it should not cause any scaling problem, because the number of reverse ICMP-pings is independent of the number of LSPs. In fact it is a small fraction of the number of LSPs.

Now if there is an LSP from the egress LSR to the ingress LSR (reverse LSP), and if that LSP is also a candidate for connectivity test, then according to this draft we should run ICMP-ping over that LSP. If we do so then we don't need to run another instance of ICMP-ping on the reverse direction. In other words we could save some overload.

Yours,
-Shahram

> -----Original Message-----
> From: Eric Gray [mailto:[email-masked]]
> Sent: Tuesday, July 17, 2001 5:03 PM
> To: [email-masked]
> Cc: Shahram Davari; [email-masked]'
> Subject: Re: LSP-ping
> 
> 
> Eric,
> 
>     The thrust of Shahram's proposal is that the egress LSR would
> normally be pinging the ingress LSR.  This was why I asked him if
> there wasn't a better approach than using ping as an alive protocol.
> ===================================================
> 
> Shahram,
> 
>     As I understand it (based in part on the partial dialog 
> between Ping
> Pan and George Swallow), Ping's proposal is not an attempt to use
> LSP ping as an alive protocol, but rather an additional tool 
> to use when
> normal ping is not working.  If I am mis-representing the 
> dialog, I offer
> my apologies, but - if this is in fact what is proposed - it 
> at least has
> this advantage over your proposal.
> 
> --
> Eric Gray
> 
> You wrote:
> 
> > Shahram> My suggestion is different. The ingress LSR checks 
> the connectivity
> > Shahram> status  of  the reverse  LSP,  by checking  to  
> see  whether it  is
> > Shahram> receiving  ICMP-pings from  the  egress  LSR. If  
> it  is, then  the
> > Shahram> reverse LSP is fine, and  any failure to receive 
> ICMP-Echo from the
> > Shahram> egress LSR is due to forward LSP.
> >
> > Presumably, the egress  LSR is not normally pinging the  
> ingress LSR, so I'm
> > not sure  just what you mean.   (If all LSP egresses  are 
> constantly pinging
> > all LSP ingresses, then I think we have a scaling problem.)
> >
> > If the problem one is investigating  is that there appear 
> to be data packets
> > that reach the LSP ingress but get  lost before they reach 
> the LSP egress, I
> > don't think one wants a diagnostic  tool that depends on 
> one's being able to
> > explicitly control  the egress.  So telling  the egress to  
> ping the ingress
> > (and then monitoring  the ingress to see if the  pings are 
> received) doesn't
> > seem like the best strategy.
>

---

From: Eric Rosen <[email-masked]>
Date: Wed, 18 Jul 2001 09:55:55 -0400

Sharam> I  understand that  this may  require running  ICMP-ping  from every
Sharam> egress router  to all  relevant ingress routers,  but it  should not
Sharam> cause any scaling problem,

This is basically  the procedure of having all routers  in a network pinging
all other  routers in the network,  which was first denigrated  as a scaling
problem  about 20  years ago.   I don't  think it's  a good  idea to  have a
troubleshooting procedure  which depends, for  its utility, on this  kind of
continuous pinging.