idnits 2.17.1 draft-ietf-nvo3-bfd-geneve-05.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 (11 November 2021) is 895 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-03 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 ZTE Corp. 4 Intended status: Standards Track G. Mirsky 5 Expires: 15 May 2022 Ericsson 6 S. Pallagatti 7 VMware 8 J. Tantsura 9 Microsoft 10 S. Aldrin 11 Google 12 11 November 2021 14 BFD for Geneve 15 draft-ietf-nvo3-bfd-geneve-05 17 Abstract 19 This document describes the use of the Bidirectional Forwarding 20 Detection (BFD) protocol in point-to-point Generic Network 21 Virtualization Encapsulation (Geneve) tunnels used to make up an 22 overlay network. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 15 May 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 59 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 3. BFD Packet Transmission over Geneve Tunnel . . . . . . . . . 3 62 3.1. BFD Encapsulation With Inner Ethernet/IP/UDP Header . . . 4 63 3.2. BFD Encapsulation With Inner IP/UDP Header . . . . . . . 6 64 4. Reception of BFD packet from Geneve Tunnel . . . . . . . . . 8 65 4.1. Demultiplexing of the BFD packet . . . . . . . . . . . . 9 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 71 8.2. Informative References . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 "Generic Network Virtualization Encapsulation" (Geneve) [RFC8926] 77 provides an encapsulation scheme that allows building an overlay 78 network by decoupling the address space of the attached virtual hosts 79 from that of the network. 81 This document describes the use of Bidirectional Forwarding Detection 82 (BFD) protocol [RFC5880] to enable monitoring continuity of the path 83 between two Geneve tunnel endpoints, which may be NVE (Network 84 Virtualization Edge) or other device acting as a Geneve tunnel 85 endpoint. Specifically, the asynchronous mode of BFD, as defined in 86 [RFC5880], is used to monitor a p2p Geneve tunnel, and support for 87 BFD Echo function is outside the scope of this document. For 88 simplicity, in this document, NVE is used to represent Geneve tunnel 89 endpoint, TS (Tenant System) is used to represent the physical or 90 virtual device attached to a Geneve tunnel endpoint from the outside. 91 VAP (Virtual Access Point) is the NVE side of the interface between 92 the NVE and the TS, and a VAP is a logical network port (virtual or 93 physical) into a specific virtual network. For detailed definitions 94 and descriptions of NVE, TS and VAP, please refer to [RFC7365] and 95 [RFC8014]. 97 The use cases and the deployment of BFD for Geneve are consistent 98 with what's described in Section 1 and 3 of [RFC8971] ("Bidirectional 99 Forwarding Detection (BFD) for Virtual eXtensible Local Area Network 100 (VXLAN)"), except for the usage of Management VNI, which in the case 101 of Geneve is described in [I-D.ietf-nvo3-geneve-oam], and outside the 102 scope of this document. The major difference between Geneve and 103 VXLAN [RFC7348] is that Geneve supports multi-protocol payload and 104 variable length options. 106 2. Conventions Used in This Document 108 2.1. Abbreviations 110 BFD: Bidirectional Forwarding Detection 112 EVPN: Ethernet Virtual Private Networks 114 Geneve: Generic Network Virtualization Encapsulation 116 NVE: Network Virtualization Edge 118 TS: Tenant System 120 VAP: Virtual Access Point 122 VNI: Virtual Network Identifier 124 VXLAN: Virtual eXtensible Local Area Network 126 2.2. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in BCP 131 14 [RFC2119] [RFC8174] when, and only when, they appear in all 132 capitals, as shown here. 134 3. BFD Packet Transmission over Geneve Tunnel 136 Concerning whether the Geneve data packets include an Ethernet frame 137 or an IP packet, this document defines two formats of BFD packet 138 encapsulation in Geneve. BFD session is originated and terminated at 139 VAP of an NVE, selection of the BFD packet encapsulation is based on 140 how the VAP encapsulates the data packets. 142 3.1. BFD Encapsulation With Inner Ethernet/IP/UDP Header 144 If the VAP that originates the BFD packets is used to encapsulate 145 Ethernet data frames, then BFD packets are encapsulated in Geneve as 146 described below. The Geneve packet format over IPv4 is defined in 147 Section 3.1 of [RFC8926]. The Geneve packet format over IPv6 is 148 defined in Section 3.2 of [RFC8926]. The Outer IP/UDP and Geneve 149 headers MUST be encoded by the sender as defined in [RFC8926]. Note 150 that the outer IP header and the inner IP header may not be of the 151 same address family, in other words, outer IPv6 header accompanied 152 with inner IPv4 header and outer IPv4 header accompanied with inner 153 IPv6 header are both possible. 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | | 159 ~ Outer Ethernet Header ~ 160 | | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | | 163 ~ Outer IPvX Header ~ 164 | | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | | 167 ~ Outer UDP Header ~ 168 | | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | | 171 ~ Geneve Header ~ 172 | | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | | 175 ~ Inner Ethernet Header ~ 176 | | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | | 179 ~ Inner IPvX Header ~ 180 | | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | | 183 ~ Inner UDP Header ~ 184 | | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | | 187 ~ BFD Control Packet ~ 188 | | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Outer Ethernet FCS | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Figure 1: Geneve Encapsulation of BFD Control Packet With the Inner 194 Ethernet/IP/UDP Header 196 The BFD packet MUST be carried inside the inner Ethernet frame of the 197 Geneve packet. The inner Ethernet frame carrying the BFD Control 198 packet has the following format: 200 Ethernet Header: 202 - Source MAC: MAC address of a VAP of the originating NVE. 204 - Destination MAC: MAC address of a VAP of the terminating NVE. 206 IP Header: 208 - Source IP: IP address of a VAP of the originating NVE. If the 209 VAP of the originating NVE has no IP address, then the IP 210 address 0.0.0.0 for IPv4 or ::/128 for IPv6 MUST be used. 212 - Destination IP: IP address of a VAP of the terminating NVE. If 213 the VAP of the terminating NVE has no IP address, then the IP 214 address 127.0.0.1 for IPv4 or ::1/128 for IPv6 MUST be used. 216 - TTL or Hop Limit: MUST be set to 255 in accordance with 217 [RFC5881]. 219 The fields of the UDP header and the BFD Control packet are 220 encoded as specified in [RFC5881]. 222 When the BFD packets are encapsulated in Geneve in this way, the 223 Geneve header defined in [RFC8926] follows the value set below. 225 Opt Len field SHOULD be set to 0, which indicates there isn't any 226 variable length option. 228 O bit MUST be set to 1, which indicates this packet contains a 229 control message. 231 C bit MUST be set to 0, which indicates there isn't any critical 232 option. 234 Protocol Type field MUST be set to 0x6558 (Ethernet frame). 236 Virtual Network Identifier (VNI) field SHOULD be set to the VNI 237 number that the originating VAP is mapped to. 239 3.2. BFD Encapsulation With Inner IP/UDP Header 241 If the VAP that originates the BFD packets is used to encapsulate IP 242 data packets, then BFD packets are encapsulated in Geneve as 243 described below. The Geneve packet format over IPv4 is defined in 244 Section 3.1 of [RFC8926]. The Geneve packet format over IPv6 is 245 defined in Section 3.2 of [RFC8926]. The Outer IP/UDP and Geneve 246 headers MUST be encoded by the sender as defined in [RFC8926]. Note 247 that the outer IP header and the inner IP header may not be of the 248 same address family, in other words, outer IPv6 header accompanied 249 with inner IPv4 header and outer IPv4 header accompanied with inner 250 IPv6 header are both possible. 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | | 256 ~ Ethernet Header ~ 257 | | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | | 260 ~ Outer IPvX Header ~ 261 | | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | | 264 ~ Outer UDP Header ~ 265 | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | | 268 ~ Geneve Header ~ 269 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | | 272 ~ Inner IPvX Header ~ 273 | | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | | 276 ~ Inner UDP Header ~ 277 | | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | | 280 ~ BFD Control Packet ~ 281 | | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | FCS | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 Figure 2: Geneve Encapsulation of BFD Control Packet With the 287 Inner IP/UDP Header 289 The BFD packet MUST be carried inside the inner IP packet of the 290 Geneve packet. The inner IP packet carrying the BFD Control packet 291 has the following format: 293 IP header: 295 - Source IP: IP address of a VAP of the originating NVE. 297 - Destination IP: IP address of a VAP of the terminating NVE. 299 - TTL or Hop Limit: MUST be set to 255 in accordance with 300 [RFC5881]. 302 The fields of the UDP header and the BFD Control packet are 303 encoded as specified in [RFC5881]. 305 When the BFD packets are encapsulated in Geneve in this way, the 306 Geneve header defined in [RFC8926] follows the value set below. 308 Opt Len field SHOULD be set to 0, which indicates there isn't any 309 variable length option. 311 O bit MUST be set to 1, which indicates this packet contains a 312 control message. 314 C bit MUST be set to 0, which indicates there isn't any critical 315 option. 317 Protocol Type field MUST be set to 0x0800 (IPv4) or 0x86DD (IPv6), 318 depending on the address family of the inner IP packet. 320 Virtual Network Identifier (VNI) field SHOULD be set to the VNI 321 number that the originating VAP is mapped to. 323 4. Reception of BFD packet from Geneve Tunnel 325 Once a packet is received, the NVE MUST validate the packet as 326 described in [RFC8926]. 328 If the Protocol Type field equals 0x6558 (Ethernet frame), and the 329 Destination MAC of the inner Ethernet frame matches the MAC 330 address of a VAP which is mapped to the same as received VNI, then 331 the Destination IP, the UDP destination port and the TTL or Hop 332 Limit of the inner IP packet MUST be validated to determine 333 whether the received packet can be processed by BFD. 335 If the Protocol Type field equals 0x0800 (IPv4) or 0x86DD (IPv6), 336 and the Destination IP of the inner IP packet matches the IP 337 address of a VAP which is mapped to the same as received VNI, then 338 the UDP destination port and the TTL or Hop Limit of the inner IP 339 packet MUST be validated to determine whether the received packet 340 can be processed by BFD. 342 4.1. Demultiplexing of the BFD packet 344 In BFD over Geneve, a BFD session is originated and terminated at 345 VAP, usually one NVE owns multiple VAPs, so multiple BFD sessions may 346 be running between two NVEs, there needs to be a mechanism for 347 demultiplexing received BFD packets to the proper session. 348 Furthermore, due to the fact that [RFC8014] allows for N-to-1 mapping 349 between VAP and VNI at one NVE, multiple BFD sessions between two 350 NVEs for the same VNI are allowed. Also note that a BFD session can 351 only be established between two VAPs that are mapped to the same VNI 352 and use the same way to encapsulate data packets. 354 If the BFD packet is received with Your Discriminator equals to 0, 355 for different BFD encapsulation, the procedure for demultiplexing the 356 received BFD packets is different. 358 When the BFD Encapsulation With Inner Ethernet/IP/UDP Header is 359 used, the BFD session MUST be identified using the VNI number, and 360 the inner Ethernet/IP/UDP Header, i.e., the source MAC, the source 361 IP, the destination MAC, the destination IP, and the source UDP 362 port number present in the inner Ethernet/IP/UDP header. 364 When the BFD Encapsulation With Inner IP/UDP Header is used, the 365 BFD session MUST be identified using the VNI number, and the inner 366 IP/UDP header, i.e., the source IP, the destination IP, and the 367 source UDP port number present in the inner IP/UDP header. 369 If the BFD packet is received with non-zero Your Discriminator, then 370 the BFD session MUST be demultiplexed only with Your Discriminator as 371 the key. The exchange of BFD discriminators may be achieved by echo 372 request/reply, EVPN, etc. The detailed mechanism on how to exchange 373 the BFD discriminators is outside the scope of this document. 375 5. Security Considerations 377 This document does not raise any additional security issues beyond 378 those of the specifications referred to in the list of references. 380 6. IANA Considerations 382 This document has no IANA action requested. 384 7. Acknowledgements 386 The authors would like to acknowledge Reshad Rahman, Jeffrey Haas and 387 Matthew Bocci for their guidance on this work. 389 The authors would like to acknowledge David Black for his explanation 390 on the mapping relation between VAP and VNI. 392 8. References 394 8.1. Normative References 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, 398 DOI 10.17487/RFC2119, March 1997, 399 . 401 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 402 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 403 . 405 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 406 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 407 DOI 10.17487/RFC5881, June 2010, 408 . 410 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 411 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 412 May 2017, . 414 [RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., 415 "Geneve: Generic Network Virtualization Encapsulation", 416 RFC 8926, DOI 10.17487/RFC8926, November 2020, 417 . 419 8.2. Informative References 421 [I-D.ietf-nvo3-geneve-oam] 422 Mirsky, G., Boutros, S., Black, D., and S. Pallagatti, 423 "OAM for use in GENEVE", Work in Progress, Internet-Draft, 424 draft-ietf-nvo3-geneve-oam-03, 8 November 2021, 425 . 428 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 429 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 430 eXtensible Local Area Network (VXLAN): A Framework for 431 Overlaying Virtualized Layer 2 Networks over Layer 3 432 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 433 . 435 [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 436 Rekhter, "Framework for Data Center (DC) Network 437 Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 438 2014, . 440 [RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 441 Narten, "An Architecture for Data-Center Network 442 Virtualization over Layer 3 (NVO3)", RFC 8014, 443 DOI 10.17487/RFC8014, December 2016, 444 . 446 [RFC8971] Pallagatti, S., Ed., Mirsky, G., Ed., Paragiri, S., 447 Govindan, V., and M. Mudigonda, "Bidirectional Forwarding 448 Detection (BFD) for Virtual eXtensible Local Area Network 449 (VXLAN)", RFC 8971, DOI 10.17487/RFC8971, December 2020, 450 . 452 Authors' Addresses 454 Xiao Min 455 ZTE Corp. 456 Nanjing 457 China 459 Phone: +86 25 88013062 460 Email: xiao.min2@zte.com.cn 462 Greg Mirsky 463 Ericsson 464 United States of America 466 Email: gregimirsky@gmail.com 468 Santosh Pallagatti 469 VMware 470 India 472 Email: santosh.pallagatti@gmail.com 474 Jeff Tantsura 475 Microsoft 476 United States of America 478 Email: jefftant.ietf@gmail.com 479 Sam Aldrin 480 Google 481 United States of America 483 Email: aldrin.ietf@gmail.com