The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

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

Reply in line....

<snip>

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

No, I simply note that there is an implementation recommendation to expedite propagating the LSP_PING cookie back to the ingress. I'd presume this is designed to reduce the time required to make an authoritative decision on the status of a suspect LSP, although I don't know if you can actually make any assumptions when picking the timeout for an LSP-PING response (e.g. you are only speeding up knowning its not broken).

>
> > 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.
>
So you think of it as more of a diagnostic aid...?

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