idnits 2.17.1 draft-mmbb-nvo3-geneve-oam-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2020) is 1376 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NVO3 Working Group G. Mirsky 3 Internet-Draft X. Min 4 Intended status: Standards Track ZTE Corp. 5 Expires: January 14, 2021 S. Boutros 6 Ciena 7 D. Black 8 Dell EMC 9 S. Pallagatti, Ed. 10 VMware 11 July 13, 2020 13 OAM for use in GENEVE 14 draft-mmbb-nvo3-geneve-oam-03 16 Abstract 18 This document defines encapsulation for active Operations, 19 Administration, and Maintenance protocols in Geneve protocol. Also, 20 the format and operation of the Echo Request and Echo Reply mechanism 21 in Geneve are defined. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 14, 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Conventions used in this document . . . . . . . . . . . . 3 59 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 60 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 61 2. Active OAM Protocols in Geneve Networks . . . . . . . . . . . 3 62 2.1. A Control Channel in the Geneve Network . . . . . . . . . 4 63 2.2. OAM Encapsulation in Geneve . . . . . . . . . . . . . . . 4 64 2.3. Associated Control Channel in Geneve Networks . . . . . . 5 65 2.3.1. Use of the Geneve ACC Header in Active OAM . . . . . 6 66 3. Echo Request and Echo Reply in Geneve Tunnel . . . . . . . . 6 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 4.1. Geneve Associated Channel Protocol Types . . . . . . . . 6 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 7 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 7.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Appendix A. Additional Considerations for OAM Encapsulation 75 Method in Geneve . . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 Geneve [I-D.ietf-nvo3-geneve] is intended to support various 81 scenarios of network virtualization. In addition to carrying multi- 82 protocol payload, e.g., Ethernet, IPv4/IPv6, the Geneve message 83 includes metadata. Operations, Administration, and Maintenance (OAM) 84 protocols support fault management and performance monitoring 85 functions necessary for comprehensive network operation. Active OAM 86 protocols, as defined in [RFC7799], use specially constructed 87 packets, that are injected into the network. To ensure that the 88 measured performance metric or the detected failure of the transport 89 layer are related to the particular Geneve flow, it is critical that 90 these test packets share fate with overlay data packets when 91 traversing the underlay network. 93 This document describes several options for encapsulation of active 94 OAM protocols in Geneve. These are intended to facilitate the 95 discussion among experts and all interested in both OAM and Geneve 96 subjects. The goal of such analysis is the selection of a practical 97 number of encapsulation methods and providing definitions of any 98 introduced constructs. 100 Also, a set of generic requirements for active OAM protocols in 101 Geneve overlay network introduced in this document. These should be 102 used in selecting the most suitable encapsulation for active OAM in 103 Geneve. 105 1.1. Conventions used in this document 107 1.1.1. Terminology 109 CC Continuity Check 111 CV Connectivity Verification 113 FM Fault Management 115 GAL Generic Associated Channel Label 117 Geneve Generic Network Virtualization Encapsulation 119 NVO3 Network Virtualization Overlays 121 OAM Operations, Administration, and Maintenance 123 ACC Associated Control Channel 125 1.1.2. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 2. Active OAM Protocols in Geneve Networks 135 OAM protocols, whether it is part of fault management or performance 136 monitoring, intended to provide reliable information that can be used 137 to detect a failure, identify the defect, localize it, thus helping 138 to apply corrective actions to minimize the negative impact on 139 service. Several OAM protocols will be used to perform these 140 functions, protocols that require demultiplexing at the receiving 141 instance of Geneve. To improve the accuracy of the correlation 142 between the condition experienced by the monitored Geneve tunnel and 143 the state of the OAM protocol the OAM encapsulation is required to 144 comply with the following requirements: 146 REQ#1: Geneve OAM packets SHOULD share the fate with data traffic 147 of the monitored Geneve tunnel, i.e., be in-band with the 148 monitored traffic, follow precisely the same overlay and transport 149 path as packets with data payload, in the forward direction, i.e. 150 from ingress toward egress endpoint(s) of the OAM test. 152 REQ#2: Encapsulation of OAM control message and data packets in 153 underlay network MUST be indistinguishable from the underlay 154 network forwarding point of view. 156 REQ#3: Presence of OAM control message in Geneve packet MUST be 157 unambiguously identifiable. 159 A test packet generated by an active OAM protocol either for a defect 160 detection or performance measurement MUST be fate-sharing with the 161 data flow being monitored In an environment where multiple paths 162 through the domain are available transient nodes can be programmed to 163 use characteristic information to balance the load across available 164 paths. It is essential that a test packet follows the same route, 165 i.e., traverses the same set of nodes and links, as a data packet of 166 the monitored flow. Thus, the following requirement to support OAM 167 packet fate-sharing with the data flow: 169 REQ#4: It MUST be possible to express entropy for underlay Equal 170 Cost Multipath in Geneve encapsulation to avoid using data packet 171 content by underlay transient nodes. 173 2.1. A Control Channel in the Geneve Network 175 There's a need for a general control channel between Geneve tunnel 176 endpoints for OAM protocols that can be used for fault detection, 177 diagnostics, maintenance, and other functions. Such a control tunnel 178 is dedicated to carrying only control and management data between 179 tunnel endpoints. Thus, the control channel of a Geneve tunnel 180 SHOULD NOT carry tenant data. As no tenants are connected using the 181 control channel, a system that supports this specification, SHOULD 182 NOT forward a packet received over the control channel. Virtual 183 Network Identifier (VNI) is used to identify the control channel. 184 The value that is associated with this function is referred to as 185 Management VNI. It is RECOMMENDED that the value 1 be used as the 186 default value of Management VNI. 188 2.2. OAM Encapsulation in Geneve 190 One of the options is to use IP/UDP encapsulation for active OAM. In 191 this case, OAM protocols are identified by the destination UDP port 192 number. This approach is well-known and has been used, for example, 193 in MPLS networks. To use IP/UDP encapsulation for an active OAM 194 protocol the Protocol Type field of the Geneve header MUST be set to 195 IPv4 (0x0800) or IPv6 (0x86DD) value. But extra IP/UDP headers that 196 immediately follow the Geneve header add to processing of OAM 197 message, further disassociating OAM message from the Geneve header, 198 all of which may cause false negative or positive failure reports. 199 Also, the additional IP/UDP header adds noticeable overhead, 200 especially if the underlay is the IPv6 network. 202 2.3. Associated Control Channel in Geneve Networks 204 An associated control channel (ACC) in the Geneve network is the 205 channel that, by using the same encapsulation as user traffic, 206 follows the same path through the underlay network as user traffic. 207 In other words, the associated channel is in-band with user traffic. 208 Creating the notion of the ACC in the Geneve network ensures that 209 packets of active OAM protocols carried in the ACC are in-band with 210 user traffic. 212 An ACC can be defined directly for a Geneve tunnel. This document 213 defines the shim for Geneve is presented in Figure 1 to demultiplex 214 Geneve OAM protocols without much of the overhead. The value of the 215 Protocol Type MAY be set to 0x8902, the value assigned to the IEEE 216 802.1ag Connectivity Fault Management protocol as part of 217 [IEEE.8021Q] and shared by ITU-T G.8013/Y.1731 OAM functions and 218 mechanisms for Ethernet-based networks [ITU-T.1731]. Alternatively, 219 the new value MAY be requested from the Ether Types registry. 221 ACC Header immediately follows the Geneve header defined in 222 [I-D.ietf-nvo3-geneve] and identifies the type of message carried 223 over the Geneve ACC. The format of the Geneve ACC Header is: 225 0 1 2 3 226 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | V | Msg Type | Length | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 1: Format of the Associated Channel Header in Geneve Network 233 The ACC Header consists of the following fields: 235 o V - two bits long field indicates the current version of the ACC 236 Header. The current value is 0b00; 238 o Msg Type - 14 bits long field identifies a protocol. In the case 239 of active OAM, these could be Echo Request/Reply, BFD, Performance 240 Measurement; 242 o Length - two octets long field that is the length of the packet in 243 octets; 245 2.3.1. Use of the Geneve ACC Header in Active OAM 247 Active OAM methods, whether used for fault management or performance 248 monitoring, generate dedicated test packets [RFC7799]. Format of an 249 OAM test packet in the Geneve network presented in Figure 2. 251 0 1 2 3 252 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 ~ Underlay network encapsulation ~ 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------ 256 |Ver| Opt Len |O|C| Rsvd. | Protocol Type | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Geneve 258 | Virtual Network Identifier (VNI) | Reserved | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header 260 | Variable Length Options | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------ 262 | V | Msg Type | Length | ACC 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------ 264 ~ Active OAM message ~ 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Figure 2: Geneve OAM Header in Active OAM Packet 269 3. Echo Request and Echo Reply in Geneve Tunnel 271 [Ed.note] Will be expanded in future versions. 273 4. IANA Considerations 275 IANA is requested to create a new registry called "Geneve Associated 276 Channel". 278 4.1. Geneve Associated Channel Protocol Types 280 IANA is requested to create new sub-registry called "Geneve 281 Associated Channel Protocol Types" in the "Geneve Associated Channel" 282 registry. All code points in the range 1 through 15615 in this 283 registry shall be allocated according to the "IETF Review" procedure 284 as specified in [RFC8126]. Remaining code points are allocated 285 according to Table 1: 287 +---------------+--------------+-------------------------+ 288 | Value | Description | Reference | 289 +---------------+--------------+-------------------------+ 290 | 0 | Reserved | | 291 | 1 - 15615 | Unassigned | IETF Review | 292 | 15616 - 16127 | Unassigned | First Come First Served | 293 | 16128 - 16143 | Experimental | This document | 294 | 16144 - 16382 | Private Use | This document | 295 | 16383 | Reserved | This document | 296 +---------------+--------------+-------------------------+ 298 Table 1: Geneve OAM Protocol type 300 5. Security Considerations 302 As part of a Geneve network, active OAM inherits the security 303 considerations discussed in [I-D.ietf-nvo3-geneve]. Additionally, a 304 system MUST provide a control to limit the rate of Geneve OAM packets 305 punted for to the Geneve control plane for processing. 307 6. Acknowledgment 309 TBD 311 7. References 313 7.1. Normative References 315 [I-D.ietf-nvo3-geneve] 316 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 317 Network Virtualization Encapsulation", draft-ietf- 318 nvo3-geneve-16 (work in progress), March 2020. 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, 322 DOI 10.17487/RFC2119, March 1997, 323 . 325 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 326 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 327 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 328 February 2006, . 330 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 331 "MPLS Generic Associated Channel", RFC 5586, 332 DOI 10.17487/RFC5586, June 2009, 333 . 335 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 336 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 337 May 2017, . 339 7.2. Informative References 341 [IEEE.8021Q] 342 IEEE, "IEEE Standard for Local and metropolitan area 343 networks -- Bridges and Bridged Networks", IEEE Std 344 802.1Q, December 2014. 346 [ITU-T.1731] 347 ITU-T, "Operations, administration and maintenance (OAM) 348 functions and mechanisms for Ethernet-based networks", 349 ITU-T G.8013/Y.1731, August 2015. 351 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 352 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 353 May 2016, . 355 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 356 Writing an IANA Considerations Section in RFCs", BCP 26, 357 RFC 8126, DOI 10.17487/RFC8126, June 2017, 358 . 360 Appendix A. Additional Considerations for OAM Encapsulation Method in 361 Geneve 363 Several other options of OAM encapsulation were considered. Those 364 are listed in the Appendix solely for the informational purpose. 366 A Protocol Type field might be used to demultiplex active OAM 367 protocols directly. Such method avoids the use of additional 368 intermediate header but requires that each active OAM protocol be 369 assigned unique identifier from the Ether Types registry maintained 370 by IANA. 372 The alternative to using the Protocol Type directly is to use a shim 373 that, in turn, identifies the OAM Protocol and, optionally, includes 374 additional information. [RFC5586] defines how the Generic Associated 375 Channel Label (GAL) can be used to identify that the Associated 376 Channel Header (ACH), defined in [RFC4385], immediately follows the 377 Bottom-of-the-Stack label. Thus the MPLS Generic Associated Channel 378 can be identified, and protocols are demultiplexed based on the value 379 of the Channel Type field. Number of channel types, e.g., for 380 continuity check and performance monitoring, already have been 381 defined and are listed in IANA MPLS Generalized Associated Channel 382 Types (including Pseudowire Associated Channel Types) registry. To 383 use this approach, the value of the Protocol Type field in the Geneve 384 header MUST be set to MPLS. The Geneve header MUST be immediately 385 followed by the GAL label with the S flag set to indicate that GAL is 386 the Bottom-of-the-stack label. Then ACH MUST follow the GAL label 387 and the value of the Channel Type identifies which of active OAM 388 protocols being encapsulated in the packet. 390 Authors' Addresses 392 Greg Mirsky 393 ZTE Corp. 395 Email: gregimirsky@gmail.com 397 Xiao Min 398 ZTE Corp. 400 Email: xiao.min2@zte.com.cn 402 Sami Boutros 403 Ciena 405 Email: sboutros@ciena.com 407 David Black 408 Dell EMC 409 176 South Street 410 Hopkinton, MA 01748 411 United States of America 413 Email: david.black@dell.com 415 Santosh Pallagatti (editor) 416 VMware 418 Email: santosh.pallagatti@gmail.com