idnits 2.17.1 draft-spallagatti-bfd-vxlan-03.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The UDP destination port and the TTL of the inner MAC frame MUST be validated to determine if the received packet can be processed by BFD. BFD packet with inner MAC set to VTEP or well-known MAC address MUST not be forwarded to VM's. -- The document date (April 15, 2016) is 2932 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) == Missing Reference: 'TBD' is mentioned on line 216, but not defined ** 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-07 ** Downref: Normative reference to an Experimental draft: draft-quinn-vxlan-gpe (ref. 'I-D.quinn-vxlan-gpe') ** Downref: Normative reference to an Informational RFC: RFC 7348 Summary: 3 errors (**), 0 flaws (~~), 4 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 B. Saji 5 Expires: October 17, 2016 S. Paragiri 6 Juniper Networks 7 V. Govindan, Ed. 8 M. Mudigonda 9 Cisco 10 G. Mirsky 11 Ericsson 12 April 15, 2016 14 BFD for VXLAN 15 draft-spallagatti-bfd-vxlan-03 17 Abstract 19 This document describes use of Bidirectional Forwarding Detection 20 (BFD) protocol for VXLAN . 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 17, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. BFD Packet Transmission . . . . . . . . . . . . . . . . . . . 5 66 4.1. BFD Packet Encapsulation . . . . . . . . . . . . . . . . 5 67 5. Reception of BFD packet . . . . . . . . . . . . . . . . . . . 6 68 5.1. Demultiplexing of the BFD packet . . . . . . . . . . . . 6 69 6. Use of reserved VNI . . . . . . . . . . . . . . . . . . . . . 6 70 7. Echo BFD . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 74 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 75 12. Normative References . . . . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 "Virtual eXtensible Local Area Network (VXLAN)" has been defined in 81 [RFC7348] that provides an encapsulation scheme which allows VM's to 82 communicate in data center network. 84 VXLAN is typically deployed in data centers interconnecting 85 virtualized hosts, which may be spread across multiple racks. The 86 individual racks may be part of a different Layer 3 network or they 87 could be in a single Layer 2 network. The VXLAN segments/overlay 88 networks are overlaid on top of these Layer 2 or Layer 3 networks. 90 A virtual machine (VM) can communicate with a VM in other host only 91 if they are on same VXLAN. VM's are unaware of VXLAN tunnels as 92 VXLAN tunnel is terminated on VXLAN Tunnel End Point(VTEP) 93 (hypervisor/TOR). VTEPs (hypervisor/TOR) are responsible for 94 encapsulating and decapsulating frames exchanged among VM's. 96 Since underlay is a L3 network, continuity check for these tunnels 97 becomes important. BFD as defined in [RFC5880] can be used to 98 monitor the VXLAN tunnels. Use of [I-D.ietf-bfd-multipoint] is for 99 future study. 101 This draft addresses requirements outlined in 102 [I-D.ashwood-nvo3-operational-requirement]. Specifically with 103 reference to the OAM model to Figure 3 of 104 [I-D.ashwood-nvo3-operational-requirement], this draft outlines 105 proposal to implement the OAM mechanism between the NV Edges using 106 BFD. 108 2. Use cases 110 Main use case of BFD for VXLAN is for tunnel continuity check. BFD 111 packets between VTEPs will exercise the VXLAN path in underlay/ 112 overlay ensuring the VXLAN path reachability. BFD failure detection 113 can be used for maintenance. There are other use cases such as 115 Layer 2 VM's: 117 Most deployments will have VM's with only L2 capabilities that 118 may not support L3. BFD being a L3 protocol can be used as 119 tunnel CC mechanism, where BFD will start and terminate at the 120 Network Virtualization (NV) Edge (VTEPs). 122 It is possible to aggregate the CC sessions for multiple 123 tenants by running a BFD session between the VTEPs over VxLAN 124 tunnel. In rest of this document terms NV Edge and VTEP are 125 used interchangeably. 127 Fault localization: 129 It is also possible that VM's are L3 aware and can possibly 130 host a BFD session. In these cases BFD sessions can be 131 established among VM's for CC. In addition BFD sessions can be 132 established among VTEPs for tunnel CC. Having a hierarchical 133 OAM model helps localize faults though requires additional 134 consideration. 136 Service node reachability: 138 Service node is responsible for sending BUM traffic. In case 139 of service node tunnel terminates at VTEP and it might not even 140 host VM's. BFD session between TOR/hypervisor and service node 141 can be used to monitor service node reachability. 143 3. Deployment 145 +------------+-------------+ 146 | Server 1 | 147 | | 148 | +----+----+ +----+----+ | 149 | |VM1-1 | |VM1-2 | | 150 | |VNI 100 | |VNI 200 | | 151 | | | | | | 152 | +---------+ +---------+ | 153 | Hypervisor VTEP (IP1) | 154 +--------------------------+ 155 | 156 | 157 | 158 | +-------------+ 159 | | Layer 3 | 160 |---| Network | 161 | | 162 +-------------+ 163 | 164 | 165 +-----------+ 166 | 167 | 168 +------------+-------------+ 169 | Hypervisor VTEP (IP2) | 170 | +----+----+ +----+----+ | 171 | |VM2-1 | |VM2-2 | | 172 | |VNI 100 | |VNI 200 | | 173 | | | | | | 174 | +---------+ +---------+ | 175 | Server 2 | 176 +--------------------------+ 178 Figure 1 180 Figure 1 illustrates the scenario where we have two servers, each of 181 them hosting two VMs. These VTEPs terminate two VXLAN tunnels with 182 VNI number 100 and 200 between them. Separate BFD sessions can be 183 established between the VTEPs (IP1 and IP2) for monitoring each of 184 the VXLAN tunnels (VNI 100 and 200). No BFD packets intended to 185 Hypervisor VTEP should be forwarded to a VM as VM may drop BFD 186 packets leading to false negative. This method is applicable whether 187 VTEP is a software or a physical device. 189 4. BFD Packet Transmission 191 BFD packet MUST be encapsulated and sent to remote VTEP as explained 192 in Section 4.1. Implementations SHOULD ensure that the BFD packets 193 follow the same lookup path of VXLAN packets within the sender 194 system. 196 4.1. BFD Packet Encapsulation 198 VXLAN packet format has been defined in Section 5 of [RFC7348]. The 199 Outer IP/UDP and VXLAN headers MUST be encoded by the sender as per 200 [RFC7348]. 202 If VTEP is equipped with Generic Protocol Extension (GPE) header 203 capabilities and decides to use GPE instead of VXLAN then GPE header 204 MUST be encoded as per Section 3.3 of [I-D.quinn-vxlan-gpe]. Next 205 Protocol Field in GPE header MUST be set to IPv4 or IPv6. 207 Details of how VTEP decides to use VXLAN or GPE header are outside 208 the scope of this document. 210 The BFD packet MUST be carried inside the inner MAC frame of the 211 VxLAN packet. The inner MAC frame carrying the BFD payload has the 212 following format: 214 Ethernet Header: 216 Destination MAC: This MUST be a well-known MAC [TBD] OR the MAC 217 address of the destination VTEP. The details of how the 218 destination MAC address is obtained are outside the scope of 219 this document. 221 Source MAC: MAC address of the originating VTEP 223 IP header: 225 Source IP: IP address of the originating VTEP. 227 Destination IP: IP address of the terminating VTEP. 229 TTL: This MUST be set to 1. This is to ensure that the BFD 230 packet is not routed within the L3 underlay network. 232 [Ed.Note]:Use of inner source and destination IP addresses 233 needs more discussion by the WG. 235 The fields of the UDP header and the BFD control packet are 236 encoded as specified in RFC 5881 for p2p VXLAN tunnels. 238 5. Reception of BFD packet 240 Once a packet is received, VTEP MUST validate the packet as described 241 in Section 4.1 of [RFC7348]. If the Destination MAC of the inner MAC 242 frame matches the well-known MAC or the MAC address of the VTEP the 243 packet MUST be processed further. 245 The UDP destination port and the TTL of the inner MAC frame MUST be 246 validated to determine if the received packet can be processed by 247 BFD. BFD packet with inner MAC set to VTEP or well-known MAC address 248 MUST not be forwarded to VM's. 250 To ensure BFD detects the proper configuration of VXLAN Network 251 Identifier(VNI) in a remote VTEP, a lookup SHOULD be performed with 252 the MAC-DA and VNI as key in the Virtual Forwarding Instance(VFI) 253 table of the originating/ terminating VTEP in order to exercise the 254 VFI associated with the VNI. 256 5.1. Demultiplexing of the BFD packet 258 Demultiplexing of IP BFD packet has been defined in Section 3 of 259 [RFC5881]. Since multiple BFD sessions may be running between two 260 VTEPs, there needs to be a mechanism for demultiplexing received BFD 261 packets to the proper session. The procedure for demultiplexing 262 packets with Your Discriminator = 0 is different from [RFC5880]. For 263 such packets, the BFD session MUST be identified using the inner 264 headers, i.e. the source IP and the destination IP present in the IP 265 header carried by the payload of the VXLAN encapsulated packet. The 266 VNI of the packet SHOULD be used to derive interface related 267 information for demultiplexing the packet. If BFD packet is received 268 with non-zero your discriminator then BFD session should be 269 demultiplexed only with your discriminator as the key. 271 6. Use of reserved VNI 273 BFD session MAY be established for the reserved VNI 0. One way to 274 aggregate BFD sessions between VTEP's is to establish a BFD session 275 with VNI 0. A VTEP MAY also use VNI 0 to establish a BFD session 276 with a service node. 278 7. Echo BFD 280 Support for echo BFD is outside the scope of this document. 282 8. IANA Considerations 284 The well-known MAC to be used for the Destination MAC address of the 285 inner MAC frame needs to be defined 287 9. Security Considerations 289 Document recommends setting of inner IP TTL to 1 which could lead to 290 DDoS attack, implementation MUST have throttling in place. 291 Throttling MAY be relaxed for BFD packeted based on port number. 293 Other than inner IP TTL set to 1 this specification does not raise 294 any additional security issues beyond those of the specifications 295 referred to in the list of normative references. 297 10. Contributors 299 Reshad Rahman 300 rrahman@cisco.com 301 Cisco 303 11. Acknowledgements 305 Authors would like to thank Jeff Hass of Juniper Networks for his 306 reviews and feedback on this material. 308 Authors would also like to thank Nobo Akiya, Marc Binderberger and 309 Shahram Davari for the extensive review. 311 12. Normative References 313 [I-D.ashwood-nvo3-operational-requirement] 314 Ashwood-Smith, P., Iyengar, R., Tsou, T., Sajassi, A., 315 Boucadair, M., Jacquenet, C., and M. Daikoku, "NVO3 316 Operational Requirements", draft-ashwood-nvo3-operational- 317 requirement-03 (work in progress), July 2013. 319 [I-D.ietf-bfd-multipoint] 320 Katz, D., Ward, D., and J. Networks, "BFD for Multipoint 321 Networks", draft-ietf-bfd-multipoint-07 (work in 322 progress), August 2015. 324 [I-D.quinn-vxlan-gpe] 325 Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., 326 Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, 327 P., and D. Melman, "Generic Protocol Extension for VXLAN", 328 draft-quinn-vxlan-gpe-04 (work in progress), February 329 2015. 331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", BCP 14, RFC 2119, 333 DOI 10.17487/RFC2119, March 1997, 334 . 336 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 337 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 338 . 340 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 341 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 342 DOI 10.17487/RFC5881, June 2010, 343 . 345 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 346 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 347 eXtensible Local Area Network (VXLAN): A Framework for 348 Overlaying Virtualized Layer 2 Networks over Layer 3 349 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 350 . 352 Authors' Addresses 354 Santosh Pallagatti (editor) 355 Independent Contributor 357 Email: santoshpk@juniper.net 359 Basil Saji 360 Juniper Networks 361 Embassy Business Park 362 Bangalore, KA 560093 363 India 365 Email: sbasil@juniper.net 367 Sudarsan Paragiri 368 Juniper Networks 369 1194 N. Mathilda Ave. 370 Sunnyvale, California 94089-1206 371 USA 373 Email: sparagiri@juniper.net 374 Vengada Prasad Govindan (editor) 375 Cisco 377 Email: venggovi@cisco.com 379 Mallik Mudigonda 380 Cisco 382 Email: mmudigon@cisco.com 384 Greg Mirsky 385 Ericsson 387 Email: gregory.mirsky@ericsson.com