The MPLS WG Archive

["Gray, Eric" <egray@celoxnetworks.com>]

George,

	Here are my last call comments on the LSP Ping draft (nits
intermixed with technical comments):

1) In general, there are several minor indications that the draft may
   not have been quite ready for last call.  The draft includes many
   partially described features and at least one incomplete section.
   Some features seem not quite fully baked, even if they are fairly
   adequately described. TLV definitions are not described in a way
   that is conducive to compatibility with future versions, and there 
   are other such indications as are reflected in comments below.
   However, once the issues are addressed, this specification will be
   very useful piece of work. 

2) The "Return Subcode" field in the format "picture" (page 5) should 
   be "Reserved" instead; no values are defined for it and it is
   supposed to be set to zero.  The text on page 6 describing this 
   field should also be changed to reflect the field name change.
   Other text should be changed to omit references to this field.
   The current field name presupposes a use for this field not yet
   (and therefore, possibly, never to be) defined.

3) At the end of the first paragraph on page 6, the parenthesized 
   text should be changed to read "(this is currently only defined
   for control planes that uses RSVP-TE)."
                    =               ===

4) For the Sender's handle, the text "There are no semantics associated 
   with this handle," (page 6) should be changed to replace "associated 
   with" with "defined for".  The intention should be that the receiver
   is not allowed to infer meaning from the bits in this field, not that
   there is no meaning.  With this change, the text "although the sender
   may find this for ..." could be removed.

5) The sentence at the top of page 7 should be changed to read - "TLVs 
   (Type-Length-Value tuples) and sub-TLVs have the following format"
   (there is no separate description of sub-TLV formats).

6) The first paragraph in section 3.1 should be changed to read - 
=======================================================================
   A Target FEC Stack is a list of sub-TLVs.  The number of elements is
   determined as a result of the combination of TLV length, and sub-TLV 
   length, fields.
=======================================================================

7) Immediately after the table in section 3.1 (page 7), the phrase 
   "Other FEC Types will be defined as needed" is not reflected in 
   IANA  considerations section - which is currently empty (the draft
   should not have been sent for WG last call with this sections
   empty).

8) First paragraph in section 3.1.3 should read - "... [RSVP-TE], 
   sections 4.6.1.1 and 4.6.2.1" - (corrected reference and moved
   close bracket).  Similarly, the first paragraph in section 3.1.4 
   should read "... [RSVP-TE], sections 4.6.1.2 and 4.6.2.2".

9) In the formats specified in sections 3.1.3 and 3.1.4 (RSVP IPv4 
   and IPv6 Session TLVs, an entire word can be eliminated from the
   TLV by simply replacing the first "Must be zero" field with the
   LSP ID field in the last word (eliminating the last 32-bit word).

10) The document editor should use nroff blocking with format diagrams
   (example - format diagrams in 3.1.3, 3.1.8 and elsewhere).

11) Sub-TLV lengths are inconsistent with format diagrams in sections
   3.1.5, 3.1.6, 3.1.7 and 3.1.8. If the authors intend that sub-TLVs
   should be contiguous, the "Must be zero" fields at the end of these
   diagrams should simply be omitted.  If the authors intended these
   fields to indicate padding to nearest word boundary, then sub-TLV
   lengths should be "rounded up" to the nearest multiple of 4.  Based
   on the definitions for LDP IPv4 and IPv6 Prefix sub-TLVs, it looks
   as if the intent was not to pad (there is no format diagram, nor a
   statement as to the alignment - therefore, the "Must be zero" fields
   would actually contain sub-TLV Type and Length information.  Based 
   on the supposition that the definition of TLV is meant to apply as
   well to sub-TLVs (see #4 above), valid length values for TLV value
   fields should be an even multiple of 4.

12) In section 3.2 the format diagram contains the fields Interface 
   Address and Downstream Label which are not described in subsequent 
   text.  In addition, the description for Address Type is buried in a
   paragraph describing MTU.  These fields need to be described briefly
   in bullets immediately following the diagram. If the descriptions
   would not make sense without the text that follows the diagram, then
   that text should precede the diagram.

13) The first sentence in the paragraph at the very bottom of page 11
   should be changed to read "The notion of 'downstream router' is 
   explained as follows:" (otherwise, it is not clear that authors
   are not leaving this as an exercise for the reader).  This should
   be made clearer, because it is hard to be sure that the notion has
   been explained - i.e. - some return codes indicate that the receiver 
   is (or is not) a "downstream router" (presumably from its own point
   of view) while the definition appears to be from the sender's point
   of view.

14) The delimited (===) text below is hard to understand.
=======================================================================
                                                       ... Consider an 
   LSR X.  If a packet with outermost label L and TTL n>1 arrived at X
   on interface I, X must be able to compute which LSRs could receive
   the packet with TTL=n+1, and what label they would see.  (It is
   outside the scope of this document to specify how this computation
   may be done.)  The set of these LSRs are the downstream routers (and
   their corresponding labels) for X with respect to L.

   The case where X is the LSR originating the echo request is a special
   case.  X needs to figure out what LSRs would receive a labelled
   packet with TTL=1 when X tries to send a packet to the FEC Stack that
   is being pinged.
=========================================================================

   What the first paragraph seems to say is that X determines the set
   of downstream LSRs as those to which it might forward an unexpired
   labeled packet for the FEC(s) in question.  If that is what it is 
   trying to say, it could be said in an easier to understand way.

   I do not understand in what way X - as the originator of the Ping
   - is a special case.  Presumably it is the only LSR that would do
   this, therefore, it is "special" only in the sense that it is the
   only LSR to which this applies.

15) The use of the Pad TLV (defined in section 3.3) is not described 
   in the text other than to state whether or not the Pad TLV is to
   be returned to the sender.  Exactly how would the Pad TLV be used
   and why is it needed?

16) The Error code TLV should not be included in this specification
   if it is not going to be defined in this specification.  Instead,
   the IANA considerations section should include requirements for
   management of the TLV type space associated with this specification.

17) In section 4.1, the point in randomly selecting an address from   
   the address range 127/8 is inadequately specified in the draft and
   has not been resolved in mailing list discussions. The common belief
   at this point is that this is provided in order to provide some hope
   of being able to test multiple ECMP paths.  The specification should 
   either specifically address behavior required to support Ping and
   Trace-Route of ECMP equal cost paths, or it should not address it at
   all.  Several suggestions have been made to date as to how the
   specification could handle ECMP paths; either one of them should be
   documented in this specification, or the specific wording should be
   changed to indicate that the destination address in the UDP packet
   should be chosen from the address range 127/8 using a mechanism not
   defined by this specification.

18) First sentence in section 4.3 should read "When the Reply Mode in
   an MPLS echo request is 2 or 3, an MPLS echo reply is constructed 
   as a UDP packet."  Alternatively, this should be a subsection, or
   the section heading should distinguish this from a control plane
   echo reply.  The latter approach is probably better, since all of
   the paragraphs in this section apply only to the UDP reply case. I
   would suggest something like -

   "4.3 Sending an MPLS Echo Reply via UDP"

19) The second sentence, first paragraph of section 4.4 should be
   changed to read - 

=======================================================================
                               "...  Thus, on receipt of an MPLS Echo
   Reply, X should parse the packet to assure that it is well-formed,
   then attempt to match up the Echo Reply with an Echo Request that it
   had previously sent, using (for example) the destination UDP port 
   and the Sender's Handle."
=======================================================================

   The sender should be free to determine on its own what means it
   will use to match a request with a reply and can do so as long 
   as the receiver has followed the rules.  Several approaches may
   be used: for example, a sender may have only one outstanding 
   echo request at a time or it may use the Sequence Number (and, 
   possibly, Time Stamp Sent).
   
20) For the RSVP-TE extension, the Time Stamp Sent should be copied to
   the Time Stamp field in the LSP ECHO object - or there should be a
   field for both Send and Receive Time Stamps. Because of differences 
   in local times likely (especially in microseconds) at two different 
   devices in the network, the time sent is likely to be of more use 
   than the time received.  For example, the time sent may be used to 
   determine which of several Pings sent is being responded to in the 
   event that multiple Pings were sent with the same sequence number.  
   Also, the Time Stamp sent can be used as a reliable way to detect
   changes in round-trip time for the Ping request/reply messages.

21) I do not see why [RSVP] and [RSVP-REFRESH] are listed as Normative
   references.  In the [RSVP] case, it does not much matter because it
   is necessarily the case that this specification has a Normative
   references to [RSVP-TE] which it self has normative references to 
   [RSVP] - though the explicit reference is redundant, especially
   given that this specification makes no apparent direct references
   to [RSVP].  However, there is no reason to include [RSVP-REFRESH]
   as a reference at all.

22) RFC 768 [UDP] should be listed as a Normative reference.

23) The last paragraph in section 8 (appropriately named Security
   Considerations) is wrong, in particular with respect to the 
   Downstream Mapping TLV.  The contents of this TLV are of a
   particularly useful nature to anyone wishing to deny access
   to the service being "Ping-ed" and should be secured against
   the possibility of un-trusted viewing.


Eric W. Gray
Systems Architect
Celox Networks, Inc.
egray@celoxnetworks.com
508 305 7214


> -----Original Message-----
> From: George Swallow [mailto:swallow@cisco.com]
> Sent: Tuesday, December 03, 2002 5:52 PM
> To: mpls@UU.NET
> 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
>