Hello Greg, Thanks for your reply.
The proposed text for the HL/TTL=255 is perfect for me. About the other DISCUSS point for using ::1/128 as the dummy/inner destination address, I will copy my reply about draft-ietf-mpls-p2mp-bfd-08 Did the NVO3 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. Regards -éric From: Greg Mirsky <[email protected]> Date: Tuesday, 7 January 2025 at 20:31 To: Eric Vyncke (evyncke) <[email protected]> Cc: The IESG <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: Éric Vyncke's Discuss on draft-ietf-nvo3-geneve-oam-14: (with DISCUSS and COMMENT) 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 <[email protected]<mailto:[email protected]>> 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 -- [email protected] To unsubscribe send an email to [email protected]
