idnits 2.17.1 draft-spallagatti-bfd-vxlan-05.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 (April 19, 2017) is 2565 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 draft: draft-ashwood-nvo3-operational-requirement (ref. 'I-D.ashwood-nvo3-operational-requirement') == Outdated reference: A later version (-19) exists of draft-ietf-bfd-multipoint-09 ** Downref: Normative reference to an Informational RFC: RFC 7348 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Pallagatti, Ed. 3 Internet-Draft Independent Contributor 4 Intended status: Standards Track S. Paragiri 5 Expires: October 21, 2017 Juniper Networks 6 V. Govindan 7 M. Mudigonda 8 Cisco 9 G. Mirsky 10 ZTE Corp. 11 April 19, 2017 13 BFD for VXLAN 14 draft-spallagatti-bfd-vxlan-05 16 Abstract 18 This document describes use of Bidirectional Forwarding Detection 19 (BFD) protocol in Virtual eXtensible Local Area Network (VXLAN) 20 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 http://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 October 21, 2017. 39 Copyright Notice 41 Copyright (c) 2017 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 (http://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. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. BFD Packet Transmission over VXLAN Tunnel . . . . . . . . . . 6 63 5.1. BFD Packet Encapsulation in VXLAN . . . . . . . . . . . . 6 64 6. Reception of BFD packet from VXLAN Tunnel . . . . . . . . . . 6 65 6.1. Demultiplexing of the BFD packet . . . . . . . . . . . . 7 66 7. Use of reserved VNI . . . . . . . . . . . . . . . . . . . . . 7 67 8. Echo BFD . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 71 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 72 13. Normative References . . . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 "Virtual eXtensible Local Area Network (VXLAN)" has been described in 78 [RFC7348]. VXLAN provides an encapsulation scheme that allows 79 virtual machines (VMs) to communicate in a data center network. 81 VXLAN is typically deployed in data centers interconnecting 82 virtualized hosts, which may be spread across multiple racks. The 83 individual racks may be part of a different Layer 3 network or they 84 could be in a single Layer 2 network. The VXLAN segments/overlay 85 networks are overlaid on top of these Layer 2 or Layer 3 networks. 87 A VM can communicate with another VM only if they are on the same 88 VXLAN. VMs are unaware of VXLAN tunnels as VXLAN tunnel is 89 terminated on VXLAN Tunnel End Point (VTEP) (hypervisor/TOR). VTEPs 90 (hypervisor/TOR) are responsible for encapsulating and decapsulating 91 frames exchanged among VMs. 93 Since underlay is a L3 network, ability to monitor path continuity, 94 i.e. perform proactive continuity check (CC) for these tunnels is 95 important. Asynchronous mode of BFD, as defined in [RFC5880], can be 96 used to monitor a VXLAN tunnel. Use of [I-D.ietf-bfd-multipoint] is 97 for future study. 99 This draft addresses requirements outlined in 100 [I-D.ashwood-nvo3-operational-requirement]. Specifically with 101 reference to the OAM model to Figure 3 of 102 [I-D.ashwood-nvo3-operational-requirement], this draft outlines 103 proposal to implement the OAM mechanism between the Network 104 Virtualization Edges (NVEs) using BFD. 106 2. Conventions used in this document 108 2.1. Terminology 110 BFD - Bidirectional Forwarding Detection 112 CC - Continuity Check 114 NVE - Network Virtualization Edge 116 TOR - Top of Rack 118 VM - Virtual Machine 120 VTEP - VXLAN Tunnel End Point 122 VXLAN - Virtual eXtensible Local Area Network 124 2.2. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 3. Use cases 132 Main use case of BFD for VXLAN is for continuity check of a tunnel. 133 By exchanging BFD control packets between VTEPs an operator exercises 134 the VXLAN path in both in underlay and overlay thus ensuring the 135 VXLAN path availability and VTEPs reachability. BFD failure 136 detection can be used for maintenance. There are other use cases 137 such as 139 Layer 2 VMs: 141 Most deployments will have VMs with only L2 capabilities that 142 may not support L3. BFD being a L3 protocol can be used as 143 tunnel CC mechanism, where BFD will start and terminate at the 144 NVEs, e.g. VTEPs. 146 It is possible to aggregate the CC sessions for multiple 147 tenants by running a BFD session between the VTEPs over VxLAN 148 tunnel. In rest of this document terms NVE and VTEP are used 149 interchangeably. 151 Fault localization: 153 It is also possible that VMs are L3 aware and can possibly host 154 a BFD session. In these cases BFD sessions can be established 155 among VMs for CC. In addition, BFD sessions can be established 156 among VTEPs for tunnel CC. Having a hierarchical OAM model 157 helps localize faults though requires additional consideration. 159 Service node reachability: 161 Service node is responsible for sending BUM traffic. In case 162 of service node tunnel terminates at VTEP and it might not even 163 host VM. BFD session between TOR/hypervisor and service node 164 can be used to monitor service node reachability. 166 4. Deployment 167 +------------+-------------+ 168 | Server 1 | 169 | | 170 | +----+----+ +----+----+ | 171 | |VM1-1 | |VM1-2 | | 172 | |VNI 100 | |VNI 200 | | 173 | | | | | | 174 | +---------+ +---------+ | 175 | Hypervisor VTEP (IP1) | 176 +--------------------------+ 177 | 178 | 179 | 180 | +-------------+ 181 | | Layer 3 | 182 |---| Network | 183 | | 184 +-------------+ 185 | 186 | 187 +-----------+ 188 | 189 | 190 +------------+-------------+ 191 | Hypervisor VTEP (IP2) | 192 | +----+----+ +----+----+ | 193 | |VM2-1 | |VM2-2 | | 194 | |VNI 100 | |VNI 200 | | 195 | | | | | | 196 | +---------+ +---------+ | 197 | Server 2 | 198 +--------------------------+ 200 Figure 1 202 Figure 1 illustrates the scenario with two servers, each of them 203 hosting two VMs. These servers host VTEPs that terminate two VXLAN 204 tunnels with VNI number 100 and 200. Separate BFD sessions can be 205 established between the VTEPs (IP1 and IP2) for monitoring each of 206 the VXLAN tunnels (VNI 100 and 200). No BFD packets, intended to 207 Hypervisor VTEP, should be forwarded to a VM as VM may drop BFD 208 packets leading to false negative. This method is applicable whether 209 VTEP is a virtual or physical device. 211 5. BFD Packet Transmission over VXLAN Tunnel 213 BFD packet MUST be encapsulated and sent to a remote VTEP as 214 explained in Section 5.1. Implementations SHOULD ensure that the BFD 215 packets follow the same lookup path of VXLAN packets within the 216 sender system. 218 5.1. BFD Packet Encapsulation in VXLAN 220 VXLAN packet format has been described in Section 5 of [RFC7348]. 221 The Outer IP/UDP and VXLAN headers MUST be encoded by the sender as 222 per [RFC7348]. 224 The BFD packet MUST be carried inside the inner MAC frame of the 225 VXLAN packet. The inner MAC frame carrying the BFD payload has the 226 following format: 228 Ethernet Header: 230 Destination MAC: This MUST be a dedicated MAC (TBA) Section 9 231 or the MAC address of the destination VTEP. The details of how 232 the MAC address of the destination VTEP is obtained are outside 233 the scope of this document. 235 Source MAC: MAC address of the originating VTEP 237 IP header: 239 Source IP: IP address of the originating VTEP. 241 Destination IP: IP address of the terminating VTEP. 243 TTL: This MUST be set to 1. This is to ensure that the BFD 244 packet is not routed within the L3 underlay network. 246 [Ed.Note]:Use of inner source and destination IP addresses 247 needs more discussion by the WG. 249 The fields of the UDP header and the BFD control packet are 250 encoded as specified in [RFC5881] for p2p VXLAN tunnels. 252 6. Reception of BFD packet from VXLAN Tunnel 254 Once a packet is received, VTEP MUST validate the packet as described 255 in Section 4.1 of [RFC7348]. If the Destination MAC of the inner MAC 256 frame matches the dedicated MAC or the MAC address of the VTEP the 257 packet MUST be processed further. 259 The UDP destination port and the TTL of the inner Ethernet frame MUST 260 be validated to determine if the received packet can be processed by 261 BFD. BFD packet with inner MAC set to VTEP or dedicated MAC address 262 MUST NOT be forwarded to VMs. 264 To ensure BFD detects the proper configuration of VXLAN Network 265 Identifier (VNI) in a remote VTEP, a lookup SHOULD be performed with 266 the MAC-DA and VNI as key in the Virtual Forwarding Instance (VFI) 267 table of the originating/ terminating VTEP in order to exercise the 268 VFI associated with the VNI. 270 6.1. Demultiplexing of the BFD packet 272 Demultiplexing of IP BFD packet has been defined in Section 3 of 273 [RFC5881]. Since multiple BFD sessions may be running between two 274 VTEPs, there needs to be a mechanism for demultiplexing received BFD 275 packets to the proper session. The procedure for demultiplexing 276 packets with Your Discriminator = 0 is different from [RFC5880]. For 277 such packets, the BFD session MUST be identified using the inner 278 headers, i.e. the source IP and the destination IP present in the IP 279 header carried by the payload of the VXLAN encapsulated packet. The 280 VNI of the packet SHOULD be used to derive interface related 281 information for demultiplexing the packet. If BFD packet is received 282 with non-zero your discriminator then BFD session should be 283 demultiplexed only with your discriminator as the key. 285 7. Use of reserved VNI 287 BFD session MAY be established for the reserved VNI 0. One way to 288 aggregate BFD sessions between VTEP's is to establish a BFD session 289 with VNI 0. A VTEP MAY also use VNI 0 to establish a BFD session 290 with a service node. 292 8. Echo BFD 294 Support for echo BFD is outside the scope of this document. 296 9. IANA Considerations 298 IANA is requested to assign a dedicated MAC address to be used as the 299 Destination MAC address of the inner Ethernet which carries BFD 300 control packet in IP/UDP encapsulation. 302 10. Security Considerations 304 Document recommends setting of inner IP TTL to 1 which could lead to 305 DDoS attack, implementation MUST have throttling in place. 306 Throttling MAY be relaxed for BFD packets based on port number. 308 Other than inner IP TTL set to 1 this specification does not raise 309 any additional security issues beyond those of the specifications 310 referred to in the list of normative references. 312 11. Contributors 314 Reshad Rahman 315 rrahman@cisco.com 316 Cisco 318 12. Acknowledgments 320 Authors would like to thank Jeff Hass of Juniper Networks for his 321 reviews and feedback on this material. 323 Authors would also like to thank Nobo Akiya, Marc Binderberger and 324 Shahram Davari for the extensive review. 326 13. Normative References 328 [I-D.ashwood-nvo3-operational-requirement] 329 Ashwood-Smith, P., Iyengar, R., Tsou, T., Sajassi, A., 330 Boucadair, M., Jacquenet, C., and M. Daikoku, "NVO3 331 Operational Requirements", draft-ashwood-nvo3-operational- 332 requirement-03 (work in progress), July 2013. 334 [I-D.ietf-bfd-multipoint] 335 Katz, D., Ward, D., and J. Networks, "BFD for Multipoint 336 Networks", draft-ietf-bfd-multipoint-09 (work in 337 progress), October 2016. 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, 341 DOI 10.17487/RFC2119, March 1997, 342 . 344 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 345 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 346 . 348 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 349 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 350 DOI 10.17487/RFC5881, June 2010, 351 . 353 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 354 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 355 eXtensible Local Area Network (VXLAN): A Framework for 356 Overlaying Virtualized Layer 2 Networks over Layer 3 357 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 358 . 360 Authors' Addresses 362 Santosh Pallagatti (editor) 363 Independent Contributor 365 Email: santosh.pallagatti@gmail.com 367 Sudarsan Paragiri 368 Juniper Networks 369 1194 N. Mathilda Ave. 370 Sunnyvale, California 94089-1206 371 USA 373 Email: sparagiri@juniper.net 375 Vengada Prasad Govindan 376 Cisco 378 Email: venggovi@cisco.com 380 Mallik Mudigonda 381 Cisco 383 Email: mmudigon@cisco.com 385 Greg Mirsky 386 ZTE Corp. 388 Email: gregimirsky@gmail.com