Hi Matthew, thank you for your helpful suggestions. I made some changes in Introduction: Active OAM protocols, as defined in [RFC7799], utilize specially constructed packets injected into the network. OAM protocols such as ICMP/ICMPv6 ([RFC0792] and [RFC4443] respectively), Bidirectional Forwarding Detection (BFD) [RFC5880], and Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] are example of active OAM protocols. and in Active OAM Encapsulation in Geneve section added the reference to RFC 9521 as: [RFC9521] describes the use of IP encapsulation for BFD.
I'll send the current working version and the diff in response to Gunter. Regards, Greg On Wed, Nov 27, 2024 at 1:50 AM Matthew Bocci (Nokia) < matthew.bo...@nokia.com> wrote: > Hi Greg, Gunter > > > > I think the draft should ideally reference 7799 a formal definition of > "Active OAM" , if that is the best we have rather than trying to redefine > it here, since it is a generic term. Adding clarifying text is OK. > > > > This document should also acknowledge RFC9521 as already defining the > Geneve encap for BFD. This document is for other active OAM. > > > > Matthew > > > > > > *From: *Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com> > *Date: *Wednesday, 27 November 2024 at 08:25 > *To: *Greg Mirsky <gregimir...@gmail.com> > *Cc: *draft-ietf-nvo3-geneve-...@ietf.org < > draft-ietf-nvo3-geneve-...@ietf.org>, nvo3-cha...@ietf.org < > nvo3-cha...@ietf.org>, nvo3@ietf.org <nvo3@ietf.org> > *Subject: *RE: [nvo3] Re: [Shepherding AD review] review of > draft-ietf-nvo3-geneve-oam-12 > > Hi Greg, > > > > Thanks for the fast action. Appreciated. > > > > Please see follow up on remaining open items with GV2> > > > > > > Once there is an updated draft I’ll spin through the document again and > see where we land. > > > > Thanks again for the fast action Greg. > > Be well, > > G/ > > > > *From:* Greg Mirsky <gregimir...@gmail.com> > *Sent:* Tuesday, November 26, 2024 6:53 PM > *To:* Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com> > *Cc:* draft-ietf-nvo3-geneve-...@ietf.org; nvo3-cha...@ietf.org; > nvo3@ietf.org > *Subject:* [nvo3] Re: [Shepherding AD review] review of > draft-ietf-nvo3-geneve-oam-12 > > > > > > *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 Gunter, > > thank you for your thorough review and helpful suggestions. Please find my > notes below tagged GIM>>. I hope that I've not missed anything. I attached > the diff that highlights updates in the working version of the draft and > the working version of the draft. > > > > Regards, > > Greg > > > > On Mon, Nov 25, 2024 at 8:52 AM Gunter van de Velde (Nokia) < > gunter.van_de_ve...@nokia.com> wrote: > > # Gunter Van de Velde, RTG AD, comments for draft-ietf-nvo3-geneve-oam-12 > > # the referenced line numbers are derived from the idnits tool: > > https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-nvo3-geneve-oam-12.txt > > # Many thanks for this write-up. Having proper OAM tools for Geneve is > useful and operationally high important. Thank you for this work. > > # Many thanks to the shepherd write-up from Matthew Bocci and the > directorate reviews from Stig Venaas, Paul Kyzivat and Himanshu Shah > > #GENERIC COMMENTS > #================ > > ## The document handles about "active OAM", while the title of the draft > just mentions "OAM". Maybe the draft title can be corrected? > > GIM>> Makes sense to me. Would the following updates of long and short > titles be helpful: > > OLD TEXT: > > OAM for use in GENEVE > > NEW TEXT: > > Active OAM for use in GENEVE > > > > OLD TEXT: > > OAM in GENEVE > > NEW TEXT: > > Active OAM in GENEVE > > > > Also, since the draft's full title is still relatively short, could it be > used as the short version? > > > > GV2> I suspect that would be fine for the Datatracker tools > > > > > ## When reading the document i got confused between the asserted > difference between active oam for geneve and STAMP or BFD. What are the > differences and what is the reason of existence of current document? Could > a small section be inserted to provide some guidelines on where the > specific value for Active OAM, and compare with other mechanisms? > > GIM>> Now I am a bit confused. STAMP and BFD are examples of active OAM > methods for observing networks. Could you help me by pointing out the text > that left that impression? I think some editorial touches are needed to > clarify that STAMP and BFD, echo request/reply, a.k.a. ping, are examples > of active OAM methods. > > > > GV2> I think i found my source of confusion, leading to your confusion 😊. > I am not that very familiar with the exact OAM science. Without a legacy of > years and years of OAM experience as you have, i did not know what exactly > active OAM represents. I was indeed missing the understanding that STAMP > and BFD, echo request/reply, a.k.a. ping, are examples of active OAM > methods. When i was reading the text, my assertion was that there is Active > OAM and separate there is BFD and separate there is STAMP, which lead me to > believe that active OAM was merely echo request/reply. If this is clarified > somewhere at the start of the document it will avoid making this assertion. > > > > > ## Is the active OAM a novel way to say icmp ping (and icmp trace)? is > there anything additional? Maybe this needs to be explicitly mentioned > somewhere early in this draft? and references added to the technologies > asserted to be utilized for active OAM. I also found that it is at the very > end (i.e. section 3) where ICMP and ICMPv6 is discussed for its impact with > Geneve. This seems rather late in the document. If the Active OAM is solely > about ICMP(v6) then maybe a helicopter perspective earlier in the document > helps document readers to understand the objectives better? > > GIM>> RFC 7799 defined active measurement methods as > > o Active Methods generate packet streams. Commonly, the packet > > stream of interest is generated as the basis of measurement. > > The common understanding of Active OAM is as follows: > > Active OAM uses specifically constructed packets to detect, troubleshoot, > > localize defects, and measure performance. > > I've re-arranged sections in the following manner: > > > > GV2> I believe my comment was based upon unclear understanding what ective > OAM is and i assumed that bfd, stamp was something different and that only > icmp echo request/reply was. When that is clarified as discussed earlier, > then that resolves the issue i think. > > > > 2. The Applicability of Active OAM Protocols in Geneve > > Networks . . . . . . . . . . . . . . . . . . . . . . . . 4 > > 2.1. Requirements for Active OAM Protocols in Geneve > > Networks . . . . . . . . . . . . . . . . . . . . . . . . 4 > > 2.2. Defect Detection and Troubleshooting in Geneve Network with > > Active OAM . . . . . . . . . . . . . . . . . . . . . . . 5 > > 2.2.1. Echo Request and Echo Reply in Geneve Tunnel . . . . 7 > > 2.3. OAM Encapsulation in Geneve . . . . . . . . . . . . . . . 7 > > Does that make it clearer? > > > > GV2> difficult to say at this stage, but it seems on the right track > > > > > > ## As i read the document for the first time, i got confused by some > sections to be formal procedures or informational sections. This could of > been due to my lesser experience with OAM protocols and judge accordingly. > Maybe making it more obvious for generalists like me could help making the > document more easy to process? > > #DETAILED COMMENTS > #================= > > 15 Abstract > 16 > 17 This document lists a set of general requirements for active OAM > 18 protocols in the Geneve overlay network. Based on these > 19 requirements, the IP encapsulation of active Operations, > 20 Administration, and Maintenance protocols in the Geneve > protocol is > 21 defined. Considerations for using ICMP and UDP-based protocols > are > 22 discussed. > > GV> What about the following alternative abstract: > > " > Geneve (Generic Network Virtualization Encapsulation) is a flexible and > extensible network virtualization overlay protocol designed to encapsulate > network packets for transport across underlying physical networks. This > document specifies the requirements and provides a framework for > Operations, Administration, and Maintenance (OAM) in Geneve networks. It > outlines the OAM functions necessary to monitor, diagnose, and troubleshoot > Geneve overlay networks to ensure their proper operation and performance. > The document aims to guide the implementation of OAM mechanisms within the > Geneve protocol to support network operators in maintaining reliable and > efficient virtualized network environments. > " > > GIM>> Many thanks for the suggested text. > > > 75 1. Introduction > 76 > 77 Geneve [RFC8926] is intended to support various scenarios of > network > 78 virtualization. In addition to carrying multiple protocols, > e.g., > 79 Ethernet, IPv4/IPv6, the Geneve message includes metadata. > 80 Operations, Administration, and Maintenance (OAM) protocols > support > 81 fault management and performance monitoring functions necessary > for > 82 comprehensive network operation. Active OAM protocols, as > defined in > 83 [RFC7799], use specially constructed packets that are injected > into > 84 the network. To ensure that a performance metric or a detected > 85 failure are related to a particular Geneve flow, it is critical > that > 86 these OAM test packets share fate with overlay data packets for > that > 87 flow when traversing the underlay network. > 88 > 89 A set of general requirements for active OAM protocols in the > Geneve > 90 overlay network is listed in Section 2. IP encapsulation > conforms to > 91 these requirements and is a suitable encapsulation of active OAM > 92 protocols in a Geneve overlay network. Active OAM in a Geneve > 93 overlay network are exchanged between two Geneve tunnel > endpoints, > 94 which may be an NVE (Network Virtualization Edge) or another > device > 95 acting as a Geneve tunnel endpoint. For simplicity, an NVE is > used > 96 to represent the Geneve tunnel endpoint. Please refer to > [RFC7365] > 97 and [RFC8014] for detailed definitions and descriptions of an > NVE. > 98 The IP encapsulation of Geneve OAM defined in this document > applies > 99 to an overlay service by introducing a Management Virtual > Network > 100 Identifier (VNI) that could be used in combination with various > 101 values of the Protocol Type field in the Geneve header, i.e., > 102 Ethertypes for IPv4 or IPv6. The analysis and definition of > other > 103 types of OAM encapsulation in Geneve are outside the scope of > this > 104 document. > > GV> What is unclear to me is how this aligns with ICMP, assuming active > OAM is ICMP? > > GIM>> ICMP packets are specially constructed to detect network defects and > localize them. Hence, ICMP is an example of active OAM. Would you agree? > > > > GV2> yes, agree. What i was missing is what was mentioned earlier that > icmp, bfd and stamp are examples of active OAM. > > > > > GV> idnits rewrite: > > " > Geneve [RFC8926] is designed to support various scenarios of network > virtualization. It encapsulates multiple protocols, such as Ethernet and > IPv4/IPv6, and includes metadata within the Geneve message. > > Operations, Administration, and Maintenance (OAM) protocols provide fault > management and performance monitoring functions necessary for comprehensive > network operation. Active OAM protocols, as defined in [RFC7799], utilize > specially constructed packets injected into the network. To ensure that > performance metrics or detected failures are accurately related to a > particular Geneve flow, it is critical that these OAM test packets share > fate with the overlay data packets of that flow when traversing the > underlay network. > > Section 2 of this document lists the general requirements for active OAM > protocols in the Geneve overlay network. IP encapsulation meets these > requirements and is suitable for encapsulating active OAM protocols within > a Geneve overlay network. Active OAM messages in a Geneve overlay network > are exchanged between two Geneve tunnel endpoints, which may be a Network > Virtualization Edge (NVE) or another device acting as a Geneve tunnel > endpoint. For simplicity, this document uses an NVE to represent the Geneve > tunnel endpoint. Refer to [RFC7365] and [RFC8014] for detailed definitions > and descriptions of an NVE. > > The IP encapsulation of Geneve OAM defined in this document applies to an > overlay service by introducing a Management Virtual Network Identifier > (VNI), which can be used in combination with various values of the Protocol > Type field in the Geneve header, such as Ethertypes for IPv4 or IPv6. The > analysis and definition of other types of OAM encapsulation in Geneve are > outside the scope of this document. > " > > GIM>> Excellent, thank you! > > > 110 * In-band OAM is an active OAM or hybrid OAM method > ([RFC7799]) that > 111 traverses the same set of links and interfaces receiving the > same > 112 QoS treatment as the monitored object, i.e., a Geneve tunnel > as a > 113 whole or a particular tenant flow within given Geneve tunnel. > > GV> In a later section (section 2) this paragraph is used as reference to > the in-band need for REQUIREMENT#1. It is a bit unusual that a terminology > section acts a reference into formal requirement. Maybe that should be > documented in a different place. > > GIM>> The intention was to establish the interpretation of the "in-band" > term. Would removing the reference to the Terminology section (Section > 1.1.1) help? > > > GV> From readability perspective, fixing some idnits: > > " > In-band OAM is an active or hybrid OAM method, as defined in [RFC7799], > that traverses the same set of links and interfaces and receives the same > Quality of Service (QoS) treatment as the monitored object. In this > context, the monitored object refers to either the Geneve tunnel as a whole > or a specific tenant flow within a given Geneve tunnel. > " > > GIM>> I've noticed that that definition of "in-band" is the only place in > the document where the QoS abbreviation is used. Hence, I don't use it in > the update. > > > > GV2> ok > > > > > 123 1.1.3. Acronyms > 124 > 125 Geneve: Generic Network Virtualization Encapsulation > 126 > 127 NVO3: Network Virtualization Overlays > 128 > 129 OAM: Operations, Administration, and Maintenance > 130 > 131 VNI: Virtual Network Identifier > > GV> potentially missing acronyms: VNE, ICMP, ICMPv6 > > GIM>> I couldn't find VNE being used in the draft. Have I missed it? > > > > GV2> My mistake. It was a fat finger typo. It should of displayed NVE > (instead of wrong VNE) > > > > GIM>> ICMP seems to be on the RFC Editor's list of well-known > abbreviations > <https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list>. > > > > GV2> ok. I did not check that list. It it is on there, then all is good > > > > GV> more accurate NVO3: Network Virtualization over Layer 3 > > GIM>> Thank you, I fixed it. > > > 133 2. Active OAM Protocols in Geneve Networks > > GV> Would it be justified to rename this header to "Requirements for > Active OAM Protocols in Geneve Networks" > > GIM>> I agree. Renamed. > > > GV> What seems missing from this discussion why only "Active" is discussed > and not "Passive"? The draft title is "OAM for use in GENEVE" and that > leaves potentially room for both active and passive OAM. is it possible to > expand a little bit about this? > > GIM>> According to the definition in RFC 7799 that we use in this > document, passive OAM methods observe a network flow without altering or > impacting that flow. SNMP query and Netcong notifications reporting, for > example, counter values, are examples of passive OAM methods. I cannot find > any requirement specific to using a passive OAM method in Geneve other than > Don't impact the monitored Geneve tunnel. > > > > GV2> as discussed earlier. The fact that icmp, bfd and stamp are examples > of active OAM i was confused. I will need to read the draft again after the > updates with that aspect in mind. > > > > > 146 Requirement#1: Geneve OAM test packets MUST share the fate > with > 147 data traffic of the monitored Geneve tunnel, i.e., be in-band > 148 (Section 1.1.1) with the monitored traffic, follow the same > 149 overlay and transport path as packets with data payload, in > the > 150 forward direction, i.e. from ingress toward egress > endpoint(s) of > 151 the OAM test. > > GV> rewrite correcting idnits: > > " > Requirement 1: Geneve OAM test packets MUST share the same fate as the > data traffic of the monitored Geneve tunnel. Specifically, the OAM test > packets MUST be in-band (see Section 1.1.1) with the monitored traffic and > follow the same overlay and transport path as packets carrying data > payloads in the forward direction-from the ingress toward the egress > endpoint(s) of the OAM test. > " > > GV2> i assume that the (see section 1.1.1) will be removed here also? > > > 153 An OAM protocol MAY be used to monitor the particular Geneve > tunnel > 154 as a whole. In that case, test packets could be in-band > relative to > 155 a sub-set of tenant flows transported over the Geneve tunnel. > If the > 156 goal is to monitor the condition experienced by the flow of a > 157 particular tenant, the test packets MUST be in-band with that > 158 specific flow in the Geneve tunnel. Both scenarios are > discussed in > 159 detail in Section 2.1. > > GV> What does "Geneve tunnel as a whole" exactly mean. Can this be > accuratly described or referenced? > Would the following describe what was intended to be outlined: > > " > An OAM protocol MAY be employed to monitor an entire Geneve tunnel. In > this case, test packets could be in-band relative to a subset of tenant > flows transported over the Geneve tunnel. If the goal is to monitor the > conditions experienced by the flow of a particular tenant, the test packets > MUST be in-band with that specific flow within the Geneve tunnel. Both > scenarios are discussed in detail in Section 2.1. > " > > GIM>> Thank you for your thoughtful consideration of this paragraph. The > proposed text is much clearer and perfectly conveys our intention. > > > 161 Requirement#2: The encapsulation of OAM control messages and > data > 162 packets in the underlay network MUST be indistinguishable > from > 163 each other from an underlay network IP forwarding point of > view. > 164 > 165 Requirement#3: The presence of an OAM control message in the > 166 Geneve packet MUST be unambiguously identifiable to Geneve > 167 functionality, e.g., at endpoints of Geneve tunnels. > 168 > 169 Requirement#4: OAM test packets MUST NOT be forwarded to a > tenant > 170 system. > > GV> Fixing small idnits: > > " > Requirement 2: The encapsulation of OAM control messages and data packets > in the underlay network MUST be indistinguishable from each other from the > underlay network IP forwarding point of view. > > Requirement 3: The presence of an OAM control message in a Geneve packet > MUST be unambiguously identifiable to Geneve functionality, such as at > endpoints of Geneve tunnels. > > Requirement 4: OAM test packets MUST NOT be forwarded to a tenant system. > " > > GIM>> Many thanks for these suggestions; updated accordingly. > > > 172 A test packet generated by an active OAM protocol, either for a > 173 defect detection or performance measurement, according to > 174 Requirement#1, MUST be in-band (Section 1.1.1) with the tunnel > or > 175 data flow being monitored. In an environment where multiple > paths > 176 through the domain are available, underlay transport nodes can > be > 177 programmed to use characteristic information to balance the load > 178 across known paths. It is essential that test packets follow > the > 179 same route, i.e., traverses the same set of nodes and links, as > a > 180 data packet of the monitored flow. Thus, the following > requirement > 181 to support OAM packet fate-sharing with the data flow: > 182 > 183 Requirement#5: It MUST be possible to express entropy for > underlay > 184 Equal Cost Multipath in the Geneve encapsulation of OAM > packets. > > GV> I am not sure why here also the (Section 1.1.1) is referenced. This > section is a terminology section, It looks unusual to be a justification > for a formal procedure. > > GIM>> As noted earlier, the reference to the Terminology section is > unnecessary. I agree with removing it. > > > > GV> idnits fixing: > > " > A test packet generated by an active OAM protocol, whether for defect > detection or performance measurement, MUST be in-band with the tunnel or > data flow being monitored, as specified in Requirement 1. In environments > 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-that is, traverse the same set of nodes and links-as a data packet of > the monitored flow. Therefore, the following requirement supports OAM > packet fate-sharing with the data flow: > > Requirement 5: It MUST be possible to express entropy for underlay > Equal-Cost Multipath in the Geneve encapsulation of OAM packets. > " > > 186 2.1. Defect Detection and Troubleshooting in Geneve Network with > Active > 187 OAM > 188 > 189 This section considers two scenarios where active OAM is used to > 190 detect and localize defects in a Geneve network. Figure 1 > presents > 191 an example of a Geneve domain. > 192 > 193 +--------+ > +--------+ > 194 | Tenant +--+ +----| > Tenant | > 195 | VNI 28 | | | | > VNI 35 | > 196 +--------+ | ................ | > +--------+ > 197 | +----+ . . +----+ | > 198 | | NVE|--. .--| NVE| | > 199 +--| A | . . | B |---+ > 200 +----+ . . +----+ > 201 / . . > 202 / . Geneve . > 203 +--------+ / . Network . > 204 | Tenant +--+ . . > 205 | VNI 35 | . . > 206 +--------+ ................ > 207 | > 208 +----+ > 209 | NVE| > 210 | C | > 211 +----+ > 212 | > 213 | > 214 ===================== > 215 | | > 216 +--------+ +--------+ > 217 | Tenant | | Tenant | > 218 | VNI 28 | | VNI 35 | > 219 +--------+ +--------+ > 220 > 221 Figure 1: An example of a Geneve domain > 222 > 223 In the first case, consider when a communication problem between > 224 Network Virtualization Edge (NVE) device A and NVE C exists. > Upon > 225 the investigation, the operator discovers that the forwarding > in the > 226 IP underlay network is working accordingly. Still, the Geneve > 227 connection is unstable for all NVE A and NVE C tenants. > Detection, > 228 troubleshooting, and localization of the problem can be done > 229 regardless of the VNI value. > 230 > 231 In the second case, traffic on VNI 35 between NVE A and NVE B > has no > 232 problems, as on VNI 28 between NVE A and NVE C. But traffic on > VNI > 233 35 between NVE A and NVE C experiences problems, for example, > 234 excessive packet loss. > 235 > 236 The first case can be detected and investigated using any VNI > value, > 237 whether it connects tenant systems or not; however, to conform > to > 238 Requirement#4 (Section 2) OAM test packets SHOULD be > transmitted on a > 239 VNI that doesn't have any tenants. Such a Geneve tunnel is > dedicated > 240 to carrying only control and management data between the tunnel > 241 endpoints, hence it is referred to as a Geneve control channel > and > 242 that VNI is referred to as the Management VNI. A configured > VNI MAY > 243 be used to identify the control channel, but it is RECOMMENDED > that > 244 the default value 1 be used as the Management VNI. > Encapsulation of > 245 test packets using the Management VNI is discussed in Section > 2.2. > 246 > 247 The control channel of a Geneve tunnel MUST NOT carry tenant > data. > 248 As no tenants are connected using the control channel, a system > that > 249 supports this specification, MUST NOT forward a packet received > over > 250 the control channel to any tenant. A packet received over the > 251 control channel MUST be forwarded if and only if it is sent > onto the > 252 control channel of the concatenated Geneve tunnel. Else, it > MUST be > 253 terminated locally. The Management VNI SHOULD be terminated on > the > 254 tenant-facing side of the Geneve encapsulation/decapsulation > 255 functionality, not the DC-network-facing side (per definitions > in > 256 Section 4 of [RFC8014]) so that Geneve encap/decap > functionality is > 257 included in its scope. This approach causes an active OAM > packet, > 258 e.g., an ICMP echo request, to be decapsulated in the same > fashion as > 259 any other received Geneve packet. In this example, the > resulting > 260 ICMP packet is handed to NVE's local management functionality > for the > 261 processing which generates an ICMP echo reply. The ICMP echo > reply > 262 is encapsulated in Geneve as specified in Section 2.2. for > forwarding > 263 back to the NVE that sent the echo request. One advantage of > this > 264 approach is that a repeated ping test could detect an > intermittent > 265 problem in Geneve encap/decap hardware, which would not be > tested if > 266 the Management VNI were handled as a "special case" at the DC- > 267 network-facing interface. > 268 > 269 The second case is when a test packet is transmitted using the > VNI > 270 value associated with the monitored service flow. By doing > that, the > 271 test packet experiences network treatment as the tenant's > packets. > 272 Details of that use case are outside the scope of this > specification > >
_______________________________________________ nvo3 mailing list -- nvo3@ietf.org To unsubscribe send an email to nvo3-le...@ietf.org
