Internet DRAFT - draft-fang-vpn4dc-problem-statement
draft-fang-vpn4dc-problem-statement
Network Working Group Luyuan Fang
Internet Draft Cisco Systems
Intended status: Informational
Expires: April 24, 2012
October 24, 2011
VPN4DC Problem Statement
draft-fang-vpn4dc-problem-statement-00.txt
Abstract
Provider Provisioned IP VPNs are commonly used to interconnect
multiple locations of a private network, such as an enterprise with
multiple offices. Current developments in data center operations
create the need to consider additional connectivity and
connectivity management problems described in this document.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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".
This Internet-Draft will expire on April 24, 2012.
Copyright Notice
Copyright (c) 2011 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 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.
Fang Expire April 24, 2012 [Page 1]
Internet Draft VPN4DC Problem Statement October 2011
Table of Contents
1. Introduction 2
2. Terminology 3
3. VPN4DC: A problem Definition 3
4. Private network connectivity between data centers 4
5. Private Networks within a public data center 5
6. Connectivity between different VPNs 5
7. Mobile connectivity 5
8. Security Considerations 6
9. IANA Considerations 6
10. Normative References 6
11. Informative References 6
12. Author's Address 6
Requirements Language
Although this document is not a protocol specification, 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 [RFC
2119].
1. Introduction
Data centers are increasingly being consolidated and outsourced in
an effort both to improve the deployment time of applications as
well as reduce operational costs. This coincides with an increasing
requirement for compute, storage and network connectivity from
applications.
The consolidation and virtualization of data centers, either public
or private, has consequences in terms of network requirements. It
creates several new problems for private network connectivity,
which are incremental the existing L3VPN technology. It is helpful
to identify and analyze these problems separately:
- Private network connectivity between different data centers,
either public or private.
- Private network connectivity between different compute
resources within a public data center.
- Connectivity between different private networks within or
across data centers.
[Page 2]
Internet Draft VPN4DC Problem Statement October 2011
- Content distribution between centralized public or private
data centers and enterprise branch offices.
- Private network connectivity for mobile devices.
This document defines the problems under the assumption that
applications require IP unicast connectivity but no layer 2 direct
adjacencies. Applications with layer 2 requirements are likely to
also have assumptions of other media characteristics such as round
trip time, for instance.
This document is also under the assumption that both IPv4 and IPv6
unicast are in scope, but multicast service is a topic for further
discussion and outside the scope of this document.
The private network service to be provided must provide traffic
isolation between different VPNs allowing the use of a common
infrastructure and take into account the need to reduce operational
costs.
2. Terminology
AS Autonomous Systems
DC Data Center
IaaS Infrastructure as a Service
LTE Long Term Evolution
RT Route Target
ToR Top-of-Rack switch
VM Virtual Machine
VMM Virtual Machine Manager, Hypervisor
VPN Virtual Private Network
3. VPN4DC: A problem Definition
A VPN4DC solution needs to address the following problems that are
incremental to existing IPVPN solutions:
- IP only data center: defined by a data center where VM,
applications, and hypervisors require only IP connectivity
and the underlying DC infrastructure is IP only.
- Network isolation among tenants or applications sharing the
same data centers.
- Hypervisors may not support BGP as a control protocol.
[Page 3]
Internet Draft VPN4DC Problem Statement October 2011
- Fast and secure provisioning of a VPN connectivity for a VM
with low operational complexity within a data center and
across data centers. This includes the ability to connect a
VM to a customer VPN outside the data center, thus requiring
the ability to provision the communication path within the
data center to the customer VPN. It also includes
interconnecting VMs within and across physical data centers
in the context of a virtual data center. The customer VPN
service could be provided by a BGP/MPLS VPN [RFC 4363]
network service provider. The VPN connectivity provisioning
is targeted to be done via in-band signaling rather than an
out-of-band control infrastructure. The Software Defined
Network (SDN) is addressing the latter approach. It is
expected that both in-band and out-of-band provisioning
control will have applicability in different environments.
4. Private network connectivity between data centers
Private data centers attach to the VPN network via a CE device,
which advertises the respective IP address prefixes to the network.
In this space, the requirements remain unchanged from current
private networks, unless we assume the ability to migrate Virtual
Machines (VMs) between different data centers.
In the case that VMs are allowed to migrate between distinct data
centers, this requires that each specific IP Host prefix for a VM
to be advertised to the VPN network or an "home agent" approach
that can redirect traffic from one data center to another (with
potential negative consequences to latency).
When private networks interconnect with public data centers, the
VPN provider must interconnect with the public data center
provider. In this case we are in the presence of an Inter-Provider
VPN in which the VPN service provider manages part of the
connectivity and in which the data center provider provides network
attachment points for multiple common customers.
As with existing Inter-AS BGP/MPLS VPN scenarios, the Route Target
(RT) associated with a specific VPN (in a symmetrical VPN) must be
coordinated between the two entities (service provider and data
center provider). The data center provider services (e.g. the API
portal to its orchestration system) must also be accessible to all
the carriers VPNs.
As data center providers often have different operational
procedures than network services providers it is important to
identify potential solutions, from operational procedures to
[Page 4]
Internet Draft VPN4DC Problem Statement October 2011
application APIs that can exchange the necessary information
between the VPN network service provider and data center provider.
5. Private Networks within a public data center
Public data centers achieve efficiencies by executing the compute
loads of many different customers over a common infrastructure for
compute, storage and network.
Compute nodes are often executed as Virtual Machines, in an
"Infrastructure as a Service" (IaaS) data center. The set of
virtual machines corresponding to a particular customer should be
constrained to a private network. L3VPN technologies have proven to
be able to scale to a large number of customer routes while
providing for aggregated management capability. It is important to
document the applicability of BGP/MPLS L3VPN technology to VMs in a
data center.
It must take into account that MPLS itself is not a common
technology within data centers and as such the solution must
provide for IP based forwarding. It is also important to consider
whether the end-system itself can contain the routing information
corresponding to the VPN overlay networks without the assistance of
the Top-of-Rack (ToR) switch, which may be constrained in terms of
its routing table size.
6. Connectivity between different VPNs
Within a data center, the VMs within a private network will need to
communicate with data center common services such as storage or
data-base services. These services often imply high traffic
volumes.
The traditional approach is to deploy stateful service appliance,
between different VPNs. That may become cost prohibitive for
services with high volume of traffic. It is important to consider
whether pushing the desired traffic control rules to the ingress
points of the network (traffic sources) may assist in addressing
this operational issue.
7. Mobile connectivity
Application access is being done increasingly from clients such as
cell phones or tablets that may come in via a private WiFi access
point or a public WiFi or 3G/LTE access. These clients must have
access to application which servers reside on a private network.
[Page 5]
Internet Draft VPN4DC Problem Statement October 2011
It is important to consider whether it is possible to connect
applications in mobile clients to provider provisioned VPNs. For
instance by using IPSec tunnels; or whether these applications are
best served by content caches running in the service provider
infrastructure.
The solution should assume that client, VPN provider and data
center may be in different Autonomous Systems.
8. Security Considerations
The document presents the problems need to be addressed in the
L3VPN for data center space. The requirements and solutions will be
documented separately.
The security considerations for general requirements or individual
solutions will be documented in the relevant documents.
9. IANA Considerations
This document contains no new IANA considerations.
10. Normative References
[RFC 4363] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
11. Informative References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
12. Author's Address
Luyuan Fang
Cisco Systems
111 Wood Avenue South
Iselin, NJ 08830
USA
Email: lufang@cisco.com
[Page 6]
Internet Draft VPN4DC Problem Statement October 2011
13. Acknowledgement
The author would like to thank Pedro Marques for his helpful
comments/input.
[Page 7]
