idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (17 May 2021) is 1074 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 (~~), 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 ZTE Corp. 4 Intended status: Standards Track S. Boutros 5 Expires: 18 November 2021 Ciena 6 D. Black 7 Dell EMC 8 S. Pallagatti 9 VMware 10 17 May 2021 12 OAM for use in GENEVE 13 draft-ietf-nvo3-geneve-oam-02 15 Abstract 17 This document lists a set of general requirements for active OAM 18 protocols in the Geneve overlay network. Based on the requirements, 19 IP encapsulation for active Operations, Administration, and 20 Maintenance protocols in Geneve protocol is defined. Considerations 21 for using ICMP and UDP-based protocols are discussed. 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 18 November 2021. 40 Copyright Notice 42 Copyright (c) 2021 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 (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Conventions used in this document . . . . . . . . . . . . 3 58 1.1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 60 2. Active OAM Protocols in Geneve Networks . . . . . . . . . . . 3 61 2.1. Defect Detection and Troubleshooting in Geneve Network with 62 Active OAM . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. OAM Encapsulation in Geneve . . . . . . . . . . . . . . . 6 64 3. Echo Request and Echo Reply in Geneve Tunnel . . . . . . . . 8 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 7.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Appendix A. Additional Considerations for OAM Encapsulation Method 72 in Geneve . . . . . . . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 Geneve [RFC8926] is intended to support various scenarios of network 78 virtualization. In addition to carrying multi-protocol payload, 79 e.g., 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 the measured performance metric or the 85 detected failure of the transport layer are related to a particular 86 Geneve flow, it is critical that these test packets share fate with 87 overlay data packets for that flow when traversing the underlay 88 network. 90 A set of general requirements for active OAM protocols in the Geneve 91 overlay network is listed in Section 2. IP encapsulation conforms to 92 these requirements and is defined as a suitable encapsulation of 93 active OAM protocols in a Geneve overlay network. Note that the IP 94 encapsulation of OAM is applicable to those VNIs that support the use 95 of the necessary values of the Protocol Type field in the Geneve 96 header, i.e., Ethertypes of IPv4 or IPv6. It does not apply to VNIs 97 that lack that support, e.g., VNIs that only support Ethernet 98 Ethertypes. Analysis and definition of other types of OAM 99 encapsulation in Geneve are outside the scope of this document. 101 1.1. Conventions used in this document 103 1.1.1. Acronyms 105 CC Continuity Check 107 CV Connectivity Verification 109 FM Fault Management 111 Geneve Generic Network Virtualization Encapsulation 113 NVO3 Network Virtualization Overlays 115 OAM Operations, Administration, and Maintenance 117 VNI Virtual Network Identifier 119 1.1.2. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in BCP 124 14 [RFC2119] [RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 2. Active OAM Protocols in Geneve Networks 129 OAM protocols, whether part of fault management or performance 130 monitoring, are intended to provide reliable information that can be 131 used to detect a failure, identify the defect and localize it, thus 132 helping to identify and apply corrective actions to minimize the 133 negative impact on service. Several OAM protocols are used to 134 perform these functions; these protocols require demultiplexing at 135 the receiving instance of Geneve. To improve the accuracy of the 136 correlation between the condition experienced by the monitored Geneve 137 tunnel and the state of the OAM protocol the OAM encapsulation is 138 required to comply with the following requirements: 140 REQ#1: Geneve OAM test packets MUST share the fate with data 141 traffic of the monitored Geneve tunnel, i.e., be in-band with the 142 monitored traffic, follow the same overlay and transport path as 143 packets with data payload, in the forward direction, i.e. from 144 ingress toward egress endpoint(s) of the OAM test. 146 An OAM protocol MAY be used to monitor the particular Geneve tunnel 147 as a whole. In that case, test packets could be fate-sharing with a 148 sub-set of tenant flows transported over the Geneve tunnel. If the 149 goal is to monitor the condition experienced by the flow of a 150 particular tenant, the test packets MUST be fate-sharing with that 151 specific flow in the Geneve tunnel. In the latter case, the test 152 packet MUST use the same Geneve encapsulation as the data packet 153 (except for the value in the Protocol Type field [RFC8926]), 154 including the value in the Virtual Network Identifier (VNI) field. 155 Both scenarios are discussed in detail in Section 2.1. 157 REQ#2: Encapsulation of OAM control message and data packets in 158 underlay network MUST be indistinguishable from the underlay 159 network IP forwarding point of view. 161 REQ#3: Presence of OAM control message in Geneve packet MUST be 162 unambiguously identifiable to Geneve functionality, e.g., at 163 endpoints of Geneve tunnels. 165 REQ#4: OAM test packets MUST NOT be forwaded to a tenant system. 167 A test packet generated by an active OAM protocol, either for a 168 defect detection or performance measurement, according to REQ#1, MUST 169 be fate-sharing with the tunnel or data flow being monitored. In an 170 environment where multiple paths through the domain are available, 171 underlay transport nodes can be programmed to use characteristic 172 information to balance the load across known paths. It is essential 173 that test packets follow the same route, i.e., traverses the same set 174 of nodes and links, as a data packet of the monitored flow. Thus, 175 the following requirement to support OAM packet fate-sharing with the 176 data flow: 178 REQ#5: It MUST be possible to express entropy for underlay Equal 179 Cost Multipath in the Geneve encapsulation of OAM packets. 181 2.1. Defect Detection and Troubleshooting in Geneve Network with Active 182 OAM 184 Figure 1 presents an example of a Geneve domain. In this section, we 185 consider two scenarios of active OAM being used to detect and 186 localize defects in the Geneve network. 188 +--------+ +--------+ 189 | Tenant +--+ +----| Tenant | 190 | VNI 28 | | | | VNI 35 | 191 +--------+ | ................ | +--------+ 192 | +----+ . . +----+ | 193 | | NVE|--. .--| NVE| | 194 +--| A | . . | B |---+ 195 +----+ . . +----+ 196 / . . 197 / . Geneve . 198 +--------+ / . Network . 199 | Tenant +--+ . . 200 | VNI 35 | . . 201 +--------+ ................ 202 | 203 +----+ 204 | NVE| 205 | C | 206 +----+ 207 | 208 | 209 ===================== 210 | | 211 +--------+ +--------+ 212 | Tenant | | Tenant | 213 | VNI 28 | | VNI 35 | 214 +--------+ +--------+ 216 Figure 1: An example of a Geneve domain 218 In the first case, a communication problem between Network 219 Virtualization Edge (NVE) device A and NVE C was observed. The 220 underlay, e.g., IP network, forwarding is working well but the Geneve 221 connection is unstable for all tenants of NVE A and NVE C. 222 Troubleshooting and localization of the problem can be done 223 irrespective of the VNI value. 225 In the second case, traffic on VNI 35 between NVE A and NVE B has no 226 problems, as on VNI 28 between NVE A and NVE C. But traffic on VNI 227 35 between NVE A and NVE C experiences problems, for example, 228 excessive packet loss. 230 The first case can be detected and investigated using any VNI value, 231 whether it connects tenant systems or not. To conform to REQ#4 232 (Section 2) OAM test packets could be transmitted on VNI that doesn't 233 have any tenant. That VNI in a Geneve tunnel is dedicated to 234 carrying only control and management data between the tunnel 235 endpoints, hence communication that uses that VNI is also and 236 referred to as a Geneve control channel. Thus, the control channel 237 of a Geneve tunnel MUST NOT carry tenant data. As no tenants are 238 connected using the control channel, a system that supports this 239 specification, MUST NOT forward a packet received over the control 240 channel to any tenant. A packet received over the control channel 241 MAY be forwarded if and only if it is sent onto the control channel 242 of the concatenated Geneve tunnel. A specific VNI MAY be used to 243 identify the control channel. The value that is associated with this 244 function is referred to as Management VNI. It is RECOMMENDED that 245 the value 1 be used as the default value of Management VNI. 246 Encapsulation of test packets, in this case, is discussed in 247 Section 2.2. The Management VNI SHOULD be terminated on the tenant- 248 facing side of the Geneve encap/decap functionality, not the DC- 249 network-facing side (per definitions in Section 4 [RFC8014]) so that 250 Geneve encap/decap functionality is included in its scope. This 251 approach causes an active OAM packet, e.g., an ICMP echo request, to 252 be decapsulated in the same fashion as any other received Geneve 253 packet. In this example, the resulting ICMP packet is handed to 254 NVE's local management functionality for the processing which 255 generates an ICMP echo reply. The ICMP echo reply is encapsulated in 256 Geneve for forwarding back to the NVE that sent the echo request. 257 One advantage of this approach is that a repeated ping test could 258 detect an intermittent problem in Geneve encap/decap hardware, which 259 would not be tested if the Management VNI were handled as a "special 260 case" at the DC-network-facing interface. 262 The second case requires that a test packet be transmitted using the 263 VNI value for the traffic that is encountering problems. The 264 encapsulation of the test packet, i.e., inner encapsulation, MUST be 265 the same as the tenant packet's encapsulation in the Geneve tunnel 266 and use the same VNI number. Encapsulation of test packets in this 267 case, is discussed in Section 2.2. 269 2.2. OAM Encapsulation in Geneve 271 Active OAM in Geneve network uses an IP encapsulation. Protocols 272 such as BFD [RFC5880] or STAMP [RFC8762] use UDP transport. 273 Destination UDP port number in the inner UDP header (Figure 2) 274 identifies the OAM protocol. This approach is well-known and has 275 been used, for example, in MPLS networks [RFC8029]. The UDP source 276 port can be used to provide entropy, e.g., for Equal Cost Multipath. 277 To use IP encapsulation for an active OAM protocol the Protocol Type 278 field of the Geneve header MUST be set to the IPv4 (0x0800) or IPv6 279 (0x86DD) value. 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | | 285 ~ Outer IPvX Header ~ 286 | | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | | 289 ~ Outer UDP Header ~ 290 | | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | | 293 ~ Geneve Header ~ 294 | | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | | 297 ~ Inner IPvX Header ~ 298 | | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | | 301 ~ Inner UDP Header ~ 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | | 305 ~ Active OAM Packet ~ 306 | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 2: Geneve IP/UDP Encapsulation of an Active OAM Packet 311 Inner IP header: 313 Destination IP: IP address MUST NOT be of one of tenant's IP 314 addresses. The IP address SHOULD be set to the loopback address 315 127.0.0.1/32 for IPv4, or the loopback address ::1/128 for IPv6 316 [RFC4291]. Alternatively, the destination IP address MAY be set 317 to VAP's IP address. 319 Source IP: IP address of the originating VAP. 321 TTL or Hop Limit: MUST be set to 255 per [RFC5082]. 323 3. Echo Request and Echo Reply in Geneve Tunnel 325 ICMP and ICMPv6 ([RFC0792] and [RFC4443] respectively) provide 326 required on-demand defect detection and failure localization. ICMP 327 control messages immediately follow the inner IP header encapsulated 328 in Geneve. ICMP extensions for Geneve networks use mechanisms 329 defined in [RFC4884]. 331 4. IANA Considerations 333 This document has no requirements for IANA. This section can be 334 removed before the publication. 336 5. Security Considerations 338 As part of a Geneve network, active OAM inherits the security 339 considerations discussed in [RFC8926]. Additionally, a system MUST 340 provide control to limit the rate of Geneve OAM packets punted to the 341 Geneve control plane for processing in order to avoid overloading 342 that control plane. 344 6. Acknowledgments 346 TBD 348 7. References 350 7.1. Normative References 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, 354 DOI 10.17487/RFC2119, March 1997, 355 . 357 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 358 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 359 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 360 February 2006, . 362 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 363 "MPLS Generic Associated Channel", RFC 5586, 364 DOI 10.17487/RFC5586, June 2009, 365 . 367 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 368 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 369 May 2017, . 371 [RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., 372 "Geneve: Generic Network Virtualization Encapsulation", 373 RFC 8926, DOI 10.17487/RFC8926, November 2020, 374 . 376 7.2. Informative References 378 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 379 RFC 792, DOI 10.17487/RFC0792, September 1981, 380 . 382 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 383 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 384 2006, . 386 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 387 Control Message Protocol (ICMPv6) for the Internet 388 Protocol Version 6 (IPv6) Specification", STD 89, 389 RFC 4443, DOI 10.17487/RFC4443, March 2006, 390 . 392 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 393 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 394 DOI 10.17487/RFC4884, April 2007, 395 . 397 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 398 Pignataro, "The Generalized TTL Security Mechanism 399 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 400 . 402 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 403 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 404 . 406 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 407 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 408 May 2016, . 410 [RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 411 Narten, "An Architecture for Data-Center Network 412 Virtualization over Layer 3 (NVO3)", RFC 8014, 413 DOI 10.17487/RFC8014, December 2016, 414 . 416 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 417 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 418 Switched (MPLS) Data-Plane Failures", RFC 8029, 419 DOI 10.17487/RFC8029, March 2017, 420 . 422 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 423 Two-Way Active Measurement Protocol", RFC 8762, 424 DOI 10.17487/RFC8762, March 2020, 425 . 427 Appendix A. Additional Considerations for OAM Encapsulation Method in 428 Geneve 430 Several other options of OAM encapsulation were considered. Those 431 are listed in the Appendix solely for the informational purpose. 433 A Protocol Type field might be used to demultiplex active OAM 434 protocols directly. Such method avoids the use of additional 435 intermediate header but requires that each active OAM protocol be 436 assigned unique identifier from the Ether Types registry maintained 437 by IANA. 439 The alternative to using the Protocol Type directly is to use a shim 440 that, in turn, identifies the OAM Protocol and, optionally, includes 441 additional information. [RFC5586] defines how the Generic Associated 442 Channel Label (GAL) can be used to identify that the Associated 443 Channel Header (ACH), defined in [RFC4385], immediately follows the 444 Bottom-of-the-Stack label. Thus, the MPLS Generic Associated Channel 445 can be identified, and protocols are demultiplexed based on the 446 Channel Type field's value. Number of channel types, e.g., for 447 continuity check and performance monitoring, already have been 448 defined and are listed in IANA MPLS Generalized Associated Channel 449 Types (including Pseudowire Associated Channel Types) registry. The 450 value of the Protocol Type field in the Geneve header MUST be set to 451 MPLS to use this approach. The Geneve header MUST be immediately 452 followed by the GAL label with the S flag set to indicate that GAL is 453 the Bottom-of-the-stack label. Then ACH MUST follow the GAL label 454 and the value of the Channel Type identifies which of active OAM 455 protocols being encapsulated in the packet. 457 Authors' Addresses 459 Greg Mirsky 460 ZTE Corp. 462 Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com 463 Sami Boutros 464 Ciena 466 Email: sboutros@ciena.com 468 David Black 469 Dell EMC 470 176 South Street 471 Hopkinton, MA, 01748 472 United States of America 474 Email: david.black@dell.com 476 Santosh Pallagatti 477 VMware 479 Email: santosh.pallagatti@gmail.com