idnits 2.17.1 draft-mmbb-nvo3-geneve-oam-00.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 5, 2019) is 1755 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) == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-13 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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 6, 2020 S. Boutros 6 VmWare, Inc. 7 D. Black 8 Dell EMC 9 July 5, 2019 11 OAM for use in GENEVE 12 draft-mmbb-nvo3-geneve-oam-00 14 Abstract 16 This document defines encapsulation for active Operations, 17 Administration, and Maintenance protocols in Geneve protocol. Also, 18 the format and operation of the Echo Request and Echo Reply mechanism 19 in Geneve are defined. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 6, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Conventions used in this document . . . . . . . . . . . . 3 57 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 58 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 59 2. OAM Protocols Encapsulation in Geneve Networks . . . . . . . 3 60 2.1. OAM Encapsulation in Geneve . . . . . . . . . . . . . . . 4 61 3. Associated Channel in Geneve Networks . . . . . . . . . . . . 5 62 4. Associate Channel Header in Geneve . . . . . . . . . . . . . 5 63 4.1. Use of the Geneve ACh Header in Active OAM . . . . . . . 6 64 5. Echo Request and Echo Reply in Geneve Tunnel . . . . . . . . 6 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 6.1. Geneve Associated Channel Protocol Types . . . . . . . . 6 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 7 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 9.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 Geneve [I-D.ietf-nvo3-geneve] is intended to support various 77 scenarios of network virtualization. In addition to carrying multi- 78 protocol payload, e.g., Ethernet, IPv4/IPv6, the Geneve message 79 includes metadata. Operations, Administration, and Maintenance (OAM) 80 protocols support fault management and performance monitoring 81 functions necessary for comprehensive network operation. Active OAM 82 protocols, as defined in [RFC7799], use specially constructed 83 packets, that are injected into the network. To ensure that the 84 measured performance metric or the detected failure of the transport 85 layer are related to the particular Geneve flow, it is critical that 86 these test packets share fate with overlay data packets when 87 traversing the underlay network. 89 This document describes several options for encapsulation of active 90 OAM protocols in Geneve. These are intended to facilitate the 91 discussion among experts and all interested in both OAM and Geneve 92 subjects. The goal of such analysis is the selection of one 93 encapsulation method and providing 95 Also, a set of generic requirements for active OAM protocols in 96 Geneve overlay network introduced in this document. These should be 97 used in selecting the most suitable encapsulation for active OAM in 98 Geneve. 100 1.1. Conventions used in this document 102 1.1.1. Terminology 104 CC Continuity Check 106 CV Connectivity Verification 108 FM Fault Management 110 GAL Generic Associated Channel Label 112 G-ACh Generic Associated Channel Header 114 Geneve Generic Network Virtualization Encapsulation 116 NVO3 Network Virtualization Overlays 118 OAM Operations, Administration, and Maintenance 120 ACh Associated Channel 122 1.1.2. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 2. OAM Protocols Encapsulation in Geneve Networks 132 OAM protocols, whether it is part of fault management or performance 133 monitoring, intended to provide reliable information that can be used 134 to detect a failure, identify the defect, localize it, thus helping 135 to apply corrective actions to minimize the negative impact on 136 service. Several OAM protocols will be used to perform these 137 functions, protocols that require demultiplexing at the receiving 138 instance of Geneve. To improve the accuracy of the correlation 139 between the condition experienced by the monitored Geneve tunnel and 140 the state of the OAM protocol the OAM encapsulation is required to 141 comply with the following requirements: 143 REQ#1: Geneve OAM packets SHOULD share the fate with data traffic 144 of the monitored Geneve tunnel, i.e., be in-band with the 145 monitored traffic, follow precisely the same overlay and transport 146 path as packets with data payload, in the forward direction, i.e. 147 from ingress toward egress endpoint(s) of the OAM test. 149 REQ#2: Encapsulation of OAM control message and data packets in 150 underlay network MUST be indistinguishable from the underlay 151 network forwarding point of view. 153 REQ#3: Presence of OAM control message in Geneve packet MUST be 154 unambiguously identifiable. 156 REQ#4: It MUST be possible to express entropy for underlay Equal 157 Cost Multipath in Geneve encapsulation to avoid using data packet 158 content by underlay transient nodes. 160 2.1. OAM Encapsulation in Geneve 162 One of the options is to use IP/UDP encapsulation for active OAM. In 163 this case OAM protocols are identified by destination UDP port 164 number. This approach is well-known and has been used, for example, 165 in MPLS networks. To use IP/UDP encapsulation for an active OAM 166 protocol the Protocol Type field of the Geneve header MUST be set to 167 IPv4 (0x0800) or IPv6 (0x86DD) value. But extra IP/UDP headers that 168 immediately follow the Geneve header adds to processing of OAM 169 message, further disassociates OAM message from the Geneve header, 170 all of which may cause false negative or positive failure reports. 171 Also, the additional IP/UDP header adds noticeable overhead, 172 especially if the underlay is the IPv6 network. 174 Another option is to use the Protocol Type field to demultiplex an 175 active OAM protocols directly. Such method avoids the use of 176 additional intermediate header but requires that each active OAM 177 protocol be assigned unique identifier from the Ether Types registry 178 maintained by IANA. 180 The alternative to using the Protocol Type directly is to use a shim 181 that, in turn, identifies the OAM Protocol and, optionally, includes 182 additional information. [RFC5586] defines how the Generic Associated 183 Channel Label (GAL) can be used to identify that the Associated 184 Channel Header (ACH), defined in [RFC4385], immediately follows the 185 Bottom-of-the-Stack label. Thus the MPLS Generic Associated Channel 186 can be identified, and protocols are demultiplexed based on the value 187 of the Channel Type field. Number of channel types, e.g., for 188 continuity check and performance monitoring, already have been 189 defined and are listed in IANA MPLS Generalized Associated Channel 190 (G-ACh) Types (including Pseudowire Associated Channel Types) 191 registry. To use this approach, the value of the Protocol Type field 192 in the Geneve header MUST be set to MPLS. The Geneve header MUST be 193 immediately followed by the GAL label with the S flag set to indicate 194 that GAL is the Bottom-of-the-stack label. Then ACH MUST follow the 195 GAL label and the value of the Channel Type identifies which of 196 active OAM protocols being encapsulated in the packet. 198 Lastly, an associated channel can be defined directly for a Geneve 199 tunnel. This document defines the shim for Geneve is presented in 200 Figure 1 to demultiplex Geneve OAM protocols without much of the 201 overhead. The value of the Protocol Type MAY be set to 0x8902, the 202 value assigned to IEEE 802.1ag Connectivity Fault Management protocol 203 as part of [IEEE.8021Q] and shared by ITU-T G.8013/Y.1731 OAM 204 functions and mechanisms for Ethernet-based networks [ITU-T.1731]. 205 Alternatively, the new value MAY be requested from the Ether Types 206 registry. 208 3. Associated Channel in Geneve Networks 210 An associated channel in the Geneve network is the channel that, by 211 using the same encapsulation as user traffic, follows the same path 212 through the underlay network as user traffic. In other words, the 213 associated channel is in-band with user traffic. Creating the notion 214 of the associated channel (ACh) in the Geneve network ensures that 215 packets of active OAM protocols carried in the ACh are in-band with 216 user traffic. 218 4. Associate Channel Header in Geneve 220 ACh Header immediately follows the Geneve header defined in 221 [I-D.ietf-nvo3-geneve] and identifies the type of message carried 222 over the Geneve ACh. The format of the Geneve ACh Header is: 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | V | Msg Type | Length | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 1: Format of the Associated Channel Header in Geneve Network 232 The ACh Header consists of the following fields: 234 o V - two bits long field indicates the current version of the ACh 235 Header. The current value is 0b00; 237 o Msg Type - 14 bits long field identifies a protocol. In the case 238 of active OAM, these could be Echo Request/Reply, BFD, Performance 239 Measurement; 241 o Length - two octets long field that is the length of the packet in 242 octets; 244 4.1. Use of the Geneve ACh Header in Active OAM 246 Active OAM methods, whether used for fault management or performance 247 monitoring, generate dedicated test packets [RFC7799]. Format of an 248 OAM test packet in Geneve network presented in Figure 2. 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 ~ Underlay network encapsulation ~ 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------ 255 |Ver| Opt Len |O|C| Rsvd. | Protocol Type | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Geneve 257 | Virtual Network Identifier (VNI) | Reserved | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header 259 | Variable Length Options | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------ 261 | V | Msg Type | Length | ACh 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------ 263 ~ Active OAM message ~ 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 2: Geneve OAM Header in Active OAM Packet 268 5. Echo Request and Echo Reply in Geneve Tunnel 270 [Ed.note] Will be expanded in the future versions. 272 6. IANA Considerations 274 IANA is requested to create a new registry called "Geneve Associated 275 Channel". 277 6.1. Geneve Associated Channel Protocol Types 279 IANA is requested to create new sub-registry called "Geneve 280 Associated Channel Protocol Types" in the "Geneve Associated Channel" 281 registry. All code points in the range 1 through 15615 in this 282 registry shall be allocated according to the "IETF Review" procedure 283 as specified in [RFC8126]. Remaining code points are allocated 284 according to Table 1: 286 +---------------+--------------+-------------------------+ 287 | Value | Description | Reference | 288 +---------------+--------------+-------------------------+ 289 | 0 | Reserved | | 290 | 1 - 15615 | Unassigned | IETF Review | 291 | 15616 - 16127 | Unassigned | First Come First Served | 292 | 16128 - 16143 | Experimental | This document | 293 | 16144 - 16382 | Private Use | This document | 294 | 16383 | Reserved | This document | 295 +---------------+--------------+-------------------------+ 297 Table 1: Geneve OAM Protocol type 299 7. Security Considerations 301 TBD 303 8. Acknowledgment 305 TBD 307 9. References 309 9.1. Normative References 311 [I-D.ietf-nvo3-geneve] 312 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 313 Network Virtualization Encapsulation", draft-ietf- 314 nvo3-geneve-13 (work in progress), March 2019. 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, 318 DOI 10.17487/RFC2119, March 1997, 319 . 321 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 322 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 323 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 324 February 2006, . 326 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 327 "MPLS Generic Associated Channel", RFC 5586, 328 DOI 10.17487/RFC5586, June 2009, 329 . 331 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 332 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 333 May 2017, . 335 9.2. Informative References 337 [IEEE.8021Q] 338 IEEE, "IEEE Standard for Local and metropolitan area 339 networks -- Bridges and Bridged Networks", IEEE Std 340 802.1Q, December 2014. 342 [ITU-T.1731] 343 ITU-T, "Operations, administration and maintenance (OAM) 344 functions and mechanisms for Ethernet-based networks", 345 ITU-T G.8013/Y.1731, August 2015. 347 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 348 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 349 May 2016, . 351 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 352 Writing an IANA Considerations Section in RFCs", BCP 26, 353 RFC 8126, DOI 10.17487/RFC8126, June 2017, 354 . 356 Authors' Addresses 358 Greg Mirsky 359 ZTE Corp. 361 Email: gregimirsky@gmail.com 363 Xiao Min 364 ZTE Corp. 366 Email: xiao.min2@zte.com.cn 368 Sami Boutros 369 VmWare, Inc. 371 Email: sboutros@vmware.com 373 David Black 374 Dell EMC 375 176 South Street 376 Hopkinton, MA 01748 377 United States of America 379 Email: david.black@dell.com