Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-01.txt]

From: Brijesh Kumar <[email-masked]>
Date: Wed, 25 Jul 2001 16:50:22 -0700

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

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

Cheers,

--brijesh
Corona Networks Inc.

> -----Original Message-----
> From: Ping Pan [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 8:54 AM
> To: mpls-list
> Subject: [Fwd: I-D ACTION:draft-pan-lsp-ping-01.txt]
> 
> 
> Hi,
> 
> Here is an updated version of LSP-ping. We have taken the suggestions
> from George and Sanjay.
> 
> Thanks!
> 
> - Ping
>

---

From: Ping Pan <[email-masked]>
Date: Wed, 25 Jul 2001 17:22:25 -0700

> Brijesh Kumar wrote:
> 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

---

From: Eric Osborne <[email-masked]>
Date: Thu, 26 Jul 2001 13:50:30 -0400

um...not a good idea to send questions like this to [email-masked].  :)
I'll answer this off-line.

eric

On Thu, Jul 26, 2001 at 09:41:43AM -0700, Gopal@Cisco wrote:
> 
> 
> HI All, For the following network scenerio;
> 
> TE.Head---OSPF Cloud-----ISIS Cloud-----TE.Tail
> 
> Customer wants to migrate OSPF network into the MPLS backbone and run 
> MPLS TE.
> Is this even possible?
> My question is  will the opaque Lsa's/TLV's  be redistributed during
> redistribution process. To clarify more, will ospf understand
> special-TLV's from ISIS and vice versa.
> 
> Any Input Highly Appreciated.
> 
> Thank You,
> Gopal

---

From: "Gopal@Cisco" <[email-masked]>
Date: Thu, 26 Jul 2001 09:41:43 -0700

Thank You,
Gopal