Subject: Last call on LSP Ping

From: George Swallow <[email-masked]>
Date: Tue, 03 Dec 2002 17:51:34 -0500

This message begins a workgroup last call on:

    Detecting MPLS Data Plane Liveness

     draft-ietf-mpls-lsp-ping-01.txt

The last call ends on Dec 16, 2002 2400H GMT.

George & Loa

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

---

From: Eric Rosen <[email-masked]>
Date: Thu, 05 Dec 2002 17:29:16 -0500

Re the last call  on "LSP Ping", I have a few  questions and comments on the
ping functionality. 

From section 4.1: 

   An MPLS echo request is a (possibly) labelled UDP packet.  The IP
   header is set as follows: the source IP address is a routable address
   of the sender; the destination IP address is a (randomly chosen)
   address from 127/8; the IP TTL is set to 1.  The source UDP port is
   chosen by the sender; the destination UDP port is set to 3503
   (assigned by IANA for MPLS echo requests).  If the echo request is
   labelled, the MPLS TTL on all the labels except the outermost should
   be set to 1.

Although  this suggests  that the  MPLS  echo request  might be  sent as  an
unlabeled UDP datagram, that doesn't  actually seem possible.  If you try to
send a UDP datagram  to 127.0.0.1 it won't go very far.   (In fact, RFC 3330
seems to make it illegal to send over the network an IP packet whose address
is in  the range 127/8.   Whether it makes  it illegal to send  such packets
encapsulated  is less  clear.)  So  I  think it  is REQUIRED  that the  echo
request be labeled.  Actually, I think the requirements are:

- The originator  of the echo request  decides to test  a FEC or a  stack of
  FECs. 

- The originator  determines the next hop  for that FEC, or  for the topmost
  FEC in the stack. 

- The originator labels  the echo request with the label  stack that is used
  for sending packets with that FEC via that next hop. 

- The  originator  sends the  labeled  echo request  to  that  next hop.  (If
  reaching the  next hop  requires going through  an LSP tunnel,  this might
  causes more labels to be pushed on the stack.) 

It would also be nice if the document were more explicit about what sorts of
error conditions  elicit what sorts of  responses.  If you  get no response,
you can conclude that one of the following conditions holds:

- The label stack you  put on the echo request did not  get the UDP datagram
  delivered a node in your network which supports LSP Ping. 

- The echo response couldn't be  delivered for some reason.  (The option for
  replying via the control plane is intended to eliminate this possibility.) 

If the  UDP datagram  does end  up, unlabeled, somewhere  where LSP  Ping is
understood, then  the 127/8 address  will cause it  to be processed  at that
point.  Presumably the  responder is supposed to look at  the stack of FECs,
and determine whether it is an LSP egress for each FEC in the stack.  If so,
it responds with a return code of 3; otherwise with a return code of 4. (I'm
ignoring the "downstream router" stuff for now.) 

So if  you get  a response  with a  return code of  3, you  know that  it is
possible to get MPLS packets to the responder, and that the responder is the
right place to be sending packets that  are in the specified FEC or stack of
FECs.   If you  get  a response  with  a return  code of  4,  you know  that
something  has  gone  wrong   somewhere,  your  labeled  packets  are  going
someplace other  than where  they are  supposed to go,  and you'd  better do
something right away.  

The suggestion  to randomly choose  IP destination addresses from  the 127/8
block is,  presumably, the way to  ensure that the various  paths created by
equal cost load splitting get exercised.  The question is, how many pings do
you need to send in order to get good coverage?  

If the request  has a stack of n  FECs, and the responder is  the egress for
the topmost  m FECs but not  for the bottommost  n-m, it might be  useful to
have a way to indicate that in the response.

Some minor observations: 

- The notion of "time  of day" is not well-defined.  I have  no idea what is
  supposed to  be put in the time  of day fields.  This  doesn't really seem
  that useful anyway unless there is synchronized time. 

- I'm not sure that the sequence  number really needs to be a separate field
  from the sender's handle.  It just  seems like an extension of the handle,
  whose semantics are private to the sender.

---

From: George Swallow <[email-masked]>
Date: Thu, 05 Dec 2002 19:01:02 -0500

> - The originator  of the echo request  decides to test  a FEC or a  stack of

I think you're really only testing one FEC.  The stack gives you a way
of noting how you set off the get to that FEC (assuming you had
multiple options - like two TE tunnels).

>   causes more labels to be pushed on the stack.) 

Yes.  I think we need to rework that section and be more explicit
about how it works.  As far as I'm concerned the only place you might
have an unlabelled Ping is after a PHP.  I was also assuming that you
only Ping one FEC at a time.  I think we should also say that in the
text.  If others think we need to be able to do more than one at a
time then we need a good deal of text to describe that.

>   replying via the control plane is intended to eliminate this possibility.) 

(Well, at least seriously ameliorate the situation.)  

Also good text to include.

> you need to send in order to get good coverage?  

Obviously this depends on the number of ECMPs that exist.  Which is
both a function of the topology and the number of hops between the
source and destination.  If you have better suggestions on how to do
this I'm quite eager to hear them.  This is the best we've been able
to come up with so far.

> have a way to indicate that in the response.

Or presumably you would just ping the outer FECs - which seems to me
to be sufficient.

>   that useful anyway unless there is synchronized time. 

Kireeti - could you comment here and also on Sharam's question on why
you deviated from ICMP Ping?

>   whose semantics are private to the sender. 

Some implementors would like to put a PID in the sender handle so the
separation seems useful.

...George

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

---

From: Eric Rosen <[email-masked]>
Date: Fri, 06 Dec 2002 10:39:30 -0500

George> I think you're really only testing one FEC. 

I don't think so.  The Echo Request might end up getting processed at a node
which is an egress for the top  FEC, but not for one of the succeeding FECs.
This would indicate that you  don't have proper connectivity for the latter,
even if you do have proper connectivity for the former.

---

From: Abhishek Saxena <[email-masked]>
Date: Tue, 10 Dec 2002 16:28:59 +0530

Hi,

I was wondering why an IP header is required in the LSP ping packet. The 
information that we need to get the packet across to the egress LSR is 
simply the mpls label. The source IP address of this LSR is needed by 
the egress LSR to return the packet back. This is already there in the 
TLV. We can therefore have a UDPoMPLS kind of a setup in this case, with 
no IP header in the packet therefore preventing any IP routing at all 
for this packet.

Does this make sense?

Regards,
- Abhishek

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 10 Dec 2002 12:16:47 -0500

> no IP header in the packet therefore preventing any IP routing at all 

The LSR needs to know what to do with the packet after the last label
is stripped off.  There is already IP processing and TTL expire
processing built into the router.  The TTL expire processing needs
minimal modification, the IP processing needs very minimal
modification (in some cases just configuration of the loopback and
filters).  Multipath schemes which look into the packet at IP headers
for known IP only LSPs can be exercised by varying the destination
address within the 127/8 range.

No router that I know of currently supports UDP over MPLS without IP.

Curtis

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 11 Dec 2002 04:31:04 -0800 (PST)

Hi Eric,

>   causes more labels to be pushed on the stack.)

As I said in an earlier reply, what if the LSP is a one-hopper, with PHP?

>   replying via the control plane is intended to eliminate this possibility.)

Yes.

> someplace other  than where  they are  supposed to go,  and you'd  better do

Yes.

> you need to send in order to get good coverage?

We've beaten this one to death.  Suggestions are most welcome.

> have a way to indicate that in the response.

True.  Someone else pointed this out --  will fix.

>   that useful anyway unless there is synchronized time.

Seconds and microseconds since 00:00:00.0, Jan 1, 1970, UTC?

>   whose semantics are private to the sender.

Same as for regular ping.

Kireeti.

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 11 Dec 2002 04:44:55 -0800 (PST)

Hi George,

> multiple options - like two TE tunnels).

Sometimes you're testing just the one FEC, sometimes you're really
testing the stack.  Say you're testing prefix 10/8 in VPN foo, and
it so happens that you go over LSP bar.  You don't really care, you
create a ping packet with target FEC "10/8 in VPN foo", slap a label
stack on it, and off it goes.

However, suppose you learned 10/8 in VPN foo from two PEs (dual-homed
CE), with LSPs bar1 and bar2.  You may want to test each independently.
So, in one case you'd have a target FEC stack of "LSP bar1; 10/8 in VPN
foo" and in the other case, "LSP bar2; 10/8 in VPN foo".

Does that make sense?

Kireeti.

---

From: Eric Rosen <[email-masked]>
Date: Thu, 12 Dec 2002 10:05:05 -0500

Eric> Although this suggests that the MPLS echo request might be sent as an 
Eric> unlabeled UDP datagram, that doesn't  actually seem possible.

Kireeti> As I  said in an  earlier reply, what  if the LSP is  a one-hopper,
Kireeti> with PHP?  

Yes, correct.  I would suggest adding two clarifications to the document: 

- The packet is  only sent unlabeled if the LSP is  a one-hopper, and PHP is
  used. 

- The LSP ingress must not  pass the packet though the "ordinary" forwarding
  procedures, else  the packet  will be  consumed by the  egress due  to its
  127/8 destination address. 

Kireeti> Say you're testing  prefix 10/8 in VPN foo, and  it so happens that
Kireeti> you go  over LSP  bar.  You  don't really care,  you create  a ping
Kireeti> packet with target FEC "10/8 in VPN foo", slap a label stack on it,
Kireeti> and off it goes. 

I agree  with this  as far  as it goes,  but I  think some  clarification is
needed with respect to the label  stack that is slapped on.  For testing VPN
routes, you must be  sure that the bottom label is not  one which will cause
the packet to be sent to the  CE.  Thus you would generally have to omit the
VPN route label from the "slapped on" label stack.