Greg, Thank you for merging the two threads, very sensible action as the two IETF drafts have the same issue.
The IESG discussed it during the 9th of January telechat, and there are at least three solutions (all allowing for ECMP probing): 1. Using the 100::/64 prefix (as you wrote it was not published when the original RFC were published), easy, immediate solution for IPv6, but not for IPv4 2. The MPLS/NVO3 drafts add an IANA section requesting an IPv6 /64 prefix and an IPv4 /24 prefix for this specific use (with a note about avoiding duplicates), similar future documents could then refer to either the MPLS/NVO3 RFC 3. A short/quick (AD-sponsored ?) IETF draft requesting the IPv6 /64 and an IPv4 / 24 prefixes for similar use cases, way nicer and easier reference for similar future documents In all cases, I am afraid that an IETF Last Call & IESG evaluation should be done again as it is a not a minor editorial change. Early allocation could be requested for 2) and 3) within weeks. For 3) the MPLS/NVO3 documents could be quickly approved by the IESG with a normative reference to the short draft. Even if I mostly care about IPv6, I think that a solution for IPv4 is important. The solution 3) is much nicer albeit probably causing delays in *publication* of the MPLS/NVO3 drafts but not for their *approvals*. On my side, 3) is the best way forward, but happy to listen to the community feedback Regards -éric From: Greg Mirsky <gregimir...@gmail.com> Date: Thursday, 9 January 2025 at 22:04 To: Eric Vyncke (evyncke) <evyn...@cisco.com> Cc: The IESG <i...@ietf.org>, draft-ietf-mpls-p2mp-...@ietf.org <draft-ietf-mpls-p2mp-...@ietf.org>, mpls-cha...@ietf.org <mpls-cha...@ietf.org>, m...@ietf.org <m...@ietf.org>, n.leym...@telekom.de <n.leym...@telekom.de>, NVO3 <nvo3@ietf.org>, nvo3-cha...@ietf.org <nvo3-cha...@ietf.org>, nvo3-...@ietf.org <nvo3-...@ietf.org>, draft-ietf-nvo3-geneve-...@ietf.org <draft-ietf-nvo3-geneve-...@ietf.org>, Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com> Subject: Re: Éric Vyncke's Discuss on draft-ietf-mpls-p2mp-bfd-08: (with DISCUSS and COMMENT) Merging two discussions might help us reach an acceptable solution. Regards, Greg On Thu, Jan 9, 2025 at 10:28 AM Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> wrote: Hi Eric, thank you for the discussion and further clarification of your concern with the proposed use of ::1/128 as the inner destination IPv6 address in tunneled active OAM packets. Please see my follow-up notes below tagged GIM2>>. Regards, Greg On Thu, Jan 9, 2025 at 5:35 AM Eric Vyncke (evyncke) <evyn...@cisco.com<mailto:evyn...@cisco.com>> wrote: Hello Greg, Thanks for your reply. A quick and easy point first: my comment on section 3.1 is really s\0:0:0:0:0:FFFF:7F00/104\::ffff:7f00/104\ or \::ffff:127.0.0.0/104\<http://127.0.0.0/104%5C> (and no need to add a reference to RFC 5952). Sorry if I was unclear in my comment. GIM2>> Thank you for the clarification. I used the first option, changing 'F' into 'f'. This leads of course to the core of my DISCUSS: using ::1 as the inner destination address to avoid the dummy inner packet to be consumed by a non-intended recipient. Like ::ff00:127.0.0.0/104<http://127.0.0.0/104> it is a violation of RFC 4291 even if slightly nicer. Did the MPLS WG consider the use of RFC 6666 (discard prefix) 100::/64 ? This would also have the benefit of allowing entry in the destination address to allow for ECMP testing. GIM2>> Thank you for pointing out this option. AFAIK when the first RFC, RFC 4379, was published defining IP/UDP encapsulation of active OAM packets in the MPLS network, the IPv6 range was not assigned yet. Also, RFC 9570<https://datatracker.ietf.org/doc/rfc9570/> recommends using ::1/128 as the inner destination IPv6 address in IP/UDP encapsulation of an active OAM packet in the MPLS network. I believe using an IPv6 address in IP/UDP encapsulation must be consistent across all cases, whether MPLS or IPv6 tunneling. E.g., the following text would be better IMHO (keeping the 2nd bullet to support legacy implementations): “This document updates Section 5.8 of [RFC8562<https://www.rfc-editor.org/info/rfc8562>] regarding the selection of the IPv6 destination address: · The sender of an echo request SHOULD select the IPv6 destination from the 100::/64 RFC 6666 prefix. · The sender of an echo request MAY select the IPv6 destination address from the 0:0:0:0:0:FFFF:7F00/104 prefix.” Alternatively, IANA could easily assign another /64 for the use of BFD. GIM2>> As this issue is present in both documents, draft-ietf-mpls-p2mp-bfd, and draft-ietf-nvo3-geneve-oam, I defer to ADs and WG Chairs for their suggestions and guidance. Regards -éric From: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> Date: Monday, 6 January 2025 at 20:49 To: Eric Vyncke (evyncke) <evyn...@cisco.com<mailto:evyn...@cisco.com>> Cc: The IESG <i...@ietf.org<mailto:i...@ietf.org>>, draft-ietf-mpls-p2mp-...@ietf.org<mailto:draft-ietf-mpls-p2mp-...@ietf.org> <draft-ietf-mpls-p2mp-...@ietf.org<mailto:draft-ietf-mpls-p2mp-...@ietf.org>>, mpls-cha...@ietf.org<mailto:mpls-cha...@ietf.org> <mpls-cha...@ietf.org<mailto:mpls-cha...@ietf.org>>, m...@ietf.org<mailto:m...@ietf.org> <m...@ietf.org<mailto:m...@ietf.org>>, n.leym...@telekom.de<mailto:n.leym...@telekom.de> <n.leym...@telekom.de<mailto:n.leym...@telekom.de>> Subject: Re: Éric Vyncke's Discuss on draft-ietf-mpls-p2mp-bfd-08: (with DISCUSS and COMMENT) Hi Éric, thank you for your review and comments. Please find my notes below tagged GIM>>. The attached diff highlights updates applied in the new working version. Regards, Greg On Mon, Jan 6, 2025 at 4:13 AM Éric Vyncke via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> wrote: Éric Vyncke has entered the following ballot position for draft-ietf-mpls-p2mp-bfd-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-p2mp-bfd/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-mpls-p2mp-bfd-08 CC @evyncke Thank you for the work put into this document. Please find below one blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Nicolai Leymann for the shepherd's detailed write-up including the WG consensus *but it lacks* the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## DISCUSS (blocking) As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics: ### Section 3.1 Happy to stand corrected, but I read section 3.1 as IP packets are sent outside of a node on a real (p2mp) link with a destination address of ::1/128. If confirmed, then this is an apparent violation of section 2.5.3 of RFC 4291 (even if sent over MPLS). GIM>> The use of a loopback IP address as the destination in MPLS-encapsulated IP/UDP was introduced in RFC 4379 (it was obsoleted by RFC 8029<https://datatracker.ietf.org/doc/html/rfc8029>). In it, the use of a loopback discussed in Section 2.1. Use of a loopback IPv4 address as the destination address in MPLS-encapsulated IP/UDP active OAM, e.g., LSP Echo request/reply (RFC 8029) or BFD (RFC 5884), as I understand is accepted and broadly deployed. This document is intended to correct earlier misconception about IPv6-mapped IPv4 loopback address range and recommends using IPv6 loopback as the destination address in IP/UDP encapsulation over MPLS. I understand that this violation started already in RFC 8562, and I have no obvious solution to propose except using a link-local mcast address, e.g., ff02::2/128 (all link routers). GIM>> The intention of using a loopback address as the IP destination address in IP/UDP encapsulation of an active OAM over MPLS discussed in Section 2.1 of RFC 8029<https://datatracker.ietf.org/doc/html/rfc8029#section-2.1>: 1. Although the LSP in question may be broken in unknown ways, the likelihood of a diagnostic packet being delivered to a user of an MPLS service MUST be held to an absolute minimum. 2. If an LSP is broken in such a way that it prematurely terminates, the diagnostic packet MUST NOT be IP forwarded. 3. A means of varying the diagnostic packets such that they exercise all ECMP paths is thus REQUIRED. It seems like using link-local mcast address would not comply to these requirements, but a loopback address is complying. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENTS (non-blocking) ### Abstract and Section 1 s/recommends the use of *an* IPv6 loopback address/recommends the use of *the* IPv6 loopback address/ GIM>> Thank you; done. ### Section 2.1 Suggest adding a reference (or a definition) of `G-ACh`. GIM>> Added reference to RFC 5586 in Section 3.2 and expanded on the first use of the abbreviation. ### Section 3.1 Please use section 5 of RFC 5952 for `0:0:0:0:0:FFFF:7F00/104`. GIMM>> Added as Informative reference. Would you agree? ### Section 3.2 In figure 1, some fields have a length that is specified and others have no length... Is it on purpose ? GIM>> Thank you for pointing that out to me. I removed occurences of '(16 bits)'. Even if the reader could guess, what are the expected sender/receiver behavior for the reserved fields ? GIM>> The Source Address TLV is defined in Section 4.1 of RFC 7212<https://www.rfc-editor.org/rfc/rfc7212.html>. Would you recommend clarificaton of how its fields are handled? ## NITS (non-blocking / cosmetic) ### Use of SVG graphics To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try ;-) GIM>> I will try it ;)
_______________________________________________ nvo3 mailing list -- nvo3@ietf.org To unsubscribe send an email to nvo3-le...@ietf.org
