Subject: Re: LSP-ping

From: Eric Rosen <[email-masked]>
Date: Tue, 17 Jul 2001 15:15:18 -0400

Shahram> Could anybody  explain to me  what is wrong with  running ICMP-ping
Shahram> over the both the forward and reverse LSP?  

This won't help you determine which of these two LSPs has failed, since each
ICMP-ping uses both LSPs. 

A mechanism which uses ONLY the LSP that is being tested seems worthwhile as
a fault isolation tool, and that's really what LSP-ping offers you. 

As you've  pointed out, the  mechanism only returns useful  information when
the control plane is functioning  properly.  What the mechanism really tells
you is that somewhere along the line, some LSR has a corrupt label switching
table, where  "corrupt" may be defined as  "what's in the table  is not what
the control plane thinks is in there". 

Although  I  think  this  mechanism   is  useful,  I'm  not  convinced  that
piggybacking the response in the control messages is necessary or desirable,
and I plan to look at alternative mechanisms for returning the response.

---

From: Ping Pan <[email-masked]>
Date: Tue, 17 Jul 2001 12:15:33 -0700

Shahram Davari wrote:
> 
> Hi,
> 
> Could anybody explain to me what is wrong with running  ICMP-ping over the both the forward and reverse LSP?
> 

If the reserve path has multiple LSP's and one of them is down, how can
you tell if the forwarding LSP (the one operators are interested in) is
up or down?

---

From: Ping Pan <[email-masked]>
Date: Tue, 17 Jul 2001 12:24:57 -0700

> If the reserve path has multiple LSP's and one of them is down, how can
         ^^^^^^^
reverse

---

From: Shahram Davari <[email-masked]>
Date: Tue, 17 Jul 2001 11:46:04 -0700

Hi,

This method has a number of advantages over using LSP-ping in combination with RESV message:

1) Is more generic: Can be applied to all types of LSPs; RSVP-TE LSPs, CR-LDP LSPs and static configured LSPs.
2) Can have quicker response time than RSVP, and is independent of RSVP timers. 
3) Does not need a new protocol: LSP-ping.

Yours,
-Shahram

---

From: Lei Yao <[email-masked]>
Date: Fri, 20 Jul 2001 16:55:02 -0400

We really need to let the authors clarify the motivations for LSP ping. It
seems to me that the following description from Eric is really the biggest
motivation to use LSP ping.
> a fault isolation tool, and that's really what LSP-ping offers you.

We would like to detect the failure of a specific LSP. However, one LSP
fails on a router does not necessarily mean that the whole data plane on the
router fails. Even when the whole dataplane on a router fails, most likely
control messages (such as RESV messages) can not be delivered either except
control messages use a totally different network from data packets.

Although it is implied, the draft did not describe how to guarantee that a
LSP ping for a specific LSP is forwarded through the designated LSP. It
requires the ingress LSR to add the appropriate label to a LSP ping/UDP
message. It also requires that  intermediate LSRs not try to IP forwarding
the LSP/ping UDP packet in case that label switching of the packet fails,
which may not be true in many cases.

Lei
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Eric
Rosen
Sent: Tuesday, July 17, 2001 3:15 PM
To: Shahram Davari
Cc: [email-masked]'
Subject: Re: LSP-ping