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

From: "David Allan" <[email-masked]>
Date: Tue, 10 Jul 2001 12:29:42 -0400

Ping:

I am specifically concerned that although this tool may be percieved as
useful, it really has very limited applicability, it assumes a specific MPLS
payload and a specific control plane. How many of these mechanisms do we
wish to support before we finally have a comprehensive toolkit?

IMHO It would be a whole lot more useful if we just tackled the problem in
its entirety instead of via the incremental approach we have seen to date. 

One group of authors (Neil Harrison and company) has a requirements draft
posted already, and we'll be bringing forward a framework to London that
builds upon it (to be posted later this week), Perhaps we can start to put
these problems to bed a bit more systematically....

cheers
Dave

---

From: "Dave Cooper" <[email-masked]>
Date: Tue, 10 Jul 2001 10:43:30 -0700

David,
I think its up to the operators to ascertain
usefulness and applicability.  We were motivated
to submit this draft because of the urgency in
detecting LSP integrity in MPLS TE networks.
No, it doesnt address all of the requirements
outlined in the OAM draft. But it attempts to
address one of the most significant issues we face in
today's MPLS networks.  Our goal is to keep it
as simple as possible but accomplish this objective.

Thanks,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of David Allan
Sent: Tuesday, July 10, 2001 9:30 AM
To: Ping Pan
Cc: mpls-list; mpls-ops
Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt]

Ping:
I am specifically concerned that although this tool may be percieved as useful, it really has very limited applicability, it assumes
a specific MPLS payload and a specific control plane. How many of these mechanisms do we wish to support before we finally have a
comprehensive toolkit?
IMHO It would be a whole lot more useful if we just tackled the problem in its entirety instead of via the incremental approach we
have seen to date.
One group of authors (Neil Harrison and company) has a requirements draft posted already, and we'll be bringing forward a framework
to London that builds upon it (to be posted later this week), Perhaps we can start to put these problems to bed a bit more
systematically....
cheers
Dave

---

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

I'm still trying to  be sure I understand just what this  mechanism is to be
used for.  

If a given LSP is working, and  was set up with RSVP-TE, this mechanism will
allow you to verify that it is working.

If a given LSP is not working,  this mechanism does not provide you with any
diagnostic information. 

So you can use it for two purposes:

- to test regularly whether an LSP is working

- to  eliminate  "LSP data  plane  outage" as  the  source  of a  particular
  problem. 

This does seem useful.

I think though that draft-bonica-icmp-mpls is also an attempt to provide the
testing  function, along  with  some diagnostic  capability,  but without  a
dependence on a particular control  plane.  Do you see draft-pan-lsp-ping as
being superior in some respect?

---

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

I meant to  say "draft-bonica-tunproto-00", not "draft-bonica-icmp-mpls", in
my last message.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 10 Jul 2001 15:30:48 -0700

Eric,

> being superior in some respect?

yes.

Yakov.

---

From: Ron Bonica <[email-masked]>
Date: Tue, 10 Jul 2001 23:18:12 -0400

> > being superior in some respect?

Eric, Yakov,

Draft-pan-lsp-ping-00.txt and draft-bonica-tunproto-00 are not competitors
to one another. One proposes an "ping", the other proposes a "traceroute".

Ping,

Shouldn't the mechanism be generalized? Possibly made independant of the
signaling mechanism? Don't LSPs that are established by LDP (or foo) need
this functionality, too?

Also, wouldn't this functionality also be useful for non-MPLS tunnels?

                                          Ron

---

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

Ron,

Ron Bonica wrote:
> 
> Ping,
> 
> Shouldn't the mechanism be generalized? 

It should.

> Possibly made independant of the signaling mechanism? 

Agree, if we don't introduce more potential code bugs and network
instability with the new approach. :-) 

> Don't LSPs that are established by LDP (or foo) need
> this functionality, too?

They do.

Actually, we have thought about this for a while. Unfortunately, LDP and
RSVP-TE are two very different protocols. Having a generic mechanism to
cover both cases can make the whole thing complex, and hard to deploy,
and hard to implement and debug. If you have ideas on this topic, let's
talk.

If you look at our proposal, when it is used, the existing MPLS
operation inside the network is not disturbed at all. The processing
overhead on the LSR's is very small. And the implementation won't be
very difficult. 

> Also, wouldn't this functionality also be useful for non-MPLS tunnels?

The lsp-ping proposal is to solve the problem where control-plane cannot
detect data-plane failure. Would it happen to non-MPLS tunnels?

Regards,

- Ping

---

From: Eric Rosen <[email-masked]>
Date: Wed, 11 Jul 2001 10:10:21 -0400

Ron> Draft-pan-lsp-ping-00.txt   and    draft-bonica-tunproto-00   are   not
Ron> competitors to one another. One  proposes an "ping", the other proposes
Ron> a "traceroute".

I don't see this.  Generally you use ping to detect (or verify) that there's
a problem, and  traceroute to get diagnostic info.   Ordinary ICMP ping will
detect that there's  a problem, you don't need  LSP-ping for this.  LSP-ping
may tell you  that the fault is not  due to particular LSP, but  I think the
tunproto stuff  would tell you that as  well.  So I don't  see that LSP-ping
provides an additional capability. 

Yakov, your message  seems to have been truncated by  the mailing system.  I
didn't get the part where you explain why the LSP-ping mechanism is superior
to the tunproto mechanism.  Please resend.

I  guess  I'm  also  having  some trouble  understanding  why  the  LSP-ping
mechanism needs  to be specific to  a particular control  protocol.  Why not
just use  a UDP packet  to send  the response back  to the tunnel  head?  It
won't necessarily travel  back along the control path,  but does that really
matter?

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 11 Jul 2001 09:26:42 -0700

Eric,

> won't necessarily travel  back along the control path,  but does that really

It may disappear the same way as the original icmp test so the head will
assume that LSP is down while it is in fact up.

R.

---

From: Eric Rosen <[email-masked]>
Date: Wed, 11 Jul 2001 13:11:44 -0400

Eric> I guess  I'm also having  some trouble understanding why  the LSP-ping
Eric> mechanism needs to be specific  to a particular control protocol.  Why
Eric> not just  use a  UDP packet to  send the  response back to  the tunnel
Eric> head?  It  won't necessarily travel  back along the control  path, but
Eric> does that really matter?

Robert> It may disappear the same way  as the original icmp test so the head
Robert> will assume that LSP is down while it is in fact up.

We just need  to invent a way to  ensure that the UDP packet  follows the IP
hop-by-hop  path,  rather  than  being  sent through  an  LSP.   That  would
eliminate  the  worry  about  MPLS   data  plane  problems  in  the  reverse
direction.  It does leave a hole  in the situation where the RSVP-TE control
plane is working  although there is no IP connectivity from  the tail to the
head, but that doesn't seem like too big of a hole.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 11 Jul 2001 11:00:06 -0700

Eric,

> hop-by-hop  path,  rather  than  being  sent through  an  LSP.   

or just use what is described in draft-pan-lsp-ping-00.txt.

Yakov.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 11 Jul 2001 12:07:38 -0700

Eric,

> hop-by-hop  path,  rather  than  being  sent through  an  LSP. 

Well I am afraid this is not easy. What you need to invent is a way not
just for tail not to send the proposed UDP reply the same way as they
send ICMP one but also to make sure each subsequent node does the same.
If a network would be managed by some offline tool yes the tool's
notification by the tail would be enough. If this is attractive solution
I don't know - could be an easy LSP-ping reply option.

I understand that there is great benefit to eliminate the control plane
usage but I am afraid nothing will be as realiable as either RSVP RESV
(the assumption is that the LSP is up) or IGP flooding (again control
plane). I also fail to come up with anything more simpler then just load
this msg on the RSVP RESV. 

I was watching the thread closely as it addresses one of the most
popular recently customer demand in some extent and would say that not
going forward with this proposal would hurt live deployed networks or
make implementations not interoperable. 

R.

---

From: Eric Rosen <[email-masked]>
Date: Wed, 11 Jul 2001 16:13:52 -0400

Eric> We just need to invent a way to ensure that the UDP packet follows the
Eric> IP hop-by-hop  path,  rather  than  being  sent through  an  LSP.   

Yakov> or just use what is described in draft-pan-lsp-ping-00.txt. 

The point is to find a simple mechanism that does not depend on a particular
control plane.

---

From: Eric Rosen <[email-masked]>
Date: Wed, 11 Jul 2001 16:19:33 -0400

Robert> What you need to  invent is a way not just for  tail not to send the
Robert> proposed UDP  reply the same way as  they send ICMP one  but also to
Robert> make sure each subsequent node does the same.

Why is it necessary  that the UDP reply "go the same  way" as anything else?
It just  has to  follow a  hop-by-hop IP path,  so that  LSP failure  in the
reverse direction cannot cause it to be lost.

---

From: Matt Squire <[email-masked]>
Date: Wed, 11 Jul 2001 23:07:18 -0400

> The point is to find a simple mechanism that does not depend on a particular

To jump on an already crowded bandwagon...

Having an LSP ping that is signalling protocol dependent does suck.  But
I agree that if they only thing you're sure about in the reverse
direction is the reverse control path, then it might have to be used. 

To this end, it would seem simple enough to compartmentalize the
signalling aspects of the proposed LSP ping that it has some header
stuff and then some signalling protocol specific TLV.  The RSVP TLV
could be as described in this draft, and a CR-LDP TLV could be just as
easily defined (maybe just the LSP ID?).  So at least the methodology
would be consistent as well as the main packet format and port numbers,
etc., with signalling specific junk tacked onto the end.

- Matt

---

From: Matt Squire <[email-masked]>
Date: Wed, 11 Jul 2001 23:13:50 -0400

> etc., with signalling specific junk tacked onto the end.

It would also be nice if the signalling protocls behaved similarly,
maybe using some type of notification message with a PING_OK status or
something, but thats doesn't seem like as big a deal.

- Matt

---

From: George Swallow <[email-masked]>
Date: Thu, 12 Jul 2001 09:15:21 -0400

> signaling mechanism? 

I don't think so.  The mechanism is intentionally tied to the control
plane to ensure that the source is properly informed even if the
reverse data path may be broken.  I wouldn't want to propose a general
mechanism for this.

> Don't LSPs that are established by LDP (or foo) need
 
Yes.  But one size may not fit all.

> Also, wouldn't this functionality also be useful for non-MPLS tunnels?

Ditto.

...George

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

---

From: Eric Rosen <[email-masked]>
Date: Thu, 12 Jul 2001 10:25:32 -0400

George> The mechanism is  intentionally tied to the control  plane to ensure
George> that the source  is properly informed even if  the reverse data path
George> may be broken.  

If  the reply is  encapsulated in  a UDP  packet which  is addressed  to the
tunnel head and has router alert  set, isn't this just as effective, without
the dependence on the control plane?

---

From: Matt Squire <[email-masked]>
Date: Thu, 12 Jul 2001 11:27:53 -0400

What prevents a packet with a router alert flag set from being sent over an
LSP?  I don't recall anything in the specs that specifies router alter packets
can't be LSP'd.

---

From: George Swallow <[email-masked]>
Date: Thu, 12 Jul 2001 11:26:46 -0400

> the dependence on the control plane? 

Interesting idea.  We should explore this.

...George

---

From: "S.Matsushima" <[email-masked]>
Date: Fri, 13 Jul 2001 14:08:15 +0900

Hi All,

I'm glad that mpls guys think LSP condition check and failure detect
is neccesary feature. Because, I'v described it as LSP-keepalive in
draft-satoru-mpls-1hop-lsp-00.txt.

Keepalive is a proactive failure detecting method for some data-link,
routing-protocol and session. It is also needed for LSP because of the
LSR can feedback LSP condition to routing/forwarding autonomic decision.
I think it is need to consider in this working group.

--
Satoru Matsushima

From: George Swallow <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] 
Date: Thu, 12 Jul 2001 11:26:46 -0400

---

From: "S.Matsushima" <[email-masked]>
Date: Fri, 13 Jul 2001 14:13:05 +0900

Hi All,

--
Satoru Matsushima