Internet DRAFT - draft-zia-nvo3-dist-arch
draft-zia-nvo3-dist-arch
INTERNET-DRAFT Osama Zia
Intended Status: Informational Microsoft
Expires: April 21, 2016 October 19, 2015
Distributed Architecture for Customer Access to Cloud
draft-zia-nvo3-dist-arch-01
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 April 21, 2016 [Page 1]
INTERNET DRAFT Dist. Arch. for Customer Access to Clo October 19, 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 April 21, 2016 [Page 2]
INTERNET DRAFT Dist. Arch. for Customer Access to Clo October 19, 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 April 21, 2016 [Page 3]
INTERNET DRAFT Dist. Arch. for Customer Access to Clo October 19, 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 April 21, 2016 [Page 4]
INTERNET DRAFT Dist. Arch. for Customer Access to Clo October 19, 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 April 21, 2016 [Page 5]
INTERNET DRAFT Dist. Arch. for Customer Access to Clo October 19, 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 April 21, 2016 [Page 6]
INTERNET DRAFT Dist. Arch. for Customer Access to Clo October 19, 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 April 21, 2016 [Page 7]
INTERNET DRAFT Dist. Arch. for Customer Access to Clo October 19, 2015
O.Zia Expires April 21, 2016 [Page 8]
