Re: [mpls] Shepherd review of draft-ietf-mpls-lspping-norao

[Adrian Farrel <[e-mail]>]

Greg,

This is all looking good. Thanks for the work.

In section 4, You are missing an “END” to delimit the change from OLD to NEW (i.e., OLD—NEW—END). I think that comes before “Additionally, this specification updates Section 2.2 of [RFC8029]”

Please post the update and I will start on the shepherd write-up.

Best,
Adrian


From: Greg Mirsky <[e-mail]> 
Sent: Monday, November 6, 2023 9:29 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: Shepherd review of draft-ietf-mpls-lspping-norao

Hi Adrian,
I've got to really appreciate the thoroughness of your review and clear and constructive suggestions. Attached, please find the working version (all your suggestions were accepted with a few minor editorial nits). A bit frustrating that gmail finds a virus in the diff and thus I am not attaching it this time. Please let me know if I've got the updates right, and will gladly upload the new version of the document.

Also, I've noticed that idnits reports the following concern:
  -- The abstract seems to indicate that this document updates RFC6398, but
     the header doesn't have an 'Updates:' line to match this.
I've checked it, and it looks like some misunderstanding of the tool. WDYT?

Regards,
Greg

On Mon, Oct 30, 2023 at 10:51 PM Adrian Farrel <mailto:[e-mail]> wrote:
Hi,

Here is my review as document shepherd. Sorry that this is me doing yet
another review, but this time there is a whole new layer of pedantry as
we get the document ready for publication. All of my changes are
editorial - no technical comments.

Let me know if there are any concerns.

Cheers,
Adrian

===

Abstract

OLD
   Therefore, this document removes the RAO from LSP ping message
   encapsulations.  It updates RFCs 7506 and 8029.
NEW
   Therefore, this document retires the Router Alert Option for MPLS
   Operations, Administration, and Maintenance (OAM).  It reclassifies
   RFC 7506 as Historic and updates RFC 8029 to remove the RAO from LSP
   ping message encapsulations.
END

---

Abstract

   This document also recommends the use of an IPv6 loopback address
   (::1/128) and discourages the use of an IPv4 loopback address mapped
   to IPv6.

I think that "discourages" may be underplaying what is going on. Don't 
you actually update 8029 to describe new rules for selecting an IPv6
address? So, perhaps,

   This document also recommends the use of an IPv6 loopback address
   (::1/128) and not the use of an IPv4 loopback address mapped to IPv6.

---

Need to expand FEC on first use.

---

Introduction

I'm a little worried that the text that describes how 8029 uses RAO is
too strong. In particular, the Introduction says "must include an RAO"
which will be confusing for the reader. So, a suggestion...

OLD
   The IP header that encapsulates an MPLS echo request message must
   include a Router Alert Option (RAO), while the IP header that
   encapsulates an MPLS echo reply message must include an RAO if the
   value of the Reply Mode in the corresponding MPLS echo request
   message is "Reply via an IPv4/IPv6 UDP packet with Router Alert".
NEW
   According to RFC 8029, the IP header that encapsulates an MPLS echo
   request message must include a Router Alert Option (RAO), while RFC 
   8029 also says that the IP header that encapsulates an MPLS echo 
   reply message must include an RAO if the value of the Reply Mode in
   the corresponding MPLS echo request message is "Reply via an 
   IPv4/IPv6 UDP packet with Router Alert".
END

---

Introduction

OLD
   Therefore, this document removes the RAO from both LSP ping message
   encapsulations.  It updates RFCs 7506 [RFC7506] and 8029 [RFC8029].
NEW
   Therefore, this document updates RFC 8026 to retire the RAO from both
   LSP ping message encapsulations and reclassifies RFC 7506 as
   Historic.
END

---

You don't need section 1.2 as all three abbreviations are already 
expanded in the introduction.

---

2.1

s/(LSR).To/(LSR). To/

---

2.1

   The authors are not aware of any implementation that relies on the
   RAO to prevent packets from being forwarded beyond the egress LSR.

I don't think we can have WG consensus on what the authors are or are
not aware of. How about changing this to:

   No implementation that rely on the RAO to prevent packets from being
   forwarded beyond the egress LSR have been reported to the MPLS 
   working group.

Similarly in 2.2

OLD
   The authors are not aware of any implementations of mode 3.
NEW
   No implementations of mode 3 have been reported to the MPLS working
   group.
END

---

2.2

s/mode 3 are removed/mode 3 is removed/

---

4.

This needs a little more clarity on exactly what change is made to
RFC 8029. So, maybe...

OLD
   Considering that this specification updates Section 2.1 of [RFC8029]
   regarding the selection of an IPv6 destination address for an MPLS
   echo request message:

   *  For IPv6, the IPv6 loopback address ::1/128 SHOULD be used.

   *  The sender of an MPLS echo request MAY select the IPv6 destination
      address from the 0:0:0:0:0:FFFF:7F00/104 range.

   *  To exercise all paths in an ECMP environment, the entropy other
      than the IP destination address SHOULD be used.
NEW
   Considering that, this specification updates Section 2.1 of [RFC8029]
   regarding the selection of an IPv6 destination address for an MPLS
   echo request message as follows:

   OLD

   The 127/8 range for IPv4 and that same range embedded in an
   IPv4-mapped IPv6 address for IPv6 was chosen for a number of reasons.

   RFC 1122 allocates the 127/8 as the "Internal host loopback address"
   and states: "Addresses of this form MUST NOT appear outside a host."
   Thus, the default behavior of hosts is to discard such packets.  This
   helps to ensure that if a diagnostic packet is misdirected to a host,
   it will be silently discarded.

   RFC 1812 [RFC1812] states:

      A router SHOULD NOT forward, except over a loopback interface, any
      packet that has a destination address on network 127.  A router
      MAY have a switch that allows the network manager to disable these
      checks.  If such a switch is provided, it MUST default to
      performing the checks.

   This helps to ensure that diagnostic packets are never IP forwarded.

   The 127/8 address range provides 16M addresses allowing wide
   flexibility in varying addresses to exercise ECMP paths.  Finally, as
   an implementation optimization, the 127/8 range provides an easy
   means of identifying possible LSP packets.

   NEW

   The 127/8 range for IPv4 was chosen for a number of reasons.

   RFC 1122 allocates the 127/8 as the "Internal host loopback address"
   and states: "Addresses of this form MUST NOT appear outside a host."
   Thus, the default behavior of hosts is to discard such packets.  This
   helps to ensure that if a diagnostic packet is misdirected to a host,
   it will be silently discarded.

   RFC 1812 [RFC1812] states:

      A router SHOULD NOT forward, except over a loopback interface, any
      packet that has a destination address on network 127.  A router
      MAY have a switch that allows the network manager to disable these
      checks.  If such a switch is provided, it MUST default to
      performing the checks.

   This helps to ensure that diagnostic packets are never IP forwarded.

   The 127/8 address range provides 16M addresses allowing wide
   flexibility in varying addresses to exercise ECMP paths.  Finally, as
   an implementation optimization, the 127/8 range provides an easy
   means of identifying possible LSP packets.

   The IPv6 destination address for an MPLS echo request message is
   selected as follows:

   *  For IPv6, the IPv6 loopback address ::1/128 SHOULD be used.

   *  The sender of an MPLS echo request MAY select the IPv6 destination
      address from the 0:0:0:0:0:FFFF:7F00/104 range.

   *  To exercise all paths in an ECMP environment, the entropy other
      than the IP destination address SHOULD be used.

   END
END

...and further...

OLD
   LSP Ping implementations SHOULD ignore RAO options when they arrive
   on incoming MPLS echo request and MPLS echo reply messages.
NEW
   Additionally, this specification updates Section 2.2 of [RFC8029] to
   replace the whole of the section with the following text:

   LSP Ping implementations SHOULD ignore RAO options when they arrive
   on incoming MPLS echo request and MPLS echo reply messages.
END   

---

5.

OLD
   LSP Ping implementations SHOULD ignore RAO options when they arrive
   on incoming MPLS echo request and MPLS echo reply messages.

   This document requests that the IPv6 RAO value for MPLS OAM (69) in
   [IANA-IPV6-RAO] is marked as "Deprecated".  It also requests that the
   Reply Mode 3 ("Reply via an IPv4/IPv6 UDP packet with Router Alert")
   in [IANA-LSP-PING] is marked as "Deprecated".

   We interpret "DEPRECATED" in this context to mean that the deprecated
   values should not be used in new implementations, and that deployed
   implementations that use these values continue to work seamlessly.
NEW
   LSP Ping implementations that conform to this specification SHOULD
   ignore RAO options when they arrive on incoming MPLS echo request and
   MPLS echo reply messages. However, this will not harm backwards 
   compatibility because other mechanisms will also be in use by all 
   legacy implementations in the messages they send and receive.

   Section 6 of this document deprecates the IPv6 RAO value for MPLS OAM
   (69) in [IANA-IPV6-RAO] and the Reply Mode 3 ("Reply via an IPv4/IPv6
   UDP packet with Router Alert") in [IANA-LSP-PING].

   [RFC8126] offers a formal description of the word "Deprecated". In 
   this context, "Deprecated" means that the deprecated values SHOULD 
   NOT be used in new implementations, and that deployed implementations
   that already use these values continue to work seamlessly.
END

---

6.

OLD
   If this document is approved, mark the IPv6 RAO value of MPLS OAM
   (69) in [IANA-IPV6-RAO] as "Deprecated".  [RFC8126] offers a formal
   description of the word "Deprecated".

   Also, mark Reply Mode 3 ("Reply via an IPv4/IPv6 UDP packet with
   Router Alert") in [IANA-LSP-PING] as "Deprecated".
NEW
   IANA is requested to mark the IPv6 RAO value of MPLS OAM (69) in
   [IANA-IPV6-RAO] as "Deprecated". 

   IANA is Also requested to mark Reply Mode 3 ("Reply via an IPv4/IPv6
   UDP packet with Router Alert") in [IANA-LSP-PING] as "Deprecated".
END