Subject: RE: Last call on LSP Ping

From: "David Allan" <[email-masked]>
Date: Wed, 4 Dec 2002 11:02:36 -0500

Hi:

I have a concern with the draft. Embedded in the protocol are a number of
features designed to test proprietary behaviors (load balancing). How these
would be used IMHO is insufficiently well documented to ensure
interoperability. On that basis I do not think the document is ready.

One specific example that come to mind is the description of "downstream
router". I consider to be poorly explained. 

Now the text:
"a packet with outermost label L and TTL n>1 arrives at X"..... OK

"X must be able to compute which LSRs could receive the packet with TTL=n+1"
whoa, where the packet came from? I thought TTL decremented. I presume the
correct text should be "what LSRs would receive the packet if forwarded from
X with TTL=1".

"the set of LSRs are the downstream routers....for X with respect to L",

So what are we discussing here, the LSRs upstream of X, downstream of X, the
specific NHLFE that load balancing resolves to given the specific details of
the packet (src address and 127./8 and whatever else the propretary
implementation considers) or the set that the FTN/ILM maps to prior to any
actual load balancing computations (is it "a" packet or "any" packet mapping
to the FEC associated with the LSP).

If the intent is to provide a mechanism to fully exercise any and all
potential load balancing configurations and to understand what
configurations were tested, this would appear to come up short. When
attempting to traceroute such a configuration, the LSR originating the trace
either:
- knows there is a problem and knows what specific 127./8 will supposedly
reproduce the problem but knows little else about the network.
- knows there is a problem but may not know what specific 127./8 will
reproduce it, therefore wishes to exercise all possibilities AND needs to be
able to verify that it did so. Therefore there is an element of "topology
discovery" inherent to performing such a traceroute.
- there may not be a problem but the LSR wishes to exercise the whole
downstream construct anyway.

Given the description, and the ambiguities in the text, it is not clear to
me what I could build and successfully interoperate with the LSR next
door....

BTW it would be useful to explicitly state in 3.2 that the downstream
mapping TLV is only valid in "traceroute mode", and that it is optional in
echo requests, and mandatory in echo replies.

Other minor comments:

- won't claim to be an expert, would TTL exhaust on an internal loopback
address generate an ICMP message back to the ping originator (which it
should be ignoring)?

- downstream mapping permits multiple labels per interface to be described
in an echo request, but the reply can only indicate that "it arrived on one
of them" rather than which specific one (which may matter).

IMHO it would be useful to have the sequence number explicitly correspond to
the LSB of the 127./8 used as I would presume otherwise the echo request
originating LSR would need to remember such details associated with the
sequence number (as the reply would not contain the address). (I'm assuming
that the sequence number is used uniquely with the LSP under test, and the
handle exists as the indexing mechanism for replies independent of the
specific LSP under consideration). T'would also facilitate picking out gaps
due to black holes in load balancing constructs esp. in don't reply mode. 

- not clear how the example of testing stacked FECs would work in CSC
scenarios, perhaps an author could comment?

cheers
Dave

---

From: Peter Willis <[email-masked]>
Date: Thu, 05 Dec 2002 16:40:48 +0000

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

"4.1. Sending an MPLS Echo Request

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

Question 1 - What does "possibly" mean above? Why possibly? Would it work if
	it was not labelled?

Question 2 - The destination address 127/8, we should also have an IPv6
	destination loopback address if we want to be future proof. (Would
        that be ::1 in IPv6 speak?)

Question 3 - What is a "routable address" when we have IP VPNs? I'm thinking 
if the LSP ping originates in a customer-routed domain (or the edge carrier in 
a carriers-carrier scenario) then in the core (P routers) that address isn't
 routable!

Regards,

-------------------------------------------------------------------------------
This post represents the views of the author and does not necessarily 
accurately represent the views of BT.
-------------------------------------------------------------------------------
Peter Willis		            | E-mail: [email-masked]
IP Technology Strategist            | 
BTexact Technologies CTO            |
-------------------------------------------------------------------------------

---

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

Hi Peter,

> Question 1 - What does "possibly" mean above? Why possibly? Would it work if

Consider a one-hop LSP with PHP.

>         that be ::1 in IPv6 speak?)

The whole issue of encoding the LSP ping in an IPv6 header hasn't
been addressed.  It might be worth doing -- I'll let the chairs and
ADs guide me.

> a carriers-carrier scenario) then in the core (P routers) that address isn't

If the ping starts in a customer domain, hopefully it ends in a customer
domain, and the reply will be routable.  The traceroute mode will not
work, but that is to be expected -- it's no different from "regular"
traceroute.

Kireeti.

---

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

Hi Dave,

> interoperability. On that basis I do not think the document is ready.

I think this has been done sufficiently to death.  I'll hunt down and
read Curtis's proposed text and comment.

> to the FEC associated with the LSP).

Explained in reply to Shahram -- does that work for you?

> me what I could build and successfully interoperate with the LSR next

MPLS to the kerb (curb)?

> echo requests, and mandatory in echo replies.

See reply to Shahram.

> of them" rather than which specific one (which may matter).

The "multiple" labels are a stack (see reply to Shahram).

> due to black holes in load balancing constructs esp. in don't reply mode.

I don't see the utility of this.  The LSB of the address is in the
packet.

> scenarios, perhaps an author could comment?

You'll have to explain, starting with expanding "CSC".

Kireeti.