Return Path Specified Label Switched Path (LSP) Ping
RFC 7110
Note: This ballot was opened for revision 13 and is now closed.
(Adrian Farrel) (was Discuss, Yes) Yes
Comment (2013-09-22 for -13)
No email
send info
send info
RFC Editor Note added to cover the issue raised by IANA
(Jari Arkko) No Objection
(Stewart Bryant) (was Discuss) No Objection
Comment (2013-12-02)
No email
send info
send info
Thank you for making the clarifying changes to the text.
(Gonzalo Camarillo) No Objection
(Spencer Dawkins) No Objection
Comment (2013-09-23 for -13)
No email
send info
send info
I echo Stewart's Discuss about terminology and his Comment about whether there are any MTU size concerns that should be mentioned.
(Stephen Farrell) (was Discuss) No Objection
Comment (2013-10-30)
No email
send info
send info
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)
(Brian Haberman) (was No Record, Discuss) No Objection
Comment (2013-09-25 for -13)
No email
send info
send info
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.
(Joel Jaeggli) No Objection
Comment (2013-09-22 for -13)
No email
send info
send info
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.
Barry Leiba No Objection
(Pete Resnick) No Objection
(Martin Stiemerling) No Objection
Comment (2013-09-24 for -13)
No email
send info
send info
The MTU issue should be checked.