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

From: Ping Pan <[email-masked]>
Date: Fri, 06 Jul 2001 22:39:00 -0700

Here is a draft on checking MPLS data plane. It would be a useful tool
for network operators. 

Please let us know if it makes sense.

Thanks!

- Ping :-)

Subject: I-D ACTION:draft-pan-lsp-ping-00.txt
From: [email-masked]
To: IETF-Announce: ;;:;
Date: Thu, 05 Jul 2001 06:52:56 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Detecting Data Plane Liveliness in RSVP-TE
	Author(s)	: P. Pan, N. Sheth, D. Cooper
	Filename	: draft-pan-lsp-ping-00.txt
	Pages		: 7
	Date		: 03-Jul-01
	
This document describes a simple and efficient mechanism that can be
used to detect data plane failures in MPLS LSP's. The proposed
mechanism requires a new optional RSVP object.  The processing
overhead imposed on LSR control plane is kept to minimum.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pan-lsp-ping-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-pan-lsp-ping-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-pan-lsp-ping-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: George Swallow <[email-masked]>
Date: Mon, 09 Jul 2001 15:37:07 -0400

Ping -

Totally agree that something along these lines is necessary.

Some comments:

The draft should say explicitly that the Echo and LSP-Ping messages
are sent down the LSPs.

If you have multiple LSPs between two nodes then it may be hard to
determine that an LSP has failed, since you will get Echo-Reply
messages from the other tunnels.  The draft should recommend use of
the Identifier field in the Echo message in this case.  

You don't give a message type for the LSP-ping.  Were you thinking of
a new message?  Perhaps the Notify message could be used?

There needs to be a means of clearing the LSP-echo object from the
RESV message.  (So that the test can be repeated at a later point).
I would simply add a timer that gets set when you first insert the
LSP-ping object in the RESV message and renewed each time you receive
a subsequent LSP-ping message.  Once the messages cease, the timer
will fire and you then send a RESV message without the LSP-ping
object.

You might add a note to the intermediate node processing that says
the text in only there to emphasize good practice.  It doen't really
impose any new requirements.

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: Ping Pan <[email-masked]>
Date: Mon, 09 Jul 2001 19:00:53 -0700

> Totally agree that something along these lines is necessary.

George,

Thanks.

> The draft should say explicitly that the Echo and LSP-Ping messages

OK.
 
> the Identifier field in the Echo message in this case.

When using LSP-ping, as we mentioned in 5.1, the echo message should
have enough information to identify an LSP. That implies, the message
will have RSVP Session and Sender-Template objects. I will articulate it
more explicitly soon.

> a new message?  Perhaps the Notify message could be used?

For LSP-ping messages, the echo packets are encapsulated in UDP with a
well-known port number. At the egress, the LSR picks up the echo by
"listening" to the UDP port, and replies them back in Resv. I didn't
consider the Notify message.... Let me think about it.
 
> will fire and you then send a RESV message without the LSP-ping

Interesting. How do I inform the egress about the timer? In the first
LSP-ping message, or Path? And how do I turn it off?

> impose any new requirements.

OK. I will.

> ...George

Very helpful. Thanks!

- Ping

---

From: Ken Nagami <[email-masked]>
Date: Tue, 10 Jul 2001 15:05:38 +0900

Hi Ping, 

>> consider the Notify message.... Let me think about it.

Why do you use a RSVP RESV message for an LSP-ping reply? 
I think it is better to use an UDP packet which is the same as
LSP-ping echo message. If you don't use an MPLS control
message(RSVP-TE, LDP) for the LSP-ping, this mechanism can be used for
all kind of LSP, such as a static LSP and an LSP established by LDP.

I think the section 4 in the draft-satoru-mpls-1hop-lsp-00.txt is the same
motivation for your draft.

Regards,

Ken Nagami

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Jul 2001 03:49:54 -0700

Hi Ken,

I am affraid if you don't use the RSVP RESV msg the return of LSP-ping
packet your response may fail in the same way as the initial ICMP ping
failed. Remeber the assumption here is that the data path is broken and
control path fine. 

The current sequence seems to be following:

Step 1: 

Ingress LSR is sending regular ICMP pings via the LSP_X

Two cases:

A) pings are returned OK (LSP_X is fine)
B) pings are lost
   1. - LSP_X is fine and return path is broken
   2. - LSP_X is broken by itself

If B then goto step 2.

Step 2: 

Ingress LSR is sending UDP LSP-pings via LSP_X

Two cases:

A) UDP LSP-pings arrive on the tail (egress) and ECHO is copied into
RSVP RESV msg, then returned to the ingress head proving that LSP_X is
fine just there was some issue with the return path of the ICMP from
Step 1.

B) LSP1's data plane is broken by itself somewhere so the tail (R4)
never receives the LSP-ping and R1 never receives the LSP_ECHO object in
the RESV msg.

R.

> Ken Nagami wrote:

---

From: Eric Rosen <[email-masked]>
Date: Tue, 10 Jul 2001 10:44:44 -0400

I'm still confused about what this actually tells you. 

From the failure  of the ICMP pings, you already know  that either the LSP's
data plane is failing, or else  there is no operational return path for data
packets.  However, there  is apparently an operational path  for the forward
and reverse control traffic.

If you send the LSP-ping down the LSP itself, then it "ought to" fail if and
only if the LSP's data plane  is failing.  So presumably, if it succeeds you
know that the failure is in the reverse data path.

If you  do not send the  LSP-ping down the  LSP itself, then it  will likely
succeed, but you don't learn anything. 

So the most you can learn from this is that the failure of the original ICMP
ping is  due to  a problem  in the return  path for  data packets.   Is that
correct? 

But if all you want to know is whether the reverse data path is working, why
not just do ordinary ICMP ping in the reverse direction? 

What am I missing?

---

From: George Swallow <[email-masked]>
Date: Tue, 10 Jul 2001 11:01:11 -0400

Ping -

> will have RSVP Session and Sender-Template objects. I will articulate it

As I understand the draft you monitor tunnels with normal ICMP pings
and only use the LSP-ping when something appears awry.  Right?  What I
was referring to in the above comment is the *normal* ICMP ping.  

> Interesting. How do I inform the egress about the timer? 

I was just thinking of a default (perhaps configurable) say 1 minute?

> In the first

Keep sending LSP-pings.

...George

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Jul 2001 07:48:26 -0700

Hi Eric,

> ping is  due to  a problem  in the return  path for  data packets.   Is that

Yes and in the same time prove that the LSP under test is fine.
 
> not just do ordinary ICMP ping in the reverse direction?

I am sure the same test procedure will be executed in the reverse
direction as well again to verify unidirectional LSP state not the both
direction state.

I think that is the author's intention.

R.

> Eric Rosen wrote:

---

From: Ping Pan <[email-masked]>
Date: Tue, 10 Jul 2001 08:34:24 -0700

> all kind of LSP, such as a static LSP and an LSP established by LDP.

Ken,

LSP-ping is used to probe the data path. There are cases where the data
path goes wrong, and you have no idea where the problem is (forwarding
LSP, reverse LSP, ...). Since the only operational path that you can
count is the control path, so you reply via RSVP.

If you use UDP to return the reply, what if the returning path is
broken? Should the user assumes the forwarding LSP is bad, or the
reverse?

At the same time, if you can come up with a simple, scalable, backward
compatible method to use for LDP (including the case where you can label
merging) as well, please do let us know. :-)

- Ping

---

From: "S.Matsushima" <[email-masked]>
Date: Wed, 11 Jul 2001 02:14:07 +0900

From: Ping Pan <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt]
Date: Tue, 10 Jul 2001 08:34:24 -0700

> broken? Should the user assumes the forwarding LSP is bad, or the

Ping,

I can't understand why do you use RSVP msg for reply LSP-ping.
It is only way to LSP using RSVP or other DoD/Orderd label
distribution mode.
Isn't it same thing that simply IP reachability from egress to
ingress for other label distribution mode?
(For example, DU/Independent label distribution)

LSP is unidirectional path besically. Thus, I suppose LSP-ping reply
scheme will be done by only have to simply IP reachability from egress
to ingress.

> merging) as well, please do let us know. :-)

How about Section.4 in draft-satoru-mpls-1hop-lsp-00.txt?
It can use not only "KeepAlive" purpose but also LSP-ping.

> 4. The Possible to LSP "KeepAlive" using 1-hop LSP
>
> 4.1  Background
>
>     This "LSP KeepAlive" ability is extremely important for the
>    applications which use LSP but cannot know the state of LSP itself
>    (for instance, consider the situation where BGP / MPLS VPNs are
>    used; they will recognise the network as "available" only if the
>    possibility of the IP accessibility to the PE exits, whatever the
>    state of the LSP).
>
> 4.2  Method of "LSP KeepAlive" process
>
>    The "KeepAlive" of LSP is possible by the use of IP Packet
>    transmission to FEC from the ingress LER with the minimum IP TTL
>    (minimum value=1) through 1-hop LSP. This is because if there is a
>    cut within LSP then there will be no reply.
>
>    In order to carry out "KeepAlive" of LSP, the expansion process is
>    also require for the core LSR such that IP TTL will not be replaced
>    by MPLS TTL, just like in the egress LER. This is because, if there
>    is a cut within LSP the core LSR will "pop" the label. This means
>    that the original core LSR will be made to act as an egress LER.
>
>    The reply can be expected from the entire installed, if, such as
>    ICMP ECHO is used for setting of the IP Packet in this situation.
>
>    The TTL does not have to, or more precisely, should not have a value
>    of 1 for reply. In case of TTL value on the reply message being 1,
>    it will go to the opposite side of LSP "KeepAlive" since the LSP is
>    a one-way path. This LSP "KeepAlive" cannot be "KeepAlive" for each
>    LSP.
>
>    The TTL value on the LSP KeepAlive's reply message should have large
>    enough value. Also, if there is no route for the reply message to
>    return, it will look as though the healthy LSP does not exit.

--
Satoru Matsushima

---

From: Ken Nagami <[email-masked]>
Date: Wed, 11 Jul 2001 14:15:40 +0900

Hi Ping, Robert,

Thank you for your explanation. I understand your point.
A hop-by-hop control plane, which is a return path for the LSP-ping 
is needed on this mechanism.

Ping, 

Do you think that the mechanism is generalized?
I think a generalized mechanism for the LSP-ping is more useful.

---

From: Ping Pan <[email-masked]>
Date: Tue, 10 Jul 2001 23:29:45 -0700

Ken,

> I think a generalized mechanism for the LSP-ping is more useful.

Say, one major advantage of having a generalized mechanism is to make
the problem easier to handle. Instead of solving the problem for one
protocol, it can solve the problem for other protocols as well. However,
if the protocols are very different in nature, the generic solution can
become quite complex. It may be complex to design, complex to develop,
and complex to deploy. In this case, we may be better off to develop a
separate and simple approach for each protocol.

Back to RSVP-TE vs. LDP, both will work to setup LSP's, but they are
very very different. If you look at other features in MPLS, such as
fast-reroute and graceful restart, we have to design separate solutions
for both protocols. At the end, it's all about to get things working
on-time, instead of spending all the precious time to design a kitchen
sink that can solve all the problem in the world, but late to market.

2 cents,

- Ping

---

From: Miya Kohno <[email-masked]>
Date: Fri, 13 Jul 2001 21:53:13 +0900

Satoru,

   The draft proposes how to validate the data plane of RSVP-TE LSPs. As for LDP LSPs, we need to discuss separately. It might be ideal if there's a generalized method, but it seems difficult because we will have to depend on the control plane anyway.

Miya
> >    return, it will look as though the healthy LSP does not exit.

----------------------------------------------------------
Miya Kohno, Sr. Consulting Engineer
Service Providers Market Developments, Cisco Systems Japan
Phone: +81-3-5219-6234, Email: [email-masked]