The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Nov> msg00154



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

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

  • From: Ping Pan <pingpan@juniper.net>
  • Date: Thu, 15 Nov 2001 09:52:22 -0800
  • CC: mpls-list <mpls@UU.NET>
  • User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2

David,

David Allan wrote:

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


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.
> 
> Is this a fair characterization of LSP-PINGs limitations?
> 


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.


> thanks
> Dave
> 



Regards,

- Ping