idnits 2.17.1 draft-mmbb-nvo3-geneve-oam-04.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 (September 25, 2020) is 1308 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: March 29, 2021 Ciena 6 D. Black 7 Dell EMC 8 S. Pallagatti 9 VMware 10 September 25, 2020 12 OAM for use in GENEVE 13 draft-mmbb-nvo3-geneve-oam-04 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 March 29, 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 [I-D.ietf-nvo3-geneve] is intended to support various 79 scenarios of network virtualization. In addition to carrying multi- 80 protocol payload, e.g., Ethernet, IPv4/IPv6, the Geneve message 81 includes metadata. Operations, Administration, and Maintenance (OAM) 82 protocols support fault management and performance monitoring 83 functions necessary for comprehensive network operation. Active OAM 84 protocols, as defined in [RFC7799], use specially constructed packets 85 that are injected into the network. To ensure that the measured 86 performance metric or the detected failure of the transport layer are 87 related to a particular Geneve flow, it is critical that these test 88 packets share fate with overlay data packets for that flow when 89 traversing the underlay 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 155 [I-D.ietf-nvo3-geneve]), including the value in the Virtual Network 156 Identifier (VNI) field. Both scenarios are discussed in detail in 157 Section 2.1. 159 REQ#2: Encapsulation of OAM control message and data packets in 160 underlay network MUST be indistinguishable from the underlay 161 network IP forwarding point of view. 163 REQ#3: Presence of OAM control message in Geneve packet MUST be 164 unambiguously identifiable to Geneve functionality, e.g., at 165 endpoints of Geneve tunnels. 167 REQ#4: OAM test packets MUST NOT be forwaded to a tenant system. 169 A test packet generated by an active OAM protocol, either for a 170 defect detection or performance measurement, according to REQ#1, MUST 171 be fate-sharing with the tunnel or data flow being monitored. In an 172 environment where multiple paths through the domain are available, 173 underlay transport nodes can be programmed to use characteristic 174 information to balance the load across known paths. It is essential 175 that test packets follow the same route, i.e., traverses the same set 176 of nodes and links, as a data packet of the monitored flow. Thus, 177 the following requirement to support OAM packet fate-sharing with the 178 data flow: 180 REQ#5: It MUST be possible to express entropy for underlay Equal 181 Cost Multipath in the Geneve encapsulation of OAM packets. 183 2.1. Defect Detection and Troubleshooting in Geneve Network with Active 184 OAM 186 Figure 1 presents an example of a Geneve domain. In this section, we 187 consider two scenarios of active OAM being used to detect and 188 localize defects in the Geneve network. 190 +--------+ +--------+ 191 | Tenant +--+ +----| Tenant | 192 | VNI 28 | | | | VNI 35 | 193 +--------+ | ................ | +--------+ 194 | +----+ . . +----+ | 195 | | NVE|--. .--| NVE| | 196 +--| A | . . | B |---+ 197 +----+ . . +----+ 198 / . . 199 / . Geneve . 200 +--------+ / . Network . 201 | Tenant +--+ . . 202 | VNI 35 | . . 203 +--------+ ................ 204 | 205 +----+ 206 | NVE| 207 | C | 208 +----+ 209 | 210 | 211 ===================== 212 | | 213 +--------+ +--------+ 214 | Tenant | | Tenant | 215 | VNI 28 | | VNI 35 | 216 +--------+ +--------+ 218 Figure 1: An example of a Geneve domain 220 In the first case, a communication problem between Network 221 Virtualization Edge (NVE) device A and NVE C was observed. The 222 underlay, e.g., IP network, forwarding is working well but the Geneve 223 connection is unstable for all tenants of NVE A and NVE C. 224 Troubleshooting and localization of the problem can be done 225 irrespective of the VNI value. 227 In the second case, traffic on VNI 35 between NVE A and NVE B has no 228 problems, as on VNI 28 between NVE A and NVE C. But traffic on VNI 229 35 between NVE A and NVE C experiences problems, for example, 230 excessive packet loss. 232 The first case can be detected and investigated using any VNI value, 233 whether it connects tenant systems or not. To conform to REQ#4 234 (Section 2) OAM test packets could be transmitted on VNI that doesn't 235 have any tenant. That VNI in a Geneve tunnel is dedicated to 236 carrying only control and management data between the tunnel 237 endpoints, hence communication that uses that VNI is also and 238 referred to as a Geneve control channel. Thus, the control channel 239 of a Geneve tunnel MUST NOT carry tenant data. As no tenants are 240 connected using the control channel, a system that supports this 241 specification, MUST NOT forward a packet received over the control 242 channel to any tenant. A packet received over the control channel 243 MAY be forwarded if and only if it is sent onto the control channel 244 of the concatenated Geneve tunnel. A specific VNI MAY be used to 245 identify the control channel. The value that is associated with this 246 function is referred to as Management VNI. It is RECOMMENDED that 247 the value 1 be used as the default value of Management VNI. 248 Encapsulation of test packets, in this case, is discussed in 249 Section 2.2. The Management VNI SHOULD be terminated on the tenant- 250 facing side of the Geneve encap/decap functionality, not the DC- 251 network-facing side (per definitions in Section 4 [RFC8014]) so that 252 Geneve encap/decap functionality is included in its scope. This 253 approach causes an active OAM packet, e.g., an ICMP echo request, to 254 be decapsulated in the same fashion as any other received Geneve 255 packet. In this example, the resulting ICMP packet is handed to 256 NVE's local management functionality for the processing which 257 generates an ICMP echo reply. The ICMP echo reply is encapsulated in 258 Geneve for forwarding back to the NVE that sent the echo request. 259 One advantage of this approach is that a repeated ping test could 260 detect an intermittent problem in Geneve encap/decap hardware, which 261 would not be tested if the Management VNI were handled as a "special 262 case" at the DC-network-facing interface. 264 The second case requires that a test packet be transmitted using the 265 VNI value for the traffic that is encountering problems. The 266 encapsulation of the test packet, i.e., inner encapsulation, MUST be 267 the same as the tenant packet's encapsulation in the Geneve tunnel 268 and use the same VNI number. Encapsulation of test packets in this 269 case, is discussed in Section 2.2. 271 2.2. OAM Encapsulation in Geneve 273 Active OAM in Geneve network uses an IP encapsulation. Protocols 274 such as BFD [RFC5880] or STAMP [RFC8762] use UDP transport. 275 Destination UDP port number in the inner UDP header (Figure 2) 276 identifies the OAM protocol. This approach is well-known and has 277 been used, for example, in MPLS networks [RFC8029]. The UDP source 278 port can be used to provide entropy, e.g., for Equal Cost Multipath. 279 To use IP encapsulation for an active OAM protocol the Protocol Type 280 field of the Geneve header MUST be set to the IPv4 (0x0800) or IPv6 281 (0x86DD) value. 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | | 287 ~ Outer IPvX Header ~ 288 | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | | 291 ~ Outer UDP Header ~ 292 | | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | | 295 ~ Geneve Header ~ 296 | | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | | 299 ~ Inner IPvX Header ~ 300 | | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | | 303 ~ Inner UDP Header ~ 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | | 307 ~ Active OAM Packet ~ 308 | | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 2: Geneve IP/UDP Encapsulation of an Active OAM Packet 313 Inner IP header: 315 Destination IP: IP address MUST NOT be of one of tenant's IP 316 addresses. The IP address SHOULD be set to the loopback address 317 127.0.0.1/32 for IPv4, or the loopback address ::1/128 for IPv6 318 [RFC4291]. Alternatively, the destination IP address MAY be set 319 to VAP's IP address. 321 Source IP: IP address of the originating VAP. 323 TTL or Hop Limit: MUST be set to 255 per [RFC5082]. 325 3. Echo Request and Echo Reply in Geneve Tunnel 327 ICMP and ICMPv6 ([RFC0792] and [RFC4443] respectively) provide 328 required on-demand defect detection and failure localization. ICMP 329 control messages immediately follow the inner IP header encapsulated 330 in Geneve. ICMP extensions for Geneve networks use mechanisms 331 defined in [RFC4884]. 333 4. IANA Considerations 335 This document has no requirements for IANA. This section can be 336 removed before the publication. 338 5. Security Considerations 340 As part of a Geneve network, active OAM inherits the security 341 considerations discussed in [I-D.ietf-nvo3-geneve]. Additionally, a 342 system MUST provide control to limit the rate of Geneve OAM packets 343 punted to the Geneve control plane for processing in order to avoid 344 overloading that control plane. 346 6. Acknowledgments 348 TBD 350 7. References 352 7.1. Normative References 354 [I-D.ietf-nvo3-geneve] 355 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 356 Network Virtualization Encapsulation", draft-ietf- 357 nvo3-geneve-16 (work in progress), March 2020. 359 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 360 Requirement Levels", BCP 14, RFC 2119, 361 DOI 10.17487/RFC2119, March 1997, 362 . 364 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 365 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 366 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 367 February 2006, . 369 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 370 "MPLS Generic Associated Channel", RFC 5586, 371 DOI 10.17487/RFC5586, June 2009, 372 . 374 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 375 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 376 May 2017, . 378 7.2. Informative References 380 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 381 RFC 792, DOI 10.17487/RFC0792, September 1981, 382 . 384 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 385 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 386 2006, . 388 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 389 Control Message Protocol (ICMPv6) for the Internet 390 Protocol Version 6 (IPv6) Specification", STD 89, 391 RFC 4443, DOI 10.17487/RFC4443, March 2006, 392 . 394 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 395 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 396 DOI 10.17487/RFC4884, April 2007, 397 . 399 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 400 Pignataro, "The Generalized TTL Security Mechanism 401 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 402 . 404 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 405 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 406 . 408 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 409 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 410 May 2016, . 412 [RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 413 Narten, "An Architecture for Data-Center Network 414 Virtualization over Layer 3 (NVO3)", RFC 8014, 415 DOI 10.17487/RFC8014, December 2016, 416 . 418 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 419 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 420 Switched (MPLS) Data-Plane Failures", RFC 8029, 421 DOI 10.17487/RFC8029, March 2017, 422 . 424 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 425 Two-Way Active Measurement Protocol", RFC 8762, 426 DOI 10.17487/RFC8762, March 2020, 427 . 429 Appendix A. Additional Considerations for OAM Encapsulation Method in 430 Geneve 432 Several other options of OAM encapsulation were considered. Those 433 are listed in the Appendix solely for the informational purpose. 435 A Protocol Type field might be used to demultiplex active OAM 436 protocols directly. Such method avoids the use of additional 437 intermediate header but requires that each active OAM protocol be 438 assigned unique identifier from the Ether Types registry maintained 439 by IANA. 441 The alternative to using the Protocol Type directly is to use a shim 442 that, in turn, identifies the OAM Protocol and, optionally, includes 443 additional information. [RFC5586] defines how the Generic Associated 444 Channel Label (GAL) can be used to identify that the Associated 445 Channel Header (ACH), defined in [RFC4385], immediately follows the 446 Bottom-of-the-Stack label. Thus, the MPLS Generic Associated Channel 447 can be identified, and protocols are demultiplexed based on the 448 Channel Type field's value. Number of channel types, e.g., for 449 continuity check and performance monitoring, already have been 450 defined and are listed in IANA MPLS Generalized Associated Channel 451 Types (including Pseudowire Associated Channel Types) registry. The 452 value of the Protocol Type field in the Geneve header MUST be set to 453 MPLS to use this approach. The Geneve header MUST be immediately 454 followed by the GAL label with the S flag set to indicate that GAL is 455 the Bottom-of-the-stack label. Then ACH MUST follow the GAL label 456 and the value of the Channel Type identifies which of active OAM 457 protocols being encapsulated in the packet. 459 Authors' Addresses 461 Greg Mirsky 462 ZTE Corp. 464 Email: gregimirsky@gmail.com 466 Sami Boutros 467 Ciena 469 Email: sboutros@ciena.com 470 David Black 471 Dell EMC 472 176 South Street 473 Hopkinton, MA 01748 474 United States of America 476 Email: david.black@dell.com 478 Santosh Pallagatti 479 VMware 481 Email: santosh.pallagatti@gmail.com