Deal Authors, (resend - error on previous email) I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments. Document Reviewed - draft-ietf-mpls-lsp-ping-reply-mode-simple-03 Link to Document - https://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply-mode-simple-03 This document updates RFC7110 (Return Path Specified Label Switched Path (LSP) Ping) by updating the usage of the 'Reply Mode value 5' by removing the need to include the 'Reply Path TLV' and introduces a new optional TLV to describe a list of Reply Mode values when using the MPLS Ping echo/echo reply protocol functions. This document is on the Standards Track, and makes the modifications as noted above and updates RFC7110. This document is generally well written and articulates the perceived challenges with the 'Reply Mode Value 5' usage, and provides contextual information on why the protocol modifications are desirable.  The document targets better protocol implementations to help alleviate (or at least reduce) operational issues when using the  [RFC7110] 'Reply Mode value 5' MPLS features which is based on functionality documented in RFC4379 (Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures). The simplification presented in this document - by allowing the 'Reply Path TLV' to not be included and considered invalid, and allow for implied behaviors - is operationally more stable and desirable. There are some editorial comments (nits, text modifications and re-writes) which are provided as guidance, but not show stoppers to publishing.  The changes are suggested to help create clarity for the perceived objective of the text. Found In Nits: == Outdated reference: draft-ietf-mpls-proxy-lsp-ping has been published as RFC 7555 Abstract - ok Section 1: Introduction Paragraph 1 which can instruct the    responder LSR to use specific LSP to send the response back to the    initiator LSR which can instruct the    responder LSR to use a specific LSP to send the response back to the    initiator LSR Section 2: Problem Statement Paragraph 2, Second Bullet In case of a bi-directional       LSP, available return path(s) on transit LSRs can also depend on       whether LSP is completely co-routed, In the case of a bi-directional       LSP, available return path(s) on transit LSRs can also depend on       whether the LSP is completely co-routed, Paragraph 2, Fourth Bullet The MPLS LSP Ping operation is expected to terminate on egress       LSR The MPLS LSP Ping operation is expected to terminate on an egress       LSR Paragraph 4 This results in the    initiator LSR not receiving the MPLS LSP echo reply packets back. This failure mode results in the initiator LSR not receiving the intended MPLS LSP echo reply packets ** suggested paragraph text - I would reword the last couple of sentences to the following for clarity** The scenario described here is a potentially acceptable result in some failure cases, like a broken LSP, where the MPLS echo request terminated on an unintended target.  However, if the initiator does not receive an MPLS echo replay, even after the receiving LSR receives the MPLS echo request and is able to verify the request, information is sent back to the user(s) which is considered a false failure. Paragraph 5 Many operators prefer some return path(s) over others for specific    LSP types. Many operators prefer particular return path(s) over other return paths for specific    LSP types. ** suggesting the following re-wirte of the paragraph’s remaining test for clarity ** To accommodate operator preferred paths, implementations may default to operator preferred return paths for particular operations, or allow a default return path to be configured.  It would not be considered beneficial to use a preferred return path for an intended target LSR if there is previous knowledge at the initiator LSR that the return path is not available.  Using a unavailable preferred return path would undesirably result in the initiator not receiving the MPLS echo return packets.    It would be considered beneficial, for given operations, if the sender of the MPLS echo request would be able to determined return path availability before the operation is initiated. Paragraph 6 And that will result in simplified    implementations across vendors, and result in improved usability to    fit operational needs.   This new mode of operation would resulted in a simplification to implementations across the various vendors and improve both usability and operational needs Section 3 Section 3.1 Paragraph 1 Some LSP types are capable of having related LSP in reverse    direction, through signaling or other association mechanisms. Some LSP types are capable of having related LSPs in the reverse    direction, through signaling or other association mechanisms. This document    uses the term "Reverse LSP" to refer to the LSP in reverse direction    of such LSP types. This document    uses the term "Reverse LSP" to refer to the LSP in the reverse direction    of such LSP types. Section 3.2 Paragraph 1 This document also introduces a new optional TLV to describe list of    Reply Mode values This document also introduces a new optional TLV to describe a list of    Reply Mode values Section A.2 Paragraph 4 One can argue that the initiator LSR can automatically generate a    same MPLS echo request … One can argue that the initiator LSR can automatically generate the    same MPLS echo request regards, Victor Kuarsingh