Subject: RE: Last call on LSP Ping

From: Shahram Davari <[email-masked]>
Date: Wed, 4 Dec 2002 13:40:07 -0800

Hi,

Although I have no hope of getting any response, but here is a repeat of my ignored comments raised in March, 2002 and some new ones:

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 isn't the
same timestamp used in ICMP not used here which says:
 
        The Timestamp is a right-justified, 32-bit timestamp in
        milliseconds since midnight UT. 
 
2) Section 3: 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. 

3) 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 and subtracting the sub-TLV lengths from it. But the text says it could be determined by looking at the sub-TLV length field. Needs clarification.

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 error response if the result of some of those FEC pings are positive and some are negative?

5) Section 3 under return code. There is no return code for the case that one of the FECs fail while others pass, or when one of the label mappings don't pass, while others pass.

6) Why doesn't the MPLS ping permit pinging multiple FECs that belong to the same LSP level? It seems that if 1000s of FECs are all mapped to the same LSP, then 1000's of MPLS-pings are required.

7) Why is the downstream label field in the downstream mapping TLV 24 bits? Is it for ATM? How is the 20 bit label mapped to this 24 bit?

8) 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+1 as indicated)?

9) Section 3.2 last paragraph: Does this apply to trace-route mode only?

10) Section 4.3: 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.5: 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: Is RSVP-TE return path used only in "ping" mode or also in trace-route mode?

14) Section 5.3 last paragraph: I think you need to delete ICMP here. It has no meaning 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 3.1.7 and 3.1.8: What is Encapsulation Type and how is it encoded?

17) Section 3.2: Why are there multiple downstream labels in the downstream mapping? do they belong to different LSP levels? Or the figure is simply showing many downstream mapping TLVs? 

18) Section 3.3: what is the purpose of Pad TLV?

19) Section 4.3: Should an Echo reply always have a downstream mapping TLV even if no downstream mapping TLV is in the Echo request?

20) Section 4.4: Seems like back to back echo-request can't be sent before receiving the echo-reply of previous echo-request. Why this limitation?

21) Section 5.1: How is the downstream mapping TLV conveyed in the echo-reply sent over RSVP-TE? it seems no downstream mapping TLV is defined for RSVP-TE.

Thanks,
-Shahram

> -----Original Message-----
> From: George Swallow [mailto:[email-masked]]
> Sent: Tuesday, December 03, 2002 5:52 PM
> To: [email-masked]
> Subject: Last call on LSP Ping
> 
> 
> 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: Kireeti Kompella <[email-masked]>
Date: Wed, 11 Dec 2002 04:06:29 -0800 (PST)

Hi Shahram,

> Although I have no hope of getting any response, but here is a repeat of my ignored comments raised in March, 2002 and some new ones:

Does that mean I don't have to reply? :-)

>         milliseconds since midnight UT.

Is there a problem with having both seconds and microseconds?

> 2) Section 3: 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 ti…

Is there a problem if the time stamp is different?

> 3) 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 and subtracting the sub-TLV lengths from it. But
> the text says it could be determined by looking at the sub-TLV length
> field. Needs clarification.

You just said it.

> 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 hierarc…

Send multiple pings.

> 5) Section 3 under return code. There is no return code for the case that one of the FECs fail while others pass, or when one of the label mappings don't pass, while others pass.

Can you give me an example of such a case?

> 6) Why doesn't the MPLS ping permit pinging multiple FECs that belong to the same LSP level? It seems that if 1000s of FECs are all mapped to the same LSP, then 1000's of MPLS-pings are required.

[There is a delicious _attitude_ in the way you pose your questions.]

One could do that.

> 7) Why is the downstream label field in the downstream mapping TLV 24 bits? Is it for ATM? How is the 20 bit label mapped to this 24 bit?

Good question.  20 bits right justified.  Will clarify.

> 8) 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+1 as indicated)?

It's obvious I need to clarify this section.

> 9) Section 3.2 last paragraph: Does this apply to trace-route mode only?

See last para of section 4.1.

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

As the section makes clear the fields that are copied from the echo
request to the reply, it should be obvious that the downstream mapping
that the receiver computes is the only one in the echo reply (i.e.,
replace, not append).  But it doesn't hurt to say that explicitly.

> 11) Section 4.5: 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…

No LSP echo reply will be sent.

> 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)

No, it is correct as is.  A router that doesn't support MPLS ping will not
know how to deal with the MPLS echo reply.  It would get this
strange-looking packet and probably discard it.

> 13) Section 5: Is RSVP-TE return path used only in "ping" mode or also in trace-route mode?

Both.

> 14) Section 5.3 last paragraph: I think you need to delete ICMP here. It has no meaning here.

Okay.

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

Explain.

> 16) Section 3.1.7 and 3.1.8: What is Encapsulation Type and how is it encoded?

I'll add a reference.

> 17) Section 3.2: Why are there multiple downstream labels in the downstream mapping? do they belong to different LSP levels? Or the figure is simply showing many downstream mapping TLVs?

That LSR may swap and push.

> 18) Section 3.3: what is the purpose of Pad TLV?

To pad the ping packet, e.g., to test large packets.

> 19) Section 4.3: Should an Echo reply always have a downstream mapping TLV even if no downstream mapping TLV is in the Echo request?

No.

> 20) Section 4.4: Seems like back to back echo-request can't be sent before receiving the echo-reply of previous echo-request. Why this limitation?

Where did you read this?

> 21) Section 5.1: How is the downstream mapping TLV conveyed in the echo-reply sent over RSVP-TE? it seems no downstream mapping TLV is defined for RSVP-TE.

Do you think it should be added?

Kireeti.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 11 Dec 2002 14:38:17 -0500

In message <[email-masked]>, Kireeti Kompella 
writes:
> 
> > 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 isn't the

This is a unix time of day, not a time duration.  We'd have a lot of
timer wrap if our counter was only 71 minutes.  This was real annoying
with the older 32 bit MIB counters.  So please keep as is.

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

It is UDP with an unrecognized port number.  Send ICMP and discard.

> > 17) Section 3.2: Why are there multiple downstream labels in the downstream
>  mapping? do they belong to different LSP levels? Or the figure is simply sho
> wing many downstream mapping TLVs?
> 

To further clarify - if the LSR was at the ingress to a heirarchical
next hop.  For example, LDP over a TE hop does this.

> > 21) Section 5.1: How is the downstream mapping TLV conveyed in the echo-rep
> ly sent over RSVP-TE? it seems no downstream mapping TLV is defined for RSVP-
> TE.
> 

Not sure I understand the question.

> Kireeti.

Kireeti - I hope you don't mind my attempt to clarify a few points.
Just let me know if I get it wrong.

Curtis