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