Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
draft-ietf-mpls-lsp-ping-13

[Ballot discuss]
The authors fixed the IPv6 address typos, but I still have open issues with this document that were not addressed from my previous discuss:

> Section 2.1 indicates that the mechanism will use 127/8 address embedded in > IPv6 addresses, but it doesn't say which mechanism will be used for this
> (there are two).  Also, an address example might be helpful.

The authors indicated via e-mail that they planned to use "IPv4 mapped IPv6 addresses", whis is okay.  But, I still don't see that stated in the -12 version of the document.  Also, the text should explicitly indicate that this address would have the form 0::FFFF:127.x.x.x, and the document should include a normative reference to the IPv6 addressing architecture (RFC 3513).

Also, there are still no IPv6 examples that show how/where the IPv4 mapped IPv6 address would be used.  The only examples of IPv6 addresses in the document show 0::1, which is the IPv6 loopback address.  This is inconsistent with the text in section 2 that indicates that mapped addresses will be used, as this is a native IPv6 address, not the IPv4 mapped IPv6 address for 127.0.0.1, which would be "0::FFFF:127.0.0.1".

If the intent is to use 0::1 in some places and IPv4 mapped IPv6 addresses in others, that needs to be explained.  Also, there should be at least one example showing where/when/how an IPv4 mapped IPv6 address will be used.

[Ballot comment]
- Still need [PW-CONTROL] refernce in section describing FEC 129 (section on FEC 128 has it now).

- The following terms for "FEC 128" and "FEC 129" are more consistent with [PW-CONTROL] (if you search on "128" or "129" in the PW-CONTROL document, you get nothing, because it uses 0x80 and 0x81).

For FEC128: The PWid FEC Element
For FEC129: The Generalized PWid FEC Element

- I know I asked for a normative reference to RFC4026, but it should be Informative given that RFC4026 is informative.

- Something that isn't mentioned in the security considerations section, if the UDP source port is varied when sending an echo request, it is something else an unsophisticated hacker would have to guess correctly for an echo reply.

- IANA Considerations: I believe the return code should be an IANA registry. I think George agreed, and probably just forgot to include it.

>  Value Meaning ----- -------
>  0 No return code
>  1 Malformed echo request received
>  2 One or more of the TLVs was not understood
>  3 Replying router is an egress for the FEC at stack depth
>  4 Replying router has no mapping for the FEC at stack depth
>  5 Downstream Mapping Mismatch (See Note 1)
>  6 Upstream Interface Index Unknown (See Note 1)
>  7 Reserved
>  8 Label switched at stack-depth
>  9 Label switched but no MPLS forwarding at stack-depth
>  10 Mapping for this FEC is not the given label at stack depth
> 
>  11 No label entry at stack-depth
>  12 Protocol not associated with interface at FEC stack depth
>  13 Premature termination of ping due to label stack shrinking to a
>  single label

[Ballot comment]
- Still need [PW-CONTROL] refernce in section describing FEC 129 (section on FEC 128 seems to be OK).


- The following terms for "FEC 128" and "FEC 129" are more consistent with [PW-CONTROL] (if you search on "128" or "129" in the PW-CONTROL document, you get nothing, because it uses 0x80 and 0x81).

For FEC128: The PWid FEC Element
For FEC129: The Generalized PWid FEC Element

- I know I asked for a normative reference to RFC4026, but it should be Informative given that RFC4026 is informative.

- Something that isn't mentioned in the security considerations section, if the UDP source port is varied when sending an echo request, it is something else an unsophisticated hacker would have to guess correctly for an echo reply.

- IANA Considerations: I believe the return code should be an IANA registry. I think George agreed, and probably just forgot to include it.

>  Value Meaning ----- -------
>  0 No return code
>  1 Malformed echo request received
>  2 One or more of the TLVs was not understood
>  3 Replying router is an egress for the FEC at stack depth
>  4 Replying router has no mapping for the FEC at stack depth
>  5 Downstream Mapping Mismatch (See Note 1)
>  6 Upstream Interface Index Unknown (See Note 1)
>  7 Reserved
>  8 Label switched at stack-depth
>  9 Label switched but no MPLS forwarding at stack-depth
>  10 Mapping for this FEC is not the given label at stack depth
> 
>  11 No label entry at stack-depth
>  12 Protocol not associated with interface at FEC stack depth
>  13 Premature termination of ping due to label stack shrinking to a
>  single label

[Ballot comment]
- Still need [PW-CONTROL] refernce in section describing FEC 129 (section on FEC 128 seems to be OK).


- The following terms for "FEC 128" and "FEC 129" are more consistent with [PW-CONTROL] (if you search on "128" or "129" in the PW-CONTROL document, you get nothing, because it uses 0x80 and 0x81).

For FEC128: The PWid FEC Element
For FEC129: The Generalized PWid FEC Element

- I know I asked for a normative reference to RFC4026, but it should be Informative given that RFC4026 is informative.

- Something that isn't mentioned in the security considerations section, if the UDP source port is varied when sending an echo request, it is something else an unsophisticated hacker would have to guess correctly for an echo reply.

- IANA Considerations: I believe the return code should be an IANA registry. I think George agreed, and probably just forgot to include it.

>  Value Meaning ----- -------
>  0 No return code
>  1 Malformed echo request received
>  2 One or more of the TLVs was not understood
>  3 Replying router is an egress for the FEC at stack depth
>  4 Replying router has no mapping for the FEC at stack depth
>  5 Downstream Mapping Mismatch (See Note 1)
>  6 Upstream Interface Index Unknown (See Note 1)
>  7 Reserved
>  8 Label switched at stack-depth
>  9 Label switched but no MPLS forwarding at stack-depth
>  10 Mapping for this FEC is not the given label at stack depth
> 
>  11 No label entry at stack-depth
>  12 Protocol not associated with interface at FEC stack depth
>  13 Premature termination of ping due to label stack shrinking to a
>  single label

[Ballot discuss]
While some of my concerns about this document have been addressed, there is still at least one that remains.

>>    The contents of the field are shown in the table above.
>>    IP addresses are drawn from the range 127/8.
>
>There are references to these addresses in several places in the document. >What does an IPv6 system do?

The document now says two different things about IPv6 addresses, but I don't think that either of them is quite right.

Section 2.1 indicates that the mechanism will use 127/8 address embedded in IPv6 addresses, but it doesn't say which mechanism will be used for this (there are two).  Also, an address example might be helpful.

Other places in the document refer to an IPv6 address of 0::1:, which is just clearly wrong.  Do they mean 0::1, the IPv6 loopback address?

Also, there are a lot of IPv4 address encoding examples and no IPv6 examples.  It might be clearer if at least one IPv6 example were provided.

[Ballot discuss]
Section 3.2 describes a bunch of FEC mapppings for various ways you
could get labels including LDP,,, BGP, various VPN specifications,
etc.  I believe the references to these specifications need to be
normative rather than informative.  I don't think you can implement
the required functionality for pinging a L3VPN without understanding
the L3VPN spec in addition to this spec.  I'm dubious that you could
even figure out what the sections on L3VPNs mean without reading the
L3VPN spec or at least having normative knowledge of it.  I'm
concerned that adding that many normative references may slow down the
document; I wonder whether "How to ping an PWE3" and some of the other
documents that may still be blocked might need to become their own
document.


Section 4.4 does not describe how to determine if you have received an
echo request.  I suspect the answer is something like any packet for
the appropriate UDP port with an expired ttl on the outermost label
and any unlabeled packet destined to the node local network and right
UDP port.  There is probably a requirement for a router alert option
in the IP header but *not* for a router alert label.  Whatever it is,
this needs to be clearly spelled out for receivers to know what
behavior to implement.

The procedure in 4.4 is unclear to the point of being neither
reviewable nor implementable.  Based on the text, I kind of expect
there to be a loop over both the target FEC TLV and the label stack.
I can at least determine that there appears to be a loop over the
label stack but I cannot see where the target FEC is examined at all.
Variables are introduced without making it clear where they come from
or what their purpose is.  I could not infer invariants useful in
making an argument of correctness.  I couldn't even convince myself
that in a trivial case of pinging the right stack, you got a success.


IN which addressing context is the reply sent?  This is most obviously
a question in the case of pinging an L3VPN but it may be an issue for
other (possibly future) MPLS applications. 

How do we guarantee that an MPLS echo request can be distinguished
from non-IP packets on applications like PWE3.  We have advice that
such application should avoid situations where their packets look like
IP packets because of ECMP.  however that only gives you a higher
probability of reordering; it does not give you incorrect behavior.
having your packets end up triggering management behavior like an echo
response definitely counts as incorrect behavior.

--Sam

[Ballot discuss]
First, Alex, as per our discussion with authors of this document and draft-ietf-pwe3-control-protocol-17.txt, please use the following diagram for the FEC 129. We will align this with draft-ietf-pwe3-control-protocol-17.txt via an RFC Editor's note, and you could do the same as well.


  0                  1                  2                  3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Sender's PE Address                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Remote PE Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            PW Type            |  AGI Type    |  AGI Length  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                          AGI Value                          ~
|                                                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  AII Type    |  SAII Length  |    SAII Value      ...          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                  SAII Value (continued)                      ~
|                                                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  AII Type    |  TAII Length  |      TAII Value    ...          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                  TAII Value (continued)                      ~
|                                                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Value (cont.)| 0-3 octets of zero padding                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- Please include an informative reference to draft-ietf-pwe3-control-protocol-17.txt for definitions of these values.

- Also, please include a normative reference to RFC4026 for any L2VPN or L3VPN terminology used in this document.

Quoted text from the draft and comments follow (again, sorry for the length):

>  The V (Validate FEC Stack) flag is set to 1 if the sender wants the
>  receiver to perform FEC stack validation; if V is 0, the choice is
>  left to the receiver.


Why leave the choice to the receiver at all for 0? If the sender is the initiator of the ping, and presumably the one looking to troubleshoot, wouldn't it be better to give him a fully deterministic choice?

Also, giving the choice to the receiver doesn't match the pseudocode in section 4.

>  Any application which supports an IP control channel between its con-
>  trol entities may set the Reply Mode to 4 to ensure that replies use
>  that same channel. Further definition of this codepoint is applica-
>  tion specific and thus beyond the scope of this document.


Not exactly sure what to do with this. First, "IP control channel" do you mean targeted LDP for a PW? VCCV? RSVP? Something else? All of the above? Perhaps an example would help.

>  The TimeStamp Sent is the time-of-day (in seconds and microseconds,
>  wrt the sender's clock)


>  (wrt the receiver's clock) that the corresponding echo request was
>  received.


>  The TimeStamp Sent is set to the time-of-day (in seconds and
>  microseconds) that the echo request is sent. The TimeStamp Received
>  is set to zero.


First a nit: Do we really allow "wrt" in formal documents?

Discuss:

With respect to the TimeStamp itself, I'm concerned that the existing text is not specific enough in terms of (1) what value to insert, i.e., the "time-of-day" in seconds/microseconds could be interpreted differently by different implementations, and (2) that some application (perhaps monitoring an SLA) may rely on syncronization between the pinging peers a bit too much, for this some warning text may be in order.

For (1), I've sent an email to NTP chairs on this topic, and have been referred to RFC 2330 which has a lot of data on gotchas with timestamps in protocols as well. I'm not sure yet what the right thing to do here is. At a minimum, since the text says it is sending "time-of-day" in seconds/microseconds, a starting time would be useful for this counter (e.g., is it Jan 1, 1970, or some other value?). Even RFC 792 (see page 17), which it looks like this was modeled after, includes a start reference and defines a bit to be set for when this particular time is not available for whatever reason. I think the bar for lsp-ping should be at least as high as ICMP-ping here, and its either missing something or I am missing an assumption.

>  Types less than 32768 (i.e., with the high order bit equal to 0) are
>  mandatory TLVs that MUST either be supported by an implementation or
>  result in the return code of 2 ("One or more of the TLVs was not
>  understood") being sent in the echo response.
>
>  Types greater than or equal to 32768 (i.e., with the high order bit
>  equal to 1) are optional TLVs that SHOULD be ignored if the implemen-
>  tation does not understand or support them.


Comment: Wouldn't it just be easier to show a "Mandatory-bit" and define its semantics?

>  Say LSR X wanted to verify that a label stack of <1001, 23456> is the
>  right label stack to use to reach a VPN IPv4 prefix of 10/8 in VPN
>  foo. Say further that LSR Y with loopback address 192.168.1.1



An informational reference to RFC2547 (preferably the RFC2547bis draft since it has been approved already) wouldn't hurt here. Hate to be the reference police, but you hit on a lot of topics and the references section is anemic by comparison.

>  3.2.7. L2 VPN Endpoint
>
>  The value field consists of a Route Distinguisher (8 octets), the
>  sender (of the pin
>
> > Label_Validation:
> >
> > If the label at Label-stack-depth is valid, goto Label_Operation.
> > If not, set Best-return-code to 11, "No label entry at stack-depth"
> > and Best-return-subcode to Label-stack-depth. Goto
> > Send_Reply_Packet.
>
>  g)'s VE ID (2 octets), the receiver's VE ID (2 octets), and an
>  encapsulation type (2 octets), formatted as follows:


I don't think you can get around a reference to draft-ietf-l2vpn-vpls-bgp here, unless there is some other place a VE ID is defined. It's not a commonly known term.

>  3.2.8. FEC 128 Pseudowire (Deprecated)


>  3.2.9. FEC 128 Pseudowire (Current)
>
I hate to say it, but I think we need a reference for FEC 128 as well.

>  Maximum Transmission Unit (MTU)
>
>  The MTU is the largest MPLS frame (including label stack) that fits
>  on the interface to the Downstream LSR.


I assume this value is in octets, but please say so.

>  If an LSR does not know the IP address of its neighbor, then it MUST
>  set the Address Type to either IPv4 Unnumbered or IPv6 Unnumbered.
>  For IPv4 it must set the Downstream IP Address to 127.0.0.1, for IPv6
>  the address is set to 0::1. In both cases the interface index MUST
>  be set to 0. If an LSR receives an Echo Request packet with either
>  of these addresses in the Downstream IP Address field, this indicates
>  that it MUST bypass interface verification but continue with label
>  validation.


I'm a bit concerned about using localhost here. Perhaps 0.0.0.0 would be a better choice?

>  The Length is always 4; the value is the SMI Enterprise code, in net-
>  work octet order, of the vendor with a Vendor Private extension to


These are referred more accurately as "SMI Private Enterprise Codes," and a reasonable reference is RFC 1700.


>  An MPLS echo request is a (possibly) labeled UDP packet. The IP
>  header is set as follows: the source IP address is a routable address
>  of the sender; the destination IP address is a (randomly chosen)
>  address from 127/8; the IP TTL is set to 1. The source UDP port is


If the echo request is an unlabeled UDP packet (as seems to be possible from the above statement), it seems that we will be trying to *route* a packet to a random destination IP address??

>  If the "Validate FEC Stack" flag is not set, goto Send_Reply_Packet.


I mentioned this above. Earlier in the document, validating the FEC stack here is left "up to the receiver" based on this flag. The pseudocode in section 4.4 doesn't seem to allow for that.

>  Once an echo reply is received for a given Sequence Number (for a
>  given UDP port and Handle), the Sequence Number for subsequent echo
>  requests for that UDP port and Handle SHOULD be incremented.


This seems broken. Shouldn't I be able to send multiple Echo Requests, incrementing the Sequence number for a given UDP and Handle for each, before I receive an Echo Reply? Or, are outstanding requests tied in lockstep to replies? I doubt you want to do this. Removing this sentence entirely should fix this.

>  from the echo request; the TimeStamp Received is set to the time-of-
>  day that the echo request is received (note that this information is
>  most useful if the time-of-day clocks on the requester and the
>  replier are synchronized). The FEC Stack TLV from the echo request


There is an implication here that the clocks are synchronized, and thus some actual calculations between the sender and receiver timestamps may be performed. All the more reason to be explicit in what time-of-day really means here.

Security Considerations, multiple problems with this paragraph:

>  Replay and spoofing attacks are unlikely to be effective given that
>  the Sender's Handle and Sequence Number need to be valid. Thus a
>  replay would be discarded as the sequence has moved on. A spoof has
>  only a small window of opportunity, however an implementation MAY
>  provide a validation on the TimeStamp Sent to limit the window to the
>  resolution of the system clock.


- For the first sentence to be true, the Handle would need to be defined as cryptographically random [RFC1750]. I found no recommendation for assignment in this document other than "There are no semantics associated with this handle, although a sender may find this useful for matching up requests with replies."

- If the TimeStamp is in fact a global time-of-day (given that there are suggestions for synchronization between endpoints, I can only guess that it is), I can see no security advantage for detecting a rogue packet based on a timestamp window when an attacker can easily obtain this value from a variety of open sources.

- Sequence numbers: For Echo replies, since the value is copied from the echo request, the sender is the one in control of what value to expect and what can be dropped. This is valid. However, for Echo requests, trying to check a sequence number here may open more security holes than they patch.

Let me try to explain what I mean...

This is the only guidance in the document I can find for what to do with sequence numbers:

>  4.3. Sending an MPLS Echo Request


>  The sender chooses a Sender's Handle, and a Sequence Number. When
>  sending subsequent MPLS echo requests, the sender SHOULD increment
>  the sequence number by 1. However, a sender MAY choose to send a
>  group of echo requests with the same sequence number to improve the
>
>  4.4. Receiving an MPLS Echo Request


(No text at all in 4.4. on processing sequence numbers for an echo request)

Given the loose (and for 4.4 entirely lacking) definition here, an Echo Request sent with a random sequence number would have very unpredicatable affects on compliant implementations. There is no text or pseudocode that explains what is considered a reasonable window for old/dup vs. new sequence numbers, what the sequence numbers should begin with, etc. In fact, I'm fairly certain that implementations must be able to accept any sequence number without checking it at all in order to be interoperable given the text here (for example, how do I handle the case where a box reboots and starts sending sequence numbers from, say, 0? What if my implementation starts at 10000? Are these old, new or rogue packets?).

In the end, I don't think you *want* to put a lot of requirements on what sequence numbers should be on receipt of an echo request. So, instead of claiming them as anti-spoofing measures, I would specifically disallow an implementation from trying to inspect sequence numbers on receipt of echo requests to determine a rogue packet as doing so will probably open up more doors to DOS attacks by giving the hacker a way to get the sequence checking algorithm out of whack.

- Something that isn't mentioned, I do think a random UDP source port could be a way to make it a *little* more difficult for a hacker to spoof for echo replies (not requests, of course).

IANA Considerations:

I found the following enumerations in the document which could require an IANA action, but no text in the IANA Considerations section to back them up:

>  Value Meaning ----- -------
>
>  0 No return code
>
>  1 Malformed echo request received
>
>  2 One or more of the TLVs was not understood
>
>  3 Replying router is an egress for the FEC at stack depth
>
>  4 Replying router has no mapping for the FEC at stack depth
>
>  5 Downstream Mapping Mismatch (See Note 1)
>
>  6 Upstream Interface Index Unknown (See Note 1)
>
>  7 Reserved
>
>  8 Label switched at stack-depth
>
>  9 Label switched but no MPLS forwarding at stack-depth
>
>  10 Mapping for this FEC is not the given label at stack depth
> 
>
>  11 No label entry at stack-depth
>
>  12 Protocol not associated with interface at FEC stack depth
>
>
>  13 Premature termination of ping due to label stack shrinking to a
>  single label



>  Type # Address Type K Octets ------
>  ------------ -------- 1 IPv4 Numbered
>  16 2 IPv4 Unnumbered 16 3 IPv6 Numbered
>  40 4 IPv6 Unnumbered 28


>  The DS Flags field is a bit vector with the following format:
>
>  0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Rsvd(MBZ) |I|N| +-+-+-+-+-+-+-+-+
>
>
>  Two flags are defined currently, I and N. The remaining flags MUST
>  be set to zero when sending, and ignored on receipt.



>  Key Type Multipath Information ---
>  ---------------- --------------------- 0 no multipath
>  Empty (Multipath Length = 0) 2 IP address IP addresses
>  4 IP address range low/high address pairs 8 Bit-masked
>  IPv4 IP address prefix and bit mask address set 9 Bit-masked
>  label set Label prefix and bit mask


>  The Protocol is taken from the following table:
>
>  Protocol # Signaling Protocol ----------
>  ------------------ 0 Unknown 1 Static 2 BGP 3
>  LDP



>  Value Meaning ----- ------- 1 Drop Pad TLV from
>  reply 2 Copy Pad TLV to reply 3-255 Reserved for future
>  use

[Ballot discuss]
There were two addressing-related issues raised by Jari Arrko during review that need to be resolved before this document will be ready for publication:

>    An MPLS echo request is a (possibly) labeled UDP packet.  The IP
>    header is set as follows: the source IP address is a routable address
>    of the sender; the destination IP address is a (randomly chosen)
>    address from 127/8; the IP TTL is set to 1.  The source UDP port is
>    chosen by the sender; the destination UDP port is set to 3503
>    (assigned by IANA for MPLS echo requests).  The Router Alert option
>    is set in the IP header.

The use of 127.0.0.1 and other 127... addresses on the wire is against a MUST in RFCs 1122, 1700, 3330 and maybe others.

Interestingly, the echo responses are not sent using these fictional addresses. Is this because at MPLS level we may not know initially what the IP address of the egress point is? Or is there some other reason?

>    The contents of the field are shown in the table above.
>    IP addresses are drawn from the range 127/8.

There are references to these addresses in several places in the document. What does an IPv6 system do?

[Ballot discuss]
There were two addressing-related issues raised by Jari Arrko during review:

>    An MPLS echo request is a (possibly) labeled UDP packet.  The IP
>    header is set as follows: the source IP address is a routable address
>    of the sender; the destination IP address is a (randomly chosen)
>    address from 127/8; the IP TTL is set to 1.  The source UDP port is
>    chosen by the sender; the destination UDP port is set to 3503
>    (assigned by IANA for MPLS echo requests).  The Router Alert option
>    is set in the IP header.

The use of 127.0.0.1 and other 127... addresses on the wire is against a MUST in RFCs 1122, 1700, 3330 and maybe others.

Interestingly, the echo responses are not sent using these fictional addresses. Is this because at MPLS level we may not know initially what the IP address of the egress point is? Or is there some other reason?

>    The contents of the field are shown in the table above.
>    IP addresses are drawn from the range 127/8.

There are references to these addresses in several places in the document. What does an IPv6 system do?

I hate to defer a ballot given that there is a long delay between
telechats.  However I have serious concerns and need additional review
I cannot get today.

Concerns fall into three categories:

I'm concerned that security implications have not been considered
adequately.  It seems like this mechanism could be used to inject
packets across addressing domains and I need to consider whether there are new security  considerations with that.

Secondly, I have been unable to understand the traceroute mechanism fully.

Finally, the normative references section seems quite sparse.  I am concerned  especially with the PWE3 FEC TLVs that more normative references are required.

I'm not prepared to enter a discuss on these issues at this time although I'm reasonably certain a discuss will come when this is before the IESG.

[Ballot comment]
Nit from Gen-ART review by David Black:

  Nit: This draft uses "TTL" to refer the MPLS TTL and "IP TTL"
  to refer to the TTL in the IP header.  That convention makes
  sense for an MPLS draft, but it should be stated in the
  conventions section, just in case the reader is not an MPLS
  expert.

[Ballot comment]
From Gen-ART review by David Black:
(Note that there is also a nit at the end)

...
The MPLS ping mechanism is rather complex by comparison to the
IP ping mechanism.  Guidance on effective and appropriate use of
the available complexity would improve the draft.
...
Issue (1) has not been addressed in this version of the draft.
I think an AD-level discussion about intended audience for this
draft is in order - if this draft need only be accessible to an
MPLS expert audience (primarily implementers), then ignoring
Issue (1) is ok.  OTOH, if the draft should be accessible to
users of MPLS Ping (e.g., MPLS network administrators), Issue
(1) should be addressed.  I recommend that this discussion take
place and that a "Discuss" be placed against this draft only if
it is needed to cause or facilitate that discussion; such a
"Discuss" should include a promise to withdraw it if the
IESG concludes that MPLS experts are the only intended audience.

Here is the Issue (1) text from the original review:

  (1) IP ping and traceroute are robust debugging tools because they
  are based on a simple underlying TTL mechanism, so that if a ping
  or traceroute packet goes off into a void, one can be reasonably
  confident that something in the data plane is broken close to where
  the packet vanished.  MPLS ping/traceroute is considerably more
  complex (40+ page draft).  That's not necessarily bad, as MPLS
  is a more complex entity and ping/traceroute for MPLS has to deal
  with a known weakness in IP ping/traceroute, namely that an IP TTL
  mechanism can't see what's going on inside a tunnel ... and MPLS is
  all about what are essentially tunnels.  On balance, I think having
  a rich mechanism capable of probing the myriad ways in which MPLS
  could malfunction is highly desirable, but ...

  ... this complexity carries a risk of fragility - if an arbitrarily
  complex MPLS ping packet goes off into a void in the absence of other
  information, it's not as obvious that the data plane is broken (vs.
  the MPLS ping/traceroute logic being broken, or a mistake having been
  made in formatting the packet) in contrast to the IP case.  OTOH,
  there are a number of fairly simple examples in the draft that lead
  me to believe that the richness of the MPLS mechanism can be used
  with complexity commensurate to the problem being investigated, and
  that one can start simple and gradually increase the complexity as
  ping/traceroute success/failure yields more information about where
  the problem is (and isn't).  Section 4 on Theory of Operation contains
  some useful info, but it's mostly a complete specification of all
  the possible operational details at full depth.

  A complementary "advice on usage" and/or "examples of usage"
  section giving advice and/or examples of how to start with something
  simple and step up to more complex ping/traceroute probes as one
  learns more would be useful.  This sort of discussion of how to
  organize pursuit of problems would be valuable to both implementers
  (indication of what basic portions of MPLS ping/traceroute really
  need to be robust) and operators (advice on effective usage of the
  functionality). I realize that I started by noticing the length
  of the draft, and am nonetheless asking for it to be longer, but
  I think this would help.

...

  Nit: This draft uses "TTL" to refer the MPLS TTL and "IP TTL"
  to refer to the TTL in the IP header.  That convention makes
  sense for an MPLS draft, but it should be stated in the
  conventions section, just in case the reader is not an MPLS
  expert.

IANA Last Call Comments:
The IANA has the following comments releated to this document -

We have verified that port number 3503 has been assigned for LSP echo requests and replies. 

In the IANA Considerations section it says the following:
  Values from "Expert Review" ranges MUST be registered with IANA, and
  MUST be accompanied by an Experimental RFC that describes the format
  and procedures for using the code point; the actual assignment is
  made during the IANA actions for the RFC.

When will the expert review take place?  Before the Experimental RFC publication?  The IANA registration rules for the expert review range will say "Expert Review with an Experimental RFC".

The IANA will create new registries for Message Types, Reply Modes, and Return Codes and will populate the registries with the initial values described in this document.

The IANA will create new registries for the Type field of top-level TLVs as well as for any associated sub-TLVs.

We believe there is a typo in the document when describing the TLV sections.
Note the
  31744-32746 should maybe be 31744-32767

In the document it lists the intial registry for TLVs and sub-TLVs.
See the document for the list.  The IANA would like further clarification
on making registrations.  Do we understand it correctly that if a new Type is added and has sub-types, the sub-types then begin numbering based on the number that was assigned to the last sub-type, and will not begin numbering new at 1.
If the above is not clear, the would be happy to discuss with the Authors/WG chairs/ and/or ADs.