[nvo3] Re: Éric Vyncke's Discuss on draft-ietf-mpls-p 2mp-bfd-08: (with DISCUSS and COMMENT)
"Eric Vyncke \(evyncke\)" <evyncke=40cisco.com-Tr9gZwTxerDR74oF6e/[email protected]> Mon, 17 Feb 2025 19:16:00 +0000
| Newsgroups | gmane.ietf.nvo3,gmane.ietf.mpls |
|---|---|
| Message-ID | <PH0PR11MB4966A2C2AF6E42F2D40A4E1EA9FB2@PH0PR11MB4966.namprd11.prod.outlook.com> |
Greg, I have received emails about the submission of the revised I-Ds, give me some time to read them and to clear my DISCUSS. Thanks for understanding my concerns and providing a nice way forward. Regards -éric From: Greg Mirsky <[email protected]> Date: Monday, 17 February 2025 at 18:35 To: Eric Vyncke (evyncke) <[email protected]> Cc: Gunter van de Velde (Nokia) <[email protected]>, The IESG <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, NVO3 <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: Éric Vyncke's Discuss on draft-ietf-mpls-p2mp-bfd-08: (with DISCUSS and COMMENT) Hi Eric, thank you for your guidance. I updated the name of the new IPv6 prefix in both drafts; added informative reference to IANA IPv6 Special-Purpose Address Registry; added table to reflect the new allocation as you suggested. Many thanks for your help in improving these drafts and setting tunneled active OAM with IP/UDP encapsulation on the right track. Regards, Greg On Mon, Feb 17, 2025 at 4:47 AM Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>> wrote: Hello Greg Thanks for your patience as last week was very busy for my $dayjob... The changes in the text are OK except for the naming of the IETF prefix ‘Associated Channel IPv6 Prefix’ as I would prefer using “Dummy IPv6 Prefix” (as it is similar to the “Dummy IPv4 Address”) and for the IANA section as it lacks some parts notably: · A reference to the specific IANA registry: https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml · Some values for the added entry: termination date = N/A, source = true, destination = false, forwardable = false, globally reachable = false, reserved-by-protocol = false Please incorporate the above changes, submit the revised I-Ds, and I am clearing my 2 DISCUSS. Regards -éric From: Greg Mirsky <[email protected]<mailto:[email protected]>> Date: Wednesday, 5 February 2025 at 04:50 To: Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>> Cc: Gunter van de Velde (Nokia) <[email protected]<mailto:[email protected]>>, The IESG <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, NVO3 <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Re: Éric Vyncke's Discuss on draft-ietf-mpls-p2mp-bfd-08: (with DISCUSS and COMMENT) Hi, Eric et al., I've updated relevant drafts, draft-ietf-mpls-p2mp-bfd and draft-ietf-nvo3-geneve-oam, to use an address from the new IPv6 Associated Channel IPv6 range as the destinatination address of the inner IP/UDP encapsulation of active OAM packets. I attached two diffs that highlight all updates applied to these drafts. Below, please find details of these changes: • draft-ietf-mpls-p2mp-bfd o A new section as part of IANA Considerations: 7.1. IPv6 Address Allocation IANA is requested to allocate an IPv6 TBA2/64 prefix as Associated Channel IPv6 Prefix in the "Internet Protocol Version 6 Address Space" and add the prefix to the "IANA IPv6 Special Purpose Address Registry". o Updated Abstract as follows: OLD TEXT: Furthermore, this document also updates RFC 8562 and recommends the use of an IPv6 loopback address (::1/128) and discourages the use of an IPv4 loopback address mapped to IPv6. NEW TEXT: Furthermore, this document also updates RFC 8562 and recommends the use of an IPv6 from the Associated Channel IPv6 range TBA2/64 and discourages the use of an IPv4 loopback address mapped to IPv6. o Updated Introduction: OLD TEXT: Historically, an IPv6-mapped IPv4 loopback range address::ffff:127.0.0.1/128<http://127.0.0.1/128> was mandated, although functionally, an IPv6 address from that range is not analogous to its IPv4 counterpart. This draft starts the transition to using the proper IPv6 loopback address as the IPv6 destination address in the IP/UDP encapsulation of active OAM over the MPLS data plane. Thus, this document also updates [RFC8562] and recommends the use of an IPv6 loopback address (::1/128) while acknowledging that an address from ::ffff:127.0.0.1/128<http://127.0.0.1/128> range might be used by existing implementations, discourages the use of the IPv6-mapped IPv4 loopback range address. NEW TEXT: Historically, an IPv6-mapped IPv4 loopback range address::ffff:127.0.0.1/128<http://127.0.0.1/128> was mandated, although functionally, an IPv6 address from that range is not analogous to its IPv4 counterpart. Furthermore, using the loopback address as the destination address even for an inner IP encapsulation of a tunneled packet violates Section 2.5.3 of [RFC4291]. Hence, IANA is requested to allocate TBA2/64 range as a new Associated Channel IPv6 Prefix range that can be used for selecting destination IPv6 addresses for IP/UDP encapsulation of management, control, and OAM packets. This draft starts the transition to using the IPv6 addresses from the Associated Channel IPv6 Prefix range as the IPv6 destination address in the IP/UDP encapsulation of active OAM over the MPLS data plane. Thus, this document also updates [RFC8562] and recommends the use of an IPv6 address from the Associated Channel IPv6 Prefix range TBA2/64 (Section 7.1) while acknowledging that an address from ::ffff:127.0.0.1/128<http://127.0.0.1/128> range might be used by existing implementations, discourages the use of the IPv6-mapped IPv4 loopback range address. o Also, updated Section 3.1: OLD TEXT: * [RFC4291] defines a single IPv6 loopback address. Hence, for IPv6, the IPv6 loopback address ::1/128 SHOULD be used. NEW TEXT: * The sender of an MPLS echo request SHOULD use an address from the Associated Channel IPv6 Prefix range TBA2/64 Section 7.1. • draft-ietf-nvo3-geneve-oam o Updated Section 2.3: OLD TEXT: Inner IP header: Destination IP: The IP address MUST be set to the loopback address 127.0.0.1/32<http://127.0.0.1/32> for IPv4, or the loopback address ::1/128 for IPv6 [RFC4291]. NEW TEXT: Inner IP header: Destination IP: The IP address MUST be set to the loopback address 127.0.0.1/32<http://127.0.0.1/32> for IPv4 version. For IPv6, the address MUST be selected from the Associated Channel IPv6 Range for IPv6 [I-D.ietf-mpls-p2mp-bfd]. o Added as the Normative reference: [I-D.ietf-mpls-p2mp-bfd] Mirsky, G., Mishra, G. S., and D. E. Eastlake, "Bidirectional Forwarding Detection (BFD) for Multipoint Networks over Point-to-Multi-Point MPLS Label Switched Path (LSP)", Work in Progress, Internet-Draft, draft-ietf- mpls-p2mp-bfd-09, 6 January 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-mpls- p2mp-bfd-09>. I greatly appreciate your thoughtful and constructive suggestions. I hope that I captured the esseintail parts and got us closer to the acceptable resolution. Regards, Greg On Tue, Jan 14, 2025 at 9:35 AM Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>> wrote: Greg, This is indeed one way (or the other way round of course) as I wrote in a different email earlier today :-) -éric From: Greg Mirsky <[email protected]<mailto:[email protected]>> Date: Tuesday, 14 January 2025 at 17:01 To: Gunter van de Velde (Nokia) <[email protected]<mailto:[email protected]>> Cc: Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>>, The IESG <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, NVO3 <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Re: Éric Vyncke's Discuss on draft-ietf-mpls-p2mp-bfd-08: (with DISCUSS and COMMENT) Hi Eric and Gunter, thank you for your guidance. I thought of using draft-ietf-mpls-p2mp-bfd to request the IANA allocation. Consequently, draft-ietf-nvo3-geneve-oam will require using the proper IPv6 addresses and have the Normative reference in that regard to draft-ietf-mpls-p2mp-bfd. Would that be an acceptable way forward? Regards, Greg On Tue, Jan 14, 2025 at 8:58 AM Gunter van de Velde (Nokia) <[email protected]<mailto:[email protected]>> wrote: Thank you for the follow up Eric, At least from draft-ietf-nvo3-geneve-oam perspective a fresh LC seems appropriate. The sequencing of events depends upon which draft Greg wants to use to get the IANA IP address related code-points. Greg, would you have an early insight on how you prefer to progress? G/ From: Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>> Sent: Tuesday, January 14, 2025 2:50 PM To: Greg Mirsky <[email protected]<mailto:[email protected]>>; The IESG <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; NVO3 <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: Éric Vyncke's Discuss on draft-ietf-mpls-p2mp-bfd-08: (with DISCUSS and COMMENT) CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext<http://nok.it/ext> for additional information. Greg, I am perfectly fine with option #2 (even if option #3 is nicer from my INT AD point of view), i.e., one I-D is requesting the IPv4/IPv6 prefixes with the right wording in its IANA section and the other I-D has some text about re-using those prefixes with a normative reference to the 1st I-D (plus some notes to the RFC editor to copy the selected prefixes). Now, these two I-Ds are in the routing area, so, it is also up to the RTG ADs to express their preferences and decide whether a new IETF Last Call is required (as this is an important technical change in the I-Ds). I understand that this is more work for many people and some delays, but the final I-Ds will be much more elegant and no more violating RFC 4291 😊 Hence, I will clear my DISCUSS position. Regards -éric From: Greg Mirsky <[email protected]<mailto:[email protected]>> Date: Friday, 10 January 2025 at 23:14 To: Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>> Cc: The IESG <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, NVO3 <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, Bocci, Matthew (Nokia - GB) <[email protected]<mailto:[email protected]>> Subject: Re: Éric Vyncke's Discuss on draft-ietf-mpls-p2mp-bfd-08: (with DISCUSS and COMMENT) Hi Eric, Thank you for the detailed explanation of all options to conclude the work of two WGs on these documents properly. I think that Option #2 is reasonable and will work on updating drafts accordingly. In the meantime, I appreciate your thoughts on where to request IANA. Would it be acceptable if such a request is expressed in one document, e.g., draft-ietf-mpls-p2mp-bfd, and the other document uses a Normative reference to that draft? If that is acceptable, we will avoid any possibility of duplication of the IANA part. Regards, Greg On Fri, Jan 10, 2025 at 2:36 AM Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>> wrote: 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 <[email protected]<mailto:[email protected]>> Date: Thursday, 9 January 2025 at 22:04 To: Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>> Cc: The IESG <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, NVO3 <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, Bocci, Matthew (Nokia - GB) <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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) <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> Date: Monday, 6 January 2025 at 20:49 To: Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>> Cc: The IESG <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 -- [email protected] To unsubscribe send an email to [email protected]