idnits 2.17.1 draft-ietf-nvo3-bfd-geneve-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 (2 August 2021) is 998 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 (-10) exists of draft-ietf-nvo3-geneve-oam-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NVO3 Working Group X. Min 3 Internet-Draft G. Mirsky 4 Intended status: Standards Track ZTE Corp. 5 Expires: 3 February 2022 S. Pallagatti 6 VMware 7 J. Tantsura 8 Microsoft 9 S. Aldrin 10 Google 11 2 August 2021 13 BFD for Geneve 14 draft-ietf-nvo3-bfd-geneve-04 16 Abstract 18 This document describes the use of the Bidirectional Forwarding 19 Detection (BFD) protocol in point-to-point Generic Network 20 Virtualization Encapsulation (Geneve) tunnels used to make up an 21 overlay network. 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 3 February 2022. 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 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 58 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 3. BFD Packet Transmission over Geneve Tunnel . . . . . . . . . 3 61 3.1. BFD Encapsulation With Inner Ethernet/IP/UDP Header . . . 4 62 3.2. BFD Encapsulation With Inner IP/UDP Header . . . . . . . 6 63 4. Reception of BFD packet from Geneve Tunnel . . . . . . . . . 8 64 4.1. Demultiplexing of the BFD packet . . . . . . . . . . . . 9 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 8.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 "Generic Network Virtualization Encapsulation" (Geneve) [RFC8926] 76 provides an encapsulation scheme that allows building an overlay 77 network by decoupling the address space of the attached virtual hosts 78 from that of the network. 80 This document describes the use of Bidirectional Forwarding Detection 81 (BFD) protocol [RFC5880] to enable monitoring continuity of the path 82 between two Geneve tunnel endpoints, which may be NVE (Network 83 Virtualization Edge) or other device acting as a Geneve tunnel 84 endpoint. Specifically, the asynchronous mode of BFD, as defined in 85 [RFC5880], is used to monitor a p2p Geneve tunnel, and support for 86 BFD Echo function is outside the scope of this document. For 87 simplicity, in this document, NVE is used to represent Geneve tunnel 88 endpoint, TS (Tenant System) is used to represent the physical or 89 virtual device attached to a Geneve tunnel endpoint from the outside. 90 VAP (Virtual Access Point) is the NVE side of the interface between 91 the NVE and the TS, and a VAP is a logical network port (virtual or 92 physical) into a specific virtual network. For detailed definitions 93 and descriptions of NVE, TS and VAP, please refer to [RFC7365] and 94 [RFC8014]. 96 The use cases and the deployment of BFD for Geneve are consistent 97 with what's described in Section 1 and 3 of [RFC8971] ("Bidirectional 98 Forwarding Detection (BFD) for Virtual eXtensible Local Area Network 99 (VXLAN)"), except for the usage of Management VNI, which in the case 100 of Geneve is described in [I-D.ietf-nvo3-geneve-oam], and outside the 101 scope of this document. The major difference between Geneve and 102 VXLAN [RFC7348] is that Geneve supports multi-protocol payload and 103 variable length options. 105 2. Conventions Used in This Document 107 2.1. Abbreviations 109 BFD: Bidirectional Forwarding Detection 111 EVPN: Ethernet Virtual Private Networks 113 Geneve: Generic Network Virtualization Encapsulation 115 NVE: Network Virtualization Edge 117 TS: Tenant System 119 VAP: Virtual Access Point 121 VNI: Virtual Network Identifier 123 VXLAN: Virtual eXtensible Local Area Network 125 2.2. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 3. BFD Packet Transmission over Geneve Tunnel 135 Concerning whether the Geneve data packets include an Ethernet frame 136 or an IP packet, this document defines two formats of BFD packet 137 encapsulation in Geneve. BFD session is originated and terminated at 138 VAP of an NVE, selection of the BFD packet encapsulation is based on 139 how the VAP encapsulates the data packets. 141 3.1. BFD Encapsulation With Inner Ethernet/IP/UDP Header 143 If the VAP that originates the BFD packets is used to encapsulate 144 Ethernet data frames, then BFD packets are encapsulated in Geneve as 145 described below. The Geneve packet format over IPv4 is defined in 146 Section 3.1 of [RFC8926]. The Geneve packet format over IPv6 is 147 defined in Section 3.2 of [RFC8926]. The Outer IP/UDP and Geneve 148 headers MUST be encoded by the sender as defined in [RFC8926]. Note 149 that the outer IP header and the inner IP header may not be of the 150 same address family, in other words, outer IPv6 header accompanied 151 with inner IPv4 header and outer IPv4 header accompanied with inner 152 IPv6 header are both possible. 154 0 1 2 3 155 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 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | | 158 ~ Outer Ethernet Header ~ 159 | | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | | 162 ~ Outer IPvX Header ~ 163 | | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | | 166 ~ Outer UDP Header ~ 167 | | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | | 170 ~ Geneve Header ~ 171 | | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | | 174 ~ Inner Ethernet Header ~ 175 | | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | | 178 ~ Inner IPvX Header ~ 179 | | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | | 182 ~ Inner UDP Header ~ 183 | | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | | 186 ~ BFD Control Packet ~ 187 | | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Outer Ethernet FCS | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Figure 1: Geneve Encapsulation of BFD Control Packet With the Inner 193 Ethernet/IP/UDP Header 195 The BFD packet MUST be carried inside the inner Ethernet frame of the 196 Geneve packet. The inner Ethernet frame carrying the BFD Control 197 packet has the following format: 199 Ethernet Header: 201 - Source MAC: MAC address of a VAP of the originating NVE. 203 - Destination MAC: MAC address of a VAP of the terminating NVE. 205 IP Header: 207 - Source IP: IP address of a VAP of the originating NVE. If the 208 VAP of the originating NVE has no IP address, then the IP 209 address 0.0.0.0 for IPv4 or ::/128 for IPv6 MUST be used. 211 - Destination IP: IP address of a VAP of the terminating NVE. If 212 the VAP of the terminating NVE has no IP address, then the IP 213 address 127.0.0.1 for IPv4 or ::1/128 for IPv6 MUST be used. 215 - TTL or Hop Limit: MUST be set to 255 in accordance with 216 [RFC5881]. 218 The fields of the UDP header and the BFD Control packet are 219 encoded as specified in [RFC5881]. 221 When the BFD packets are encapsulated in Geneve in this way, the 222 Geneve header defined in [RFC8926] follows the value set below. 224 Opt Len field SHOULD be set to 0, which indicates there isn't any 225 variable length option. 227 O bit MUST be set to 1, which indicates this packet contains a 228 control message. 230 C bit MUST be set to 0, which indicates there isn't any critical 231 option. 233 Protocol Type field MUST be set to 0x6558 (Ethernet frame). 235 Virtual Network Identifier (VNI) field SHOULD be set to the VNI 236 number that the originating VAP is mapped to. 238 3.2. BFD Encapsulation With Inner IP/UDP Header 240 If the VAP that originates the BFD packets is used to encapsulate IP 241 data packets, then BFD packets are encapsulated in Geneve as 242 described below. The Geneve packet format over IPv4 is defined in 243 Section 3.1 of [RFC8926]. The Geneve packet format over IPv6 is 244 defined in Section 3.2 of [RFC8926]. The Outer IP/UDP and Geneve 245 headers MUST be encoded by the sender as defined in [RFC8926]. Note 246 that the outer IP header and the inner IP header may not be of the 247 same address family, in other words, outer IPv6 header accompanied 248 with inner IPv4 header and outer IPv4 header accompanied with inner 249 IPv6 header are both possible. 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | | 255 ~ Ethernet Header ~ 256 | | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | | 259 ~ Outer IPvX Header ~ 260 | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | | 263 ~ Outer UDP Header ~ 264 | | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | | 267 ~ Geneve Header ~ 268 | | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | | 271 ~ Inner IPvX Header ~ 272 | | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | | 275 ~ Inner UDP Header ~ 276 | | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | | 279 ~ BFD Control Packet ~ 280 | | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | FCS | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Figure 2: Geneve Encapsulation of BFD Control Packet With the 286 Inner IP/UDP Header 288 The BFD packet MUST be carried inside the inner IP packet of the 289 Geneve packet. The inner IP packet carrying the BFD Control packet 290 has the following format: 292 IP header: 294 - Source IP: IP address of a VAP of the originating NVE. 296 - Destination IP: IP address of a VAP of the terminating NVE. 298 - TTL or Hop Limit: MUST be set to 255 in accordance with 299 [RFC5881]. 301 The fields of the UDP header and the BFD Control packet are 302 encoded as specified in [RFC5881]. 304 When the BFD packets are encapsulated in Geneve in this way, the 305 Geneve header defined in [RFC8926] follows the value set below. 307 Opt Len field SHOULD be set to 0, which indicates there isn't any 308 variable length option. 310 O bit MUST be set to 1, which indicates this packet contains a 311 control message. 313 C bit MUST be set to 0, which indicates there isn't any critical 314 option. 316 Protocol Type field MUST be set to 0x0800 (IPv4) or 0x86DD (IPv6), 317 depending on the address family of the inner IP packet. 319 Virtual Network Identifier (VNI) field SHOULD be set to the VNI 320 number that the originating VAP is mapped to. 322 4. Reception of BFD packet from Geneve Tunnel 324 Once a packet is received, the NVE MUST validate the packet as 325 described in [RFC8926]. 327 If the Protocol Type field equals 0x6558 (Ethernet frame), and the 328 Destination MAC of the inner Ethernet frame matches the MAC 329 address of a VAP which is mapped to the same as received VNI, then 330 the Destination IP, the UDP destination port and the TTL or Hop 331 Limit of the inner IP packet MUST be validated to determine 332 whether the received packet can be processed by BFD. 334 If the Protocol Type field equals 0x0800 (IPv4) or 0x86DD (IPv6), 335 and the Destination IP of the inner IP packet matches the IP 336 address of a VAP which is mapped to the same as received VNI, then 337 the UDP destination port and the TTL or Hop Limit of the inner IP 338 packet MUST be validated to determine whether the received packet 339 can be processed by BFD. 341 4.1. Demultiplexing of the BFD packet 343 In BFD over Geneve, a BFD session is originated and terminated at 344 VAP, usually one NVE owns multiple VAPs, so multiple BFD sessions may 345 be running between two NVEs, there needs to be a mechanism for 346 demultiplexing received BFD packets to the proper session. 347 Furthermore, due to the fact that [RFC8014] allows for N-to-1 mapping 348 between VAP and VNI at one NVE, multiple BFD sessions between two 349 NVEs for the same VNI are allowed. Also note that a BFD session can 350 only be established between two VAPs that are mapped to the same VNI 351 and use the same way to encapsulate data packets. 353 If the BFD packet is received with Your Discriminator equals to 0, 354 for different BFD encapsulation, the procedure for demultiplexing the 355 received BFD packets is different. 357 When the BFD Encapsulation With Inner Ethernet/IP/UDP Header is 358 used, the BFD session MUST be identified using the VNI number, and 359 the inner Ethernet/IP/UDP Header, i.e., the source MAC, the source 360 IP, the destination MAC, the destination IP, and the source UDP 361 port number present in the inner Ethernet/IP/UDP header. 363 When the BFD Encapsulation With Inner IP/UDP Header is used, the 364 BFD session MUST be identified using the VNI number, and the inner 365 IP/UDP header, i.e., the source IP, the destination IP, and the 366 source UDP port number present in the inner IP/UDP header. 368 If the BFD packet is received with non-zero Your Discriminator, then 369 the BFD session MUST be demultiplexed only with Your Discriminator as 370 the key. The exchange of BFD discriminators may be achieved by echo 371 request/reply, EVPN, etc. The detailed mechanism on how to exchange 372 the BFD discriminators is outside the scope of this document. 374 5. Security Considerations 376 This document does not raise any additional security issues beyond 377 those of the specifications referred to in the list of references. 379 6. IANA Considerations 381 This document has no IANA action requested. 383 7. Acknowledgements 385 The authors would like to acknowledge Reshad Rahman, Jeffrey Haas and 386 Matthew Bocci for their guidance on this work. 388 The authors would like to acknowledge David Black for his explanation 389 on the mapping relation between VAP and VNI. 391 8. References 393 8.1. Normative References 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, 397 DOI 10.17487/RFC2119, March 1997, 398 . 400 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 401 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 402 . 404 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 405 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 406 DOI 10.17487/RFC5881, June 2010, 407 . 409 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 410 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 411 May 2017, . 413 [RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., 414 "Geneve: Generic Network Virtualization Encapsulation", 415 RFC 8926, DOI 10.17487/RFC8926, November 2020, 416 . 418 8.2. Informative References 420 [I-D.ietf-nvo3-geneve-oam] 421 Mirsky, G., Boutros, S., Black, D., and S. Pallagatti, 422 "OAM for use in GENEVE", Work in Progress, Internet-Draft, 423 draft-ietf-nvo3-geneve-oam-02, 17 May 2021, 424 . 427 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 428 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 429 eXtensible Local Area Network (VXLAN): A Framework for 430 Overlaying Virtualized Layer 2 Networks over Layer 3 431 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 432 . 434 [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 435 Rekhter, "Framework for Data Center (DC) Network 436 Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 437 2014, . 439 [RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 440 Narten, "An Architecture for Data-Center Network 441 Virtualization over Layer 3 (NVO3)", RFC 8014, 442 DOI 10.17487/RFC8014, December 2016, 443 . 445 [RFC8971] Pallagatti, S., Ed., Mirsky, G., Ed., Paragiri, S., 446 Govindan, V., and M. Mudigonda, "Bidirectional Forwarding 447 Detection (BFD) for Virtual eXtensible Local Area Network 448 (VXLAN)", RFC 8971, DOI 10.17487/RFC8971, December 2020, 449 . 451 Authors' Addresses 453 Xiao Min 454 ZTE Corp. 455 Nanjing 456 China 458 Phone: +86 25 88013062 459 Email: xiao.min2@zte.com.cn 461 Greg Mirsky 462 ZTE Corp. 463 United States of America 465 Email: gregory.mirsky@ztetx.com 467 Santosh Pallagatti 468 VMware 469 India 471 Email: santosh.pallagatti@gmail.com 473 Jeff Tantsura 474 Microsoft 475 United States of America 477 Email: jefftant.ietf@gmail.com 478 Sam Aldrin 479 Google 480 United States of America 482 Email: aldrin.ietf@gmail.com