The MPLS WG Archive

[Ping Pan <pingpan@juniper.net>]

David,

David Allan wrote:

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


LSP-ping uses a two-step query sequence: first use ICMP-ECHO-REQUEST. If 
no response, use LSP-ECHO. One of the reasons for a such design is to 
control processing overhead at the egress. We assume ICMP-ECHO-REQUEST 
packets are always easier to handle than LSP-ECHO.

When to generate those query messages is up to the users (just like the 
'ping' command). If they want to run it in the background, I hope they 
can use a large time interval. If they need to find out the problem 
faster, send a storm (like 'ping -f'). To define the protocol, we cannot 
specify the actual time values (I tried, and Dave Cooper told me to get 
lost. :-)).

> So you think of it as more of a diagnostic aid...?
> 


Actually, does it matter? :-)

Thanks!

- Ping