< draft-ietf-nvo3-use-case-02.txt   draft-ietf-nvo3-use-case-03.txt >
skipping to change at page 1, line 13 skipping to change at page 1, line 13
Internet Draft Huawei Internet Draft Huawei
Category: Informational M. Toy Category: Informational M. Toy
Comcast Comcast
A. Isaac A. Isaac
Bloomberg Bloomberg
V. Manral V. Manral
Hewlett-Packard Hewlett-Packard
L. Dunbar L. Dunbar
Huawei Huawei
Expires: January 2014 July 11, 2013 Expires: July 2014 January 8, 2014
Use Cases for DC Network Virtualization Overlays Use Cases for DC Network Virtualization Overlays
draft-ietf-nvo3-use-case-02 draft-ietf-nvo3-use-case-03
Abstract Abstract
This document describes the DC Network Virtualization (NVO3) use This document describes DC Network Virtualization (NVO3) use cases
cases that may be potentially deployed in various data centers and that may be potentially deployed in various data centers and apply
apply to different applications. to different applications.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January, 2014. This Internet-Draft will expire on July, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Conventions used in this document
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].
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Contributors..............................................4 1.1. Contributors..............................................4
1.2. Terminology...............................................4 1.2. Terminology...............................................4
2. Basic Virtual Networks in a Data Center........................4 2. Basic Virtual Networks in a Data Center........................5
3. Interconnecting DC Virtual Network and External Networks.......6 3. Interconnecting DC Virtual Network and External Networks.......6
3.1. DC Virtual Network Access via Internet....................6 3.1. DC Virtual Network Access via Internet....................6
3.2. DC VN and Enterprise Sites interconnected via SP WAN......7 3.2. DC VN and Enterprise Sites interconnected via SP WAN......7
4. DC Applications Using NVO3.....................................8 4. DC Applications Using NVO3.....................................9
4.1. Supporting Multi Technologies and Applications in a DC....9 4.1. Supporting Multi Technologies and Applications in a DC....9
4.2. Tenant Network with Multi-Subnets or across multi DCs.....9 4.2. Tenant Network with Multi-Subnets or across multi DCs.....9
4.3. Virtual Data Center (vDC)................................11 4.3. Virtualized Data Center (vDC)............................11
5. OAM Considerations............................................12 5. OAM Considerations............................................13
6. Summary.......................................................13 6. Summary.......................................................13
7. Security Considerations.......................................14 7. Security Considerations.......................................14
8. IANA Considerations...........................................14 8. IANA Considerations...........................................14
9. Acknowledgements..............................................14 9. Acknowledgements..............................................14
10. References...................................................14 10. References...................................................14
10.1. Normative References....................................14 10.1. Normative References....................................14
10.2. Informative References..................................15 10.2. Informative References..................................15
Authors' Addresses...............................................15 Authors' Addresses...............................................15
1. Introduction 1. Introduction
Server Virtualization has changed IT industry in terms of efficiency, Server Virtualization has changed IT industry in terms of efficiency,
cost, and the speed in providing a new applications and/or services. cost, and the speed in providing a new applications and/or services.
However the problems in today's data center networks hinder the However, today's data center networks have limited support for cloud
support of cloud applications and multi tenant networks [NVO3PRBM]. applications and multi tenant networks.[NVO3PRBM] The goal of DC
The goal of DC Network Virtualization Overlays, i.e. NVO3, is to Network Virtualization Overlays, i.e. NVO3, is to decouple the
decouple the communication among tenant systems from DC physical communication among tenant systems from DC physical networks and to
networks and to allow one physical network infrastructure to provide: allow one physical network infrastructure to provide: 1) multi-
1) traffic isolation among tenant virtual networks over the same tenant virtual networks and traffic isolation among the virtual
physical network; 2) independent address space in each virtual networks over the same physical network; 2) independent address
network and address isolation from the infrastructure's; 3) Flexible spaces in individual virtual networks such as MAC, IP, TCP/UDP etc;
VM placement and move from one server to another without VM address 3) Flexible VM placement including the ability to move from one
and configuration change. These characteristics will help address server to another without requiring VM address and configuration
the issues in today's cloud applications [NVO3PRBM]. change and the ability doing a hot move in which no disruption to
the live application on the VM. These characteristics will help
address the issues in today's cloud applications [NVO3PRBM].
Although NVO3 enables a true network virtualization environment, the Although NVO3 enables a true network virtualization environment, the
NVO3 solution has to address the communication between a virtual NVO3 solution has to address the communication between a virtual
network and a physical network. This is because 1) many DCs that network and a physical network. This is because 1) many DCs that
need to provide network virtualization are currently running over need to provide network virtualization are currently running over
physical networks, the migration will be in steps; 2) a lot of DC physical networks, the migration will be in steps; 2) a lot of DC
applications are served to Internet users which run directly on applications are served to Internet users which run directly on
physical networks; 3) some applications are CPU bound like Big Data physical networks; 3) some applications are CPU bound like Big Data
analytics and may not need the virtualization capability. analytics and may not need the virtualization capability.
skipping to change at page 3, line 50 skipping to change at page 4, line 8
o DC virtual network access from external. A DC provider offers a o DC virtual network access from external. A DC provider offers a
secure DC service to an enterprise customer and/or Internet users. secure DC service to an enterprise customer and/or Internet users.
An enterprise customer may use a traditional VPN provided by a An enterprise customer may use a traditional VPN provided by a
carrier or an IPsec tunnel over Internet connecting to a virtual carrier or an IPsec tunnel over Internet connecting to a virtual
network within a provider DC site. This mainly constitutes DC network within a provider DC site. This mainly constitutes DC
North-South traffic. North-South traffic.
o DC applications or services that may use NVO3. Three scenarios o DC applications or services that may use NVO3. Three scenarios
are described: 1) use NVO3 and other network technologies to are described: 1) use NVO3 and other network technologies to
build a tenant network; 2) construct several virtual networks as build a tenant network; 2) construct several virtual networks as
a tenant network; 3) apply NVO3 to a virtual DC (vDC) service. a tenant network; 3) apply NVO3 to a virtualized DC (vDC).
The document uses the architecture reference model defined in The document uses the architecture reference model defined in
[NVO3FRWK] to describe the use cases. [NVO3FRWK] to describe the use cases.
1.1. Contributors 1.1. Contributors
Vinay Bannai Vinay Bannai
PayPal PayPal
2211 N. First St, 2211 N. First St,
San Jose, CA 95131 San Jose, CA 95131
skipping to change at page 4, line 47 skipping to change at page 5, line 8
NAT: Network Address Translation NAT: Network Address Translation
VIRB: Virtual Integrated Routing/Bridging VIRB: Virtual Integrated Routing/Bridging
Note that a virtual network in this document is an overlay virtual Note that a virtual network in this document is an overlay virtual
network instance. network instance.
2. Basic Virtual Networks in a Data Center 2. Basic Virtual Networks in a Data Center
A virtual network may exist within a DC. The network enables a A virtual network may exist within a DC. The network enables a
communication among Tenant Systems (TSs) that are in a Closed User communication among Tenant Systems (TS). A TS may be a physical
Group (CUG). A TS may be a physical server/device or a virtual server/device or a virtual machine (VM) on a server. A network
machine (VM) on a server. The network virtual edge (NVE) may co- virtual edge (NVE) may be co-located with a TS, i.e. on a same end-
exist with Tenant Systems, i.e. on a same end-device, or exist on a device, or reside on a different device, e.g. a top of rack switch
different device, e.g. a top of rack switch (ToR). A virtual network (ToR). A virtual network has a unique virtual network identifier
has a unique virtual network identifier (may be local or global (may be local or global unique) for an NVE to properly differentiate
unique) for an NVE to properly differentiate it from other virtual it from other virtual networks.
networks.
The TSs attached to the same NVE may belong to the same or different Tenant Systems attached to the same NVE may belong to the same or
virtual network. The multiple CUGs can be constructed in a way so different virtual network. The multiple virtual networks can be
that the policies are enforced when the TSs in one CUG communicate constructed in a way so that the policies are enforced when the TSs
with the TSs in other CUGs. An NVE provides the reachbility for in one virtual network communicate with the TSs in other virtual
Tenant Systems in a CUG, and may also have the policies and provide networks. An NVE provides tenant traffic forwarding/encapsulation
the reachbility for Tenant Systems in different CUGs (See section and obtains tenant systems reachability information from Network
4.2). Furthermore in a DC operators may construct many tenant Virtualization Authority (NVA)[NVO3ARCH]. Furthermore in a DC
networks that have no communication in between at all. In this case, operators may construct many tenant networks that have no
each tenant network may use its own address space. One tenant communication in between at all. In this case, each tenant network
may use its own address spaces such as MAC and IP. One tenant
network may have one or more virtual networks. network may have one or more virtual networks.
A Tenant System may also be configured with multiple addresses and A Tenant System may also be configured with one or multiple
participate in multiple virtual networks, i.e. use different address addresses and participate in multiple virtual networks, i.e. use the
in different virtual networks. For examples, a TS may be a NAT GW; same or different address in different virtual networks. For
or a firewall for multiple CUGs. examples, a TS may be a NAT GW or a firewall and connect to more
than one virtual network.
Network Virtualization Overlay in this context means that a virtual Network Virtualization Overlay in this context means that a virtual
network is implemented in overlay, i.e. traffic from an NVE to network is implemented with an overlay technology, i.e. traffic from
another is sent via a tunnel.[NVO3FMWK] This architecture decouples an NVE to another is sent via a tunnel between a pair of
tenant system address scheme and configuration from the NVEs.[NVO3FRWK] This architecture decouples tenant system address
infrastructure's, which brings a great flexibility for VM placement scheme and configuration from the infrastructure's, which brings a
and mobility. This also makes the transit nodes in the great flexibility for VM placement and mobility. This also makes the
infrastructure not aware of the existence of the virtual networks. transit nodes in the infrastructure not aware of the existence of
One tunnel may carry the traffic belonging to different virtual the virtual networks. One tunnel may carry the traffic belonging to
networks; a virtual network identifier is used for traffic different virtual networks; a virtual network identifier is used for
demultiplexing. traffic demultiplexing.
A virtual network may be an L2 or L3 domain. The TSs attached to an A virtual network may be an L2 or L3 domain. The TSs attached to an
NVE may belong to different virtual networks that may be in L2 or NVE may belong to different virtual networks that may be in L2 or
L3. A virtual network may carry unicast traffic and/or L3. A virtual network may carry unicast traffic and/or
broadcast/multicast/unknown traffic from/to tenant systems. There broadcast/multicast/unknown traffic from/to tenant systems. There
are several ways to transport BUM traffic.[NVO3MCAST] are several ways to transport BUM traffic.[NVO3MCAST]
It is worth to mention two distinct cases here. The first is that It is worth to mention two distinct cases here. The first is that
TSs and NVE are co-located on a same end device, which means that TSs and NVE are co-located on a same end device, which means that
the NVE can be made aware of the TS state at any time via internal the NVE can be made aware of the TS state at any time via internal
API. The second is that TSs and NVE are remotely connected, i.e. API. The second is that TSs and NVE are remotely connected, i.e.
connected via a switched network or point-to-point link. In this connected via a switched network or point-to-point link. In this
case, a protocol is necessary for NVE to know TS state. case, a protocol is necessary for NVE to know TS state.
One virtual network may connect many TSes that attach to many One virtual network may connect many TSs that attach to many
different NVEs. TS dynamic placement and mobility results in different NVEs. TS dynamic placement and mobility results in
frequent changes in the TS and NVE bindings. The TS reachbility frequent changes in the TS and NVE bindings. The TS reachbility
update mechanism need be fast enough to not cause any service update mechanism need be fast enough to not cause any service
interruption. The capability of supporting many TSs in a virtual interruption. The capability of supporting many TSs in a virtual
network and many more virtual networks in a DC is critical for NVO3 network and many more virtual networks in a DC is critical for NVO3
solution. solution.
If a virtual network spans across multiple DC sites, one design is If a virtual network spans across multiple DC sites, one design is
to allow the network seamlessly to span across the sites without DC to allow the network seamlessly to span across the sites without DC
gateway routers' termination. In this case, the tunnel between a gateway routers' termination. In this case, the tunnel between a
skipping to change at page 7, line 42 skipping to change at page 8, line 6
An enterprise company may lease the VM and storage resources hosted An enterprise company may lease the VM and storage resources hosted
in the 3rd party DC to run its applications. For example, the rd company may run its web applications at 3 party sites but run in the 3rd party DC to run its applications. For example, the rd company may run its web applications at 3 party sites but run
backend applications in own DCs. The Web applications and backend rd applications need to communicate privately. The 3 party DC may backend applications in own DCs. The Web applications and backend rd applications need to communicate privately. The 3 party DC may
construct one or more virtual networks to connect all VMs and construct one or more virtual networks to connect all VMs and
storage running the Enterprise Web applications. The company may buy storage running the Enterprise Web applications. The company may buy
a p2p private tunnel such as VPWS from a SP to interconnect its site a p2p private tunnel such as VPWS from a SP to interconnect its site
and the virtual network at the 3rd party site. A protocol is and the virtual network at the 3rd party site. A protocol is
necessary for exchanging the reachability between two peering points necessary for exchanging the reachability between two peering points
and the traffic are carried over the tunnel. If an enterprise has and the traffic are carried over the tunnel. If an enterprise has
multiple sites, it may buy multiple p2p tunnels to form a mesh rd interconnection among the sites and the 3 party site. This requires multiple sites, it may buy multiple p2p tunnels to form a mesh
each site peering with all other sites for route distribution. interconnection among the sites and the third party site. This
requires each site peering with all other sites for route
distribution.
Another way to achieve multi-site interconnection is to use Service Another way to achieve multi-site interconnection is to use Service
Provider (SP) VPN services, in which each site only peers with SP PE Provider (SP) VPN services, in which each site only peers with SP PE
site. A DC Provider and VPN SP may build a DC virtual network (VN) site. A DC Provider and VPN SP may build a DC virtual network (VN)
and VPN independently. The VPN interconnects several enterprise and VPN independently. The VPN interconnects several enterprise
sites and the DC virtual network at DC site, i.e. VPN site. The DC sites and the DC virtual network at DC site, i.e. VPN site. The DC
VN and SP VPN interconnect via a local link or a tunnel. The control VN and SP VPN interconnect via a local link or a tunnel. The control
plan interconnection options are described in RFC4364 [RFC4364]. In plan interconnection options are described in RFC4364 [RFC4364]. In
Option A with VRF-LITE [VRF-LITE], both DC GW and SP PE maintain a Option A with VRF-LITE [VRF-LITE], both DC GW and SP PE maintain a
routing/forwarding table, and perform the table lookup in forwarding. routing/forwarding table, and perform the table lookup in forwarding.
skipping to change at page 9, line 35 skipping to change at page 9, line 42
encapsulation/decapsulation and may also perform address mapping or encapsulation/decapsulation and may also perform address mapping or
translation, and etc. translation, and etc.
A data center may be also constructed with multi-tier zones. Each A data center may be also constructed with multi-tier zones. Each
zone has different access permissions and run different applications. zone has different access permissions and run different applications.
For example, the three-tier zone design has a front zone (Web tier) For example, the three-tier zone design has a front zone (Web tier)
with Web applications, a mid zone (application tier) with service with Web applications, a mid zone (application tier) with service
applications such as payment and booking, and a back zone (database applications such as payment and booking, and a back zone (database
tier) with Data. External users are only able to communicate with tier) with Data. External users are only able to communicate with
the Web application in the front zone. In this case, the the Web application in the front zone. In this case, the
communication between the zones MUST pass through the security communication between the zones must pass through the security
GW/firewall. One virtual network may be configured in each zone and GW/firewall. One virtual network may be configured in each zone and
a GW is used to interconnect two virtual networks. If individual a GW is used to interconnect two virtual networks. If individual
zones use the different implementations, the GW needs to support zones use the different implementations, the GW needs to support
these implementations as well. these implementations as well.
4.2. Tenant Network with Multi-Subnets or across multi DCs 4.2. Tenant Network with Multi-Subnets or across multi DCs
A tenant network may contain multiple subnets. The DC physical A tenant network may contain multiple subnets. The DC physical
network needs support the connectivity for many tenant networks. The network needs support the connectivity for many tenant networks. The
inter-subnets policies may be placed at some designated gateway inter-subnets policies may be placed at some designated gateway
skipping to change at page 10, line 32 skipping to change at page 10, line 38
Bridging (VIRB) is used between L2VNI and L3VNI on NVE5 and NVE6, Bridging (VIRB) is used between L2VNI and L3VNI on NVE5 and NVE6,
respectively. The L2VNI is the MAC/NVE mapping table and the L3VNI respectively. The L2VNI is the MAC/NVE mapping table and the L3VNI
is the IP prefix/NVE mapping table. A packet to the NVE5 from L2VNa is the IP prefix/NVE mapping table. A packet to the NVE5 from L2VNa
will be decapsulated and converted into an IP packet and then will be decapsulated and converted into an IP packet and then
encapsulated and sent to the site Z. The policies can be checked at encapsulated and sent to the site Z. The policies can be checked at
VIRB. VIRB.
Note that the L2VNa, L2VNz, and L3VNx in Figure 2 are overlay Note that the L2VNa, L2VNz, and L3VNx in Figure 2 are overlay
virtual networks. virtual networks.
NVE5/DCGW+------------+ +-----------+NVE6/DCGW NVE5/DCGW+------------+ +-----------+ NVE6/DCGW
| +-----+ | '''''''''''''''' | +-----+ | | +-----+ | '''''''''''''''' | +-----+ |
| |L3VNI+----+' L3VNx '+---+L3VNI| | | |L3VNI+----+' L3VNx '+---+L3VNI| |
| +--+--+ | '''''''''''''''' | +--+--+ | | +--+--+ | '''''''''''''''' | +--+--+ |
| |VIRB | | VIRB| | | |VIRB | | VIRB| |
| +--+---+ | | +---+--+ | | +--+---+ | | +---+--+ |
| |L2VNIs| | | |L2VNIs| | | |L2VNIs| | | |L2VNIs| |
| +--+---+ | | +---+--+ | | +--+---+ | | +---+--+ |
+----+-------+ +------+----+ +----+-------+ +------+----+
''''|'''''''''' ''''''|''''''' ''''|'''''''''' ''''''|'''''''
' L2VNa ' ' L2VNz ' ' L2VNa ' ' L2VNz '
skipping to change at page 11, line 12 skipping to change at page 11, line 17
| ++---++ | | ++---++ | | ++---++ | | ++---++ | | ++---++ | | ++---++ | | ++---++ | | ++---++ |
+--+---+--+ +--+---+--+ +--+---+--+ +--+---+--+ +--+---+--+ +--+---+--+ +--+---+--+ +--+---+--+
|...| |...| |...| |...| |...| |...| |...| |...|
Tenant Systems Tenant Systems Tenant Systems Tenant Systems
DC Site A DC Site Z DC Site A DC Site Z
Figure 2 Tenant Virtual Network with Bridging/Routing Figure 2 Tenant Virtual Network with Bridging/Routing
4.3. Virtual Data Center (vDC) 4.3. Virtualized Data Center (vDC)
Enterprise DC's today may deploy routers, switches, and network Enterprise DC's today may deploy routers, switches, and network
appliance devices to construct its internal network, DMZ, and appliance devices to construct its internal network, DMZ, and
external network access and have many servers and storage running external network access and have many servers and storage running
various applications. A DC Provider may offer a virtual DC service various applications. A DC Provider may construct a virtualized DC
to enterprise customers. A vDC provides the same capability as a over its DC infrastructure and offer a virtual DC service to
enterprise customers. A vDC provides the same capability as a
physical DC. A customer manages what and how applications to run in physical DC. A customer manages what and how applications to run in
the vDC. Instead of using many hardware devices to do it, with the the vDC. Instead of using many hardware devices to do it, with the
network virtualization overlay technology, DC operators may build network virtualization overlay technology, DC operators may build
such vDCs on top of a common DC infrastructure for many such such vDCs on top of a common DC infrastructure for many such
customers and run network service application per vDC. The network customers and offer network service functions to a vDC. The network
service applications may include firewall, DNS, load balancer, service functions may include firewall, DNS, load balancer, gateway,
gateway, etc. The network virtualization overlay further enables etc. The network virtualization overlay further enables potential
potential for vDC mobility when a customer moves to different for vDC mobility when a customer moves to different locations
locations because vDC configuration is decouple from the because vDC configuration is decouple from the infrastructure
infrastructure network. network.
Figure 3 below illustrates one scenario. For the simple Figure 3 below illustrates one scenario. For the simple
illustration, it only shows the L3 VN or L2 VN as virtual routers or illustration, it only shows the L3 VN or L2 VN as virtual routers or
switches. In this case, DC operators create several L2 VNs (L2VNx, switches. In this case, DC operators create several L2 VNs (L2VNx,
L2VNy, L2VNz) in Figure 3 to group the tenant systems together per L2VNy, L2VNz) in Figure 3 to group the tenant systems together per
application basis, create one L3 VN, e.g. VNa for the internal application basis, create one L3 VN, e.g. VNa for the internal
routing. A net device (may be a VM or server) runs firewall/gateway routing. A net device (may be a VM or server) runs firewall/gateway
applications and connects to the L3VNa and Internet. A load balancer applications and connects to the L3VNa and Internet. A load balancer
(LB) is used in L2 VNx. A VPWS p2p tunnel is also built between the (LB) is used in L2 VNx. A VPWS p2p tunnel is also built between the
gateway and enterprise router. Enterprise customer runs gateway and enterprise router. Enterprise customer runs
skipping to change at page 12, line 10 skipping to change at page 12, line 16
only and which by both intranet and extranet and configures the only and which by both intranet and extranet and configures the
proper security policy and gateway function. Furthermore a customer proper security policy and gateway function. Furthermore a customer
may want multi-zones in a vDC for the security and/or set different may want multi-zones in a vDC for the security and/or set different
QoS levels for the different applications. QoS levels for the different applications.
This use case requires the NVO3 solution to provide the DC operator This use case requires the NVO3 solution to provide the DC operator
an easy way to create a VN and NVEs for any design and to quickly an easy way to create a VN and NVEs for any design and to quickly
assign TSs to VNIs on a NVE they attach to, easily to set up virtual assign TSs to VNIs on a NVE they attach to, easily to set up virtual
topology and place or configure policies on an NVE or VMs that run topology and place or configure policies on an NVE or VMs that run
net services, and support VM mobility. Furthermore a DC operator net services, and support VM mobility. Furthermore a DC operator
and/or customer should be able to view the tenant network topology and/or customer should be able to view the vDC topology and access
and configure the tenant network functions. DC provider may further individual virtual components in the vDC. Either DC provider or
let a tenant to manage the vDC itself. tenant can provision virtual components in the vDC. It is desirable
to automate the provisioning process and have programmability.
Internet ^ Internet Internet ^ Internet
| |
^ +--+---+ ^ +--+---+
| | GW | | | GW |
| +--+---+ | +--+---+
| | | |
+-------+--------+ +--+---+ +-------+--------+ +--+---+
|FireWall/Gateway+--- VPN-----+router| |Firewall/Gateway+--- VPN-----+router|
+-------+--------+ +-+--+-+ +-------+--------+ +-+--+-+
| | | | | |
...+.... |..| ...+.... |..|
+-------: L3 VNa :---------+ LANs +-------: L3 VNa :---------+ LANs
+-+-+ ........ | +-+-+ ........ |
|LB | | | Enterprise Site |LB | | | Enterprise Site
+-+-+ | | +-+-+ | |
...+... ...+... ...+... ...+... ...+... ...+...
: L2VNx : : L2VNy : : L2VNx : : L2VNx : : L2VNy : : L2VNx :
....... ....... ....... ....... ....... .......
skipping to change at page 14, line 26 skipping to change at page 14, line 34
volume of traffic to overload DC underlying network. The NVO3 volume of traffic to overload DC underlying network. The NVO3
solution has to address these issues. solution has to address these issues.
8. IANA Considerations 8. IANA Considerations
This document does not request any action from IANA. This document does not request any action from IANA.
9. Acknowledgements 9. Acknowledgements
Authors like to thank Sue Hares, Young Lee, David Black, Pedro Authors like to thank Sue Hares, Young Lee, David Black, Pedro
Marques, Mike McBride, David McDysan, Randy Bush, and Uma Chunduri Marques, Mike McBride, David McDysan, Randy Bush, Uma Chunduri, and
for the review, comments, and suggestions. Eric Gray for the review, comments, and suggestions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
[IEEE 802.1ag] "Virtual Bridged Local Area Networks - Amendment 5: [IEEE 802.1ag] "Virtual Bridged Local Area Networks - Amendment 5:
Connectivity Fault Management", December 2007. Connectivity Fault Management", December 2007.
[ITU-T G.8013/Y.1731] OAM Functions and Mechanisms for Ethernet [ITU-T G.8013/Y.1731] OAM Functions and Mechanisms for Ethernet
based Networks, 2011. based Networks, 2011.
[ITU-T Y.1564] "Ethernet service activation test methodology", 2011. [ITU-T Y.1564] "Ethernet service activation test methodology", 2011.
skipping to change at page 15, line 15 skipping to change at page 15, line 19
[RFC4301] Kent, S., "Security Architecture for the Internet [RFC4301] Kent, S., "Security Architecture for the Internet
Protocol", rfc4301, December 2005 Protocol", rfc4301, December 2005
[RFC5880] Katz, D. and Ward, D., "Bidirectional Forwarding Detection [RFC5880] Katz, D. and Ward, D., "Bidirectional Forwarding Detection
(BFD)", rfc5880, June 2010. (BFD)", rfc5880, June 2010.
10.2. Informative References 10.2. Informative References
[NVGRE] Sridharan, M., "NVGRE: Network Virtualization using Generic [NVGRE] Sridharan, M., "NVGRE: Network Virtualization using Generic
Routing Encapsulation", draft-sridharan-virtualization- Routing Encapsulation", draft-sridharan-virtualization-
nvgre-02, work in progress. nvgre-03, work in progress.
[NVO3ARCH] Black, D., et al, "An Architecture for Overlay Networks
(NVO3)", draft-ietf-nvo3-arch-00, work in progress.
[NVO3PRBM] Narten, T., et al "Problem Statement: Overlays for [NVO3PRBM] Narten, T., et al "Problem Statement: Overlays for
Network Virtualization", draft-ietf-nvo3-overlay-problem- Network Virtualization", draft-ietf-nvo3-overlay-problem-
statement-03, work in progress. statement-04, work in progress.
[NVO3FRWK] Lasserre, M., Motin, T., and et al, "Framework for DC [NVO3FRWK] Lasserre, M., Motin, T., and et al, "Framework for DC
Network Virtualization", draft-ietf-nvo3-framework-03, Network Virtualization", draft-ietf-nvo3-framework-04,
work in progress. work in progress.
[NVO3MCAST] Ghanwani, A., "Multicast Issues in Networks Using NVO3", [NVO3MCAST] Ghanwani, A., "Multicast Issues in Networks Using NVO3",
draft-ghanwani-nvo3-mcast-issues-00, work in progress. draft-ghanwani-nvo3-mcast-issues-00, work in progress.
[VRF-LITE] Cisco, "Configuring VRF-lite", http://www.cisco.com [VRF-LITE] Cisco, "Configuring VRF-lite", http://www.cisco.com
[VXLAN] Mahalingam,M., Dutt, D., etc "VXLAN: A Framework for [VXLAN] Mahalingam,M., Dutt, D., etc "VXLAN: A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", draft-mahalingam-dutt-dcops-vxlan-03.txt, work Networks", draft-mahalingam-dutt-dcops-vxlan-06.txt, work
in progress. in progress.
Authors' Addresses Authors' Addresses
Lucy Yong Lucy Yong
Huawei Technologies,
5340 Legacy Dr.
Plano, TX 75025
Phone: +1-469-277-5837 Phone: +1-918-808-1918
Email: lucy.yong@huawei.com Email: lucy.yong@huawei.com
Mehmet Toy Mehmet Toy
Comcast Comcast
1800 Bishops Gate Blvd., 1800 Bishops Gate Blvd.,
Mount Laurel, NJ 08054 Mount Laurel, NJ 08054
Phone : +1-856-792-2801 Phone : +1-856-792-2801
E-mail : mehmet_toy@cable.comcast.com E-mail : mehmet_toy@cable.comcast.com
Aldrin Isaac Aldrin Isaac
Bloomberg Bloomberg
E-mail: aldrin.isaac@gmail.com E-mail: aldrin.isaac@gmail.com
Vishwas Manral Vishwas Manral
Hewlett-Packard Corp. Hewlett-Packard Corp.
3000 Hanover Street, Building 20C 3000 Hanover Street, Building 20C
Palo Alto, CA 95014 Palo Alto, CA 95014
Phone: 650-857-5501 Phone: 650-857-5501
 End of changes. 32 change blocks. 
89 lines changed or deleted 88 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/