idnits 2.17.1 draft-ietf-nvo3-bfd-geneve-00.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 (November 15, 2020) is 1257 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: May 19, 2021 S. Pallagatti 6 VMware 7 J. Tantsura 8 Apstra 9 November 15, 2020 11 BFD for Geneve 12 draft-ietf-nvo3-bfd-geneve-00 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 May 19, 2021. 38 Copyright Notice 40 Copyright (c) 2020 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 . . . . . . . . . . . . 9 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) 75 [I-D.ietf-nvo3-geneve] provides an encapsulation scheme that allows 76 building an overlay network by decoupling the address space of the 77 attached virtual hosts 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 [I-D.ietf-bfd-vxlan]. 98 The major difference between Geneve and "Virtual eXtensible Local 99 Area Network" (VXLAN) [RFC7348] encapsulation is that Geneve supports 100 multi-protocol payload and variable length options. 102 2. Conventions Used in This Document 104 2.1. Abbreviations 106 BFD: Bidirectional Forwarding Detection 108 Geneve: Generic Network Virtualization Encapsulation 110 NVE: Network Virtualization Edge 112 TS: Tenant System 114 VAP: Virtual Access Point 116 VNI: Virtual Network Identifier 118 VXLAN: Virtual eXtensible Local Area Network 120 2.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 3. BFD Packet Transmission over Geneve Tunnel 130 Concerning whether the Geneve data packets include an Ethernet frame 131 or an IP packet, this document defines two formats of BFD packet 132 encapsulation in Geneve. BFD session is originated and terminated at 133 VAP of an NVE, selection of the BFD packet encapsulation is based on 134 how the VAP encapsulates the data packets. 136 3.1. BFD Encapsulation With Inner Ethernet/IP/UDP Header 138 If the VAP that originates the BFD packets is used to encapsulate 139 Ethernet data frames, then BFD packets are encapsulated in Geneve as 140 described below. The Geneve packet format over IPv4 is defined in 141 Section 3.1 of [I-D.ietf-nvo3-geneve]. The Geneve packet format over 142 IPv6 is defined in Section 3.2 of [I-D.ietf-nvo3-geneve]. The Outer 143 IP/UDP and Geneve headers MUST be encoded by the sender as defined in 144 [I-D.ietf-nvo3-geneve]. Note that the outer IP header and the inner 145 IP header may not be of the same address family, in other words, 146 outer IPv6 header accompanied with inner IPv4 header and outer IPv4 147 header accompanied with inner IPv6 header are both possible. 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | | 153 ~ Outer Ethernet Header ~ 154 | | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | | 157 ~ Outer IPvX Header ~ 158 | | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | | 161 ~ Outer UDP Header ~ 162 | | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | | 165 ~ Geneve Header ~ 166 | | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | | 169 ~ Inner Ethernet Header ~ 170 | | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | | 173 ~ Inner IPvX Header ~ 174 | | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | | 177 ~ Inner UDP Header ~ 178 | | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | | 181 ~ BFD Control Packet ~ 182 | | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Outer Ethernet FCS | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Figure 1: Geneve Encapsulation of BFD Control Packet With the Inner 188 Ethernet/IP/UDP Header 190 The BFD packet MUST be carried inside the inner Ethernet frame of the 191 Geneve packet. The inner Ethernet frame carrying the BFD Control 192 packet has the following format: 194 Ethernet Header: 196 Source MAC: MAC address of a VAP of the originating NVE. 198 Destination MAC: MAC address of a VAP of the terminating NVE. 200 IP Header: 202 Source IP: IP address of a VAP of the originating NVE. If the 203 VAP of the originating NVE has no IP address, then the IP 204 address of the originating NVE is used. 206 Destination IP: IP address of a VAP of the terminating NVE. If 207 the VAP of the terminating NVE has no IP address, then the IP 208 address MUST be chosen from the 127/8 range for IPv4, and from 209 the ::ffff:127.0.0.0/104 range for IPv6. 211 TTL or Hop Limit: MUST be set to 255 in accordance with 212 [RFC5881]. 214 The fields of the UDP header and the BFD Control packet are 215 encoded as specified in [RFC5881]. 217 When the BFD packets are encapsulated in Geneve in this way, the 218 Geneve header defined in [I-D.ietf-nvo3-geneve] follows the value set 219 below. 221 Opt Len field SHOULD be set to 0, which indicates there isn't any 222 variable length option. 224 O bit MUST be set to 1, which indicates this packet contains a 225 control message. 227 C bit MUST be set to 0, which indicates there isn't any critical 228 option. 230 Protocol Type field MUST be set to 0x6558 (Ethernet frame). 232 Virtual Network Identifier (VNI) field SHOULD be set to the VNI 233 number that the originating VAP is mapped to. 235 3.2. BFD Encapsulation With Inner IP/UDP Header 237 If the VAP that originates the BFD packets is used to encapsulate IP 238 data packets, then BFD packets are encapsulated in Geneve as 239 described below. The Geneve packet format over IPv4 is defined in 240 Section 3.1 of [I-D.ietf-nvo3-geneve]. The Geneve packet format over 241 IPv6 is defined in Section 3.2 of [I-D.ietf-nvo3-geneve]. The Outer 242 IP/UDP and Geneve headers MUST be encoded by the sender as defined in 243 [I-D.ietf-nvo3-geneve]. Note that the outer IP header and the inner 244 IP header may not be of the same address family, in other words, 245 outer IPv6 header accompanied with inner IPv4 header and outer IPv4 246 header accompanied with inner IPv6 header are both possible. 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | | 252 ~ Ethernet Header ~ 253 | | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | | 256 ~ Outer IPvX Header ~ 257 | | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | | 260 ~ Outer UDP Header ~ 261 | | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | | 264 ~ Geneve Header ~ 265 | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | | 268 ~ Inner IPvX Header ~ 269 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | | 272 ~ Inner UDP Header ~ 273 | | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | | 276 ~ BFD Control Packet ~ 277 | | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | FCS | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Figure 2: Geneve Encapsulation of BFD Control Packet With the Inner 283 IP/UDP Header 285 The BFD packet MUST be carried inside the inner IP packet of the 286 Geneve packet. The inner IP packet carrying the BFD Control packet 287 has the following format: 289 IP header: 291 Source IP: IP address of a VAP of the originating NVE. 293 Destination IP: IP address of a VAP of the terminating NVE. 295 TTL or Hop Limit: MUST be set to 255 in accordance with 296 [RFC5881]. 298 The fields of the UDP header and the BFD Control packet are 299 encoded as specified in [RFC5881]. 301 When the BFD packets are encapsulated in Geneve in this way, the 302 Geneve header defined in [I-D.ietf-nvo3-geneve] follows the value set 303 below. 305 Opt Len field SHOULD be set to 0, which indicates there isn't any 306 variable length option. 308 O bit MUST be set to 1, which indicates this packet contains a 309 control message. 311 C bit MUST be set to 0, which indicates there isn't any critical 312 option. 314 Protocol Type field MUST be set to 0x0800 (IPv4) or 0x86DD (IPv6), 315 depending on the address family of the inner IP packet. 317 Virtual Network Identifier (VNI) field SHOULD be set to the VNI 318 number that the originating VAP is mapped to. 320 4. Reception of BFD packet from Geneve Tunnel 322 Once a packet is received, the NVE MUST validate the packet as 323 described in [I-D.ietf-nvo3-geneve]. 325 If the Protocol Type field equals 0x6558 (Ethernet frame), and the 326 Destination MAC of the inner Ethernet frame matches the MAC 327 address of a VAP which is mapped to the same as received VNI, then 328 the Destination IP, the UDP destination port and the TTL or Hop 329 Limit of the inner IP packet MUST be validated to determine 330 whether the received packet can be processed by BFD. 332 If the Protocol Type field equals 0x0800 (IPv4) or 0x86DD (IPv6), 333 and the Destination IP of the inner IP packet matches the IP 334 address of a VAP which is mapped to the same as received VNI, then 335 the UDP destination port and the TTL or Hop Limit of the inner IP 336 packet MUST be validated to determine whether the received packet 337 can be processed by BFD. 339 4.1. Demultiplexing of the BFD packet 341 In BFD over Geneve, a BFD session is originated and terminated at 342 VAP, usually one NVE owns multiple VAPs, so multiple BFD sessions may 343 be running between two NVEs, there needs to be a mechanism for 344 demultiplexing received BFD packets to the proper session. 345 Furthermore, due to the fact that [RFC8014] allows for N-to-1 mapping 346 between VAP and VNI at one NVE, multiple BFD sessions between two 347 NVEs for the same VNI are allowed. Also note that a BFD session can 348 only be established between two VAPs that are mapped to the same VNI 349 and use the same way to encapsulate data packets. 351 If the BFD packet is received with Your Discriminator equals to 0, 352 for different BFD encapsulation, the procedure for demultiplexing the 353 received BFD packets is different. 355 When the BFD Encapsulation With Inner Ethernet/IP/UDP Header is 356 used, the BFD session MUST be identified using the VNI number, and 357 the inner Ethernet/IP/UDP Header, i.e., the source MAC, the source 358 IP, the destination MAC, the destination IP, and the source UDP 359 port number present in the inner Ethernet/IP/UDP header. 361 When the BFD Encapsulation With Inner IP/UDP Header is used, the 362 BFD session MUST be identified using the VNI number, and the inner 363 IP/UDP header, i.e., the source IP, the destination IP, and the 364 source UDP port number present in the inner IP/UDP header. 366 If the BFD packet is received with non-zero Your Discriminator, then 367 the BFD session MUST be demultiplexed only with Your Discriminator as 368 the key. 370 5. Security Considerations 372 This document does not raise any additional security issues beyond 373 those of the specifications referred to in the list of references. 375 6. IANA Considerations 377 This document has no IANA action requested. 379 7. Acknowledgements 381 The authors would like to acknowledge Reshad Rahman, Jeffrey Haas and 382 Matthew Bocci for their guidance on this work. 384 The authors would like to acknowledge David Black for his explanation 385 on the mapping relation between VAP and VNI. 387 8. References 389 8.1. Normative References 391 [I-D.ietf-nvo3-geneve] 392 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 393 Network Virtualization Encapsulation", draft-ietf- 394 nvo3-geneve-16 (work in progress), March 2020. 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 [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 411 Rekhter, "Framework for Data Center (DC) Network 412 Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 413 2014, . 415 [RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 416 Narten, "An Architecture for Data-Center Network 417 Virtualization over Layer 3 (NVO3)", RFC 8014, 418 DOI 10.17487/RFC8014, December 2016, 419 . 421 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 422 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 423 May 2017, . 425 8.2. Informative References 427 [I-D.ietf-bfd-vxlan] 428 Pallagatti, S., Mirsky, G., Paragiri, S., Govindan, V., 429 and M. Mudigonda, "BFD for VXLAN", draft-ietf-bfd-vxlan-16 430 (work in progress), October 2020. 432 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 433 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 434 eXtensible Local Area Network (VXLAN): A Framework for 435 Overlaying Virtualized Layer 2 Networks over Layer 3 436 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 437 . 439 Authors' Addresses 441 Xiao Min 442 ZTE Corp. 443 Nanjing 444 China 446 Phone: +86 25 88013062 447 Email: xiao.min2@zte.com.cn 449 Greg Mirsky 450 ZTE Corp. 451 USA 453 Email: gregimirsky@gmail.com 455 Santosh Pallagatti 456 VMware 458 Email: santosh.pallagatti@gmail.com 460 Jeff Tantsura 461 Apstra 463 Email: jefftant.ietf@gmail.com