The MPLS WG Archive[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]
Title: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-02.txt] 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
|
|