Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-02.txt]

From: "David Allan" <[email-masked]>
Date: Wed, 14 Nov 2001 12:55:43 -0500

Hi Ping:

I'm trying to place LSP-PING in the spectrum between detection and
diagnostic tools.

If it is detection, then it strikes me as somewhat slow, not somthing I'd
(for example) base protection switching on. If I try to switch quickly, then
I'm doing it on the basis of ICMP failures (which can generate a false
positive quite easily). If I switch authoritatively (avoiding false
positives), then I am looking at relatively long outages (10s of seconds, as
I need repeated ICMP failures to render the LSP as suspect, then some number
of LSP-PING timeouts to ensure that it is the LSP that failed). I note the
requirement to expedite LSP-PING handling in aware LSRs in 4.3.

If it is diagnostic, then it does relatively quickly tell me that the LSP is
genuinely and uniquely broken, but I need further tools to figure out the
resource that is messed up. Simply tearing down the LSP returns suspect
resources to the available pool in the network.

Is this a fair characterization of LSP-PINGs limitations?

BTW You mention the ability to test e2e MTU in the advertisment, but it does
not leap out in the text. I assume this is an ad-hoc use of the PING
mechanism (operator triggers MTU test and injects big LSP-PING packet into
LSP and observes if it works). Is this the case?

thanks
Dave

---

From: Ping Pan <[email-masked]>
Date: Thu, 15 Nov 2001 09:52:22 -0800

David,

David Allan wrote:

> If it is detection, then it strikes me as somewhat slow, not somthing 
> I'd (for example) base protection switching on. If I try to switch 
> quickly, then I'm doing it on the basis of ICMP failures (which can 
> generate a false positive quite easily). If I switch authoritatively 
> (avoiding false positives), then I am looking at relatively long outages 
> (10s of seconds, as I need repeated ICMP failures to render the LSP as 
> suspect, then some number of LSP-PING timeouts to ensure that it is the 
> LSP that failed). I note the requirement to expedite LSP-PING handling 
> in aware LSRs in 4.3.
> 

Do you imply that the root of the cause is due to the requirement to 
expedite LSP-ping handing on the intermediate routers?

> If it is diagnostic, then it does relatively quickly tell me that the 
> LSP is genuinely and uniquely broken, but I need further tools to figure 
> out the resource that is messed up. Simply tearing down the LSP returns 
> suspect resources to the available pool in the network.
> 

When we were looking into this problem at first, we were thinking along 
the line:" would that be nice to ping through a LSP?"

Normally, if something goes wrong inside the network, we (developers and 
operators) always want to 'ping' it or/and run 'show route', then figure 
out what to do next. So if there is a LSP is black-holing traffic, and 
the LSP is up and running in the routing table, we need to 'ping' the 
damn LSP. :-) I am not saying that LSP-ping can solve all the MPLS 
network problems, but it is a useful tool to provide some insight for 
the operators.

> BTW You mention the ability to test e2e MTU in the advertisment, but it 
> does not leap out in the text. I assume this is an ad-hoc use of the 
> PING mechanism (operator triggers MTU test and injects big LSP-PING 
> packet into LSP and observes if it works). Is this the case?
> 

Yes.

> Dave

Regards,

- Ping