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