idnits 2.17.1 draft-fang-l3vpn-data-center-interconnect-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 -- The document date (July 4, 2014) is 3555 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Luyuan Fang 3 Intended Status: Informational Microsoft 4 Expires: January 4, 2015 Rex Fernando 5 Dhananjaya Rao 6 Sami Boutros 7 Cisco 9 July 4, 2014 11 BGP/MPLS IP VPN Data Center Interconnect 12 draft-fang-l3vpn-data-center-interconnect-03 14 Abstract 16 This document discusses two categories of inter-connections of 17 BGP/MPLS IP VPN and Data Center (DC) overlay networks. In the first 18 category, DC overlay virtual network is built with BGP/MPLS IP VPN 19 (IP VPN) technologies, and the inter-connection of IP VPN in the DC 20 either to IP VPN in other DCs or to IP VPN in the WAN enables end-to- 21 end IP VPN connectivity. In the second category, DC overlay network 22 uses non IP VPN overlay technologies, and the inter-connection of any 23 overlay virtual network in the DC to IP VPN in the WAN provides end 24 user connectivity through stitching of different overlay 25 technologies. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2.1 Case 1: End-to-end BGP IP VPN cloud inter-connection . . . . 4 69 2.2 Case 2: Hybrid cloud inter-connection . . . . . . . . . . . 4 70 3. Architecture reference models . . . . . . . . . . . . . . . . . 4 71 3.1 BGP/MPLS IP VPN Inter-AS model . . . . . . . . . . . . . . . 4 72 3.2 BGP/MPLS IP VPN Gateway PE to DC vCE Model . . . . . . . . . 5 73 3.3 Hybrid inter-connection model . . . . . . . . . . . . . . . 6 74 4. Inter-connect IP VPN between DC and WAN . . . . . . . . . . . . 7 75 4.1 Existing Inter-AS options and DCI gap analysis . . . . . . . 7 76 4.1.1 Option A pros and cons . . . . . . . . . . . . . . . . . 7 77 4.1.2 Option B pros and cons . . . . . . . . . . . . . . . . . 8 78 4.1.3 Option C pros and cons . . . . . . . . . . . . . . . . . 8 79 4.1.4 Use of RTC . . . . . . . . . . . . . . . . . . . . . . . 9 80 5. Inter-connect IP VPN and non-IP VPN overlay networks . . . . . 9 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 8.1 Normative References . . . . . . . . . . . . . . . . . . . 11 85 8.2 Informative References . . . . . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 88 1 Introduction 90 With the growth of cloud services, the need of inter-connecting DC 91 overlay networks and Enterprise BGP/MPLS IP VPNs in the Wide Area 92 Network (WAN) arises. 94 Two categories of inter-connections of BGP/MPLS IP VPN [RFC4364] and 95 Data Center (DC) overlay networks are discussed in this document. In 96 the first category, DC overlay virtual network is built with BGP/MPLS 97 IP VPN (IP VPN) technologies, and the inter-connection of IP VPN in 98 the DC either to IP VPN in other DCs or to IP VPN in the WAN enables 99 end-to-end IP VPN connectivity for Virtual Private Cloud (VPC) 100 services. In the second category, DC overlay network uses non IP VPN 101 overlay technologies, the inter- connection of any overlay virtual 102 network in the DC to IP VPN in the WAN provides end user connectivity 103 through stitching of different overlay technologies. 105 This document discusses use cases of the inter-connection of BGP/MPLS 106 VPN to Data Centers, the general requirements, and the proposed 107 solutions for the inter-connections. 109 1.1 Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 Term Definition 116 ----------- -------------------------------------------------- 117 AS Autonomous System 118 ASBR Autonomous System Border Router 119 BGP Border Gateway Protocol 120 CE Customer Edge 121 GRE Generic Routing Encapsulation 122 Hypervisor Virtual Machine Manager 123 I2RS Interface to Routing System 124 MP-BGP Multi-Protocol Border Gateway Protocol 125 NVGRE Network Virtualization using GRE 126 QoS Quality of Service 127 RD Route Distinguisher 128 RR Route Reflector 129 RT Route Target 130 RTC RT Constraint 131 SDN Software Defined Network 132 ToR Top-of-Rack switch 133 vCE virtual Customer Edge Router 134 VM Virtual Machine 135 VN Virtual Network 136 VPC Virtual Private Cloud 137 vPE virtual Provider Edge Router 138 VPN Virtual Private Network 139 VXLAN Virtual eXtensible Local Area Network 140 WAN Wide Area Network 142 2. Use Cases 143 2.1 Case 1: End-to-end BGP IP VPN cloud inter-connection 145 BGP/MPLS IP VPN is a proven scalable overlay technology with 146 extensive deployment. It is an excellent candidate for end-to-end 147 (host-to-host) overlay technology for Cloud-Scale DC application 148 support. In addition, many SPs are interested to extend the IP VPN 149 capabilities into their DCs to provide end-to-end native BGP IP VPN 150 services to their enterprise customers. 152 BGP IP VPN provides routing isolation, rich policy control, and QoS 153 support. The technologies developed to extend BGP IP VPN into DC 154 servers or ToR are work in progress in IETF, 155 [I-D.fang-l3vpn-virtual-pe],and [I-D.ietf-l3vpn-end-system]. 157 The WAN and DC may be managed by the same or different administrative 158 domains. 160 2.2 Case 2: Hybrid cloud inter-connection 162 Inter-connecting network SPs Enterprise IP VPNs to Cloud/Content 163 providers DCs for expanded services. The inter-connection between the 164 SP BGP/MPLS IP VPNs and the cloud provider networks is needed to 165 provide the service end-to-end. The inter-connection of different 166 types of providers can be BGP/MPLS IP VPN to other VPN or overlay 167 technologies which may be virtualized or non-virtualized. 169 3. Architecture reference models 171 The architecture reference models described below focus on the inter- 172 connection aspects. Although the intra-DC implementation is not 173 within the scope of this discussion, the intra-DC technology has a 174 direct impact to inter-DC connection. Therefore, various models are 175 illustrated. 177 3.1 BGP/MPLS IP VPN Inter-AS model 179 The BGP/MPLS IP VPNs are implemented in both the WAN network and the 180 Data Center. A customer VPN, for example VPNA in figure 1, consists 181 of enterprise remote sites and VMs supporting applications in the DC. 182 The IP VPN implementation is using vPE technology in DC. The two 183 segments of the VPNs are inter-connected through ASBRs facing each 184 other in the respective networks. 186 ,-----. ,-----. 187 ( ') ( ') 188 .--(. '.---. .-.(. '.---. 189 ( ' ' +-----+ +-----+ ) 190 ( IP/MPLS WAN |ASBR1|---|ASBR2| DC Network ) 191 (. +-----+ +-----+ .) 192 +-----+ ( .) ( ( +-----+ 193 | PE1 |-.-' '-''--'' ''--' '-''-|vPE2 | 194 .----.-.----. .----.-.----. 195 |VRFA| |VRFB| |VRFA| |VRFB| 196 '----' '----' '----' '----' 197 / \ / \ \ 198 +---+ +---+ .---. .---. .---. 199 |CE1| |CE2| |VM1| |VM2| |VM3| 200 +---+ +---+ '---' '---' '---' 201 (VPNA) (VPNB) ( VPNA ) (VPNB) 203 Figure 1. BGP/MPLS IP VPN Inter-Connection 204 with ASBR in each network 206 One boarding ASBR can be shared for the inter-connection of the two 207 networks, especially if the WAN and DC belong to the same provider. 208 Figure 2 illustrates this shared ASBR model. 210 ,----.. ,-----. 211 ( ') ( ') 212 .--(. '.----. .-.(. '.---. 213 ( ' ' +------+ ) 214 ( IP/MPLS WAN | ASBR | DC Network ) 215 (. +------+ .) 216 +-----+ ( .) ( ( +-----+ 217 | PE1 |-.-' '-''---'' ''--' '-''-|vPE2 | 218 .----.-.----. .----.-.----. 219 |VRFA| |VRFB| |VRFA| |VRFB| 220 '----' '----' '----' '----' 221 / \ / \ \ 222 +---+ +---+ .---. .---. .---. 223 |CE1| |CE2| |VM1| |VM2| |VM3| 224 +---+ +---+ '---' '---' '---' 225 (VPNA) (VPNB) ( VPNA ) (VPNB) 227 Figure 2. BGP/MPLS IP VPN Inter-Connection 228 with share ASBR 230 3.2 BGP/MPLS IP VPN Gateway PE to DC vCE Model 231 A simple virtual CE (vCE) [I-D.fang-l3vpn-virtual-ce] model can be 232 used to inter-connect client containers to the DC Gateway which 233 function as PE. This model is used by SPs to provide managed 234 services, when scale can meet the service requirement. 236 ,----.. ,-----. 237 ( ') ( ') 238 .--(. '.----. .----. '.----. 239 ( ' ' +-----|VRFA| +----+ 240 ( IP/MPLS WAN |GW/PE'----' DC Network |vCE4| 241 (. +-----|VRFB| +----+ 242 +-----+ ( )' '----'.( )-' | (VPNB) 243 | PE1 |-.-' '-''- ' '--' '+----+ .---. 244 .----.-.----. |vCE3| |VM3| 245 |VRFA| |VRFB| (VPNA) +----+ '---' 246 '----' '----' / \ 247 / \ .---..---. 248 +---+ +---+ |VM1||VM2| 249 |CE1| |CE2| '---''---' 250 +---+ +---+ 251 (VPNA) (VPNB) 253 Figure 3. BGP/MPLS IP VPN GW/PE to vCEs 254 without BGP/MPLS IP VPN in the DC 256 3.3 Hybrid inter-connection model 258 The BGP/MPLS IP VPNs are implemented in the WAN network, and non 259 BGP/MPLS IP VPN Overlay are implemented in the DC. The connection of 260 the two networks is outside of the technologies for Inter-AS 261 connections for BGP IP VPNs. This model includes many variations 262 depending on the specific technologies used in the DC overlay. Figure 263 4 provides a general view of this inter-connecting model with ASBR on 264 the MPLS WAN side, and the DC GW on the DC side. It is also viable to 265 use one shared ASBR/GW for the inter-connection, especially if the 266 WAN and the DC belong to the same provider. 268 ,-----. ,-----. 269 ( ') ( ') 270 .--(. '.---. .-.(. '.---. 271 ( ' ' +-----+ +-----+ ) 272 ( IP/MPLS WAN |ASBR |---|DC GW| DC Network ) 273 (. +-----+ +-----+ .) 274 +-----+ ( .) ( ( +-----+ 275 | PE1 |-.-' '-''--'' ''--' '-''-| NVE | 276 .----.-.----. +-----+ 277 |VRFA| |VRFB| / \ \ 278 '----' '----' .---. .---. .---. 279 / \ |VM1| |VM2| |VM3| 280 +---+ +---+ .---. .---. .---. 281 |CE1| |CE2| ( TenantA) (TenantB) 282 +---+ +---+ 283 (VPNA) (VPNB) 285 Figure 4. BGP/MPLS IP VPN Inter-Connection with 286 non BGP/MPLS IP VPN Overlay in DC 288 4. Inter-connect IP VPN between DC and WAN 290 4.1 Existing Inter-AS options and DCI gap analysis 292 The inter-AS options described in [RFC4364] can be used for DC inter- 293 connection. Option A, B, and C must be supported. 295 4.1.1 Option A pros and cons 297 In Option A: back-to-back VRF. The PE-ASBR in one AS performs MPLS or 298 IP VPN de-encapsulation and transmits packets to the peer PE-ASBR in 299 the adjacent AS. The peer PE-ASBR performs MPLS or IP VPN 300 encapsulation on the customer IPv4/IPv6 packets received, and 301 transmits the packet through the IP backbone of the AS. VPN service 302 providers exchange routes across a back-to-back VRF connection. Each 303 VRF instance represents a separate VPN client, and it is configured 304 on a separate PE-ASBR interface, allowing a PE-ASBR to communicate 305 with its peer PE-ASBR as if the peer was a CE router. 307 Pros: This is the most secure option among options A, B, and C. And 308 it is the simplest model from operation perspective. Each PE-ASBR is 309 treating the other as a CE. 311 Cons: This option suffers from scaling limitations, because per 312 Inter-AS VPN VRF and interface are needed on the PE-ASBR. 314 Option A has been commonly used in BGP/MPLS VPN Inter-Provider inter- 315 connections because of the security considerations and its clear 316 operational demarcation. 318 DCI considerations: This is a simple way to connect DC and WAN if 319 both sides are of small scale. Scale will be the major concern for DC 320 inter-connect if large scale support is needed. Even if the DC scale 321 is small, there are major concerns on receiving relevant routes 322 (potentially a large number) from the WAN side, and Vice Versa. 324 4.1.2 Option B pros and cons 326 In Option B: EBGP redistribution of labeled VPN-IPv4/IPv6 routes 327 between the neighboring ASes. ASes exchange VPN routing information 328 (routes and labels) to establish connections. To control connections 329 between ASes, the PE routers and EBGP border edge routers maintain a 330 label forwarding information base (LFIB). The LFIB manages the labels 331 and routes that the PE routers and EBGP border edge routers receive 332 during the exchange of VPN information. The ASes exchange VPN routing 333 information, such as, the destination network, the next hop field 334 associated with the distributing router, a local MPLS label, and an 335 RD. ASBRs are configured to change the next hop (next-hop-self) when 336 sending VPN-IPv4 NLRIs to the IBGP neighbors; the ASBRs must allocate 337 a new label when they forward the NLRI to the IBGP neighbors. 339 Pros: It provides improved scalability when compared with option A, 340 since it removes the needs of per Inter-AS VPN VRF and interface on 341 the ASBR. 343 Cons: vanilla version of Option B is considered less secure in 344 comparison with Option A, due to the dynamic routing information 345 exchange that is involved. The ASBR scaling may still be an issue 346 because ASBR must maintain all VPN routes. 348 Option B is commonly used within single provider or for inter- 349 provider connections. 351 DCI considerations: Option B is one viable option to be used in DC 352 inter-connection. However, it has the same scale concerns as other 353 options because of the potentially large number of routes exchanged 354 between the WAN and the DC. 356 4.1.3 Option C pros and cons 358 In option C: Multihop eBGP redistribution of labeled VPN-IPv4/Ipv6 359 routes between source and destination ASs, with eBGP redistribution 360 of labeled IPv4/IPv6 routes from AS to neighboring AS. The ASBRs need 361 only to exchange host routes (/32 or /128) to the PE routers involved 362 in the VPN, with the labels needed to get there. A Label Switch Path 363 (LSP) is built from the ingress PE router in one AS to the egress PE 364 in the other AS (using Loopback addresses). VPN traffic uses this LSP 365 to reach the other AS. From data plane's perspective, the ASBRs act 366 as P routers, with no knowledge about the VPNs concerned. Between the 367 two inter-connecting ASBRs, the VPN traffic is treated just as 368 between two P routers, each VPN data packet is pre-pended with the 369 VPN label and then with an egress-PE label. Option C can be further 370 scaled by using route reflectors (RRs) in each AS. 372 Pros:It is the most scalable option among all three. ASBR is no 373 longer a bottle neck for VPN routes scaling as in Option B. 375 Cons: Major security issues as IGP reachability must be exchanged 376 between the inter-connecting ASes. 378 Option C has seen used within a single SP for inter-AS connections. 379 Using RR for VPN routes exchange is the common approach. 381 DCI consideration: Option C SHOULD NOT be used for any DCI which is 382 between two different providers for security reasons. 384 In this option, though ASBR is not longer the scaling bottleneck, the 385 scaling issues still call for careful design, as the total numbers of 386 VRFs, VPN interfaces, and the VPN routes being exchanged between the 387 two ASes can be very large. 389 4.1.4 Use of RTC 391 RT constraint [RFC4684] function must be used to only distribute the 392 IP VPN routes of a VPN from one AS to another under the condition 393 that they both support that VPN in each of the AS. This is one most 394 important function for scalable solution. 396 However, all IP VPN routes are exchanged between the two ASes (e.g. 397 WAN and DC) as long as they have to support the same VPNs. The 398 potential IP VPN routes distribution can still be very substantial in 399 large WAN and DC deployment. Additional aggregation and abstraction 400 mechnisms can be used to avoid large numbers of VPN routes being 401 exchanges across the border between the interconnecting WAN and the 402 DC in either directions. 404 5. Inter-connect IP VPN and non-IP VPN overlay networks 406 As one significant instance of the hybrid use-case described in 407 section 2.2, a DC may support a multi-tenant virtualized service 408 network using IP based DC overlay encapsulations such as VXLAN 409 [I-D.mahalingam-dutt-dcops-vxlan] or NVGRE 410 [I-D.sridharan-virtualization-nvgre]. Different deployment models may 411 be used within the DC depending on the DC provider's functional and 412 operational requirements. 414 When an IP DC overlay is terminated at the DC Gateway router and 415 traffic directed into a BGP/MPLS IP VPN, the DC Gateway router 416 performs MPLS encapsulation towards the WAN and IP overlay based 417 forwarding within the DC. 419 The inter-connection mechanisms between the DC and the WAN may fall 420 into two categories: 422 1. VRF Termination 424 The overlay based virtual network terminates into a BGP IP VPN VRF at 425 the DC-WAN Gateway router. Both the internal routes of the DC as well 426 as the external routes received from the WAN router can be installed 427 in the VRF forwarding table at the DC Gateway router. The DC Gateway 428 performs an IP lookup, appropriate MPLS or IP encapsulation, and 429 forward traffic. 431 The DC Gateway router peers with the WAN router using one of the 432 existing inter-AS mechanisms described above. The DC Gateway 433 functions as an IP-VPN ASBR with local VRFs; for example, packets 434 still undergo an IP forwarding lookup. 436 2. DC-VN and IP VPN Inter-working 438 In this case, the DC Gateway router performs a direct translation 439 between VN-IDs and IP VPN labels while switching packets between the 440 DC and WAN interfaces without performing an IP lookup. The forwarding 441 table at the DC Gateway router is set up to do a VN-ID or label 442 lookup and derive the output label or VN-ID. The DC Gateway Router 443 acts as an Inter-AS Option B ASBR peering with other ASBRs. 445 6. Security Considerations 447 BGP/MPLS Inter-AS security threats and defense techniques described 448 in RFC 4111 [RFC4111] are applicable for the WAN/DC inter- 449 connections. 451 In addition, the protocols between the Gateway routers and the 452 controller/orchestrator MUST be mutually authenticated. Given the 453 potentially very large scale and the dynamic nature in the cloud/DC 454 environment, the choice of key management mechanisms need to be 455 further studied. 457 7. IANA Considerations 458 None. 460 8. References 462 8.1 Normative References 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, March 1997. 467 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 468 Networks (VPNs)", RFC 4364, February 2006. 470 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 471 R., Patel, K., and J. Guichard, "Constrained Route 472 Distribution for Border Gateway Protocol/MultiProtocol 473 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 474 Private Networks (VPNs)", RFC 4684, November 2006. 476 8.2 Informative References 478 [RFC4111] Fang, L., Ed., "Security Framework for Provider- 479 Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, 480 July 2005. 482 [I-D.ietf-l3vpn-end-system] Marques, P., Fang, L., Pan, P., Shukla, 483 A., Napierala, M., "BGP-signaled end-system IP/VPNs", 484 draft-ietf-l3vpn-end-system, work in progress. 486 [I-D.fang-l3vpn-virtual-pe] Fang, L., Ward, D., Fernando, R., 487 Napierala, M., Bitar, N., Rao, D., Rijsman, B., So, N., 488 "BGP IP VPN Virtual PE", draft-fang-l3vpn-virtual-pe, work 489 in progress. 491 [I-D.fang-l3vpn-virtual-ce] Fang, L., Evans, J., Ward, D., Fernando, 492 R., Mullooly, J., So, N., Bitar., N., Napierala, M., "BGP 493 IP VPN Virtual PE", draft-fang-l3vpn-virtual-ce, work in 494 progress. 496 [I-D.mahalingam-dutt-dcops-vxlan]: Mahalingam, M, Dutt, D.., et al., 497 "A Framework for Overlaying Virtualized Layer 2 Networks 498 over Layer 3 Networks" draft-mahalingam-dutt-dcops-vxlan, 499 work in progress. 501 [I-D.sridharan-virtualization-nvgre]: SridharanNetwork, M., et al., 502 "Virtualization using Generic Routing Encapsulation", 503 draft-sridharan-virtualization-nvgre, work in progress. 505 Authors' Addresses 506 Luyuan Fang 507 Microsoft 508 5600 148th Ave NE 509 Redmond, WA 98052 510 Email: lufang@microsoft.com 512 Rex Fernando 513 Cisco 514 170 W Tasman Dr 515 San Jose, CA 516 Email: rex@cisco.com 518 Dhananjaya Rao 519 Cisco 520 170 W Tasman Dr 521 San Jose, CA 522 Email: dhrao@cisco.com 524 Sami Boutros 525 Cisco 526 170 W Tasman Dr 527 San Jose, CA 528 Email: dhrao@cisco.com