idnits 2.17.1 draft-mmbb-nvo3-geneve-oam-02.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 (March 9, 2020) is 1508 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: September 10, 2020 S. Boutros 6 Ciena 7 D. Black 8 Dell EMC 9 S. Pallagatti, Ed. 10 VMware 11 March 9, 2020 13 OAM for use in GENEVE 14 draft-mmbb-nvo3-geneve-oam-02 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 September 10, 2020. 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 3. Associated Control Channel in Geneve Networks . . . . . . . . 5 65 4. Associated Control Channel Header in Geneve . . . . . . . . . 5 66 4.1. Use of the Geneve ACC Header in Active OAM . . . . . . . 6 67 5. Echo Request and Echo Reply in Geneve Tunnel . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 6.1. Geneve Associated Channel Protocol Types . . . . . . . . 6 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 7 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 74 9.2. Informative References . . . . . . . . . . . . . . . . . 8 75 Appendix A. Additional Considerations for OAM Encapsulation 76 Method in Geneve . . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 Geneve [I-D.ietf-nvo3-geneve] is intended to support various 82 scenarios of network virtualization. In addition to carrying multi- 83 protocol payload, e.g., Ethernet, IPv4/IPv6, the Geneve message 84 includes metadata. Operations, Administration, and Maintenance (OAM) 85 protocols support fault management and performance monitoring 86 functions necessary for comprehensive network operation. Active OAM 87 protocols, as defined in [RFC7799], use specially constructed 88 packets, that are injected into the network. To ensure that the 89 measured performance metric or the detected failure of the transport 90 layer are related to the particular Geneve flow, it is critical that 91 these test packets share fate with overlay data packets when 92 traversing the underlay network. 94 This document describes several options for encapsulation of active 95 OAM protocols in Geneve. These are intended to facilitate the 96 discussion among experts and all interested in both OAM and Geneve 97 subjects. The goal of such analysis is the selection of a practical 98 number of encapsulation methods and providing definitions of any 99 introduced constructs. 101 Also, a set of generic requirements for active OAM protocols in 102 Geneve overlay network introduced in this document. These should be 103 used in selecting the most suitable encapsulation for active OAM in 104 Geneve. 106 1.1. Conventions used in this document 108 1.1.1. Terminology 110 CC Continuity Check 112 CV Connectivity Verification 114 FM Fault Management 116 GAL Generic Associated Channel Label 118 Geneve Generic Network Virtualization Encapsulation 120 NVO3 Network Virtualization Overlays 122 OAM Operations, Administration, and Maintenance 124 ACC Associated Control Channel 126 1.1.2. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in BCP 131 14 [RFC2119] [RFC8174] when, and only when, they appear in all 132 capitals, as shown here. 134 2. Active OAM Protocols in Geneve Networks 136 OAM protocols, whether it is part of fault management or performance 137 monitoring, intended to provide reliable information that can be used 138 to detect a failure, identify the defect, localize it, thus helping 139 to apply corrective actions to minimize the negative impact on 140 service. Several OAM protocols will be used to perform these 141 functions, protocols that require demultiplexing at the receiving 142 instance of Geneve. To improve the accuracy of the correlation 143 between the condition experienced by the monitored Geneve tunnel and 144 the state of the OAM protocol the OAM encapsulation is required to 145 comply with the following requirements: 147 REQ#1: Geneve OAM packets SHOULD share the fate with data traffic 148 of the monitored Geneve tunnel, i.e., be in-band with the 149 monitored traffic, follow precisely the same overlay and transport 150 path as packets with data payload, in the forward direction, i.e. 151 from ingress toward egress endpoint(s) of the OAM test. 153 REQ#2: Encapsulation of OAM control message and data packets in 154 underlay network MUST be indistinguishable from the underlay 155 network forwarding point of view. 157 REQ#3: Presence of OAM control message in Geneve packet MUST be 158 unambiguously identifiable. 160 REQ#4: It MUST be possible to express entropy for underlay Equal 161 Cost Multipath in Geneve encapsulation to avoid using data packet 162 content by underlay transient nodes. 164 2.1. A Control Channel in the Geneve Network 166 There's a need for a general control channel between Geneve tunnel 167 endpoints for OAM protocols that can be used for fault detection, 168 diagnostics, maintenance, and other functions. Such a control tunnel 169 is dedicated to carrying only control and management data between 170 tunnel endpoints. Thus, the control channel of a Geneve tunnel 171 SHOULD NOT carry tenant data. As no tenants are connected using the 172 control channel, a system that supports this specification, SHOULD 173 NOT forward a packet received over the control channel. Virtual 174 Network Identifier (VNI) is used to identify the control channel. 175 The value that is associated with this function is referred to as 176 Management VNI. It is RECOMMENDED that the value 1 be used as the 177 default value of Management VNI. 179 2.2. OAM Encapsulation in Geneve 181 One of the options is to use IP/UDP encapsulation for active OAM. In 182 this case, OAM protocols are identified by the destination UDP port 183 number. This approach is well-known and has been used, for example, 184 in MPLS networks. To use IP/UDP encapsulation for an active OAM 185 protocol the Protocol Type field of the Geneve header MUST be set to 186 IPv4 (0x0800) or IPv6 (0x86DD) value. But extra IP/UDP headers that 187 immediately follow the Geneve header adds to processing of OAM 188 message, further disassociates OAM message from the Geneve header, 189 all of which may cause false negative or positive failure reports. 190 Also, the additional IP/UDP header adds noticeable overhead, 191 especially if the underlay is the IPv6 network. 193 An associated control channel can be defined directly for a Geneve 194 tunnel. This document defines the shim for Geneve is presented in 195 Figure 1 to demultiplex Geneve OAM protocols without much of the 196 overhead. The value of the Protocol Type MAY be set to 0x8902, the 197 value assigned to the IEEE 802.1ag Connectivity Fault Management 198 protocol as part of [IEEE.8021Q] and shared by ITU-T G.8013/Y.1731 199 OAM functions and mechanisms for Ethernet-based networks 200 [ITU-T.1731]. Alternatively, the new value MAY be requested from the 201 Ether Types registry. 203 3. Associated Control Channel in Geneve Networks 205 An associated control channel in the Geneve network is the channel 206 that, by using the same encapsulation as user traffic, follows the 207 same path through the underlay network as user traffic. In other 208 words, the associated channel is in-band with user traffic. Creating 209 the notion of the associated control channel (ACC) in the Geneve 210 network ensures that packets of active OAM protocols carried in the 211 ACC are in-band with user traffic. 213 4. Associated Control Channel Header in Geneve 215 ACC Header immediately follows the Geneve header defined in 216 [I-D.ietf-nvo3-geneve] and identifies the type of message carried 217 over the Geneve ACC. The format of the Geneve ACC Header is: 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | V | Msg Type | Length | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Figure 1: Format of the Associated Channel Header in Geneve Network 227 The ACC Header consists of the following fields: 229 o V - two bits long field indicates the current version of the ACC 230 Header. The current value is 0b00; 232 o Msg Type - 14 bits long field identifies a protocol. In the case 233 of active OAM, these could be Echo Request/Reply, BFD, Performance 234 Measurement; 236 o Length - two octets long field that is the length of the packet in 237 octets; 239 4.1. Use of the Geneve ACC Header in Active OAM 241 Active OAM methods, whether used for fault management or performance 242 monitoring, generate dedicated test packets [RFC7799]. Format of an 243 OAM test packet in the Geneve network presented in Figure 2. 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 ~ Underlay network encapsulation ~ 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------ 250 |Ver| Opt Len |O|C| Rsvd. | Protocol Type | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Geneve 252 | Virtual Network Identifier (VNI) | Reserved | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header 254 | Variable Length Options | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------ 256 | V | Msg Type | Length | ACC 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------ 258 ~ Active OAM message ~ 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Figure 2: Geneve OAM Header in Active OAM Packet 263 5. Echo Request and Echo Reply in Geneve Tunnel 265 [Ed.note] Will be expanded in future versions. 267 6. IANA Considerations 269 IANA is requested to create a new registry called "Geneve Associated 270 Channel". 272 6.1. Geneve Associated Channel Protocol Types 274 IANA is requested to create new sub-registry called "Geneve 275 Associated Channel Protocol Types" in the "Geneve Associated Channel" 276 registry. All code points in the range 1 through 15615 in this 277 registry shall be allocated according to the "IETF Review" procedure 278 as specified in [RFC8126]. Remaining code points are allocated 279 according to Table 1: 281 +---------------+--------------+-------------------------+ 282 | Value | Description | Reference | 283 +---------------+--------------+-------------------------+ 284 | 0 | Reserved | | 285 | 1 - 15615 | Unassigned | IETF Review | 286 | 15616 - 16127 | Unassigned | First Come First Served | 287 | 16128 - 16143 | Experimental | This document | 288 | 16144 - 16382 | Private Use | This document | 289 | 16383 | Reserved | This document | 290 +---------------+--------------+-------------------------+ 292 Table 1: Geneve OAM Protocol type 294 7. Security Considerations 296 TBD 298 8. Acknowledgment 300 TBD 302 9. References 304 9.1. Normative References 306 [I-D.ietf-nvo3-geneve] 307 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 308 Network Virtualization Encapsulation", draft-ietf- 309 nvo3-geneve-16 (work in progress), March 2020. 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, 313 DOI 10.17487/RFC2119, March 1997, 314 . 316 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 317 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 318 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 319 February 2006, . 321 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 322 "MPLS Generic Associated Channel", RFC 5586, 323 DOI 10.17487/RFC5586, June 2009, 324 . 326 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 327 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 328 May 2017, . 330 9.2. Informative References 332 [IEEE.8021Q] 333 IEEE, "IEEE Standard for Local and metropolitan area 334 networks -- Bridges and Bridged Networks", IEEE Std 335 802.1Q, December 2014. 337 [ITU-T.1731] 338 ITU-T, "Operations, administration and maintenance (OAM) 339 functions and mechanisms for Ethernet-based networks", 340 ITU-T G.8013/Y.1731, August 2015. 342 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 343 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 344 May 2016, . 346 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 347 Writing an IANA Considerations Section in RFCs", BCP 26, 348 RFC 8126, DOI 10.17487/RFC8126, June 2017, 349 . 351 Appendix A. Additional Considerations for OAM Encapsulation Method in 352 Geneve 354 Several other options of OAM encapsulation were considered. Those 355 are listed in the Appendix solely for the informational purpose. 357 A Protocol Type field might be used to demultiplex active OAM 358 protocols directly. Such method avoids the use of additional 359 intermediate header but requires that each active OAM protocol be 360 assigned unique identifier from the Ether Types registry maintained 361 by IANA. 363 The alternative to using the Protocol Type directly is to use a shim 364 that, in turn, identifies the OAM Protocol and, optionally, includes 365 additional information. [RFC5586] defines how the Generic Associated 366 Channel Label (GAL) can be used to identify that the Associated 367 Channel Header (ACH), defined in [RFC4385], immediately follows the 368 Bottom-of-the-Stack label. Thus the MPLS Generic Associated Channel 369 can be identified, and protocols are demultiplexed based on the value 370 of the Channel Type field. Number of channel types, e.g., for 371 continuity check and performance monitoring, already have been 372 defined and are listed in IANA MPLS Generalized Associated Channel 373 Types (including Pseudowire Associated Channel Types) registry. To 374 use this approach, the value of the Protocol Type field in the Geneve 375 header MUST be set to MPLS. The Geneve header MUST be immediately 376 followed by the GAL label with the S flag set to indicate that GAL is 377 the Bottom-of-the-stack label. Then ACH MUST follow the GAL label 378 and the value of the Channel Type identifies which of active OAM 379 protocols being encapsulated in the packet. 381 Authors' Addresses 383 Greg Mirsky 384 ZTE Corp. 386 Email: gregimirsky@gmail.com 388 Xiao Min 389 ZTE Corp. 391 Email: xiao.min2@zte.com.cn 393 Sami Boutros 394 Ciena 396 Email: sboutros@ciena.com 398 David Black 399 Dell EMC 400 176 South Street 401 Hopkinton, MA 01748 402 United States of America 404 Email: david.black@dell.com 406 Santosh Pallagatti (editor) 407 VMware 409 Email: santosh.pallagatti@gmail.com