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
