Internet DRAFT - draft-hy-nvo3-vpn-protocol-gap-analysis
draft-hy-nvo3-vpn-protocol-gap-analysis
Network Working Group L. Yong
Internet Draft S. Hares
Intended status: Informational Huawei
Expires: April 2013 October 21, 2012
VPN Protocol Gap Analysis for DC Network Virtualization Overlays
draft-hy-nvo3-vpn-protocol-gap-analysis-02
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April, 2013.
Copyright Notice
Copyright (c) 2009 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.
Yong & Hares Expires April 21, 2013 [Page 1]
Internet-Draft NVO3 and VPN Gap October 2012
Abstract
This document is to describe the applicability of traditional
IP/MPLS L2VPN and L3VPN for NVO3 and identify the protocol gaps. It
also addresses the use of the VPNs for inter DC connectivity when
NVO3 is used.
Table of Contents
1. Introduction...................................................2
2. Terminology....................................................3
3. IP/MPLS Virtual Private Networks (VPNs)........................3
4. VPN for Network Virtualization Overlays........................4
4.1. NVE Location..............................................4
4.2. VM Mobility...............................................6
4.3. VNI on NVE................................................6
4.4. Tunneling.................................................6
4.5. Auto Discovery............................................7
4.6. Load Balancing............................................7
4.7. Broadcast and Multicast Traffic...........................7
4.8. Gateway...................................................7
4.9. Underlay Network Design...................................8
5. VPN for Inter DC Connectivity..................................8
5.1. Interconnecting DC Underlying Networks....................8
5.2. Interconnecting DC Overlay Networks.......................9
5.3. Interconnecting a DC VN and Enterprise Networks..........10
6. Operator Aspects..............................................12
7. Security Considerations.......................................13
8. IANA Considerations...........................................13
9. Acknowledgments...............................................13
10. References...................................................13
10.1. Normative References....................................13
10.2. Informative Reference...................................14
1. Introduction
DC Network Virtualization Overlay is driven by a desire of building
a tenant application in a true virtual and secure environment
[NVO3PRBM]. The NVO3 aims on a solution to group virtual hosts
together in a true virtual environment that is decoupled from the
physical network configuration. This decoupling not only speeds up
the construction of a tenant applications and virtual Data Centers
but also enables a new cloud application. For example, allow the hot
VM move from a server to another.
Yong & Hares Expires April 21, 2013 [Page 2]
Internet-Draft NVO3 and VPN Gap October 2012
Virtual and overlay network technology is not new. [RFC4364]
[RFC4761] [RFC6325] The main differences between other overlay
network technologies and NVO3 are 1) the client edge of the NVO3
network may be individual virtualized hosts, not network sites or
LANs; 2) the hosts and the network edge may be on the same server
and the server is a host, not a network edge device; 3) the
capability to support dynamic host placement and mobility.
VPLS [RFC4761] [RFC4762] based L2VPN and BGP/MPLS L3VPN [RFC4364]
have been widely deployed in Service Provider IP/MPLS networks to
provide Layer 2 or Layer 3 virtual private networking for a
customer. In fact, these VPN technologies have a lot of common
characteristics that the NVO3 requires. These characteristics are:
1) the capability to build many L2VPN and/or L3VPN instances on a
common IP/MPLS backbone infrastructure; 2) to segregate the VPN
traffic from other VPN's; 3) each VPN uses its own address space and
the address is isolated from the infrastructure address space.
Further both L2VPN and L3VPN solutions use the virtualization and
encapsulation approach at the edge device, i.e. PE, to hide customer
frames or packets and use a LSP tunnel transporting the
frames/packets. This is very similar to the targeted NVO3 solution.
Thus, it is useful to evaluate the L2VPN and L3VPN applicability for
NVO3 and identify the protocol gaps between them. In addition, an
NVO3 application may need to communicate with external users in a
secured manner. The use of a traditional VPN to interconnect between
a DC virtual network and enterprise networks [NVO3UCASE] remains the
minimum changes in the enterprise networks and service provider
networks. As a result the VPNs in a WAN may be necessary to support
NVO3 features as well.
This draft is to analyze NV03 requirements and L2VPN/L3VPN
solutions/protocols and point out the gaps in between. The draft
intends to stay in neutral on whether a new solution or the
extension/simplification of the VPN solutions is right approach for
NVO3.
2. Terminology
This document uses the terminologies defined in [NVO3FRWK],
[RFC4364].
3. IP/MPLS Virtual Private Networks (VPNs)
IP/MPLS based VPLS and E-VPN [RFC4761][RFC4762][EVPN] and L3VPN
[RFC4364] are developed for Wide-Area Networks. Both VPLS and L3VPN
Yong & Hares Expires April 21, 2013 [Page 3]
Internet-Draft NVO3 and VPN Gap October 2012
have been widely deployed in Service Provider WANs, MANs, and some
access networks. The E-VPN is still under development. These VPN
solutions allow a Service Provider IP/MPLS backbone network provides
a virtual private network in a WAN for a customer who has more than
one network sites, i.e. the connectivity among customer network
sites. The architecture of L2VPN [RFC4664] and L3VPN are very
similar. The three entities in the VPN architecture are CE, PE, and
P. CE is the customer edge, representing a customer site. PE is the
backbone network edge that connects to a customer CE via a physical
interface. P is the backbone core node that does not connect to the
customer site directly.
The distinction between L2VPN and L3VPN is that an L2VPN routes and
forwards on Ethernet MAC addresses while an L3VPN routes and forward
on IP addresses. The VPLS solution uses the PW [RFC4448] for the
transport between any pair of PEs; the L3VPN [RFC4364] and EVPN
[EVPN] uses a MPLS LSP tunnel for the transport between any pair of
PEs. Note that the PW in turn relies on a LSP tunnel for the
transport as well. The VPLS uses data plane MAC learning at each PE
to resolve the endpoint location. The L3VPN and EVPN uses iBGP
protocol to disseminate customer IP and MAC address to the remote
PEs. The L3VPN may use eBGP, OSPF [RFC4577], or others for the route
population between CE-PE; EVPN uses data plane MAC learning at a PE
customer facing interface. Both L2VPN and L3VPN solutions make the
core node unaware of the VPN existence at PEs. Regarding auto
discovery and configuration, the L3VPN and EVPN use the BGP
protocols; the VPLS uses either LDP [RFC4762] or iBGP [RFC4761]
protocol.
Note that PW [RFC4448], L2TP [RFC5641], etc are often known as a
L2VPN solution because they can transport Ethernet MAC frames
between two points. This draft focuses on the analysis of VPLS, EVPN
and L3VPN for the NVO3 and refers these two as L2VPN.
4. VPN for Network Virtualization Overlays
4.1. NVE Location
One characteristics of NVO3 is the NVE location [NVO3FRWK]. There
are two distinct cases. First an NVE resides on a server, i.e. TESs
and NVE are on the same hardware. In this case, a server manager
system is responsible to create NVE/VNs and VMs, and also
responsible to assign a VM to a VN that has unique identification,
then server software just makes it works properly and securely. A
server itself may connect to the ToR as a host and DC physical
network uses L3 network. This configuration is similar to Option B
in RFC4363 [RFC4364]. Second an NVE resides on an external switch
Yong & Hares Expires April 21, 2013 [Page 4]
Internet-Draft NVO3 and VPN Gap October 2012
such as ToR. When a server manager creates a VM and adds the VM to a
VN on a local NVE, the server will send a notification of VM
participation in the VN to the local NVE. In both cases, when a
local NVE notices the new attached TES in a VN, it will announce the
TES to remote NVEs [RFC4364] [EVPN] or to a mapping server via a
control plane protocol [LISP].
Traditional VPN architecture has PE and CE roles on different
devices and two devices are connected via a wire (or more). In
addition, PE and CE may be managed by different administration
systems and serve as the service demarcation point. A CE is typical
a network site (in L3VPN) or LANs (in L2VPN). PE is a Service
Provider edge device.
Although the VPN PE function is some similar to NVE, CE function is
very different from NVO3 TES's from several aspects:
o PE and CE are on different hardware not on one. The provision
process on CE and PE is done by different systems. TES/NVE in
NV03 may be managed by one system.
o When CE is at a network site, a new end system is added into the
site first, then this route is populated or learned by the PE.
Thus the supporting of the dynamic changes of end-points is not
critical to a VPN solution today due to the CE site network
limitation to support that. However, in NVO3, a TES directly
attaches to an NVE, the NVO3 solution has to support the dynamic
change of TES.
o In L3VPN, the route population between PE and CE can be done by
some control plane protocol such as eBGP, OSPF, etc. If an NVE is
on a server, no need a control plane protocol between a TES and
NVE; if an NVE is on an external switch, it may not be practical
or efficient to run these protocols on every server as CE's. Thus
NV03 may use a different protocol between an NVE and a server
when the NVE is on an external switch.[ESYS] From the data plane
perspective, L2VPN and L3VPN both can support virtual sub-
interface on a wire.[RFC4761][EVPN][VRF-LITE]
o When an NVE is on a server, the server connects to one or more
ToRs as a host, i.e. the server does not run any routing protocol
but is configured with a default gateway. DC physical network
does not have any visibility of NVO3. See section 5.2. NVO3 makes
TES and NVE more coupled together while VPN solution has VPN
function and underlay network more coupled.
Yong & Hares Expires April 21, 2013 [Page 5]
Internet-Draft NVO3 and VPN Gap October 2012
4.2. VM Mobility
Compute virtualization drives the need for network virtualization
overlays, which lets closed user groups (CUG) to communication in a
true virtual environment without considering physical network
configuration. One BIG application for this is to enable dynamic VM
placement and move without the change of VM IP and MAC address.
Further the VM move has to be quickly enough so that the application
does not get disrupted. This requires the NVO3 solution to
differentiate a VM placement from a VM move. Both L2VPN and L3VPN
solutions do not distinguish two actions and are not able to support
a hot move. Further VM mobility adds the challenges for IP routing
optimization [ISSUES].
If the VM move is necessary across Data Centers [ISSUES], a
traditional VPN solution also needs to support that. The BGP
protocol supports sending a MAC withdraw message to allow a local PE
to inform the remote PEs about its end-system removal. However, if a
local PE can't detect the end-system removal quickly, this message
may not be sufficient to insure the frame forwarding properly. For
example, if a TES does not directly connect to a PE by a wire, the
PE hardly syncs the state of TES when it moves. Another issue is
when a VM moves, if its default gateway has no change, the traffic
to/from the VM will still be routed through the same gateway entity,
which is not optimized router. [ISSUES]
4.3. VNI on NVE
NVO3 may apply to a large data center that may have hundred thousand
servers and several millions of VMs. One NVO3 requirement is to be
able to support a large number of virtual networks on a common data
center infrastructure where each virtual network may be highly
distributed in term of NVEs and spares TES per a NVE. To let each
NVE maintain all the routes may lead a scalability issue for a
server or a ToR switch. Considering a TES in a closed user group may
rarely communicate with all other TESs at the same time, it is not
necessary for an NVE to maintain all the routes at all the time.
Some advanced control plane protocol and mechanism may fit better
than traditional VPN control plane protocol for the route population
between NVEs. [LISP]
4.4. Tunneling
Traditional L2VPN and L3VPN are mainly implemented with the MPLS
tunnels for transporting over the backbone network. Although the GRE
tunnel [RFC4797] is technically feasible, the majority L2VPN and
L3VPN deployments if not all use MPLS/LSP tunnel approach, i.e. one
Yong & Hares Expires April 21, 2013 [Page 6]
Internet-Draft NVO3 and VPN Gap October 2012
MPLS label (inner label) as the VPN identifier (or PW for VPLS) and
one label (outer label) for MPLS/LSP tunnel. Thus core nodes, i.e. P
nodes, are unaware of individual VPN instances. This implementation
integrates the VPN solutions and the underlying MPLS network
technology in one or another way. For example, the use of one label
stack for the packet processing at PE and P, the traffic engineering
capability, and MPLS trace [RFC4379] tools are able to track both
inner and outer labels.
NVO3 clearly requires the decoupling the overlay and underlying
networking configuration. Further it has a high desirable to use IP
tunnel instead of MPLS tunnel in a Data Center. Although the IP/GRE
tunnel can apply to L2/L3 VPN solutions, the lack of the deployment
in a real network may leave some unknown holes in the packet
processing and management. For example, the IP/GRE tunnel approach
aggregates the tunneled traffic in the underlying network, which may
impacts the recovery and traffic optimization in the network. Thus a
diligent study is necessary.
4.5. Auto Discovery
Both L2VPN and L3VPN have auto discovery capability and use BGP
protocol. The protocol can apply to the NVO3 if the same control
plane protocol is used. However, if other route population protocol
is used, NVO3 also needs the similar auto discovery capability.
4.6. Load Balancing
Address in next version.
4.7. Broadcast and Multicast Traffic
Address in next version.
4.8. Gateway
A logical gateway places an important role in NVO3 use case
[NVO3UCASE]. A gateway may interconnect NVO3 instances together,
connect a NVO and a virtual network in a DC, or connect a NVO to
external users via Internet, WAN VPN, or direct line. Furthermore a
logical gateway may perform encapsulation translation, NAT,
firewall, IPSEC, etc. Although an L3VPN is able to provide some
gateway and policy functions, it does not have the role to perform
encapsulation translation, NAT functions.
Yong & Hares Expires April 21, 2013 [Page 7]
Internet-Draft NVO3 and VPN Gap October 2012
4.9. Underlay Network Design
DC underlay network design may be different from carrier WAN network
design. DC physical networks have a common three tier architecture,
ToR, aggregation switch and core switch plus DC gateway for the
external connection. DC operator may not deploy any IGP in DC and
just configure many ASes and use BGP protocol for the reachbility in
DC physical networks [DCBGP] or use Open Flow design [ONF] instead
of distributed control plane. This makes some challenges or new
aspects for underlay network configuration and management,
optimization, resiliency, and convergence. Although MPLS/BGP
solution supports multi-ASes and allows a transit AS carrying a VPN
seamlessly, the configuration is more complex than the VPN in single
IGP. See section 5.2.
5. VPN for Inter DC Connectivity
Today Service Provider VPN services are mainly used for
interconnecting Enterprise DCs that are at different locations
including DC providers. In this case, DC provider sites as the CE
site and connect to Service Provider edge routers, i.e. PEs, via a
physical wire. Typically an Ethernet Interface is used.
Service provider may offer either a L2VPN [RFC4761][RFC4762] or
L3VPN [RFC4364] service over the WANs to a customer. The service
provides the connectivity among customer physical networks (port
based) or virtual networks (sub-interface) at the locations. When
using NVO3, one difference is that NVO3 uses the overlay for each VN
instead of VLANs. In other words, on a DC provider infrastructure,
there is one underlying network (physical) and many overlay networks
(virtual). Following sections describe the VPN applicability for
interconnecting such DC locations and potential enhancements to
interwork with NVO3. Note that the description applies to both L2VPN
and L3VPN unless it is stated explicitly.
5.1. Interconnecting DC Underlying Networks
In this case, a Service Provider constructs a traditional VPN to
interconnect multiple DC physical networks over the WANs for a DC
customer. Then the DC customer may configure a NVO3 virtual network
in multiple DCs in the same way as if configuring it in one DC
without considering the VPN configuration at all.
The DC physical networks and the VPN in the WANs together provide
the underlying networking for an NVO3 virtual network. Two NVEs in
the different DC locations can build one tunnel for NVO3 transport
over DC networks and the VPN. The VPN transports the tunneled
Yong & Hares Expires April 21, 2013 [Page 8]
Internet-Draft NVO3 and VPN Gap October 2012
packets seamlessly across WANs and does not have the visibility of
the end systems in each virtual network. The routes populated
between a CE and PE are the DC underlying network routes only. The
NVO3 functions such as auto discovery and VM mobility seamlessly
work over the VPN. No change on the existing VPN solutions is
necessary for this option. From the NVO3 perspective, it is
completely decoupled from the VPN and is not aware of the VPN
existence at all. When using BGP/MPLS VPNs, the eBGP interworks with
DC control plane protocols such as OSPF or ISIS, which makes each DC
network as individual islands from the control plane perspective.
In the case that different DCs use different NVO3 solutions and
require a gateway entity between two virtual networks, this option
still works seamlessly. However the NVO3 control plane needs to
address disseminating the end system locations across DCs
[NVO3PRBM], which is discussed in next section. This is the
interface protocol between oracle systems Note that for an L3VPN
configuration, the control plane in each DC site just peers with the
local PE not a remote CE; For an L2VPN configuration, a Service
Provider can configure the policy for L2CP BDUs at a PE based on the
customer request. They can be either passed or discarded.
It is worth to mention that there are other network solutions that
support an overlay networking beside IP IGP technology. PBB [PBB] is
L2 network solution; SPB [RFC6329] and TRILL [RFC6325] are L2
network solution with IS-IS control plane. Some DC operators may
choose one of them for their data centers. The EVPN extensions such
as [PBB-EVPN],[SPB-EVPN],[TRILL-EVPN] allow to interconnect DCs that
use these solutions.
5.2. Interconnecting DC Overlay Networks
In this case, a Service Provider constructs a VPN in the WANs to
interconnect a particular NVO3 virtual network (i.e. a tenant
virtual network that spans across multiple DCs). A sub-interface
such as a VLAN between CE and PE can be used to identify the VN
between the CE, e.g. DC Gateway Router, and the PE. Each DC builds a
tunnel between a NVE and the DC Gateway Router for the transport
within the DC. The VPN may use a MPLS/LSP tunnel between any pair of
PEs in WANs. This option creates one NVO3 virtual network in each DC
and one VPN over the WANs and stitches them together by a local VLAN
between a CE and PE to form one tenant virtual network.
The VPN in the WANs in this case only has the visibility of the VN
in a DC. The VPN does not have the visibility of the DC physical
network and other VNs in the DCs. The end systems in other DCs will
appear as if associating with the DC Gateway Router in a DC. The VPN
Yong & Hares Expires April 21, 2013 [Page 9]
Internet-Draft NVO3 and VPN Gap October 2012
protocol extension may be necessary for the route population between
CE and PE as well as among PEs. This is because 1) NVO3 may use a
new control plane protocol that current VPN does not support. 2) The
capability to support VM mobility. [ISSUES]
Note that this option allows individual DCs to use the same or
different NVO3 encapsulation schema. In fact, this option is very
similar to Option A [RFC4364] except NVO3 implementation may differ.
If DC operators want to construct an L2 VN within a data center but
buy an L3VPN interconnect them, the NVE on the DC GW will perform
the ARP function to resolve the IP/MAC mapping.
If DC operators use eBGP and RR to disseminate the TES locations
across DCs, it is possible to implement Option B and C [RFC4364]. In
option B, the IP address of remote NVE in another DC is used in
outer header, i.e. as the tunnel address. In option C, two tunnels
are necessary. The inter tunnel is to the remote NVE; the outer
tunnel is to the ASBR, which enables IGP routers to forward packets
in IGP. In both cases, a WAN VPN (or Internet) has to connect DC
physical networks first as mentioned in section 5.1. There is not a
WAN VPN directly connecting to an overlay network in DC. It is
interesting to note that two BGP separated control planes are used:
one works with DC underlying network control plane and another is
used for overlay network control plane.
Note that no matter a VPN in a WAN connects to a DC underlying
network or overlay network, a DC network never have the visibility
to the WAN network, i.e. the VPN networking is decoupled from the
IP/MPLS transport.
5.3. Interconnecting a DC VN and Enterprise Networks
[NVO3UCASE] describes the needs and the different ways for a virtual
network in a Data Center to communicate with external users. For a
private cloud application, the use of a traditional VPN in a WAN to
interconnect with a VN in DC provider site is desirable. The benefit
of the traditional VPN is to leverage existing VPN usage or minimize
the change on the VPN when the enterprise customer uses it to access
a cloud service provided by a DC provider.
Figure 1 below illustrates this scenario. Both enterprise A and B
uses a Service Provider L3VPN services to interconnect its branch
locations respectively. Note that the two VPN topologies may differ.
Now each buys a virtual DC from a DC provider and wants the vDC to
connect to their VPN supported by the Service Provider. In this
case, the VPN service provider configures a VPN for each customer at
the PE near to DC provider location, i.e. PE3 in Figure 1. The PE
Yong & Hares Expires April 21, 2013 [Page 10]
Internet-Draft NVO3 and VPN Gap October 2012
has a physical interface connecting DC Gateway Router (DCGR). The DC
provider constructs an NVO3 based vDC for each enterprise customer.
.----------------------.
| IP/MPLS Network |
*-------* | | *-------*
| +--+ AC +----+ iBGP +----+ AC +--+ |
| |CE+----| PE1|............| PE2|----+CE| |
|E-A.+--+ +----+ LSP Tunnel +----+ +--+ E-A|
|Site 1 | /| . . |\ |Site 2 |
*-------* / | . . | \ *-------*
/ | +---+ | \
AC/ | |PE3| | \AC
/ .--------+-+-+---------. \
/ eBGP |AC(s) \
/ | \
*-+--+--* *-------+-+--+-------* *-+--+--*
| |CE| | | |DCGR| | | |CE| |
| +--+ | | +/--\+ | | +--+ |
|E-B | | .../. .\... | | E-B |
|Site 1 | | . V . . V . | |Site 2 |
+-------+ | . D . . D . | *-------*
| . C . . C . |
| . a . . b . | Date Center
| ..... ..... | Provider Site
*--------------------*
Figure 1 L3VPN for Enterprise and Provider DC Interconnection
This configuration can be seen as the combination of section 5.1 and
section 5.2. The VPN at PE1 and PE2 connects to the enterprise
customer physical networks; while the VPN at PE3 connects to a DC
provider NVO3 virtual network. Using option A [RFC4364], the VPN
does not have the visibility of DC Provider physical network. The
overlay tunnel terminates at the DCGR. Note that Option B and C may
apply to this case with additional inter-tenant configuration. In
addition, the VPN policy may be used for controlling routes and
traffic in inter-tenant connectivity.
This configuration provides the connectivity among the enterprise
networks and its vDC in the DC provider location and isolates the
VPN from the DC provider infrastructure, WAN infrastructure, as well
as other virtual networks in the DC provider location. Note that it
Yong & Hares Expires April 21, 2013 [Page 11]
Internet-Draft NVO3 and VPN Gap October 2012
is possible that vDC span across multiple DC provider locations. One
VPN can be used to interconnect them all.
For this configuration, the VPN Service Provider has to work with
both an enterprise customer and a DC provider to provision the VPN
properly at each PE. The VPN protocol extension for this is the same
as in section 5.2.
6. Operator Aspects
The L2VPN and L3VPN were developed for a Metro or Wide Area Networks
(MAN and WAN). The architecture model fits the Service Provider
business model well and both are well-known services and have been
deployed widely in Service Provider networks.
The NVO3 is driven by DC operators for a quicker and easier
constructing a tenant IT application in a Data Center. A tenant IT
application requires the capability to form a virtual communication
domain for a highly distributed closed user groups. The NVO3 has
some common characteristics as VPN's such as virtualization and
encapsulation but also has some unique characteristics such as 1)
the same hardware for both switching and end-systems; 2) end-system
mobility. In addition, DC operator aims on NVO3 potentials for
supporting a new IT application.
From the operation perspective, the NVO3 aims that the virtual hosts
and NVE are managed by the same orchestration system and the
underlying network is decoupled from the overlay network and may be
managed by a different orchestration system. However, in the VPN
operation model, PE and P, i.e. the VPNs and underlying networks,
are managed by the same operators; CEs at the customer sites are
managed by different operators and two have the provider-customer
relationship. Furthermore, the creation and remove NVE and VM
placement and move in NVO3 could be very dynamic compared to the
creation of a VPN on a PE. Thus, NVO3 needs a better auto
provisioning software than the command-line interface for the
provisioning.
These distinct areas are significant enough for people to further
study if we should develop a brand new technology for NVO3 or may
evolve the VPN technologies for it and trade-offs in each. Note that
any new IT application may also require WAN VPN technology
enhancement at the same time anyway. For example, the VM mobility
across DCs also requires the VPN on a WAN network to support that
properly.
Yong & Hares Expires April 21, 2013 [Page 12]
Internet-Draft NVO3 and VPN Gap October 2012
It is important for DC operators and SP operators as well as the
people from vendors to work together on the NVO3 solution. It would
be ideal to make the future virtual and overlay networking
technology seamlessly work in DC, WANs, and wireless networks.
7. Security Considerations
The VPN protocol solutions provide the security capability for a
customer and allow many VPN running on one common network
infrastructure. However, the VPN does not have much way to protect
the infrastructure network attacked by the VPN traffic except the
rate limit at the PE. This approach may not apply to NVO3 due to the
VM dynamical placement and move.
If the underlying network uses IP network and NVO3 uses GRE or IP
Tunnel, it makes the security more challenge because of heavy
filtering process [RFC4365].
8. IANA Considerations
The document does not require any IANA action.
9. Acknowledgments
Authors like to thanks Aldrin Isaac, Ivan Pepeinjak, Yakov Rekhter,
John Drake, Joe Halpern, and others on mailing list for their
valuable input.
10. References
10.1. Normative References
[RFC4364] Rosen, E. and Rekhter, Y., "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC4364, February 2006.
[RFC4365] Rosen, E. "Applicability Statement for BGP/MPLS IP Virtual
Private Network (VPNs)", RFC4365, February 2006.
[RFC4379] Kompella, K. and Swallow, G., "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC4379,
February 2006
[RFC4448] Martini, L., etc, "Encapsulation Methods for Transport
Ethernet over MPLS networks", RFC4448, April 2006
Yong & Hares Expires April 21, 2013 [Page 13]
Internet-Draft NVO3 and VPN Gap October 2012
[RFC4577] Rosen, E., Psenak, P., and Pillay-Esnault, P., "OSPF as
the Provider/Customer Edge Protocol for BGP/MPLS IP
Virtual Private Network (VPNs)", RFC4577, Jun 2006
[RFC4664] Andersson, L., "Framework for Layer 2 Virtual Private
Networks (L2VPNs)", RFC4664, September 2006
[RFC4761] Kompella, K. and Rekhter, Y., "virtual Private LAN
Services (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC4761, January 2007
[RFC4762] Lasserre, M. and Kompella, V., "Virtual Private LAN
Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC4762, January 2007
[RFC4797] Rekhter, Y., etc, "Use of Provider Edge to Provider Edge
(PE-PE) Generic Routing Encapsulation (GRE) or IP in
BGP/MPLS IP Virtual Private Networks", RFC4797, January
2007
[RFC5641] McGill, N., "Layer 2 Tunneling Protocol Version 3
(L2TPv3) Extended Circuit Status Values", rfc5641, April
2009.
[RFC6325] Perlman, R., Eastlake, D., and etc, "Routing Bridges
(RBridges): Base Protocol Specification", RFC6325, July
2011
[RFC6329] Fedyk, D., etc, "IS-IS Extension Supporting IEEE 802.1aq
Shorest Path Bridging", RFC6329, April 2012
[PBB] "Standard for Local and Metropolitan Area Networks /
Virtual Bridged Local Area Networks / Amendment 7:
Provider Backbone Bridges, IEEE STD 802.1ah", 2008.
10.2. Informative Reference
[DCBGP] Lapukhov, P., and Premji, A.,, "Using BGP for Routing in
Large-Scale Data Centers", draft-lapukhov-bgp-routing-
large-dc-02, August 2012
[ESYS] Marques,P., "End-System support for BGP-signaled IP/VPNs",
draft-marques-l3vpn-end-system-07, August 2012
[EVPN] Sajassi, A.,"BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn-
evpn-01, July 2012
Yong & Hares Expires April 21, 2013 [Page 14]
Internet-Draft NVO3 and VPN Gap October 2012
[ISSUES] Rekhter, Y., "Network-related VM Mobility Issues", draft-
rekhter-nvo3-vm-mobility-issues-03, October 2012
[LISP] Maino, F., etc "LISP Control Plane for Network
Virtualization Overlays", draft-maino-nvo3-lisp-cp-01,
September 2012
[NVO3PRBM] Narten, T., etc "Problem Statement: Overlays for Network
Virtualization", draft-narten-nvo3-overlay-problem-
statement-04, August 2012
[NVO3FRWK] Lasserre, M., Motin, T., and etc, "Framework for DC
Network Virtualization", draft-lasserre-nvo3-framework-03,
July 2012
[NVO3UCASE] Yong, L., and etc, "Use Case for DC Network
Virtualization Overlays", draft-mity-nvo3-use-case-03,
August 2012
[ONF] Open Network Forum, "Open Flow 1.2",
https://www.opennetworking.org/images/stories/downloads/sp
ecification/openflow-spec-v1.2.pdf, Dec. 2011
[PBB-EVPN] Sajassi, A. et al. "PBB-EVPN", draft-sajassi-l2vpn-pbb-
evpn-03., June 2012.
[SPB-EVPN] Allan, D., etc, "802.1aq and 802.1Qbp Support over EVPN",
draft-allan-l2vpn-spbm-evpn-01, July 2012
[TRILL-EVPN] Sajassi, A., etc, "TRILL-EVPN", draft-ietf-l2vpn-trill-
evpn-00, June 20, 2012
[VRF-LITE] Cisco, "Configuring VRF-lite", http://www.cisco.com
Yong & Hares Expires April 21, 2013 [Page 15]
Internet-Draft NVO3 and VPN Gap October 2012
Authors' Addresses
Lucy Yong
Huawei Technologies (USA)
5340 Legacy Drive
Plano, TX75025
Phone: +1-469-277-5873
Email: lucy.yong@huawei.com
Susan Hares
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara, CA 95050
Phone: +408-330-4581
Email: susan.hares@huawei.com
Yong & Hares Expires April 21, 2013 [Page 16]
