My apologies, for missing COMMENTS. The attached diff highlights updates applied in the working version.
Regards, Greg On Tue, Jan 7, 2025 at 11:31 AM Greg Mirsky <gregimir...@gmail.com> wrote: > 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 ? >> > GIM>> I don't think that there's that relationship between these requirements. In my opinion, Requirement#2 stipulates that outer IP/UDP encapsulation of an active OAM Geneve packet MUST be same as of the monitored Geneve tunnel. Requirement#1 addresses a broader space - it includes fields that are used in the underlay network for load-balancing. > >> ### 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. >> > GIM>> That terminology re-used from Management VLAN. We explain that Management VNI is not solely designated to management, configuration of an VNE, but is the naming of a control channel that might be used for management and maintanence of the Geneve tunnel. > >> `A packet received over the control channel MUST be forwarded` forwarded >> by >> whom and to whom ? >> > GIM>> It was implied that "a system that supports this specification". I propose the following update: OLD TEXT: A packet received over the control channel MUST be forwarded if and only if it is sent onto the control channel of the concatenated Geneve tunnel. NEW TEXT: A packet received by the system that supports this specification over the control channel MUST be forwarded if and only if it is sent onto the control channel of the concatenated Geneve tunnel. > >> ### Section 2.3 >> >> Is there any recommendation for inner source IP address/UDP port ? >> > GIM>> I think that source IP address/UDP port are selected according to the specification of the particular active OAM protocol. > >> ## 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 experiment with one of drafts I am working on.
<<< text/html; charset="US-ASCII"; name="draft-ietf-nvo3-geneve-oam-15.diff.html": Unrecognized >>>
_______________________________________________ nvo3 mailing list -- nvo3@ietf.org To unsubscribe send an email to nvo3-le...@ietf.org
