The MPLS WG Archive

[Jean Philippe Vasseur <jvasseur@cisco.com>]

Sharam,

I guess this email was for LSP Ping.

JP.

At 13:30 04/12/2002 -0800, Shahram Davari wrote:
>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
> >
> >
> >