The MPLS WG Archive

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

Hi,

Please ignore my last email with this subject. I intended the
comments for MPLS-ping.

Thanks,
-Shahram

> -----Original Message-----
> From: Shahram Davari 
> Sent: Wednesday, December 04, 2002 4:31 PM
> To: 'George Swallow'; mpls@UU.NET
> Subject: RE: Last Call on Fast Reroute
> 
> 
> 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
> > 
> > 
> > 
>