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) <evyn...@cisco.com> 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 <gregimir...@gmail.com> > *Date: *Wednesday, 5 February 2025 at 04:50 > *To: *Eric Vyncke (evyncke) <evyn...@cisco.com> > *Cc: *Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>, The > IESG <i...@ietf.org>, draft-ietf-mpls-p2mp-...@ietf.org < > draft-ietf-mpls-p2mp-...@ietf.org>, m...@ietf.org <m...@ietf.org>, NVO3 < > nvo3@ietf.org>, nvo3-cha...@ietf.org <nvo3-cha...@ietf.org>, > draft-ietf-nvo3-geneve-...@ietf.org <draft-ietf-nvo3-geneve-...@ietf.org> > *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 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 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 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 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 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 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) <evyn...@cisco.com> > 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 <gregimir...@gmail.com> > *Date: *Tuesday, 14 January 2025 at 17:01 > *To: *Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com> > *Cc: *Eric Vyncke (evyncke) <evyn...@cisco.com>, The IESG <i...@ietf.org>, > draft-ietf-mpls-p2mp-...@ietf.org <draft-ietf-mpls-p2mp-...@ietf.org>, > m...@ietf.org <m...@ietf.org>, NVO3 <nvo3@ietf.org>, nvo3-cha...@ietf.org > <nvo3-cha...@ietf.org>, draft-ietf-nvo3-geneve-...@ietf.org < > draft-ietf-nvo3-geneve-...@ietf.org> > *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) < > gunter.van_de_ve...@nokia.com> 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) <evyncke=40cisco....@dmarc.ietf.org> > *Sent:* Tuesday, January 14, 2025 2:50 PM > *To:* Greg Mirsky <gregimir...@gmail.com>; The IESG <i...@ietf.org> > *Cc:* draft-ietf-mpls-p2mp-...@ietf.org; m...@ietf.org; NVO3 < > nvo3@ietf.org>; nvo3-cha...@ietf.org; draft-ietf-nvo3-geneve-...@ietf.org > *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 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 <gregimir...@gmail.com> > *Date: *Friday, 10 January 2025 at 23:14 > *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>, 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) > > 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) <evyn...@cisco.com> > 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 <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> 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> > 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 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> > *Date: *Monday, 6 January 2025 at 20:49 > *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> > *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> 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
