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

[Greg Mirsky <[e-mail]>]

Hi Adrian,
sorry, you've got to review this draft for the second time in such a short
time ;)
Thank you for your thorough review and detailed suggestions to improve the
document. I'll work on updating it and will bring it back for you to check
for completeness of changes.

Regards,
Greg

On Mon, Oct 30, 2023 at 2:51 PM Adrian Farrel <[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
>
>