Return Path Specified Label Switched Path (LSP) Ping
draft-ietf-mpls-return-path-specified-lsp-ping-15

There is no benefit to using an IPv4-mapped IPv6 address to represent loopback addresses and there have been recommendations to not use them whenever possible.  Given that the original specification (RFC 4379) defined the use of IPv4-mapped IPv6 addresses in the multipath information field, it is not the fault of this document for their use.  In general, the use of IPv4-mapped addresses is very limited and the use-case here does not call for their use. The native IPv6 loopback would have been more appropriate.

the use of ipv4 mapped address in lieu of the whole 0000::/8

0:0:0:0:0:FFFF:127.0.0.0/104 in section 4 kind of gives me heart burn.

in general ipv4 transition-isms shouldn't make their appearance or be imparted special meaning when that's unnecessary. and it appears to be uneccessary in this case.

e.g.

   The destination IP address of the echo reply message MUST
   never be used in a forwarding decision.  To avoid this possibility
   the destination IP address of the echo reply message that is
   transmitted along the specified return path MUST be set to numbers
   from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127.0.0.0/104 for
   IPv6, and the IP TTL MUST be set 1, and the TTL in the outermost
   label MUST be set to 255.

e.g. ::2/128 has the same result.

The MTU issue should be checked.

I echo Stewart's Discuss about terminology and his Comment about whether there are any MTU size concerns that should be mentioned.

Thanks for adding the security consideration text
that resolved my discuss. I think you could do with
a bit more editing of that text, but I'm sure that'll
be fixed in AUTH-48. Feel free to ping me if you
want though.

I didn't check the comments below vs. the latest
version. Again, let me know if there's something
more to say or do.

Thanks,
S.

-------

- 3.2: "A flag" - I didn't find the description here easy to
follow. Setting this means "don't use the path you'd use if
reply mode 2 or 3 was sent" but how does the egress LSR know
what non-default path to pick?

- 3.2: "B flag" - I don't get how the return path is known.
Maybe the same problem (of my understanding) as the for the A
flag:-)

- 3.2: The reply paths sub-TLV seems underspecified.  Maybe a
ref to a bit of 4379 is needed?

- 3.3: How can a sub-tlv with no typing carry any "future
defined" type? (That is I support Stewart's discuss.)

- 3.3: I can't parse this "One usage of these generic RSVP
Tunnel sub-TLVs is when LSP Ping is used to periodically
verify the control plane against the data plane [RFC5884],
using Tunnel other than particular LSP can avoid the impact
of LSP identifier changing when Make-Before-Break (MBB) is
deployed."

- 4: "the echo reply MUST carry the FEC stack information in
a Reply Path TLV" huh? do you mean echo request? and don't
you need to say which of 3.3.x is the one to use? (presumably
3.3.3)

Thank you for making the clarifying changes to the text.