Hi Éric, thank you for the review and your comments. Please find my notes below tagged by GIM>>.
Regards, Greg On Tue, Jan 7, 2025 at 8:46 AM Éric Vyncke via Datatracker <nore...@ietf.org> wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-nvo3-geneve-oam-14: 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-nvo3-geneve-oam/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > # Éric Vyncke, INT AD, comments for draft-ietf-nvo3-geneve-oam-14 > CC @evyncke > > Thank you for the work put into this document. > > Please find below two blocking DISCUSS points (one is easy to address), > some > non-blocking COMMENT points (but replies would be appreciated even if only > for > my own education), and some nits. > > Special thanks to Matthew Bocci for the shepherd's detailed write-up > including > the WG consensus *and* the justification of the intended status. > > Other thanks to Tim Chown, the Internet directorate reviewer (at my > request), > please consider this int-dir review (esp Tim's comment about section 2.1 > and > entropy): > > https://datatracker.ietf.org/doc/review-ietf-nvo3-geneve-oam-14-intdir-lc-chown-2025-01-06/ > (his review is recent, hence I understand the lack of replies by the > authors) > > 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 2.3 > > In order to use RFC 5082, the receiver MUST also drop packets whose Hop > Limit/TTL is not 255, please be specific in this section in addition to > section > 4. > GIM>> Thank you for the suggested. Would the follwoing new text be acceptable: NEW TEXT: The receiver of an active OAM Geneve packet with IP/UDP encapsulation MUST drop packets whose TTL/Hop Limit is not 255. > > Destination address being IPv6/IPv4 loopback address... I may well be > missing > one obvious part but as a Geneve tunnel behaves like a layer-2 link, no > IPv6 > packet can be sent to another host with the loopback address per section > 2.5.3 > of RFC 4291: `An IPv6 packet with a destination address of loopback must > never > be sent outside of a single node` (and I am pretty sure there is a similar > constraint for IPv4). Suggest using a destination address of ff02::2/128 > (all > link routers) or even requesting a specific link-local multicast address > for > Geneve OAM. > GIM>> For the Geneve tunnel we follow the rationale and methodology accepted for IP/UDP encapsulated active OAM over a MPLS tunnel specified in Section 2.1 of RFC 8029 <https://datatracker.ietf.org/doc/html/rfc8029#section-2.1>. The solution must conform to the following requirements: 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. After considering several options, MPLS WG concluded that a loopback address is the behavior that conforms to all three requirements (although it also introduced a misconception of functional equivalency between 127/8 IPv4 range and corresponding IPv4-mapped IPv6 address range). Do you think that IP/UDP encapsulation of active OAM packets in Geneve tunnels cannot follow methodology used in IP/UDP encapsulation of active OAM over MPLS? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ## COMMENTS (non-blocking) > > ### Section 2.1 > > Isn't requirement #1 implied by requirement #2 ? I.e., all packets > complying to > requirement #2 also complies to requirement #1 ? > > ### Section 2.2 > > Is `Management VNI` the right term for active probing OAM traffic ? I.e., I > would not use 'management' for ping and would reserve it for netconf or > other > configuration/telemetry traffic. > > `A packet received over the control channel MUST be forwarded` forwarded by > whom and to whom ? > > ### Section 2.3 > > Is there any recommendation for inner source IP address/UDP port ? > > ## 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 ;-) > > > >
_______________________________________________ nvo3 mailing list -- nvo3@ietf.org To unsubscribe send an email to nvo3-le...@ietf.org
