idnits 2.17.1 draft-spallagatti-bfd-vxlan-00.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 4, 2015) is 3281 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) == Outdated reference: A later version (-11) exists of draft-ietf-bfd-seamless-base-04 ** Downref: Normative reference to an Informational RFC: RFC 7348 Summary: 1 error (**), 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 S. Paragiri 4 Intended status: Standards Track B. Saji 5 Expires: November 5, 2015 Juniper Networks 6 May 4, 2015 8 BFD for VXLAN 9 draft-spallagatti-bfd-vxlan-00 11 Abstract 13 This document describes use of Bidirectional Forwarding Detection 14 (BFD) protocol for VXLAN . Comments on this draft should be directed 15 to nvo3@ietf.org. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 5, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Transmission of BFD Packet: . . . . . . . . . . . . . . . . . 6 62 6. Reception of BFD Packet: . . . . . . . . . . . . . . . . . . 7 63 6.1. Demux of BFD Packet: . . . . . . . . . . . . . . . . . . 7 64 7. Echo BFD: . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8. S-BFD: . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 8.1. Transmission of S-BFD: . . . . . . . . . . . . . . . . . 8 67 8.2. Reception of S-BFD: . . . . . . . . . . . . . . . . . . . 8 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 71 12. Normative References . . . . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 "Virtual eXtensible Local Area Network (VXLAN)" has been defined in 77 [RFC7348] that provides an encapsulation scheme which allows VM's to 78 communicate in data centre network. 80 VXLAN is typically deployed in data centres on virtualized hosts, 81 which may be spread across multiple racks. The individual racks may 82 be parts of a different Layer 3 network or they could be in a single 83 Layer 2 network. The VXLAN segments/overlay networks are overlaid on 84 top of these Layer 2 or Layer 3 networks. 86 A VM can communicate with a VM in other host only if they are on same 87 VXLAN. VM's are unaware of VXLAN tunnels as VXLAN tunnel terminates 88 on VTEP (hypervisor/TOR). VETP (hypervisor/TOR) are responsible for 89 encapsulating and decapsulating frames sent from VM's. 91 Since underlay is a L3 network connectivity check for these tunnels 92 becomes important. BFD as defined in [RFC5880] can be used to 93 monitor the VXLAN tunnels. 95 2. Use cases 97 Main use case of BFD for VXLAN is for tunnel connectivity check. 98 There are other use cases such as 100 Layer 2 VM's: 102 Most deployments will have VM's with only L2 aware and may not 103 understand L3. BFD being a L3 protocol can be used for tunnel 104 connectivity check, where BFD will start and terminate at VTEP 105 on different host. 107 Fault localization: 109 It is also possible that VM's are L3 aware and can possible 110 host a BFD session. In these cases BFD session can be used to 111 run between VM's for VM's connectivity check, also BFD session 112 between VTEP's for tunnel connectivity check. With both VM's 113 BFD session and tunnel BFD can easily localize the fault to 114 either VM or tunnel. 116 Service node reachability: 118 Service node is responsible for sending BUM traffic. In case 119 of service node tunnel terminates at VTEP and it might not even 120 host VM's. If TOR's/Hypervisor wants to check service node 121 reachability then it would like run BFD session over VXLAN 122 tunnel to service node. 124 3. Deployment 125 +------------+-------------+ 126 | Server 1 | 127 | | 128 | +----+----+ +----+----+ | 129 | |VM1-1 | |VM1-2 | | 130 | |VNI 100 | |VNI 200 | | 131 | | | | | | 132 | +---------+ +---------+ | 133 | Hypervisor VTEP (IP1) | 134 +--------------------------+ 135 | 136 | 137 | 138 | +-------------+ 139 | | Layer 3 | 140 |---| Network | 141 | | 142 +-------------+ 143 | 144 | 145 +-----------+ 146 | 147 | 148 +------------+-------------+ 149 | Hypervisor VTEP (IP2) | 150 | +----+----+ +----+----+ | 151 | |VM2-1 | |VM2-2 | | 152 | |VNI 100 | |VNI 200 | | 153 | | | | | | 154 | +---------+ +---------+ | 155 | Server 2 | 156 +--------------------------+ 158 Consider the above diagram, where we have two servers with IP1 and 159 IP2 and each of them are hosting two VM's. There are two VXLAN 160 tunnels with VNI number 100 and 200. For connectivity check of these 161 two VXLAN tunnels, BFD sessions needs to be established per tunnel. 162 In the diagram above two BFD will be established between server 1's 163 Hypervisor VTEP (IP1) and server2 Hypervisor VTEP(IP2). BFD session 164 will originate from Hypervisor VTEP (IP1) and terminate at Hypervisor 165 VTEP (IP2) and visa versa. Each BFD session on Hypervisor VTEP will 166 be identified by its VNI in VXLAN header. No BFD packet intended to 167 Hypervisor VTEP should be forwarded to VM's as VM's may drop this 168 leading to false negative. 170 This method is also applicable VTEP which are either software or 171 physical device. 173 4. Packet Format 175 Packet format has been defined in Section 5 of [RFC7348]. Outer IP/ 176 UDP and VXLAN header will remain same and they should be filled by 177 sending VTEP as per [RFC7348]. Inner packet format has been defined 178 as below for BFD packet which terminates at VETP. BFD packet MUST 179 have a inner IP/UDP header followed by BFD payload. 181 0 1 2 3 182 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 184 Inner IPv4 Header: 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 |Version| IHL |Type of Service| Total Length | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Identification |Flags| Fragment Offset | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | TTL = 1 |Protocl=17(UDP)| Header Checksum | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Inner Source IPv4 Address | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Inner Destination Ipv4 Address = 127/8 address | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Inner IPv6 Header: 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 |Version| Traffic Class | Flow Label | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Payload Length | NxtHdr=17(UDP)| Hop Limit = 1 | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | | 206 + + 207 | | 208 + Inner Source IPv6 Address + 209 | | 210 + + 211 | | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | | 214 + + 215 | | 216 + Inner Destination IPv6 Address = + 217 | 0:0:0:0:0:FFFF:7F00/104 | 218 + + 219 | | 220 + + 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Inner UDP Header: 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Source Port | Dest Port = 3784 | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | UDP Length | UDP Checksum | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 BFD packet: 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | My Discriminator | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Your Discriminator | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Desired Min TX Interval | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Required Min RX Interval | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Required Min Echo RX Interval | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 5. Transmission of BFD Packet: 249 This section describes BFD packet encapsulation while transmitting 250 BFD packet from VTEP 252 Outer IP/UDP and VXLAN header: 254 VETP which is transmitting the packet MUST encapsulate the BFD 255 packet in outer IP/UDP and VXLAN header as described in 256 Section 5 of [RFC7348]. IP TOS value MUST be set to 257 "Internetwork Control". 259 Inner IP/UDP header: 261 Srouce IP address: 263 MUST be set to outgoing interface of sending VTEP interface. 265 Destination IP address: 267 MUST be set to non-routable 127/8 or 0:0:0:0:0:FFFF:7F00/104 268 range address. 270 IP TTL/HOP LIMIT: 272 MUST be set to 1. 274 UDP header: 276 UDP header is set as defined in Section 4 of [RFC5881] 278 BFD Packet: 280 BFD packet SHOULD be constructed as defined in Section 4 of 281 [RFC5880]. 283 6. Reception of BFD Packet: 285 Once a packet is received VTEP MUST validate packet as described in 286 Section 4.1 of [RFC7348]. Since inner IP TTL is set to 1 packet 287 SHOULD be consumed by VTEP and should not be forwarded further to VM. 288 It is recommended that BFD packets should not be throttled with TTL 289 1. Implementation MAY have a check to relax throttling if the inner 290 IP address is 127/8 range for IPv4 and 0:0:0:0:0:FFFF:7F00/104 for 291 IPv6 then UDP destination port is 3784. 293 6.1. Demux of BFD Packet: 295 Demux of IP BFD packet has been defined in Section 3 of [RFC5881]. 296 BFD demultiplexing for VXLAN is going to be different as destination 297 IP is same for all sessions and underlay is layer 3 and may have 298 ECMP. Source address and VNI should identify a BFD session on VTEP, 299 initially when BFD packets are sent with with your discriminator set 300 to 0 BFD packets MUST be demultiplexed with source address and VNI as 301 the key. If BFD packet is received with non-zero your discriminator 302 then BFD session should be demultiplexed only with your discriminator 303 as the key. 305 7. Echo BFD: 307 Support for echo BFD is outside the scope of this document. 309 8. S-BFD: 311 S-BFD can also be used for connectivity check as defined in 312 [I-D.ietf-bfd-seamless-base] 314 8.1. Transmission of S-BFD: 316 VTEP MUST encapsulate S-BFD packet as defined in Section 5. For 317 S-BFD however your Discriminator will be set to VNI from the VXLAN 318 header. 320 8.2. Reception of S-BFD: 322 VTEP MUST decapsulate S-BFD packet as defined in above section 323 "reception of BFD packet". Reflector MUST validate if your 324 Discriminator belongs any one of the VNI on that VTEP. 326 9. IANA Considerations 328 This document has no actions for IANA. 330 10. Security Considerations 332 Document recommends setting of inner IP TTL to 1 which could lead to 333 DDoS attack, implementation MUST have throttling in place. 334 Throttling MAY be relaxed for BFD packeted based on port number. 336 Other than inner IP TTL set to 1 this specification does not raise 337 any additional security issues beyond those of the specifications 338 referred to in the list of normative references. 340 11. Acknowledgements 342 Authors would like to thank Jeff Hass of Juniper Networks for his 343 reviews and feedback on this material. 345 12. Normative References 347 [I-D.ietf-bfd-seamless-base] 348 Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J. 349 Networks, "Seamless Bidirectional Forwarding Detection 350 (S-BFD)", draft-ietf-bfd-seamless-base-04 (work in 351 progress), January 2015. 353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 354 Requirement Levels", BCP 14, RFC 2119, March 1997. 356 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 357 (BFD)", RFC 5880, June 2010. 359 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 360 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 361 2010. 363 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 364 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 365 eXtensible Local Area Network (VXLAN): A Framework for 366 Overlaying Virtualized Layer 2 Networks over Layer 3 367 Networks", RFC 7348, August 2014. 369 Authors' Addresses 371 Santosh Pallagatti (editor) 372 Juniper Networks 373 Embassy Business Park 374 Bangalore, KA 560093 375 India 377 Email: santoshpk@juniper.net 379 Sudarsan Paragiri 380 Juniper Networks 381 1194 N. Mathilda Ave. 382 Sunnyvale, California 94089-1206 383 USA 385 Email: sparagiri@juniper.net 387 Basil Saji 388 Juniper Networks 389 Embassy Business Park 390 Bangalore, KA 560093 391 India 393 Email: sbasil@juniper.net