INTERNET-DRAFT Osama Zia Intended Status: Informational Microsoft Expires: October 19, 2015 April 17, 2015 Distributed Architecture for Customer Access to Cloud draft-zia-nvo3-dist-arch-00 Abstract This draft describes a distributed architecture within the data center for providing customers, access to their VMs in the data center. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must O.Zia Expires October 19, 2015 [Page 1] INTERNET DRAFT Dist. Arch. for Customer Access to Clo April 17, 2015 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Components of Existing Architecture . . . . . . . . . . . . . 3 3. Limitation of Existing Architecture . . . . . . . . . . . . . 4 4. Proposed Architecture . . . . . . . . . . . . . . . . . . . . 5 5. Advantages of proposed architecture . . . . . . . . . . . . . . 6 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1 Normative References . . . . . . . . . . . . . . . . . . . 6 5.2 Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 O.Zia Expires October 19, 2015 [Page 2] INTERNET DRAFT Dist. Arch. for Customer Access to Clo April 17, 2015 1 Introduction Customers today connect to the cloud providers using solutions that have been conventionally used by service providers to provide backhaul to customers. These are based on establishing some sort of Layer3 with the service provider (IGP, BGP or static route). The service provider then uses an overlay (generally mpls) to carry customers' traffic to their other locations where it is delivered to the customer over a similar Layer3 handoff. In a cloud environment especially in case of hybrid cloud, the expectation is to provide customers, access to their assets (compute, storage etc.)in the cloud with the same ease as they would access their assets at their premises. However, conventional connectivity model used by existing cloud providers make it difficult for the customers because they require complicated interconnection with the cloud provider. The other problem with this approach is the scalability and cost implications on the edge device at the cloud provider such as: 1. Number of VRFs 2. Number of routes 3. Number of BGP sessions 4. Cost of high bandwidth interfaces 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document uses the same terminology as [RFC7365]. In addition, the following terms are used: VRF: Virtual Routing and Forwarding Edge: Device at the cloud provider used to connect customers Cloud Router: Routing software running on a server or VM O.Zia Expires October 19, 2015 [Page 3] INTERNET DRAFT Dist. Arch. for Customer Access to Clo April 17, 2015 2. Components of Existing Architecture Starting from customer on-prem towards the customer assets in the cloud here are the transport components and traffic flow. Customer connects to the cloud provider either directly or through carrier. When using carrier the most common method is MPLS VPN as described in [RFC4364]. In case of carrier, customer either establishes a new layer3 connection (mostly BGP)or leverages an existing connection with the carrier. While in case of cloud provider it will be a new layer3 connection. For this purpose customer deploys or leverages an existing routing device. At the cloud provider end there is again a routing device to terminate customer connections and establish layer3 connectivity. In order to deal with customer security requirements and overlapping address space problems, the cloud provider creates VRF at the routing device. BGP (or IGP) protocol is used to dynamically exchange customer routes. The customer VRF at this edge device stores customer's on-prem routes as well as customer routes in the cloud. From the edge device the cloud provider establishes some kind of overlay encapsulation mechanism to tunnel the traffic towards the customer VMs. There are many encapsulation options available today and used by the cloud providers such as VXLAN, GRE, NVGRE, IPSec, IP- in-IP etc. There are tunnel endpoint devices close to customer VMs that are responsible for decapsulating the traffic encapsulated by the cloud provider edge device. These are NVE devices that can be hardware based such as ToRs or can be software gateways in the hypervisor or dedicated VMs. The choice and location of these devices varies between cloud providers. 3. Limitation of Existing Architecture The edge device at the cloud provider needs to create separate VRF for each customer. This pose limitation on the number of customers that can be onboarded via single edge device. As BGP is the most common protocol being used. These routing devices are limited on how many BGP sessions they can establish. Another limitation is the number of routes. This is an interesting problem. Unlike Internet, in this case the device will have to store same prefixes over and over for each customer. So, while the number of prefixes may not be huge (as the private address space is limited as compared to public address space) but number of instances of same O.Zia Expires October 19, 2015 [Page 4] INTERNET DRAFT Dist. Arch. for Customer Access to Clo April 17, 2015 prefixes will fill up the route storage capacity of the device very quickly. Also, unlike Internet the customer has no need to aggregate these prefixes as this network is an extension of their existing network. This would mean that either customer is forced to aggregate or a new device needs to be deployed to keep up with growing number of routes. The cost of high speed interfaces on routing devices tend to be quite higher than on switching devices. Hence, the cost of the edge device is higher to start with. An important thing to note here is that all the above factors come into play at the same time. Either one of these variable could impact other variables and force the upgrade or additional deployment of these devices. 4. Proposed Architecture Customer Router +--------+ | | +------:-+ :<--BGP +--------:+ |NVE Edge:| +---.----:+ . : . +:--------+ . | |Cloud Router . +---------+ . | +--.----------+ | NVA | .+-----.-------+. . . . +-------.+ +---.----+ +--.-----+ | NVE 1 | | NVE 2 | | NVE 3 | +--------+ +--------+ +--------+ / \ / \ / \ +---+ +---+ +---+ +---+ +---+ +---+ |VM1| |VM2| |VM3| |VM4| |VM5| |VM6| +---+ +---+ +---+ +---+ +---+ +---+ O.Zia Expires October 19, 2015 [Page 5] INTERNET DRAFT Dist. Arch. for Customer Access to Clo April 17, 2015 The proposed architecture is based on three tenants. 1. Separation of control plane and data plane 2. Leverage extensibility of NVA 3. Cost reduction At the cloud provider there will be a layer2 edge device instead of a layer3 edge device. This device will be used for direct or indirect physical connection to the customer. For the control plane there will be routing software running on a server or VM called cloud router. The customer will establish BGP connection with the cloud router. This cloud router will get its information from NVA. When a customer deploys a new VN the provisioning system will update NVA with the NVE and prefix for the customer. The NVA will update the cloud router which will send BGP update to the customer. For the data plane, the edge device will act as an NVE and use incoming interface to identify the customer. NVE will need more information to craft the header for the incoming packet such as destination NVE, encapsulation type etc. NVA will hold customer information such as VNID, NVEs belonging to the customer and the prefixes that each NVE is serving. There could be a push or pull model between NVE and NVA to update information. The destination NVE will received the packet, look at the VNID, decapsulate it and deliver it to the corresponding VM. NVEs that are close the customer VMs can be software or hardware NVEs. They use NVA in similar way to get more information about the TSs and their VNs. However, there search string could be different. For example the NVE could provide NVA with VNID to gather information about the destination NVE. 5. Advantages of proposed architecture By moving the routing function into cloud router, the route storing capacity will be increased many fold and at a very low cost as compared to a router. This will also make it more scalable. High bandwidth interfaces such as 10G and 40G are much cheaper on a switch than on a router. This will reduce the cost. Another advantage is space and power. A 48G switch takes less space and consumer less power than a 48 port router. By deploying a switch the throughput capacity of the device will be O.Zia Expires October 19, 2015 [Page 6] INTERNET DRAFT Dist. Arch. for Customer Access to Clo April 17, 2015 almost non-blocking which will increase the scalability. Extensibility of NVA can be leveraged for routing decisions. For example NVA can have a field that allows access to certain prefixes by a VNID or Sub-VNID. At the ingress NVE packet can be dropped based on this policy. Similarly, the NVA can provide information related to encapsulation type used by the remote NVE. 3 Security Considerations Tenant isolation is the primary concern in a cloud provider. In this architecture, tenant information in NVA, Cloud Router and encapsulation are three components that need to be tenant specific. It is expected that NVO3 will address these issues in their specific areas. 4 IANA Considerations This document does not request any action from IANA. 5 References 5.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 5.2 Informative References [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.Rekhter, "Framework for Data Center (DC) Network Virtualization", RFC 7365, October 2014 Authors' Addresses Osama Zia 1 Microsoft Way Redmond, WA, 98052 US EMail: osamaz@microsoft.com O.Zia Expires October 19, 2015 [Page 7] INTERNET DRAFT Dist. Arch. for Customer Access to Clo April 17, 2015 O.Zia Expires October 19, 2015 [Page 8]