Subject: RE: LSP-ping

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

Eric,

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Tuesday, July 17, 2001 3:15 PM
> To: Shahram Davari
> Cc: [email-masked]'
> Subject: Re: LSP-ping 
> 
> 
> 
> Shahram> Could anybody  explain to me  what is wrong with  
> running ICMP-ping
> Shahram> over the both the forward and reverse LSP?  
> 
> This won't help you determine which of these two LSPs has 
> failed, since each
> ICMP-ping uses both LSPs.

My suggestion is different. The ingress LSR checks the connectivity
status of the reverse LSP, by checking to see whether it is receiving
ICMP-pings from the egress LSR. If it is, then the reverse LSP is fine, and
any failure to receive ICMP-Echo from the egress LSR is due to forward LSP. 

-Shahram

> A mechanism which uses ONLY the LSP that is being tested 
> seems worthwhile as
> a fault isolation tool, and that's really what LSP-ping offers you. 
> 
> As you've  pointed out, the  mechanism only returns useful  
> information when
> the control plane is functioning  properly.  What the 
> mechanism really tells
> you is that somewhere along the line, some LSR has a corrupt 
> label switching
> table, where  "corrupt" may be defined as  "what's in the 
> table  is not what
> the control plane thinks is in there". 
> 
> Although  I  think  this  mechanism   is  useful,  I'm  not  
> convinced  that
> piggybacking the response in the control messages is 
> necessary or desirable,
> and I plan to look at alternative mechanisms for returning 
> the response.
> 
> 
>

---

From: Eric Rosen <[email-masked]>
Date: Tue, 17 Jul 2001 15:54:49 -0400

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 Gray <[email-masked]>
Date: Tue, 17 Jul 2001 17:03:11 -0400

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

---

From: Peter Willis <[email-masked]>
Date: Wed, 18 Jul 2001 10:29:51 +0100

Colleagues,

Perhaps the draft-pan-lsp-ping-00.txt can be modified to make it more clear 
that this is a DIAGNOSTIC tool used AFTER the LSP has failed to deliver user 
traffic. The draft says this clearly in Section 4 "Motivation" but does not
make this clear in the Abstract and Section 3 where it says 
"This document describes a simple and efficient mechanism that can be
   used to detect data plane failures in MPLS LSP's"

I think instead of saying "used to detect data plane failures" it should say
"used to diagnose data plane failures".

If this wording was changed I would be a lot happier with this draft.

Then I can go on to point out that the actual DETECTION mechanism used by this 
draft is the customer, that is the customer notices connectivity has failed 
and this triggers diagnostics. So we still need a mechanism to detect LSP 
failure.

--------------------------------------------------------------------------------
Peter Willis                                          [email-masked]
IP Technology Strategist                              Phone: +44 (0)1473 645178 
Chief Technology Office                               Fax: +44 (0)1473 644506
BTexact Technologies.
PP3, RSB10, Adastral Park, Martlesham, Ipswich IP5 3RE, UK.
--------------------------------------------------------------------------------