idnits 2.17.1 draft-ietf-nvo3-bfd-geneve-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 21, 2021) is 1159 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) ** Downref: Normative reference to an Informational RFC: RFC 7365 ** Downref: Normative reference to an Informational RFC: RFC 8014 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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: August 25, 2021 S. Pallagatti 6 VMware 7 J. Tantsura 8 Juniper Networks 9 February 21, 2021 11 BFD for Geneve 12 draft-ietf-nvo3-bfd-geneve-01 14 Abstract 16 This document describes the use of the Bidirectional Forwarding 17 Detection (BFD) protocol in point-to-point Generic Network 18 Virtualization Encapsulation (Geneve) tunnels used to make up an 19 overlay network. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 25, 2021. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 57 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 58 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 3. BFD Packet Transmission over Geneve Tunnel . . . . . . . . . 3 60 3.1. BFD Encapsulation With Inner Ethernet/IP/UDP Header . . . 3 61 3.2. BFD Encapsulation With Inner IP/UDP Header . . . . . . . 6 62 4. Reception of BFD packet from Geneve Tunnel . . . . . . . . . 8 63 4.1. Demultiplexing of the BFD packet . . . . . . . . . . . . 8 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 69 8.2. Informative References . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 "Generic Network Virtualization Encapsulation" (Geneve) [RFC8926] 75 provides an encapsulation scheme that allows building an overlay 76 network by decoupling the address space of the attached virtual hosts 77 from that of the network. 79 This document describes the use of Bidirectional Forwarding Detection 80 (BFD) protocol [RFC5880] to enable monitoring continuity of the path 81 between two Geneve tunnel endpoints, which may be NVE (Network 82 Virtualization Edge) or other device acting as a Geneve tunnel 83 endpoint. Specifically, the asynchronous mode of BFD, as defined in 84 [RFC5880], is used to monitor a p2p Geneve tunnel, and support for 85 BFD Echo function is outside the scope of this document. For 86 simplicity, in this document, NVE is used to represent Geneve tunnel 87 endpoint, TS (Tenant System) is used to represent the physical or 88 virtual device attached to a Geneve tunnel endpoint from the outside. 89 VAP (Virtual Access Point) is the NVE side of the interface between 90 the NVE and the TS, and a VAP is a logical network port (virtual or 91 physical) into a specific virtual network. For detailed definitions 92 and descriptions of NVE, TS and VAP, please refer to [RFC7365] and 93 [RFC8014]. 95 The use cases and the deployment of BFD for Geneve are consistent 96 with what's described in Section 1 and 3 of [RFC8971] ("Bidirectional 97 Forwarding Detection (BFD) for Virtual eXtensible Local Area Network 98 (VXLAN)"), except for the usage of Management VNI, which is outside 99 the scope of this document. The major difference between Geneve and 100 VXLAN [RFC7348] is that Geneve supports multi-protocol payload and 101 variable length options. 103 2. Conventions Used in This Document 105 2.1. Abbreviations 107 BFD: Bidirectional Forwarding Detection 109 EVPN: Ethernet Virtual Private Networks 111 Geneve: Generic Network Virtualization Encapsulation 113 NVE: Network Virtualization Edge 115 TS: Tenant System 117 VAP: Virtual Access Point 119 VNI: Virtual Network Identifier 121 VXLAN: Virtual eXtensible Local Area Network 123 2.2. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in BCP 128 14 [RFC2119] [RFC8174] when, and only when, they appear in all 129 capitals, as shown here. 131 3. BFD Packet Transmission over Geneve Tunnel 133 Concerning whether the Geneve data packets include an Ethernet frame 134 or an IP packet, this document defines two formats of BFD packet 135 encapsulation in Geneve. BFD session is originated and terminated at 136 VAP of an NVE, selection of the BFD packet encapsulation is based on 137 how the VAP encapsulates the data packets. 139 3.1. BFD Encapsulation With Inner Ethernet/IP/UDP Header 141 If the VAP that originates the BFD packets is used to encapsulate 142 Ethernet data frames, then BFD packets are encapsulated in Geneve as 143 described below. The Geneve packet format over IPv4 is defined in 144 Section 3.1 of [RFC8926]. The Geneve packet format over IPv6 is 145 defined in Section 3.2 of [RFC8926]. The Outer IP/UDP and Geneve 146 headers MUST be encoded by the sender as defined in [RFC8926]. Note 147 that the outer IP header and the inner IP header may not be of the 148 same address family, in other words, outer IPv6 header accompanied 149 with inner IPv4 header and outer IPv4 header accompanied with inner 150 IPv6 header are both possible. 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | | 156 ~ Outer Ethernet Header ~ 157 | | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | | 160 ~ Outer IPvX Header ~ 161 | | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | | 164 ~ Outer UDP Header ~ 165 | | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | | 168 ~ Geneve Header ~ 169 | | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | | 172 ~ Inner Ethernet Header ~ 173 | | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | | 176 ~ Inner IPvX Header ~ 177 | | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | | 180 ~ Inner UDP Header ~ 181 | | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | | 184 ~ BFD Control Packet ~ 185 | | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Outer Ethernet FCS | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Figure 1: Geneve Encapsulation of BFD Control Packet With the Inner 191 Ethernet/IP/UDP Header 193 The BFD packet MUST be carried inside the inner Ethernet frame of the 194 Geneve packet. The inner Ethernet frame carrying the BFD Control 195 packet has the following format: 197 Ethernet Header: 199 Source MAC: MAC address of a VAP of the originating NVE. 201 Destination MAC: MAC address of a VAP of the terminating NVE. 203 IP Header: 205 Source IP: IP address of a VAP of the originating NVE. If the 206 VAP of the originating NVE has no IP address, then the IP 207 address 0.0.0.0 for IPv4 or ::/128 for IPv6 SHOULD be used. 209 Destination IP: IP address of a VAP of the terminating NVE. If 210 the VAP of the terminating NVE has no IP address, then the IP 211 address SHOULD be selected from the range 127/8 for IPv4, or be 212 set to ::1/128 for IPv6. 214 TTL or Hop Limit: MUST be set to 255 in accordance with 215 [RFC5881]. 217 The fields of the UDP header and the BFD Control packet are 218 encoded as specified in [RFC5881]. 220 When the BFD packets are encapsulated in Geneve in this way, the 221 Geneve header defined in [RFC8926] follows the value set below. 223 Opt Len field SHOULD be set to 0, which indicates there isn't any 224 variable length option. 226 O bit MUST be set to 1, which indicates this packet contains a 227 control message. 229 C bit MUST be set to 0, which indicates there isn't any critical 230 option. 232 Protocol Type field MUST be set to 0x6558 (Ethernet frame). 234 Virtual Network Identifier (VNI) field SHOULD be set to the VNI 235 number that the originating VAP is mapped to. 237 3.2. BFD Encapsulation With Inner IP/UDP Header 239 If the VAP that originates the BFD packets is used to encapsulate IP 240 data packets, then BFD packets are encapsulated in Geneve as 241 described below. The Geneve packet format over IPv4 is defined in 242 Section 3.1 of [RFC8926]. The Geneve packet format over IPv6 is 243 defined in Section 3.2 of [RFC8926]. The Outer IP/UDP and Geneve 244 headers MUST be encoded by the sender as defined in [RFC8926]. Note 245 that the outer IP header and the inner IP header may not be of the 246 same address family, in other words, outer IPv6 header accompanied 247 with inner IPv4 header and outer IPv4 header accompanied with inner 248 IPv6 header are both possible. 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | | 254 ~ Ethernet Header ~ 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | | 258 ~ Outer IPvX Header ~ 259 | | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | | 262 ~ Outer UDP Header ~ 263 | | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | | 266 ~ Geneve Header ~ 267 | | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | | 270 ~ Inner IPvX Header ~ 271 | | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | | 274 ~ Inner UDP Header ~ 275 | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | | 278 ~ BFD Control Packet ~ 279 | | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | FCS | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Figure 2: Geneve Encapsulation of BFD Control Packet With the Inner 285 IP/UDP Header 287 The BFD packet MUST be carried inside the inner IP packet of the 288 Geneve packet. The inner IP packet carrying the BFD Control packet 289 has the following format: 291 IP header: 293 Source IP: IP address of a VAP of the originating NVE. 295 Destination IP: IP address of a VAP of the terminating NVE. 297 TTL or Hop Limit: MUST be set to 255 in accordance with 298 [RFC5881]. 300 The fields of the UDP header and the BFD Control packet are 301 encoded as specified in [RFC5881]. 303 When the BFD packets are encapsulated in Geneve in this way, the 304 Geneve header defined in [RFC8926] follows the value set below. 306 Opt Len field SHOULD be set to 0, which indicates there isn't any 307 variable length option. 309 O bit MUST be set to 1, which indicates this packet contains a 310 control message. 312 C bit MUST be set to 0, which indicates there isn't any critical 313 option. 315 Protocol Type field MUST be set to 0x0800 (IPv4) or 0x86DD (IPv6), 316 depending on the address family of the inner IP packet. 318 Virtual Network Identifier (VNI) field SHOULD be set to the VNI 319 number that the originating VAP is mapped to. 321 4. Reception of BFD packet from Geneve Tunnel 323 Once a packet is received, the NVE MUST validate the packet as 324 described in [RFC8926]. 326 If the Protocol Type field equals 0x6558 (Ethernet frame), and the 327 Destination MAC of the inner Ethernet frame matches the MAC 328 address of a VAP which is mapped to the same as received VNI, then 329 the Destination IP, the UDP destination port and the TTL or Hop 330 Limit of the inner IP packet MUST be validated to determine 331 whether the received packet can be processed by BFD. 333 If the Protocol Type field equals 0x0800 (IPv4) or 0x86DD (IPv6), 334 and the Destination IP of the inner IP packet matches the IP 335 address of a VAP which is mapped to the same as received VNI, then 336 the UDP destination port and the TTL or Hop Limit of the inner IP 337 packet MUST be validated to determine whether the received packet 338 can be processed by BFD. 340 4.1. Demultiplexing of the BFD packet 342 In BFD over Geneve, a BFD session is originated and terminated at 343 VAP, usually one NVE owns multiple VAPs, so multiple BFD sessions may 344 be running between two NVEs, there needs to be a mechanism for 345 demultiplexing received BFD packets to the proper session. 346 Furthermore, due to the fact that [RFC8014] allows for N-to-1 mapping 347 between VAP and VNI at one NVE, multiple BFD sessions between two 348 NVEs for the same VNI are allowed. Also note that a BFD session can 349 only be established between two VAPs that are mapped to the same VNI 350 and use the same way to encapsulate data packets. 352 If the BFD packet is received with Your Discriminator equals to 0, 353 for different BFD encapsulation, the procedure for demultiplexing the 354 received BFD packets is different. 356 When the BFD Encapsulation With Inner Ethernet/IP/UDP Header is 357 used, the BFD session MUST be identified using the VNI number, and 358 the inner Ethernet/IP/UDP Header, i.e., the source MAC, the source 359 IP, the destination MAC, the destination IP, and the source UDP 360 port number present in the inner Ethernet/IP/UDP header. 362 When the BFD Encapsulation With Inner IP/UDP Header is used, the 363 BFD session MUST be identified using the VNI number, and the inner 364 IP/UDP header, i.e., the source IP, the destination IP, and the 365 source UDP port number present in the inner IP/UDP header. 367 If the BFD packet is received with non-zero Your Discriminator, then 368 the BFD session MUST be demultiplexed only with Your Discriminator as 369 the key. The exchange of BFD discriminators may be achieved by echo 370 request/reply, EVPN, etc. The detailed mechanism on how to exchange 371 the BFD discriminators is outside the scope of this document. 373 5. Security Considerations 375 This document does not raise any additional security issues beyond 376 those of the specifications referred to in the list of references. 378 6. IANA Considerations 380 This document has no IANA action requested. 382 7. Acknowledgements 384 The authors would like to acknowledge Reshad Rahman, Jeffrey Haas and 385 Matthew Bocci for their guidance on this work. 387 The authors would like to acknowledge David Black for his explanation 388 on the mapping relation between VAP and VNI. 390 8. References 392 8.1. Normative References 394 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 395 Requirement Levels", BCP 14, RFC 2119, 396 DOI 10.17487/RFC2119, March 1997, 397 . 399 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 400 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 401 . 403 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 404 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 405 DOI 10.17487/RFC5881, June 2010, 406 . 408 [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 409 Rekhter, "Framework for Data Center (DC) Network 410 Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 411 2014, . 413 [RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 414 Narten, "An Architecture for Data-Center Network 415 Virtualization over Layer 3 (NVO3)", RFC 8014, 416 DOI 10.17487/RFC8014, December 2016, 417 . 419 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 420 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 421 May 2017, . 423 [RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., 424 "Geneve: Generic Network Virtualization Encapsulation", 425 RFC 8926, DOI 10.17487/RFC8926, November 2020, 426 . 428 8.2. Informative References 430 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 431 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 432 eXtensible Local Area Network (VXLAN): A Framework for 433 Overlaying Virtualized Layer 2 Networks over Layer 3 434 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 435 . 437 [RFC8971] Pallagatti, S., Ed., Mirsky, G., Ed., Paragiri, S., 438 Govindan, V., and M. Mudigonda, "Bidirectional Forwarding 439 Detection (BFD) for Virtual eXtensible Local Area Network 440 (VXLAN)", RFC 8971, DOI 10.17487/RFC8971, December 2020, 441 . 443 Authors' Addresses 445 Xiao Min 446 ZTE Corp. 447 Nanjing 448 China 450 Phone: +86 25 88013062 451 Email: xiao.min2@zte.com.cn 453 Greg Mirsky 454 ZTE Corp. 455 USA 457 Email: gregimirsky@gmail.com 459 Santosh Pallagatti 460 VMware 462 Email: santosh.pallagatti@gmail.com 464 Jeff Tantsura 465 Juniper Networks 467 Email: jefftant.ietf@gmail.com