Subject: RE: Last call on LSP Ping

From: Shahram Davari <[email-masked]>
Date: Thu, 5 Dec 2002 11:39:57 -0800

Some more comments:

22) I can't understand section 3.2 at all. Since TTL=n+1 makes no sense, for the sake of argument I'll assume you meant TTL=n-1. Now let's assume the following topology:

   L1       L2       L3
-------R1-------R2-------R3
                  \   L4
                   \-----R4

In which R1, R2, R3, and R4 are LSRs and L1, L2, L3 and L4 are each a set of labels that are received on those LSRs.
 
It seems from the text that the following sequential behavior is expected: (DM means Downstream Mapping TLV)

Ingress => Echo Request: DM (R1, L1)
R1      => Echo Reply  : DM (R2, L2)
Ingress => Echo Request: DM (R2, L2)
R2      => Echo Reply  : DM (R3, L3 and R4, L4)
Ingress => Echo Request: DM (R3, L3 and R4, L4)
etc.

Is this the behavior that is intended? And does it apply only to trace-route?
What is the purpose of this function? it seems that DM is being used to extract the
whole switching table of each interface, is that correct? If so, then it is neither ping, nor trace-route?

23) section 4.1: In order to exercise all the ECMP paths, you need to scan through all 127/8 addresses (16 million of them), don't you think this is not feasible?

24) Section 4.1: Why should an LSR send multiple echo requests with the same seq#? What function is in mind that can't be achieved by incrementing seq #?

-Shahram

> -----Original Message-----
> From: Shahram Davari 
> Sent: Wednesday, December 04, 2002 4:40 PM
> To: 'George Swallow'; [email-masked]
> Subject: RE: Last call on LSP Ping
> 
> 
> 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:22:45 -0800 (PST)

Hi Shahram,

> 22) I can't understand section 3.2 at all. Since TTL=n+1 makes no sense, for the sake of argument I'll assume you meant TTL=n-1. Now let's assume the following topology:

It's quite simple: read "initial TTL=n>1", "initial TTL=n+1", etc.

> In which R1, R2, R3, and R4 are LSRs and L1, L2, L3 and L4 are each a
> set of labels that are received on those LSRs.

Correction: L1, ... L4 are all label mappings for a given FEC.  Also,
R3 and R4 are equidistant from R2.  To make this more exciting, add an
R5 with label L5 such that R5's metric from R2 is bigger than R3's.

> Is this the behavior that is intended? And does it apply only to trace-route?

Yes (with the changes above), and yes.

> whole switching table of each interface, is that correct? If so, then it is neither ping, nor trace-route?

No, just the label bindings for a given FEC.

> 23) section 4.1: In order to exercise all the ECMP paths, you need to
> scan through all 127/8 addresses (16 million of them), don't you think
> this is not feasible?

"The difficult, we do immediately.  The impossible takes a little longer."

> 24) Section 4.1: Why should an LSR send multiple echo requests with the same seq#? What function is in mind that can't be achieved by incrementing seq #?

To increase the probability of receipt of a ping with a given sequence
number.

Kireeti.