The MPLS WG Archive

[Ping Pan <pingpan@juniper.net>]

> Brijesh Kumar wrote:
> 
> From this draft:
> 
>    When the ingress LSR suspects that the LSP may have failed and the
>    RSVP control plane shows the LSP as operational, the ingress LSR
> MUST
>    send LSP-ping messages to the egress over the LSP, periodically.
> The
>    value of the time interval should be configurable.
> 
> Could you please tell me what do you mean by "LSR suspects"? In other
> words,
> what is the triggering input for LSR to start "suspecting" the LSP may
> have failed?
> 
> It will be better if you replace "suspect" with "detect" in your draft
> as suspect is an imprecise human emotion and no operator would like
> routers that have negative emotions ;-).
> 

It's network operators suspect something may have gone wrong with some
LSP's....

> In addition, I do have issues with introducing a mechanism dependent
> on a particular signalling protocol for a generic problem - testing
> liveness of the label switched data path. 

OK. Do you have problem with the mechanism itself?

> Secondly, can we have some
> input/justification with regards to the assumption that there is a
> need to detect such a failure since only cause for such a failure
> given in the draft is "memory Corruption". What causes so called
> memory corruption? Are we trying to repair badly written code here?
> 

The problem did happen in the real network. I'm not going to point
fingers on the cause of the problem. But we (vendors and providers) did
realize from that incidence that we need to have a simple mechanism to
check LSP's data plane in today's operational networks.

The whole purpose on various proposals (fast reroute, graceful restart
and LSP-ping) is to make the whole network working nicely, even when we
have routers from other vendors that have badly written code.

- Ping