Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping
draft-ietf-mpls-lsp-ping-relay-reply-11

I have some comments/questions:

1. TBD2 is the Relay Node Address Stack TLV Type.  There seems to be some confusion in the text: Section 4.2. (Receiving an Echo Request)  says that the "Type of the Relay Node Address Stack TLV is chosen from the range 32768 to 49161…” giving the impression that any value can be used, while 8.2. (New TLV) in the IANA Considerations says that a "suggested value should be assigned” giving me the impression that the assignment is just a suggestion (and somehow reinforcing the text in 4.2), but the original definition in 3.2. (Relay Node Address Stack) simply says that the "value should be assigned by IANA”.  Assuming that you simply want an assignment and that it would be what is used, please clean the text up; I suggest just referring to the value as TBD2 (in 4.2 and 8.2) and explicitly including the text about the assignment and the range (from 3.2) in 8.2.

2. Section 4.1. (Sending an Echo Request) says that the "Relay Node Address Stack TLV MUST be carried in the Echo Request message if the relay functionality is required”.  How does the initiator know that it needs the functionality?

3. Section 4.2. (Receiving an Echo Request) "A second or more address entries MAY also be added if necessary, depending on implementation.”  Isn’t this document defining how the implementation should work?  What are the cases where these additional entries may be added?

Thanks for your work on this draft.  The security review from 6 months ago hasn't been fully addressed in the draft and I think it would be helpful to do so.  There were responses given on list, but corresponding updates didn't happen for all of the comments.

https://www.ietf.org/mail-archive/web/secdir/current/msg05301.html

For the first comment, the response was that this mechanism does not deprecate use of "Echo Reply".  The language in the first paragraph of section 3 should be made clear on that point.

For the second comment:
    s4.1: Is the outermost label allowed to be set to 255 to support the
    “ping” mode or must it always be set to 1, 2, etc. to support “traceroute"
    mode - as described in RFC 4379 s4.3?   I know s5 is just an example
    but it really looks like this extension is just supposed to be for fault
    isolation.

The response via email says it is possible to set it to 255, could this be made clear in the draft?

The third comment was addressed, thank you.

It was also good to see the security considerations cover path discovery as well as DoS related attacks.  Thanks for that!

- 3.2: The description of the destination address offset isn't
clear to me. If this is some common thing in MPLS though, that's
fine. If not, maybe it'd be worth being clearer here.
(It does become clear later though, so this is a nit.)