The MPLS WG Archive

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

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:swallow@cisco.com]
> Sent: Tuesday, December 03, 2002 5:50 PM
> To: mpls@UU.NET
> Subject: Last Call on Fast Reroute
> 
> 
> This message begins a workgroup last call on:
> 
> Fast Reroute Extensions to RSVP-TE for LSP Tunnels
>     
>   draft-ietf-mpls-rsvp-lsp-fastreroute-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
> 
> 
>