idnits 2.17.1 draft-ietf-bfd-vxlan-07.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 (May 17, 2019) is 1805 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 7348 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BFD S. Pallagatti, Ed. 3 Internet-Draft Rtbrick 4 Intended status: Standards Track S. Paragiri 5 Expires: November 18, 2019 Individual Contributor 6 V. Govindan 7 M. Mudigonda 8 Cisco 9 G. Mirsky 10 ZTE Corp. 11 May 17, 2019 13 BFD for VXLAN 14 draft-ietf-bfd-vxlan-07 16 Abstract 18 This document describes the use of the Bidirectional Forwarding 19 Detection (BFD) protocol in point-to-point Virtual eXtensible Local 20 Area Network (VXLAN) tunnels forming up an overlay network. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 18, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions used in this document . . . . . . . . . . . . . . 3 58 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. BFD Packet Transmission over VXLAN Tunnel . . . . . . . . . . 5 62 4.1. BFD Packet Encapsulation in VXLAN . . . . . . . . . . . . 6 63 5. Reception of BFD Packet from VXLAN Tunnel . . . . . . . . . . 7 64 5.1. Demultiplexing of the BFD Packet . . . . . . . . . . . . 7 65 6. Use of the Specific VNI . . . . . . . . . . . . . . . . . . . 8 66 7. Echo BFD . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 70 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 71 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 73 12.2. Informational References . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 "Virtual eXtensible Local Area Network" (VXLAN) [RFC7348] provides an 79 encapsulation scheme that allows building an overlay network by 80 decoupling the address space of the attached virtual hosts from that 81 of the network. 83 One use of VXLAN is in data centers interconnecting virtual machines 84 (VMs) of a tenant. VXLAN addresses requirements of the Layer 2 and 85 Layer 3 data center network infrastructure in the presence of VMs in 86 a multi-tenant environment by providing a Layer 2 overlay scheme on a 87 Layer 3 network [RFC7348]. Another use is as an encapsulation for 88 Ethernet VPN [RFC8365]. 90 This document is written assuming the use of VXLAN for virtualized 91 hosts and refers to VMs and VXLAN Tunnel End Points (VTEPs) in 92 hypervisors. However, the concepts are equally applicable to non- 93 virtualized hosts attached to VTEPs in switches. 95 In the absence of a router in the overlay, a VM can communicate with 96 another VM only if they are on the same VXLAN segment. VMs are 97 unaware of VXLAN tunnels as a VXLAN tunnel is terminated on a VTEP. 98 VTEPs are responsible for encapsulating and decapsulating frames 99 exchanged among VMs. 101 Ability to monitor path continuity, i.e., perform proactive 102 continuity check (CC) for point-to-point (p2p) VXLAN tunnels, is 103 important. The asynchronous mode of BFD, as defined in [RFC5880], 104 can be used to monitor a p2p VXLAN tunnel. 106 In the case where a Multicast Service Node (MSN) (as described in 107 Section 3.3 of [RFC8293]) resides behind an NVE, the mechanisms 108 described in this document apply and can, therefore, be used to test 109 the connectivity from the source NVE to the MSN. 111 This document describes the use of Bidirectional Forwarding Detection 112 (BFD) protocol to enable monitoring continuity of the path between 113 VXLAN VTEPs, performing as Network Virtualization Endpoints, and/or 114 availability of a replicator multicast service node. 116 2. Conventions used in this document 118 2.1. Terminology 120 BFD Bidirectional Forwarding Detection 122 CC Continuity Check 124 p2p Point-to-point 126 MSN Multicast Service Node 128 VFI Virtual Forwarding Instance 130 VM Virtual Machine 132 VTEP VXLAN Tunnel End Point 134 VXLAN Virtual eXtensible Local Area Network 136 2.2. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in BCP 141 14 [RFC2119] [RFC8174] when, and only when, they appear in all 142 capitals, as shown here. 144 3. Deployment 146 Figure 1 illustrates the scenario with two servers, each of them 147 hosting two VMs. The servers host VTEPs that terminate two VXLAN 148 tunnels with VNI number 100 and 200 respectively. Separate BFD 149 sessions can be established between the VTEPs (IP1 and IP2) for 150 monitoring each of the VXLAN tunnels (VNI 100 and 200). An 151 implementation that supports this specification MUST be able to 152 control the number of BFD sessions that can be created between the 153 same pair of VTEPs. BFD packets intended for a Hypervisor VTEP MUST 154 NOT be forwarded to a VM as a VM may drop BFD packets leading to a 155 false negative. This method is applicable whether the VTEP is a 156 virtual or physical device. 158 +------------+-------------+ 159 | Server 1 | 160 | | 161 | +----+----+ +----+----+ | 162 | |VM1-1 | |VM1-2 | | 163 | |VNI 100 | |VNI 200 | | 164 | | | | | | 165 | +---------+ +---------+ | 166 | Hypervisor VTEP (IP1) | 167 +--------------------------+ 168 | 169 | 170 | 171 | +-------------+ 172 | | Layer 3 | 173 |---| Network | 174 | | 175 +-------------+ 176 | 177 | 178 +-----------+ 179 | 180 | 181 +------------+-------------+ 182 | Hypervisor VTEP (IP2) | 183 | +----+----+ +----+----+ | 184 | |VM2-1 | |VM2-2 | | 185 | |VNI 100 | |VNI 200 | | 186 | | | | | | 187 | +---------+ +---------+ | 188 | Server 2 | 189 +--------------------------+ 191 Figure 1: Reference VXLAN Domain 193 4. BFD Packet Transmission over VXLAN Tunnel 195 BFD packet MUST be encapsulated and sent to a remote VTEP as 196 explained in Section 4.1. Implementations SHOULD ensure that the BFD 197 packets follow the same lookup path as VXLAN data packets within the 198 sender system. 200 4.1. BFD Packet Encapsulation in VXLAN 202 BFD packets are encapsulated in VXLAN as described below. The VXLAN 203 packet format is defined in Section 5 of [RFC7348]. The Outer IP/UDP 204 and VXLAN headers MUST be encoded by the sender as defined in 205 [RFC7348]. 207 0 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | | 211 ~ Outer Ethernet Header ~ 212 | | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | | 215 ~ Outer IPvX Header ~ 216 | | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | | 219 ~ Outer UDP Header ~ 220 | | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | | 223 ~ VXLAN Header ~ 224 | | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | | 227 ~ Inner Ethernet Header ~ 228 | | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | | 231 ~ Inner IPvX Header ~ 232 | | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | | 235 ~ Inner UDP Header ~ 236 | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | | 239 ~ BFD Control Message ~ 240 | | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | FCS | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 2: VXLAN Encapsulation of BFD Control Message 247 The BFD packet MUST be carried inside the inner MAC frame of the 248 VXLAN packet. The inner MAC frame carrying the BFD payload has the 249 following format: 251 Ethernet Header: 253 Destination MAC: This MUST be the dedicated MAC TBA (Section 8) 254 or the MAC address of the destination VTEP. The details of how 255 the MAC address of the destination VTEP is obtained are outside 256 the scope of this document. 258 Source MAC: MAC address of the originating VTEP 260 IP header: 262 Source IP: IP address of the originating VTEP. 264 Destination IP: IP address of the terminating VTEP. 266 TTL: MUST be set to 1 to ensure that the BFD packet is not 267 routed within the L3 underlay network. 269 The fields of the UDP header and the BFD control packet are 270 encoded as specified in [RFC5881]. 272 5. Reception of BFD Packet from VXLAN Tunnel 274 Once a packet is received, VTEP MUST validate the packet. If the 275 Destination MAC of the inner MAC frame matches the dedicated MAC or 276 the MAC address of the VTEP the packet MUST be processed further. 278 The UDP destination port and the TTL of the inner IP packet MUST be 279 validated to determine if the received packet can be processed by 280 BFD. BFD packet with inner MAC set to VTEP or dedicated MAC address 281 MUST NOT be forwarded to VMs. 283 5.1. Demultiplexing of the BFD Packet 285 Demultiplexing of IP BFD packet has been defined in Section 3 of 286 [RFC5881]. Since multiple BFD sessions may be running between two 287 VTEPs, there needs to be a mechanism for demultiplexing received BFD 288 packets to the proper session. The procedure for demultiplexing 289 packets with Your Discriminator equal to 0 is different from 290 [RFC5880]. For such packets, the BFD session MUST be identified 291 using the inner headers, i.e., the source IP, the destination IP, and 292 the source UDP port number present in the IP header carried by the 293 payload of the VXLAN encapsulated packet. The VNI of the packet 294 SHOULD be used to derive interface-related information for 295 demultiplexing the packet. If BFD packet is received with non-zero 296 Your Discriminator, then BFD session MUST be demultiplexed only with 297 Your Discriminator as the key. 299 6. Use of the Specific VNI 301 In most cases, a single BFD session is sufficient for the given VTEP 302 to monitor the reachability of a remote VTEP, regardless of the 303 number of VNIs in common. When the single BFD session is used to 304 monitor the reachability of the remote VTEP, an implementation SHOULD 305 choose any of the VNIs but MAY choose VNI = 0. 307 7. Echo BFD 309 Support for echo BFD is outside the scope of this document. 311 8. IANA Considerations 313 IANA has assigned TBA as a dedicated MAC address from the IANA 48-bit 314 unicast MAC address registry to be used as the Destination MAC 315 address of the inner Ethernet of VXLAN when carrying BFD control 316 packets. 318 9. Security Considerations 320 The document requires setting the inner IP TTL to 1, which could be 321 used as a DDoS attack vector. Thus the implementation MUST have 322 throttling in place to control the rate of BFD control packets sent 323 to the control plane. Throttling MAY be relaxed for BFD packets 324 based on port number. 326 The implementation SHOULD have a reasonable upper bound on the number 327 of BFD sessions that can be created between the same pair of VTEPs. 329 Other than inner IP TTL set to 1 and limit the number of BFD sessions 330 between the same pair of VTEPs, this specification does not raise any 331 additional security issues beyond those of the specifications 332 referred to in the list of normative references. 334 10. Contributors 336 Reshad Rahman 337 rrahman@cisco.com 338 Cisco 340 11. Acknowledgments 342 Authors would like to thank Jeff Haas of Juniper Networks for his 343 reviews and feedback on this material. 345 Authors would also like to thank Nobo Akiya, Marc Binderberger, 346 Shahram Davari, Donald E. Eastlake 3rd, and Anoop Ghanwani for the 347 extensive reviews and the most detailed and helpful comments. 349 12. References 351 12.1. Normative References 353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 354 Requirement Levels", BCP 14, RFC 2119, 355 DOI 10.17487/RFC2119, March 1997, 356 . 358 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 359 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 360 . 362 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 363 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 364 DOI 10.17487/RFC5881, June 2010, 365 . 367 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 368 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 369 eXtensible Local Area Network (VXLAN): A Framework for 370 Overlaying Virtualized Layer 2 Networks over Layer 3 371 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 372 . 374 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 375 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 376 May 2017, . 378 12.2. Informational References 380 [RFC8293] Ghanwani, A., Dunbar, L., McBride, M., Bannai, V., and R. 381 Krishnan, "A Framework for Multicast in Network 382 Virtualization over Layer 3", RFC 8293, 383 DOI 10.17487/RFC8293, January 2018, 384 . 386 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 387 Uttaro, J., and W. Henderickx, "A Network Virtualization 388 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 389 DOI 10.17487/RFC8365, March 2018, 390 . 392 Authors' Addresses 394 Santosh Pallagatti (editor) 395 Rtbrick 397 Email: santosh.pallagatti@gmail.com 399 Sudarsan Paragiri 400 Individual Contributor 402 Email: sudarsan.225@gmail.com 404 Vengada Prasad Govindan 405 Cisco 407 Email: venggovi@cisco.com 409 Mallik Mudigonda 410 Cisco 412 Email: mmudigon@cisco.com 414 Greg Mirsky 415 ZTE Corp. 417 Email: gregimirsky@gmail.com