idnits 2.17.1 draft-spallagatti-bfd-vxlan-01.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 (July 6, 2015) is 3210 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 204, but not defined == Unused Reference: 'I-D.ietf-bfd-seamless-base' is defined on line 288, 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 (-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 (~~), 5 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: January 7, 2016 Juniper Networks 6 V. Govindan 7 M. Mudigonda 8 Cisco 9 G. Mirsky 10 Ericsson 11 July 6, 2015 13 BFD for VXLAN 14 draft-spallagatti-bfd-vxlan-01 16 Abstract 18 This document describes use of Bidirectional Forwarding Detection 19 (BFD) protocol for VXLAN . Comments on this draft should be directed 20 to nvo3@ietf.org, rtg-bfd@ietf.org. 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 January 7, 2016. 45 Copyright Notice 47 Copyright (c) 2015 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 Encapsulation . . . . . . . . . . . . . . . . . . 5 66 5. Reception of BFD packet . . . . . . . . . . . . . . . . . . . 5 67 5.1. Demux of the BFD packet . . . . . . . . . . . . . . . . . 6 68 6. Echo BFD . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 73 11. Normative References . . . . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 "Virtual eXtensible Local Area Network (VXLAN)" has been defined in 79 [RFC7348] that provides an encapsulation scheme which allows VM's to 80 communicate in data centre network. 82 VXLAN is typically deployed in data centres on virtualized hosts, 83 which may be spread across multiple racks. The individual racks may 84 be parts of a different Layer 3 network or they could be in a single 85 Layer 2 network. The VXLAN segments/overlay networks are overlaid on 86 top of these Layer 2 or Layer 3 networks. 88 A VM can communicate with a VM in other host only if they are on same 89 VXLAN. VM's are unaware of VXLAN tunnels as VXLAN tunnel terminates 90 on VTEP (hypervisor/TOR). VTEP (hypervisor/TOR) are responsible for 91 encapsulating and decapsulating frames sent from VM's. 93 Since underlay is a L3 network, connectivity check for these tunnels 94 becomes important. BFD as defined in [RFC5880] can be used to 95 monitor the VXLAN tunnels. 97 This draft addresses requirements outlined in 98 [I-D.ashwood-nvo3-operational-requirement]. Specifically with 99 reference to the OAM model to Figure 3 of 100 [I-D.ashwood-nvo3-operational-requirement], this draft outlines 101 proposal to implement the OAM mechanism between the NV Edges using 102 BFD. 104 2. Use cases 106 Main use case of BFD for VXLAN is for tunnel connectivity check. 107 There are other use cases such as 109 Layer 2 VM's: 111 Most deployments will have VM's with only L2 capabilities and 112 may not understand L3. BFD being a L3 protocol can be used for 113 tunnel connectivity check, where BFD will start and terminate 114 at the NV Edge (VTEPs). 116 It is possible to aggregate the connectivity checks for 117 multiple tenants by running a BFD session between the VTEPs 118 over VxLAN tunnel. In rest of this document terms NV Edge and 119 VTEP are used interchangeably. 121 Fault localization: 123 It is also possible that VM's are L3 aware and can possibly 124 host a BFD session. In these cases BFD sessions can be 125 established between VM's for connectivity check. In addition a 126 BFD session can be established between VTEPs for tunnel 127 connectivity check. Having a hierarchical OAM model helps 128 localize faults. 130 Service node reachability: 132 Service node is responsible for sending BUM traffic. In case 133 of service node tunnel terminates at VTEP and it might not even 134 host VM's. If TOR's/Hypervisor wants to check service node 135 reachability then it would like run BFD session over VXLAN 136 tunnel to service node. 138 3. Deployment 140 +------------+-------------+ 141 | Server 1 | 142 | | 143 | +----+----+ +----+----+ | 144 | |VM1-1 | |VM1-2 | | 145 | |VNI 100 | |VNI 200 | | 146 | | | | | | 147 | +---------+ +---------+ | 148 | Hypervisor VTEP (IP1) | 149 +--------------------------+ 150 | 151 | 152 | 153 | +-------------+ 154 | | Layer 3 | 155 |---| Network | 156 | | 157 +-------------+ 158 | 159 | 160 +-----------+ 161 | 162 | 163 +------------+-------------+ 164 | Hypervisor VTEP (IP2) | 165 | +----+----+ +----+----+ | 166 | |VM2-1 | |VM2-2 | | 167 | |VNI 100 | |VNI 200 | | 168 | | | | | | 169 | +---------+ +---------+ | 170 | Server 2 | 171 +--------------------------+ 173 Figure 1 175 Figure 1 illustrates a scenario where we have two servers, each of 176 them hosting two VMs. These VTEPs terminate two VXLAN tunnels with 177 VNI number 100 and 200 between them. Separate BFD sessions can be 178 established between the VTEPs (IP1 and IP2) for monitoring each of 179 the VXLAN tunnels (VNI 100 and 200). No BFD packet intended to 180 Hypervisor VTEP should be forwarded to VM's as VM's may drop this 181 leading to false negative. This method is also applicable VTEP which 182 are either software or physical device. 184 4. BFD Packet Encapsulation 186 VxLAN packet format has been defined in Section 5 of [RFC7348]. The 187 Outer IP/UDP and VXLAN headers MUST be encoded by the sender as per 188 [RFC7348]. 190 If VTEP is equipped with GPE header capitalises and decides to use 191 GPE instead of VXLAN then GPE header MUST be encoded as per 192 Section 3.3 of [I-D.quinn-vxlan-gpe]. Next Protocol Field in GPE 193 header MUST be set to IPv4 or IPv6. 195 Details of how VTEP decides to use VXLAN or GPE header is outside the 196 scope of this document. 198 The BFD packet MUST be carried inside the inner MAC frame of the 199 VxLAN packet. The inner MAC frame carrying the BFD payload has the 200 following format: 202 Ethernet Header: 204 Destination MAC: This MUST be a well-known MAC [TBD] OR the MAC 205 address of the destination VTEP. The details of how the 206 destination MAC address is obtained is outside the scope of 207 this document. 209 Source MAC: MAC address of the originating VTEP 211 IP header: 213 Source IP: IP address of the originating VTEP. 215 Destination IP: IP address of the terminating VTEP. 217 TTL: This MUST be set to 1. This is to ensure that the BFD 218 packet is not routed within the L3 underlay network. 220 Note: Inner source and destination IP needs more discussion in 221 WG. 223 The fields of the UDP header and the BFD control packet are 224 encoded as specified in RFC 5881. 226 5. Reception of BFD packet 228 Once a packet is received, VTEP MUST validate the packet as described 229 in Section 4.1 of [RFC7348]. If the Destination MAC of the inner MAC 230 frame matches the well-known MAC or the MAC address of the VTEP the 231 packet MUST be processed further. 233 The UDP destination port and the TTL of the inner MAC frame MUST be 234 validated to determine if the received packet can be processed by 235 BFD. BFD packet with inner MAC set to VTEP or well-known MAC address 236 MUST not be forwarded to VM's. 238 5.1. Demux of the BFD packet 240 Demux of IP BFD packet has been defined in Section 3 of [RFC5881]. 241 Since multiple BFD sessions may be running between two VTEPs, there 242 needs to be a mechanism for demultiplexing received BFD packets to 243 the proper session. The procedure for demultiplexing packets with 244 Your Discriminator = 0 is different from [RFC5880]. For such 245 packets, the BFD session is identified using the VNID, the source IP 246 and the destination IP of the packet. If BFD packet is received with 247 non-zero your discriminator then BFD session should be demultiplexed 248 only with your discriminator as the key. 250 6. Echo BFD 252 Support for echo BFD is outside the scope of this document. 254 7. IANA Considerations 256 The well-known MAC to be used for the Destination MAC address of the 257 inner MAC frame needs to be defined 259 8. Security Considerations 261 Document recommends setting of inner IP TTL to 1 which could lead to 262 DDoS attack, implementation MUST have throttling in place. 263 Throttling MAY be relaxed for BFD packeted based on port number. 265 Other than inner IP TTL set to 1 this specification does not raise 266 any additional security issues beyond those of the specifications 267 referred to in the list of normative references. 269 9. Contributors 271 Reshad Rahman 272 rrahman@cisco.com 273 Cisco 275 10. Acknowledgements 277 Authors would like to thank Jeff Hass of Juniper Networks for his 278 reviews and feedback on this material. 280 11. Normative References 282 [I-D.ashwood-nvo3-operational-requirement] 283 Ashwood-Smith, P., Iyengar, R., Tsou, T., Sajassi, A., 284 Boucadair, M., Jacquenet, C., and M. Daikoku, "NVO3 285 Operational Requirements", draft-ashwood-nvo3-operational- 286 requirement-03 (work in progress), July 2013. 288 [I-D.ietf-bfd-seamless-base] 289 Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J. 290 Networks, "Seamless Bidirectional Forwarding Detection 291 (S-BFD)", draft-ietf-bfd-seamless-base-05 (work in 292 progress), June 2015. 294 [I-D.quinn-vxlan-gpe] 295 Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., 296 Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, 297 P., and D. Melman, "Generic Protocol Extension for VXLAN", 298 draft-quinn-vxlan-gpe-04 (work in progress), February 299 2015. 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, March 1997. 304 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 305 (BFD)", RFC 5880, June 2010. 307 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 308 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 309 2010. 311 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 312 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 313 eXtensible Local Area Network (VXLAN): A Framework for 314 Overlaying Virtualized Layer 2 Networks over Layer 3 315 Networks", RFC 7348, August 2014. 317 Authors' Addresses 319 Santosh Pallagatti (editor) 320 Juniper Networks 321 Embassy Business Park 322 Bangalore, KA 560093 323 India 325 Email: santoshpk@juniper.net 326 Basil Saji 327 Juniper Networks 328 Embassy Business Park 329 Bangalore, KA 560093 330 India 332 Email: sbasil@juniper.net 334 Sudarsan Paragiri 335 Juniper Networks 336 1194 N. Mathilda Ave. 337 Sunnyvale, California 94089-1206 338 USA 340 Email: sparagiri@juniper.net 342 Vengada Prasad Govindan 343 Cisco 345 Email: venggovi@cisco.com 347 Mallik Mudigonda 348 Cisco 350 Email: mmudigon@cisco.com 352 Greg Mirsky 353 Ericsson 355 Email: gregory.mirsky@ericsson.com