Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping
draft-ietf-mpls-lsp-ping-relay-reply-11
Yes
(Deborah Brungard)
No Objection
(Alissa Cooper)
(Barry Leiba)
(Ben Campbell)
(Benoît Claise)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Spencer Dawkins)
(Terry Manderson)
Note: This ballot was opened for revision 10 and is now closed.
Alia Atlas Former IESG member
Yes
Yes
(2015-09-25 for -10)
Unknown
1) In Sec 2 above Figure 1 "1) Note that throughout the document, routable address means that it is possible to route an IP packet to this address using the normal information exchanged by the IGP operating in the AS." Shouldn't that be "by the IGP and BGP (or EGP) operating in the AS"??
Deborah Brungard Former IESG member
Yes
Yes
(for -10)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -10)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(2015-09-29 for -10)
Unknown
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?
Barry Leiba Former IESG member
No Objection
No Objection
(for -10)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(for -10)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -10)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -10)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -10)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -10)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2015-09-28 for -10)
Unknown
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!
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -10)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -10)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2015-09-30 for -10)
Unknown
- 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.)
Terry Manderson Former IESG member
No Objection
No Objection
(for -10)
Unknown