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
