Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping
RFC 6425

Note: This ballot was opened for revision 18 and is now closed.

(Stewart Bryant) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

Comment (2011-08-06 for -)
No email
send info
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".

(Wesley Eddy) No Objection

(Stephen Farrell) No Objection

Comment (2011-08-11 for -)
No email
send info
(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.

(David Harrington) (was Discuss) No Objection

Comment (2011-08-08)
No email
send info
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.

(Russ Housley) No Objection

Comment (2011-08-11 for -)
No email
send info
  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

(Pete Resnick) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

(Sean Turner) No Objection

Comment (2011-08-08 for -)
No email
send info
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).

(Adrian Farrel) Recuse