Hi Matthew, thank you for you help in improving the document. Updated the Abstract and uploaded the new version: The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve-oam/
There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-nvo3-geneve-oam-12.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-nvo3-geneve-oam-12 Regards, Greg On Fri, Sep 20, 2024 at 4:37 AM Matthew Bocci (Nokia) < matthew.bo...@nokia.com> wrote: > Hi Greg > > > > Thanks for the updated draft addressing my comments. > > > > One more nit that I noticed in the abstract: > > > > “Based on these requirements, IP encapsulation for active Operations, > Administration, and Maintenance protocols in Geneve protocol is defined.” > > > > I think this would read better as: “Based on these requirements, the IP > encapsulation *of *active Operations, Administration, and Maintenance > protocols in *the* Geneve protocol is defined.” > > > > I am fine with the other changes. Please go ahead and submit it with the > above change, and I will proceed with the publication process. > > > > Regards > > > > Matthew > > > > *From: *Greg Mirsky <gregimir...@gmail.com> > *Date: *Friday, 20 September 2024 at 11:27 > *To: *Matthew Bocci (Nokia) <matthew.bo...@nokia.com> > *Cc: *draft-ietf-nvo3-geneve-...@ietf.org < > draft-ietf-nvo3-geneve-...@ietf.org>, NVO3 <nvo3@ietf.org> > *Subject: *Re: Document shepherd review of draft-ietf-nvo3-geneve-oam-11 > > > > *CAUTION:* This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext for > additional information. > > > > Hi Matthew, > > thank you for your thorough review and helpful comments. Please find my > notes below tagged GIM>>. Also, I've attached the diff highlighting the > updates applied in the new working version of the draft. > > > > Regards, > > Greg > > > > On Fri, Sep 13, 2024 at 11:40 AM Matthew Bocci (Nokia) < > matthew.bo...@nokia.com> wrote: > > Authors > > > > I have reviewed the latest version of the draft. In general, the draft is > clear and well written – thanks! I have a few comments in-line below that > are mainly aimed at improving the readability of the document, prefixed by > MB> or s/ ( in the case of grammar issues). Please treat these as you would > any other WG last call comments. > > > > Regards > > > > Matthew > > > > > > ======= > > > > > > > > > > NVO3 Working Group G. Mirsky > > Internet-Draft Ericsson > > Intended status: Standards Track S. Boutros > > Expires: 28 February 2025 Ciena > > D. Black > > Dell EMC > > S. Pallagatti > > VMware > > 27 August 2024 > > > > > > OAM for use in GENEVE > > draft-ietf-nvo3-geneve-oam-11 > > > > Abstract > > > > This document lists a set of general requirements for active OAM > > protocols in the Geneve overlay network. Based on the requirements, > > > > s/the requirements/these requirements > > GIM>> Got it, thank you! > > > > > > IP encapsulation for active Operations, Administration, and > > Maintenance protocols in Geneve protocol is defined. Considerations > > for using ICMP and UDP-based protocols are discussed. > > > > [snip] > > > > 1. Introduction > > > > Geneve [RFC8926] is intended to support various scenarios of network > > virtualization. In addition to carrying multi-protocol payload, > > > > s/multi-protocol payload/multiple protocols > > GIM>> It is better indeed. > > > > > > e.g., Ethernet, IPv4/IPv6, the Geneve message includes metadata. > > Operations, Administration, and Maintenance (OAM) protocols support > > fault management and performance monitoring functions necessary for > > comprehensive network operation. Active OAM protocols, as defined in > > [RFC7799], use specially constructed packets that are injected into > > the network. To ensure that the measured performance metric or the > > detected failure of the transport layer are related to a particular > > Geneve flow, it is critical that these test packets share fate with > > overlay data packets for that flow when traversing the underlay > > network. > > > > MB> The last sentence above is a little hard to parse, and I think we > should > > also avoid mixing "transport layer" with the IETF concept of transport > protocols. > > Maybe rephrase along the following lines: > > "To ensure that a performance metric or a detected failure are related to > a particular > > Geneve flow, it is critical that these OAM test packets share fate with > > overlay data packets for that flow when traversing the underlay > > network." > > GIM>> Thank you for that suggestion; applied. > > > > > > A set of general requirements for active OAM protocols in the Geneve > > overlay network is listed in Section 2. IP encapsulation conforms to > > these requirements and is a suitable encapsulation of active OAM > > protocols in a Geneve overlay network. Active OAM in a Geneve > > overlay network are exchanged between two Geneve tunnel endpoints, > > which may be an NVE (Network Virtualization Edge) or another device > > > > > > > > Mirsky, et al. Expires 28 February 2025 [Page 2] > > > > > Internet-Draft OAM in GENEVE August 2024 > > > > > > acting as a Geneve tunnel endpoint. For simplicity, NVE is used to > > > > s/NVE/an NVE > > > > represent the Geneve tunnel endpoint. Please refer to [RFC7365] and > > [RFC8014] for detailed definitions and descriptions of NVE. The IP > > > > s/NVE/an NVE > > GIM>> Done. > > > > encapsulation of Geneve OAM defined in this document applies to an > > overlay service by introducing a Management Virtual Network > > Identifier (VNI) that could be used in combination with various > > values of the Protocol Type field in the Geneve header, i.e., > > Ethertypes for IPv4 or IPv6. Analysis and definition of other types > > > > s/Analysis / The analysis > > GIM>> Thank you! > > > > of OAM encapsulation in Geneve are outside the scope of this > > document. > > > > 1.1. Conventions used in this document > > > > [snip] > > > > 1.1.3. Acronyms > > > > Geneve Generic Network Virtualization Encapsulation > > > > NVO3 Network Virtualization Overlays > > > > OAM Operations, Administration, and Maintenance > > > > VNI Virtual Network Identifier > > > > MB> I suggest adding a '-' or ':' after the terms above > > GIM>> Added ':' > > > > 2. Active OAM Protocols in Geneve Networks > > > > [snip] > > > > tunnel and the state of the OAM protocol the OAM encapsulation is > > required to comply with the following requirements: > > > > REQ#1: Geneve OAM test packets MUST share the fate with data > > traffic of the monitored Geneve tunnel, i.e., be in-band > > (Section 1.1.1) with the monitored traffic, follow the same > > overlay and transport path as packets with data payload, in the > > forward direction, i.e. from ingress toward egress endpoint(s) of > > the OAM test. > > > > MB> I suggest expanding "REQ" to "Requirement" throughout. > > GIM>> Updated accordingly. > > > > An OAM protocol MAY be used to monitor the particular Geneve tunnel > > as a whole. In that case, test packets could be in-band relative to > > a sub-set of tenant flows transported over the Geneve tunnel. If the > > goal is to monitor the condition experienced by the flow of a > > particular tenant, the test packets MUST be in-band with that > > specific flow in the Geneve tunnel. Both scenarios are discussed in > > detail in Section 2.1. > > > > REQ#2: Encapsulation of OAM control message and data packets in > > underlay network MUST be indistinguishable from the underlay > > network IP forwarding point of view. > > > > MB> This is not really clear. I think you are trying to say: "The > encapsulation of > > OAM control messages and data packets in the underlay network MUST be > indistinguishable from > > each other from an underlay network IP forwarding point of view." > > GIM>> You are right, thank you for the proposed text. > > > > REQ#3: Presence of OAM control message in Geneve packet MUST be > > unambiguously identifiable to Geneve functionality, e.g., at > > endpoints of Geneve tunnels. > > > > s/Presence of OAM control message in Geneve packet / The presence of OAM > control messages > > in the Geneve packet > > GIM>> I think that the Geneve packet may include only a single OAM > message. Applied the update in singular form as "OAM control message". > > > > > > > > REQ#4: OAM test packets MUST NOT be forwarded to a tenant system. > > > > A test packet generated by an active OAM protocol, either for a > > defect detection or performance measurement, according to REQ#1, MUST > > be in-band (Section 1.1.1) with the tunnel or data flow being > > monitored. In an environment where multiple paths through the domain > > are available, underlay transport nodes can be programmed to use > > characteristic information to balance the load across known paths. > > It is essential that test packets follow the same route, i.e., > > traverses the same set of nodes and links, as a data packet of the > > monitored flow. Thus, the following requirement to support OAM > > packet fate-sharing with the data flow: > > > > REQ#5: It MUST be possible to express entropy for underlay Equal > > Cost Multipath in the Geneve encapsulation of OAM packets. > > > > 2.1. Defect Detection and Troubleshooting in Geneve Network with Active > > OAM > > > > Figure 1 presents an example of a Geneve domain. In this section, we > > consider two scenarios of active OAM being used to detect and > > localize defects in the Geneve network. > > > > MB> I suggest removing the first person from the above sentence. Also, > rearrange it so the description > > of the section comes first and flows into the figure description: > > > > " This section considers two scenarios where active OAM is used to detect > and > > localize defects in a Geneve network. Figure 1 presents an example of a > Geneve domain." > > GIM>> Thank you for the helpful suggestion. Applied. > > > > > > Mirsky, et al. Expires 28 February 2025 [Page 4] > > > > > Internet-Draft OAM in GENEVE August 2024 > > > > > > +--------+ +--------+ > > | Tenant +--+ +----| Tenant | > > | VNI 28 | | | | VNI 35 | > > +--------+ | ................ | +--------+ > > | +----+ . . +----+ | > > | | NVE|--. .--| NVE| | > > +--| A | . . | B |---+ > > +----+ . . +----+ > > / . . > > / . Geneve . > > +--------+ / . Network . > > | Tenant +--+ . . > > | VNI 35 | . . > > +--------+ ................ > > | > > +----+ > > | NVE| > > | C | > > +----+ > > | > > | > > ===================== > > | | > > +--------+ +--------+ > > | Tenant | | Tenant | > > | VNI 28 | | VNI 35 | > > +--------+ +--------+ > > > > > > Figure 1: An example of a Geneve domain > > > > In the first case, consider when a communication problem between > > Network Virtualization Edge (NVE) device A and NVE C exists. Upon > > the investigation, the operator discovers that the forwarding in the > > underlay, e.g., the IP network, is working well. Still, the Geneve > > connection is unstable for all NVE A and NVE C tenants. Detection, > > troubleshooting, and localization of the problem can be done > > irrespective of the VNI value. > > > > MB> I think this could be phrased "regardless of the VNI value" rather > than > > "irrespective of" because you are not totally dismissng the VNI, but > rather saying that > > detection, troubleshooting and localization can be done for all or any > value of VNI. Is that > > what you mean? > > GIM>> Yes, that is the intended message we convey. Thank you for your > help in making it clearer. > > Also, I think you are refering to the IP underlay network working well. > Please clarify. > > GIM>> Applied s/IP network/IP underlay network/ > > > > > > > > In the second case, traffic on VNI 35 between NVE A and NVE B has no > > problems, as on VNI 28 between NVE A and NVE C. But traffic on VNI > > 35 between NVE A and NVE C experiences problems, for example, > > excessive packet loss. > > > > The first case can be detected and investigated using any VNI value, > > whether it connects tenant systems or not; however, to conform to > > REQ#4 (Section 2) OAM test packets SHOULD be transmitted on a VNI > > that doesn't have any tenants. Such a Geneve tunnel is dedicated to > > > > > > > > Mirsky, et al. Expires 28 February 2025 [Page 5] > > > > > Internet-Draft OAM in GENEVE August 2024 > > > > > > carrying only control and management data between the tunnel > > endpoints, hence it is referred to as a Geneve control channel and > > that VNI is referred to as the Management VNI. A configured VNI MAY > > be used to identify the control channel, but it is RECOMMENDED that > > the default value 1 be used as the Management VNI. Encapsulation of > > test packets using the Management VNI is discussed in Section 2.2. > > > > The control channel of a Geneve tunnel MUST NOT carry tenant data. > > As no tenants are connected using the control channel, a system that > > supports this specification, MUST NOT forward a packet received over > > the control channel to any tenant. A packet received over the > > control channel MAY be forwarded if and only if it is sent onto the > > control channel of the a concatenated Geneve tunnel. > > > > MB> The sentence above is hard to parse. I guess there are a couple of > cases: > > - forward to a concatenated Geneve tunnel. > > - terminate locally. > > Also, why is the above a 'MAY' and not a 'MUST'? Isn't it the case that > if it is forwarded, it MUST only be > > forwarded on the management VNI of a concatenated Geneve tunnel. Else, > it MUST be terminated locally? > > GIM>> Thank you for helping us untangle this knot. The updated text reads > as the following: > > NEW 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. Else, it MUST > > be terminated locally. > > > > > > The Management > > VNI SHOULD be terminated on the tenant-facing side of the Geneve > > encap/decap functionality, not the DC-network-facing side (per > > definitions in Section 4 of [RFC8014]) so that Geneve encap/decap > > functionality is included in its scope. This approach causes an > > active OAM packet, e.g., an ICMP echo request, to be decapsulated in > > the same fashion as any other received Geneve packet. In this > > example, the resulting ICMP packet is handed to NVE's local > > management functionality for the processing which generates an ICMP > > echo reply. The ICMP echo reply is encapsulated in Geneve as > > specified in Section 2.2. for forwarding back to the NVE that sent > > the echo request. One advantage of this approach is that a repeated > > ping test could detect an intermittent problem in Geneve encap/decap > > hardware, which would not be tested if the Management VNI were > > handled as a "special case" at the DC-network-facing interface. > > > > MB> please expand 'encap/decap' to 'encapsulation / decapsulation' > > GIM>> Done. > > > > The second case is when a test packet is transmitted using the VNI > > value associated with the monitored service flow. By doing that, the > > test packet experiences network treatment as the tenant's packets. > > Details of that use case are outside the scope of this specification. > > > > 2.2. OAM Encapsulation in Geneve > > > > Active OAM over a Management VNI in the Geneve network uses an IP > > encapsulation. Protocols such as BFD [RFC5880] or STAMP [RFC8762] > > > > MB> suggest changing to 'BFD [RFC5880] and STAMP [RFC8762] since both can > use UDP transport. > > GIM>> Done. > > > > > > use UDP transport. The destination UDP port number in the inner UDP > > header (Figure 2) identifies the OAM protocol. This approach is > > well-known and has been used, for example, in MPLS networks > > [RFC8029]. To use IP encapsulation for an active OAM protocol the > > Protocol Type field of the Geneve header MUST be set to the IPv4 > > (0x0800) or IPv6 (0x86DD) value. > > > > s/active OAM protocol the / active OAM protocol, the > > GIM>> Applied. > > > > > > > > > > > > > > > > [snip] > > > > > > 5. Security Considerations > > > > As part of a Geneve network, active OAM inherits the security > > considerations discussed in [RFC8926]. Additionally, a system MUST > > provide control to limit the rate of Geneve OAM packets punted to the > > Geneve control plane for processing in order to avoid overloading > > that control plane. > > > > OAM in GENEVE packets uses the General TTL Security Mechanism > > [RFC5082] and any packet received with an inner TTL / Hop Count other > > than 255 MUST be discarded. > > > > MB> I suggest adding a ',' after [RFC5082]. > > GIM>> Thank you. > > > > > > > > > > [snip] > > > > > > Appendix A. Additional Considerations for OAM Encapsulation Method in > > Geneve > > > > > > MB> Do we still need this appendix? I am not sure this history adds value > to a standards track protocol document. > > I suggest removing it. > > GIM>> Thank you for raising that question. I agree with you that there's > not much value in retaining the Appendix for the publication. Earlier > versions of the draft that are already in the datatracker seem to already > preserve that information. > > > > > > Several other options for OAM encapsulation were considered. Those > > are listed in the Appendix solely for informational purposes. These > > options were discarded in favor of the approach described in the main > > body of this document. > > > > A Protocol Type field might be used to demultiplex active OAM > > protocols directly. Such method avoids the use of additional > > intermediate header but requires that each active OAM protocol be > > assigned unique identifier from the Ether Types registry maintained > > by IANA. > > > > The alternative to using the Protocol Type directly is to use a shim > > that, in turn, identifies the OAM Protocol and, optionally, includes > > additional information. [RFC5586] defines how the Generic Associated > > Channel Label (GAL) can be used to identify that the Associated > > Channel Header (ACH), defined in [RFC4385], immediately follows the > > Bottom-of-the-Stack label. Thus, the MPLS Generic Associated Channel > > can be identified, and protocols are demultiplexed based on the > > Channel Type field's value. Number of channel types, e.g., for > > continuity check and performance monitoring, already have been > > defined and are listed in IANA MPLS Generalized Associated Channel > > Types (including Pseudowire Associated Channel Types) registry. The > > value of the Protocol Type field in the Geneve header MUST be set to > > MPLS to use this approach. The Geneve header MUST be immediately > > followed by the GAL label with the S flag set to indicate that GAL is > > the Bottom-of-the-stack label. Then ACH MUST follow the GAL label > > and the value of the Channel Type identifies which of active OAM > > protocols being encapsulated in the packet. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
_______________________________________________ nvo3 mailing list -- nvo3@ietf.org To unsubscribe send an email to nvo3-le...@ietf.org
