Last Call Review of draft-ietf-mpls-lspping-norao-02
review-ietf-mpls-lspping-norao-02-rtgdir-lc-pignataro-2023-09-04-00

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.