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