Hi, Please find below the Routing Area Directorate (rtgdir) review for draft-ietf-mpls-lspping-norao-02. I'll be happy to provide further clarifications or provide text as appropriate. I hope these are useful and clear. More Substantive: Abstract The echo request and echo response messages, defined in RFC 8029 "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures" CMP> In the first line, the messages are misnamed. I suggest: The MPLS echo request and MPLS echo response messages, defined in RFC 8029 "Detecting MPLS Data-Plane Failures"... CMP> While this might seem, on the surface, an editorial, I feel it CMP> is important for two main reasons. CMP> First, the actual name of the messages is "MPLS echo request" CMP> and "MPLS echo reply". CMP> Second, as it was discussed during RFC 8029, it disambiguates CMP> from ICMP homonyms. The rationale for having an RAO is questionable. CMP> As this is the whole justification for this document, I do not CMP> believe that the "rationale is questionable". Maybe its CMP> effectiveness, or the applicability of the rationale to RAO as CMP> a solution. But the rationale (intercept packets) is key... Furthermore, RFC 6398 identifies security vulnerabilities associated with the RAO. CMP> This loose sentence feels handwavish -- as RFC 6398 has CMP> no-use recommendations for the open Internet end-to-end, CMP> while allows use in controlled environments. CMP> Overall, I feel the rationale for this doc needs some CMP> tightening in the Abstract. 1. Introduction RFC 8029 - "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures" (aka LSP Ping) [RFC8029] detects data-plane failures in MPLS Label Switched Paths (LSPs). It can operate in “ping mode” or “traceroute mode”. When operating in ping mode, it verifies end-to- end LSP continuity. When operating in traceroute mode, it can localize failures to a particular node along an LSP. CMP> I would keep the definition of ping and traceroute modes aligned CMP> with RFC 8029, that says "ping mode is used for connectivity checks, and traceroute is used for hop-by-hop fault localization as well as path tracing." CMP> note "continuity" vs. "connectivity", and addition of "path tracing" The echo request message is further encapsulated in an MPLS label stack. CMP> This should be a global check on the document, "The MPLS echo request" CMP> Also, this sentence implies that it is always encapsulated in an MPLS CMP> label stack -- whereas that would not be the case for Implicit Null. CMP> This is in Section 4.3 of RFC 8029, in: "If all of the FECs in the stack correspond to Implicit Null labels, the MPLS echo request is considered unlabeled..."" When operating in ping mode, LSP ping sends a single echo request message, with the MPLS TTL set to a high value (e.g., 255). This CMP> Is this TTL set to any "high value" (and what exactly is high??), CMP> Or to "255" as in S4.3 of RFC 8029? When operating in traceroute mode, MPLS ping sends multiple echo request messages. CMP> This paragraph above is potentially ambiguous: can traceroute CMP> send lots of "MPLS echo requests" messages all at once in a CMP> concurrent fashion (like concurrent algo in Paris Traceroute)? CMP> Not really due to the DDSMAP. I'd suggest pointing to RFC 8029 CMP> as much as possible on this, instead of re-writing it. CMP> And for this sentence, add that subsequently increasing TTL, etc. The IP header that encapsulates an echo request message must include a Router Alert Option (RAO), while the IP header that encapsulates an echo reply message may include an RAO. CMP> It is not that the *MPLS* (keeps being missed) echo reply "may" CMP> include a RAO. It is that there are cases in which it MUST and CMP> cases in which it doesn't -- as per reply-modes. See S4.5 of CMP> RFC 8029. In both cases, the rationale for including an RAO is questionable. Furthermore, [RFC6398] identifies security vulnerabilities associated with the RAO and recommends against its use outside of controlled environments. CMP> All same comments as with the Abstract, plus, "MPLS LSP Ping" CMP> is not used end-to-end in the open Internet, right? As such, CMP> the applicability (as this justification) of 6398 is questionable. 2.1. Echo Request ... To achieve this, RFC 8029 proposes the following: CMP> This section and enumeration is very useful. CMP> Nit: RFC 8029 doesn't "propose" but "specifies" maybe. CMP> There's one important element missing, however, which CMP> is the "MPLS Router Alert Label". See Section 4.4 of CMP> RFC 8029, first paragraph. 3. When the echo request message is encapsulated in IPv4, the IPv4 header must include an RAO. When the echo request message is encapsulated in IPv6, the IPv6 header chain must include a Hop- by-hop extension header and the Hop-by-hop extension header must include an RAO. CMP> This is slightly incomplete, given RFC 7506 (specifying the CMP> actual RAO value) 2.2. Echo Reply An LSP ping replies to the MPLS echo message with an MPLS echo reply message. It has four reply modes: CMP> There are 4 reply modes specified in RFC 8029, but there's more, see CMP> https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml#reply-modes 3. Update to RFC 7506 RFC 7506 defines the IPv6 Router Alert Option for MPLS Operations, Administration, and Management. This document reclassifies RFC 7506 as Historic. CMP> A question: since RFC 7506 defines the IPv6 RAO value as "MPLS OAM", CMP> and not as "MPLS LSP Ping", are other MPLS OAM potential uses of it? CMP> An ICMPv6 over MPLS with RAO, would it use this value? 4. Update to RFC 8029 CMP> This section changes subject to focus on the loopback address for CMP> IPv6. Given how many pieces of RFC 8029 include the RAO text, CMP> I'd suggest this section to specifically enumerate all places CMP> in RFC 8029 that it's updating. CMP> For example, how would these sections of RFC 8029 be re-written? CMP> Sections 2.2, 3, 4.3, 4.4 (what if a RAO is *received*?), and CMP> the "Label Operation Check", 4.5, 6.2.1, etc. * For IPv6, the IPv6 loopback address ::1/128 SHOULD be used. CMP> The issue of ::1/128 is a bit more complex than a single sentence, CMP> because it is swapping a range for an address. This is documented CMP> in https://www.rfc-editor.org/rfc/rfc7439#section-3.4.2, and CMP> that analysis should be referenced/cited and addressed. CMP> Further, RFC 7439 Section 3.4.2 should be Updated by this doc. CMP> Further, what happens to RFC 8029's Section 3.4.1.1.1, "Multipath CMP> Information Encoding"? 7. Security Considerations The recommendations this document makes do not compromise security. CMP> Given that security was one of the cited rationales mentioned, CMP> I'd think that this section should discuss how the security CMP> posture is improved with this document. More Editorial: Abstract The echo request and echo response messages, defined in RFC 8029 "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures" (aka LSP ping messages), are encapsulated in IP headers that include CMP> ^^^ suggest "AKA" or "usually referred to as" instead of "aka". CMP> Same comment on the Introduction. 1. Introduction RFC 8029 - "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures" (aka LSP Ping) [RFC8029] detects data-plane failures in MPLS Label Switched Paths (LSPs). It can operate in “ping mode” or CMP> ^^^^^^^^^^^ CMP> There's a number of non-ascii characters, as for example the use of CMP> “” instead of "". Suggest global replacement. Therefore, this document removes the RAO from both LSP ping message encapsulations. It updates RFCs 7506 [RFC7506] and 8029. CMP> Missing citation for RFC 8029. 2.1. Echo Request CMP> "When the *MPLS* echo request message" ("MPLS" is missing in each CMP> one of the number list elements) 2. When the echo request message is encapsulated in IPv4, the IPv4 TTL must be equal to 1. When the echo request message is encapsulated in IPv6, the IPv6 Hop Limit must be equal to 1. For further information on the encoding of the TTL/Hop Limit in an echo request message see Section 4.3 of [RFC8029]. CMP> Missing comma, "...echo request message, see Section..." 2.2. Echo Reply However, it is not clear that the use of the RAO increases the reliability of the return path. In fact, one can argue it decreases the reliability in many instances, due to the additional burden of processing the RAO. This document changes RGC 8020 in that mode 3 are removed. CMP> Typo, "RGC 8020" isntead of "RFC 8029". 5. Backwards Compatibility This document requests that the IPv6 RAO value for MPLS OAM (69) in [IANA-IPV6-RAO] is marked as "Deprecated". It also requests tha that CMP> Typo, "tha that" should be "that the" ^^^^^^^^ I hope these help and are clear and useful. Thanks! Carlos.