Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels
Note: This ballot was opened for revision 11 and is now closed.
(Stewart Bryant) Yes
(Adrian Farrel) Yes
(Ron Bonica) No Objection
(Gonzalo Camarillo) No Objection
(Ralph Droms) No Objection
Comment (2011-08-06 for -** No value found for 'p.get_dochistory.rev' **)
Very minor editorial suggestions: Section 1: This documents describes methods for performing LSP-Ping (specified in [RFC4379] traceroute over MPLS tunnels. change to "This document [...]"; is there a right paren missing? In the next sentence "in case where" sounds wrong; perhaps use "in the case where" for both parts of the sentence? Section 3.3.1: MAY be include [...] change to "MAY be included"
(Wesley Eddy) No Objection
(Stephen Farrell) No Objection
Comment (2011-08-11 for -** No value found for 'p.get_dochistory.rev' **)
I see that this defines a "NIL FEC" that can be used to hide information, which is just fine. That made me wonder though if this is only needed here or maybe also elsewhere (e.g. in draft-ietf-mpls-p2mp-lsp-ping)? Or, perhaps other MPLS ping functions need some equivalent? (Just checking.)
(David Harrington) (was Discuss) No Objection
in 3.2.1, s/the node needs to return a different Return Code/Return SubCode for each downstream. / the node needs to return a Return Code/Return SubCode for each downstream./ (I suspect that each return code may not need to be different) in 3.4, "The Downstream Mapping TLV has been deprecated." should this be "This document deprecates the Downstream Mapping TLV"? If another document specified the deprecation, please provide a reference.