[mpls] Shepherd review of draft-ietf-mpls-lspping-norao
Adrian Farrel <adrian@olddog.co.uk> Mon, 30 October 2023 21:51 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DB9C15107E; Mon, 30 Oct 2023 14:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.805
X-Spam-Level:
X-Spam-Status: No, score=-2.805 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=olddog.co.uk
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXUrkj0AV_Um; Mon, 30 Oct 2023 14:51:28 -0700 (PDT)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B47C15106F; Mon, 30 Oct 2023 14:51:27 -0700 (PDT)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.7/8.14.7) with ESMTP id 39ULpPq0015014; Mon, 30 Oct 2023 21:51:25 GMT
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 201464604B; Mon, 30 Oct 2023 21:51:25 +0000 (GMT)
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0AAC84603D; Mon, 30 Oct 2023 21:51:25 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS; Mon, 30 Oct 2023 21:51:24 +0000 (GMT)
Received: from LAPTOPK7AS653V (82-69-109-75.dsl.in-addr.zen.co.uk [82.69.109.75]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.7/8.14.7) with ESMTP id 39ULpO3F012773 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Oct 2023 21:51:24 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: mpls@ietf.org
Cc: draft-ietf-mpls-lspping-norao.all@ietf.org
Date: Mon, 30 Oct 2023 21:51:24 -0000
Organization: Old Dog Consulting
Message-ID: <019401da0b7b$3a640f90$af2c2eb0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdoLey35rJ6YCBRTQHufv0Ykkc3BQQ==
Content-Language: en-gb
X-Originating-IP: 82.69.109.75
X-Thinkmail-Auth: adrian@olddog.co.uk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:cc:subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=20221128; bh=KFSfQ+It58BfoRO07vbdb /tBx5Dx5f90S3xdzUgCoeo=; b=cYpRF2qfxKK/5RcQCaHbBIUtaXL7BDr8khuuL wA2+QWyhtjm2RBsSoFBfdWxurBC2fvYaBWINqR1HKyW/J9nfiE0dZigFrEpmFKQm BVXF7cCKfM6AtzTgLzzAuUc4MNDn+DA0Fy+vupc32Btldeb0kiR4xDnxUojKVpN4 7E4iMbtAT+jFq5pGa4mzaliQrxLFY2BPamKwmkO8JIA27tzXDlAjT+J3Mc9695PW SKx2i9M/KAoInomSG7L0fNrY8mYimPTG1fljeWTEEweySgLUyFanXeWi3PljT/Uk fd/OIhjA+Mu1DVM1tARjrBjjW3m4OPaQp2WaNvN/eZmHYTnPQ==
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-27968.002
X-TM-AS-Result: No--28.010-10.0-31-10
X-imss-scan-details: No--28.010-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-27968.002
X-TMASE-Result: 10--28.010200-10.000000
X-TMASE-MatchedRID: fr/TTUtmA4MOwAmmWH5kBPSG/+sPtZVk3AJrtcannrYUta+LQgEZMLPF u1TaJjTDvs75gcY5ey4b5v9k3iREiMVQ1jrs5s2SJwrTBASFB26V3TRDlI7Srn4Y9ulihlboL7t ZVXGShKDdcDyNhqS6uz9wWKOjaGxyC2chykIIZH1MCv0D/ZD4DEAXM2GkmIJPMAGHatVU16OqcA PQHbLY5X/c6wGNzGrTd7ZR6n09UrxOxzeg8qHiCsaw71DJbaIEW1VjHhznmWgceUlujmm1FaxIj SYfsSaZgXWKaD86aY2T2y3cScrksXbph30JxFrn9k5nZzZVBSD6DHtjrOvoOTnZfxjBVQRb3kUs 9G0YRzHoctvDJKffMxe9WHkW7nI9tGHSg65p69jidvCqqY53aZQ7eT0DII9N2vch1fMqmI+W7eQ GT57Co7XQW2R7SC3r6SYb29c3rTT8aPREpCgBjZdVcy7Vo9q8vuCq/w742Ipd5x7f4pBaYzlCRr 8Hb3qig8QT+c7qUeSkvxI/lOCBBVajduGHvJlh9DGkDtq4vAzYUDvAr2Y/17Xl40gTGJ5p2l+1z UPkXzjmYWok44PCwaDvOjkIjUu6POH18WBiNhPX3j/lf1V8LOq04IwIzM5hmyiLZetSf8nJ4y0w P1A6ADMMszeAZpzJdB0ntd9Tzp7iRhduhvElsvJT+hf62k2YIbZSWXZZ520=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/VH_MlFmem6YlPfDS_t03FF4t9m0>
Subject: [mpls] Shepherd review of draft-ietf-mpls-lspping-norao
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Oct 2023 21:51:34 -0000
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
- [mpls] Shepherd review of draft-ietf-mpls-lspping… Adrian Farrel
- Re: [mpls] Shepherd review of draft-ietf-mpls-lsp… Greg Mirsky
- Re: [mpls] Shepherd review of draft-ietf-mpls-lsp… Greg Mirsky
- Re: [mpls] Shepherd review of draft-ietf-mpls-lsp… Adrian Farrel
- Re: [mpls] Shepherd review of draft-ietf-mpls-lsp… Adrian Farrel
- Re: [mpls] Shepherd review of draft-ietf-mpls-lsp… Adrian Farrel
- Re: [mpls] Shepherd review of draft-ietf-mpls-lsp… Greg Mirsky