Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping
RFC 6425
Yes
No Objection
Recuse
Note: This ballot was opened for revision 18 and is now closed.
(Stewart Bryant; former steering group member) Yes
(David Harrington; former steering group member) (was Discuss) No Objection
in 3.4, s/on the packet/in the packet/ in 4.2, s/is RECOMMENDED to/SHOULD/ in 4.2.1.1, there is a reference to <RSC>. your terminology section mentions <RSC>, butmade no sense to me at 1.2, and by the time I reached 4.2.1.1, I had forgotten it was mentioned in 1.2. I think this would be more effective if you provide the reference at first usage.
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Peter Saint-Andre; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
Very clear and readable document. Thank you.
I have a few minor editorial comments.
If I understand the formats of the P2MP Sub-TLVs in sections 3.1.1.1
and 3.1.1.2 correctly, the P2MP ID in both sub-TLVs are 32 bits long.
It is potentially confusing to show them as different sizes in the two
diagrams in those sections.
I was surprised not to find diagrams for the formats of the Egress
Address and Node Address Responder Identifier sub-TLVs in section 3.
If the authors think the format will be obvious to an implementor
based on the description of the sub-TLVs - they each carry a single
IPv4 or IPv6 address - there's no need for the diagrams.
I'm not sure how I would interpret this text from section 4.2.1.2
(similar text is used elsewhere in the document):
MAY be set to value 3 ('Replying
router is an egress for the FEC at stack-depth <RSC>') or any other
error value as needed
Should this be interpreted as "the Return Code MUST be set to either
the value 3 or an error value" or "the Return Code MAY be set; if it
is set, is MUST be set to the value 3 or an error value".
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
Please consider the comments from the Gen-ART Review by Alexey Melnikov on 31-May-2011. The document has been updated since the review was posted, but it looks like these comments were not addressed. None of the comments are showstoppers. The review can be found here: http://www.ietf.org/mail-archive/web/gen-art/current/msg06355.html
(Sean Turner; former steering group member) No Objection
Two nits: 1) Maybe indent the bit that's copied from 4379: The motivations listed in [RFC4379] are reproduced here for completeness: When an LSP fails to deliver user traffic, the failure cannot always be detected by the MPLS control plane. There is a need to provide a tool that enables users to detect such traffic "black holes" or misrouting within a reasonable period of time. A mechanism to isolate faults is also required. 2) To line up with RFC 4875 r/Must/MUST in the packet figures in sections 3.1.1.1 and 3.1.1.2 (x4).
(Stephen Farrell; former steering group member) No Objection
(1) 4.2.1.3 gives "guidelines" as to what to do and has a list of Return Codes nodes that "MAY" be used but with no MUSTs. I found that a bit puzzling so maybe saying why these are guidelines and whether guideline == SHOULD would be good. (2) 4.3.3 says that when you get no answer, you SHOULD retry with a larger TTL. It doesn't say how long to wait though, nor when the SHOULD doesn't apply. Maybe that SHOULD would be better as a "could" and explicitly say that you're just leaving it all to the implementer? (3) This is probably a dumb question but it wasn't clear to me how the replies get back to the node sending the ping. 4.1.2 says that the P2MP LSPs are unidirectional and that replies "are often sent back through the control plane" but that, by itself, doesn't make it clear to me. I assume that this would be clear to implementers but just wanted to check.
(Wesley Eddy; former steering group member) No Objection
(Adrian Farrel; former steering group member) Recuse