Subject: technical comments on LSP-ping-03

From: Shahram Davari <[email-masked]>
Date: Thu, 28 Mar 2002 07:20:32 -0800

Hi,

I've looked over the draft, looks like a good start at a useful tool, but I have the following comments and questions:

1) Time stamp: Why is the time stamp in both seconds and microseconds? The microsecond could count up to 71 minutes. Isn't that enough? Why milliseconds is not used?

2) Section 3.1: If I understand it correctly a Target FEC TLV could consist of a number of FEC stack sub-TLVs. Therefore it seems that the number of these sub-TLVs could be determined by looking at the Target FEC TLV length field. But the text says it could be determined by looking at the sub-TLV length field. Which one is correct?

3) Section 3.1: The value field in the type 7 should probably read VPN IPV6.

4) Section 3.1: How can you ping multiple FECs simultaneously (i.e., piggy back multiple pings), while each FEC belongs to a different level of the label stack? This requires that all those hierarchical labels (LSPs) be initiated and terminated at the same LSRs. Also how do you intend to generate response if the result of some of those FEC pings are positive and some are negative?

5) Why is the downstream label field in the downstream mapping TLV 24 bits?

6) Section 3.2: When X receives a packet with TTL of n>1, shouldn't it compute the downstream LSRs that could receive the packet with TTL=n-1 (rather than TTL=n as indicated)?

7) Section 3.2 last paragraph: I think it is better to add that this applies to trace-route mode only.

8) Section 4.2: Why the echo reply time stamp is not similar to ICMP echo-reply time-stamp in which a received time-stamp and sent-time stamp is set by the receiver? Which gives you the processing time at the receiver too. 

9) Section 4.2: Does the echo-reply time stamp replace the echo-request time stamp or it is appended to the echo-request time stamp? 

10) Section 4.2: Does the downstream mapping TLV of the echo-reply replace the downstream mapping TLV of the echo-request or it is appended to it?

11) Section 4.3: If the egress for an FEC stack being pinged doesn't support MPLS ping, isn't an ICMP TTL expire message generated for the IP TTL=1 received (instead of no reply as mentioned in the draft)?

12) Section 5 2nd paragraph last sentence I think should be changed to: "Note that this may not work if some transit LSR does not support IP options" (not 'MPLS ping' as mentioned in the draft)

13) Section 5: I think you need to mention that RSVP-TE return path should be used only in "ping" mode.

14) Section 5.3 last paragraph: I think you need to delete ICMP here.

15) Section 5.5: I think you need to mention that if intermediate LSRs don't support refresh reduction, then it could take many minutes before the echo-reply is received at the source.

16) Section 6: I think you need to add security implication for the IP return path.

Thanks,
Shahram Davari
Senior Product Research Engineer
R&D Research Ottawa
PMC-Sierra, Inc. 
Phone: (613) 271-4018
Fax:   (613) 271-6468

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 29 Mar 2002 13:58:29 -0800 (PST)

Thanks David and Shahram for your comments.  This is very clearly
a work in progress and yours (and others) input is very welcome.

Hopefully, in the next week or so, there will be another version of
this draft.  Some of your questions have been (or will be) addressed,
but probably not most.  I will reply to the rest of your comments in
detail shortly.

Kireeti.