idnits 2.17.1 draft-xiao-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 23, 2018) is 1978 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ETYPES' == Outdated reference: A later version (-16) exists of draft-ietf-bfd-vxlan-03 ** Downref: Normative reference to an Informational draft: draft-ietf-bfd-vxlan (ref. 'I-D.ietf-bfd-vxlan') == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-08 ** Downref: Normative reference to an Informational RFC: RFC 7348 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BFD Working Group X. Min 3 Internet-Draft G. Mirsky 4 Intended status: Standards Track ZTE 5 Expires: May 27, 2019 November 23, 2018 7 BFD for Geneve 8 draft-xiao-bfd-geneve-00 10 Abstract 12 This document describes the use of the Bidirectional Forwarding 13 Detection (BFD) protocol in Generic Network Virtualization 14 Encapsulation (Geneve) overlay networks. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 27, 2019. 33 Copyright Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Conventions Used in This Document . . . . . . . . . . . . 2 52 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 2 53 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 54 2. BFD Packet Transmission over Geneve Tunnel . . . . . . . . . 3 55 2.1. BFD Packet Encapsulation in Geneve . . . . . . . . . . . 3 56 2.1.1. BFD Encapsulation With IP/UDP Header . . . . . . . . 3 57 2.1.2. BFD Encapsulation Without IP/UDP Header . . . . . . . 5 58 3. Reception of BFD packet from Geneve Tunnel . . . . . . . . . 7 59 3.1. Demultiplexing of the BFD packet . . . . . . . . . . . . 8 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 63 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 66 1. Introduction 68 "Generic Network Virtualization Encapsulation" (Geneve) 69 [I-D.ietf-nvo3-geneve] provides a generic tunneling protocol that is 70 applicable to many scenarios, including an encapsulation scheme that 71 allows virtual machines (VMs) to communicate in a data center 72 network. 74 This document describes the use of Bidirectional Forwarding Detection 75 (BFD) protocol for Geneve to enable monitoring continuity of the path 76 between Network Virtualization Edges (NVEs) and/or availability of a 77 replicator service node using BFD. 79 The use cases and the deployment of BFD for Geneve are consistent 80 with what's described in Section 3 and Section 4 of 81 [I-D.ietf-bfd-vxlan]. The main difference between Geneve and 82 "Virtual eXtensible Local Area Network" (VXLAN) [RFC7348] 83 encapsulation is that Geneve supports multi-protocol payload and 84 variable length options. 86 1.1. Conventions Used in This Document 88 1.1.1. Terminology 90 BFD: Bidirectional Forwarding Detection 92 Geneve: Generic Network Virtualization Encapsulation 94 NVE: Network Virtualization Edge 95 VFI: Virtual Forwarding Instance 97 VM: Virtual Machine 99 VNI: Virtual Network Identifier 101 VXLAN: Virtual eXtensible Local Area Network 103 1.1.2. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in BCP 108 14 [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 2. BFD Packet Transmission over Geneve Tunnel 113 BFD packet MUST be encapsulated and sent to a remote NVE using one of 114 the options described in Section 2.1. Implementations SHOULD ensure 115 that the BFD packets follow the same lookup path as Geneve data 116 packets within the sender system. 118 2.1. BFD Packet Encapsulation in Geneve 120 Concerning whether or not the Geneve data packets include an IP 121 protocol data unit, this document defines three options of BFD packet 122 encapsulation in Geneve. 124 2.1.1. BFD Encapsulation With IP/UDP Header 126 If the Protocol Type field (as defined in Section 3.4 of 127 [I-D.ietf-nvo3-geneve]) of data packets indicates that there exists 128 an inner IP header, i.e., the Protocol Type equals to 0x6558 129 (Ethernet frame), or 0x0800 (IPv4), or 0x86DD (IPv6), or 0x8847 130 (MPLS), or 0x8848 (MPLS with the upstream-assigned label), then BFD 131 packets are encapsulated in Geneve as described below. The Geneve 132 packet format over IPv4 is defined in Section 3.1 of 133 [I-D.ietf-nvo3-geneve]. The Geneve packet format over IPv6 is 134 defined in Section 3.2 of [I-D.ietf-nvo3-geneve]. The Outer IP/UDP 135 and Geneve headers MUST be encoded by the sender as defined in 136 [I-D.ietf-nvo3-geneve]. Note that the outer IP header and the inner 137 IP header may not be of the same address family, in other words, 138 outer IPv6 header accompanied with inner IPv4 header and outer IPv4 139 header accompanied with inner IPv6 header are both possible. 141 0 1 2 3 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | | 145 ~ Outer Ethernet Header ~ 146 | | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | | 149 ~ Outer IPvX Header ~ 150 | | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | | 153 ~ Outer UDP Header ~ 154 | | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | | 157 ~ Geneve Header ~ 158 | | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | | 161 ~ Inner IPvX Header ~ 162 | | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | | 165 ~ Inner UDP Header ~ 166 | | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | | 169 ~ BFD Control Message ~ 170 | | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | FCS | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Figure 1: Geneve Encapsulation of BFD Control Message With the Inner 176 IP/UDP Header 178 When the BFD packets are encapsulated in Geneve in this way, the BFD 179 packet MUST be carried inside the inner IP packet of the Geneve 180 packet. The inner IP packet carrying the BFD payload has the 181 following format: 183 IP header: 185 Source IP: IP address of the originating NVE. 187 Destination IP: IP address of the terminating NVE. 189 TTL: MUST be set to 1 to ensure that the BFD packet is not 190 routed within the L3 underlay network. 192 The fields of the UDP header and the BFD control packet are 193 encoded as specified in [RFC5881]. 195 When the BFD packets are encapsulated in Geneve in this way, the 196 Geneve header SHOULD follow the value set below. 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 |Ver| Opt Len |O|C| Rsvd. | Protocol Type | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Virtual Network Identifier (VNI) | Reserved | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Variable Length Options | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Figure 2: Geneve Header 210 Opt Len field SHOULD be set to 0, which indicates there isn't any 211 variable length option. 213 [Ed.Note]: Use of O bit is still being discussed in the NVO3 WG, so 214 the value is undetermined. 216 C bit SHOULD be set to 0. 218 Protocol Type field SHOULD be set to 0x0800 (IPv4) or 0x86DD (IPv6). 220 2.1.2. BFD Encapsulation Without IP/UDP Header 222 Alternatively to the use of the inner IP/UDP header to demultiplex 223 BFD control packet by the value of the destination UDP port, BFD 224 control packet MAY be encapsulated without the inner IP/UDP header. 225 The BFD control packet MAY be identified directly in the Geneve 226 header or through Geneve OAM shim. In either case, the Outer IP/UDP 227 and Geneve headers MUST be encoded by the sender as defined in 228 [I-D.ietf-nvo3-geneve]. 230 Figure 3 displays the layout of the Ethernet frame with BFD control 231 packet encapsulated in Geneve without the use of IP/UDP header and 232 identified by the value TBA1 (to be assigned by IANA) of the Protocol 233 Type field. 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | | 239 ~ Outer Ethernet Header ~ 240 | | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | | 243 ~ Outer IPvX Header ~ 244 | | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | | 247 ~ Outer UDP Header ~ 248 | | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | | 251 ~ Geneve Header ~ 252 | | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | | 255 ~ BFD Control Message ~ 256 | | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | FCS | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Figure 3: Geneve Encapsulation of BFD Control Message Without the 262 Inner IP/UDP Header 264 When the BFD packets are encapsulated in Geneve in this way, the BFD 265 packet MUST immediately follow the Geneve header, and the Geneve 266 header SHOULD follow the value set below. 268 Opt Len field SHOULD be set to 0, which indicates there isn't any 269 variable length option. 271 [Ed.Note]: Use of O bit is still being discussed in the NVO3 WG, so 272 the value is undetermined. 274 C bit SHOULD be set to 0. 276 Also, if BFD control packet is encapsulated in Geneve without the use 277 of IP/UDP header, the BFD control packet MAY be identified through 278 the Geneve OAM shim. The layout of the Ethernet frame is shown in 279 Figure 4. Protocol Type field MUST be set to the value TBA2 (to be 280 assigned by IANA) which indicates a Geneve OAM shim that will have a 281 field to indicate the inner BFD control packet. Definition of the 282 format of the Geneve OAM shim is outside the scope of this document. 283 The Geneve OAM shim immediately follows the Geneve header, and the 284 BFD control packet immediately follows the Geneve OAM shim. 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | | 290 ~ Outer Ethernet Header ~ 291 | | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | | 294 ~ Outer IPvX Header ~ 295 | | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | 298 ~ Outer UDP Header ~ 299 | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | | 302 ~ Geneve Header ~ 303 | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Geneve OAM Shim | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | | 308 ~ BFD Control Message ~ 309 | | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | FCS | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Figure 4: Geneve Encapsulation of BFD Control Message With Geneve OAM 315 Shim 317 3. Reception of BFD packet from Geneve Tunnel 319 Once a packet is received, NVE MUST validate the packet as described 320 in [I-D.ietf-nvo3-geneve]. 322 If the Protocol Type field equals 0x0800 (IPv4) or 0x86DD (IPv6), and 323 the Destination IP of the inner IP packet matches the IP address of 324 the NVE, the UDP destination port and the TTL of the inner IP packet 325 MUST be validated to determine whether BFD can process the received 326 packet. BFD packet with inner IP set to NVE MUST NOT be forwarded to 327 VMs. 329 If the Protocol Type field equals the value TBA1 (to be assigned by 330 IANA) which indicates an inner BFD control message, the received 331 packet MUST be processed by BFD and MUST NOT be forwarded to VMs. 333 If the Protocol Type field equals the value TBA2 (to be assigned by 334 IANA) which indicates a Geneve OAM shim that will have a field to 335 indicate the inner BFD control message, the received packet MUST be 336 processed by BFD and MUST NOT be forwarded to VMs. This case is for 337 further study. 339 To ensure BFD detects the proper configuration of Virtual Network 340 Identifier (VNI) in a remote NVE, a lookup SHOULD be performed with 341 the MAC-DA/IP-DA/MPLS-Label and VNI as key in the Virtual Forwarding 342 Instance (VFI) table of the originating/terminating NVE to exercise 343 the VFI associated with the VNI. 345 3.1. Demultiplexing of the BFD packet 347 If the Protocol Type field equals 0x0800 (IPv4) or 0x86DD (IPv6), 348 demultiplexing of IP BFD packet has been defined in Section 3 of 349 [RFC5881]. Since multiple BFD sessions may be running between two 350 NVEs, there needs to be a mechanism for demultiplexing received BFD 351 packets to the proper session. The procedure for demultiplexing 352 packets with Your Discriminator equal to 0 is different from 353 [RFC5880]. For such packets, the BFD session MUST be identified 354 using the inner headers, i.e., the source IP and the destination IP 355 present in the IP header carried by the payload of the Geneve 356 encapsulated packet. The VNI of the packet SHOULD be used to derive 357 interface-related information for demultiplexing the packet. If BFD 358 packet is received with non-zero Your Discriminator, then BFD session 359 MUST be demultiplexed only with Your Discriminator as the key. 361 If the Protocol Type field equals the value TBA1 (to be assigned by 362 IANA) which indicates an inner BFD control message, or the value TBA2 363 (to be assigned by IANA) which indicates a Geneve OAM shim that will 364 have a field to indicate the inner BFD control message, the VNI of 365 the packet SHOULD be used to derive interface-related information for 366 demultiplexing the packet, demultiplexing of BFD packet MUST rely on 367 non-zero Your Discriminator as the key. 369 4. Security Considerations 371 This document does not raise any additional security issues beyond 372 those of the specifications referred to in the list of normative 373 references. 375 5. IANA Considerations 377 In the Geneve Protocol Type registry defined in [ETYPES], a new BFD 378 Control Message or Geneve OAM Shim is requested from IANA as follows: 380 +----------------+-----------------+------------------+-------------+ 381 | Geneve | Description | Semantics | Reference | 382 | Protocol Type | | Definition | | 383 +----------------+-----------------+------------------+-------------+ 384 | TBA1 | BFD Control | Section 3.1 | This | 385 | | Message | | Document | 386 | TBA2 | Geneve OAM Shim | Section 3.1 | This | 387 | | | | Document | 388 +----------------+-----------------+------------------+-------------+ 390 Table 1: New BFD Control Message or Geneve OAM shim Ethertype 392 6. Acknowledgements 394 To be added. 396 7. Normative References 398 [ETYPES] The IEEE Registration Authority, "IEEE 802 Numbers", 2013, 399 . 402 [I-D.ietf-bfd-vxlan] 403 Networks, J., Paragiri, S., Govindan, V., Mudigonda, M., 404 and G. Mirsky, "BFD for VXLAN", draft-ietf-bfd-vxlan-03 405 (work in progress), October 2018. 407 [I-D.ietf-nvo3-geneve] 408 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 409 Network Virtualization Encapsulation", draft-ietf- 410 nvo3-geneve-08 (work in progress), October 2018. 412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 413 Requirement Levels", BCP 14, RFC 2119, 414 DOI 10.17487/RFC2119, March 1997, 415 . 417 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 418 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 419 . 421 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 422 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 423 DOI 10.17487/RFC5881, June 2010, 424 . 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 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 434 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 435 May 2017, . 437 Authors' Addresses 439 Xiao Min 440 ZTE 441 Nanjing 442 China 444 Phone: +86 25 88016574 445 Email: xiao.min2@zte.com.cn 447 Greg Mirsky 448 ZTE 449 USA 451 Email: gregimirsky@gmail.com