É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. 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. ---------------------------------------------------------------------- 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
