< draft-mity-nvo3-use-case-03.txt   draft-mity-nvo3-use-case-04.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: February 2013 August 30, 2012 Expires: April 2013 October 22, 2012
Use Cases for DC Network Virtualization Overlays Use Cases for DC Network Virtualization Overlays
draft-mity-nvo3-use-case-03 draft-mity-nvo3-use-case-04
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 40 skipping to change at page 1, line 40
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 February, 2013. This Internet-Draft will expire on April, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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. respect to this document.
Abstract Abstract
This draft describes the generalized NVO3 use cases. The work This draft describes the general NVO3 use cases. The work intention
intention is to help validate the NVO3 framework and requirements as is to help validate the NVO3 framework and requirements as along
along with the development of the solutions. with the development of the solutions.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Terminology....................................................4 2. Terminology....................................................4
3. Virtual Networks in a Data Center..............................4 3. Basic Virtual Networks in a Data Center........................4
4. Interconnecting DC Virtual Network and External Networks.......6 4. Interconnecting DC Virtual Network and External Networks.......6
4.1. DC Virtual Network Access via Internet....................6 4.1. DC Virtual Network Access via Internet....................6
4.2. DC Virtual Network and WAN VPN Interconnection............7 4.2. DC Virtual Network and WAN VPN Interconnection............7
5. DC Applications Using NVO3.....................................9 5. DC Applications Using NVO3.....................................9
5.1. Supporting Multi Technologies in a Data Center............9 5.1. Supporting Multi Technologies in a Data Center............9
5.2. Tenant Virtual Network with Bridging/Routing.............10 5.2. Tenant Virtual Network with Bridging/Routing.............10
5.3. Virtual Data Center......................................11 5.3. Virtual Data Center (VDC)................................11
5.4. Federating NV03 Domains..................................13
6. OAM Considerations............................................13 6. OAM Considerations............................................13
7. Summary.......................................................13 7. Summary.......................................................13
8. Security Considerations.......................................14 8. Security Considerations.......................................14
9. IANA Considerations...........................................14 9. IANA Considerations...........................................14
10. Acknowledgements.............................................14 10. Acknowledgements.............................................14
11. References...................................................14 11. References...................................................15
11.1. Normative References....................................14 11.1. Normative References....................................15
11.2. Informative References..................................15 11.2. Informative References..................................15
Authors' Addresses...............................................16 Authors' Addresses...............................................16
1. Introduction 1. Introduction
Compute Virtualization has dramatically and quickly changed IT Compute Virtualization has dramatically and quickly changed IT
industry in terms of efficiency, cost, and the speed in providing a industry in terms of efficiency, cost, and the speed in providing a
new applications and/or services. However the problems in today's new applications and/or services. However the problems in today's
data center hinder the support of an elastic cloud service and data center hinder the support of an elastic cloud service and
dynamic virtual tenant networks [NVO3PRBM]. The goal of DC Network dynamic virtual tenant networks [NVO3PRBM]. The goal of DC Network
Virtualization Overlays, i.e. NVO3, is to decouple the end systems Virtualization Overlays, i.e. NVO3, is to decouple a communication
(VMs) and DC physical networks and to allow the network among tenant end systems (VMs) from DC physical networks and to
infrastructure to provide: 1) traffic isolation among one virtual allow the network infrastructure to provide: 1) traffic isolation
network and another; 2) independent address space in each virtual among one virtual network and another; 2) independent address space
network and address isolation from the infrastructure's; 3) VM in each virtual network and address isolation from the
placement and move from one server to another without any physical infrastructure's; 3) Flexible VM placement and move from one server
network limitation. These characteristics will help address the to another without any physical network limitation. These
issues in the data centers. characteristics will help address the issues in the data centers.
Although NVO3 may enable a true virtual environment where VMs and Although NVO3 may enable a true virtual environment where VMs and
net service appliances communicate, the NVO3 solution has to address net service appliances communicate, the NVO3 solution has to address
how to communicate between a virtual network and a physical network. how to communicate between a virtual network and a physical network.
This is because 1) many traditional DCs exist and will not disappear This is because 1) many traditional DCs exist and will not disappear
any time soon; 2) a lot of DC applications serve to Internet and/or any time soon; 2) a lot of DC applications serve to Internet and/or
cooperation users; 3) some applications like Big Data analytics cooperation users; 3) some applications like Big Data analytics
which are CPU bound may not want to the virtualization capability. which are CPU bound may not want the virtualization capability.
This document is to describe generalized NVO3 use cases in various This document is to describe general NVO3 use cases that apply to
data center networks to make sure the future framework and solutions various data center networks to ensure nvo3 framework and solutions
can meet the demand. Three types of the use cases are: can meet the demands. Three types of the use cases are:
o A virtual network connects many tenant end systems within a Data o A virtual network connects many tenant end systems within a Data
Center and form one L2 or L3 communication domain. A virtual Center and form one L2 or L3 communication domain. A virtual
network segregates its traffic from others and allows the VMs in network segregates its traffic from others and allows the VMs in
the network moving from one server to another. The case may be the network moving from one server to another. The case may be
used for DC internal applications that constitute the DC East- used for DC internal applications that constitute the DC East-
West traffic. West traffic.
o A DC provider offers a secure DC service to an enterprise o A DC provider offers a secure DC service to an enterprise
customer and/or Internet users. In these cases, the enterprise customer and/or Internet users. In these cases, the enterprise
skipping to change at page 4, line 32 skipping to change at page 4, line 32
CPE: Customer Premise Equipment CPE: Customer Premise Equipment
DNS: Domain Name Service DNS: Domain Name Service
DMZ: DeMilitarized Zone DMZ: DeMilitarized Zone
NAT: Network Address Translation NAT: Network Address Translation
VNIF: Internal Virtual Network Interconnection Interface VNIF: Internal Virtual Network Interconnection Interface
3. Virtual Networks in a Data Center 3. Basic Virtual Networks in a Data Center
A tenant virtual network may exist within a DC. The network A virtual network may exist within a DC. The network enables a
interconnects many tenant end systems (ESs) which can be hosted by communication among tenant end systems (TESs) that are in a Closed
physical servers or virtual machines (VMs). The network enables the User Group (CUG). A TES may be a physical server or virtual machine
communication among the ESs that are considered as Closed User (VM) on a server. A virtual network has a unique virtual network
Groups (CUG). A virtual network has a unique virtual network identifier (may be local or global unique) for switches/routers to
identifier for switches/routers to properly differentiate them from properly differentiate it from other virtual networks. The CUGs are
virtual networks. The Closed User Groups are formed so that proper formed so that proper policies can be applied when the TESs in one
policies can be applied when the ESs in one CUG communicate with the CUG communicate with the TESs in other CUGs.
ESs in other CUGs.
Figure 1 depicts this case by using the framework model. [NVO3FRWK] Figure 1 depicts this case by using the framework model. [NVO3FRWK]
NVE1 and NVE2 are two network virtual edges and each may exist on a NVE1 and NVE2 are two network virtual edges and each may exist on a
server or ToR. Each NVE may be the members of multiple virtual server or ToR. Each NVE may be the member of one or more virtual
networks that may have different topologies and run at L2 or L3 networks. Each virtual network may be L2 or L3 basis. In this
individually. In this illustration, three virtual networks with VN illustration, three virtual networks with VN context Ta, Tn, and Tm
context Ta, Tn, and Tm are shown. The VNIa terminates on both NVE1 are shown. The VN 'Ta' terminates on both NVE1 and NVE2; The VN 'Tn'
and NVE2; The VNIn terminates on NVE1 and the VNIm at NVE2 only. terminates on NVE1 and the VN 'Tm' at NVE2 only. If an NVE is a
Each NVE has one overlay module to perform frame member of a VN, one or more virtual network instances (VNI) (i.e.
encapsulation/decapsulation and tunneling initiation/termination. In routing and forwarding table) exist on the NVE. Each NVE has one
this scenario, a tunnel between NVE1 and NVE2 is necessary for the overlay module to perform frame encapsulation/decapsulation and
virtual network Ta. Note that it is possible that one TES tunneling initiation/termination. In this scenario, a tunnel between
participates in more than one virtual network via one VAP for each; NVE1 and NVE2 is necessary for the virtual network Ta.
further if individual virtual networks use different address spaces,
the TES participating in them will be configured with multiple
addresses as well. A TES as a gateway is an example.
A VNI on an NVE is a forwarding table that caches and/or maintains A TES attaches to a virtual network (VN) via a virtual access point
the mapping of an end system and its attached NVE. The table entry (VAP) on an NVE. One TES may participate in one or more virtual
may be updated by the control plane or data plane or the combination networks via VAPs; one NVE may be configured with multiple VAPs for
of both. A TES associates to one VNI via a VAP. One tenant virtual a VN. Furthermore if individual virtual networks use different
network may terminate on many NVEs and interconnect several address spaces, the TES participating in all of them will be
thousands of TESs, the capability of supporting a lot of TESs per configured with multiple addresses as well. A TES as a gateway is an
tenant instance and TES mobility is critical for NVO3 solution no example for this. In addition, multiple TESes may use one VAP to
matter where an NVE resides. attach to a VN. For example, VMs are on a server and NVE is on ToR,
some VMs may attach to NVE via one VLAN.
A VNI on an NVE is a routing and forwarding table that caches and/or
maintains the mapping of a tenant end system and its attached NVE.
The table entry may be updated by the control plane or data plane or
management plane. It is possible that an NVE has more than one VNIs
associated with a VN.
+------- L3 Network ------+ +------- L3 Network ------+
| Tunnel Overlay | | Tunnel Overlay |
+------------+--------+ +--------+-------------+ +------------+--------+ +--------+-------------+
| +----------+------+ | | +------+----------+ | | +----------+------+ | | +------+----------+ |
| | Overlay Module | | | | Overlay Module | | | | Overlay Module | | | | Overlay Module | |
| +---+---------+---+ | | +--+----------+---+ | | +---+---------+---+ | | +--+----------+---+ |
| |Ta |Tn | | |Ta |Tm | | |Ta |Tn | | |Ta |Tm |
| +--+---+ +--+---+ | | +-+----+ +--+---+ | | +--+---+ +--+---+ | | +-+----+ +--+---+ |
| | VNIa |..| VNIn | | | | VNIa |..| VNIm | | | | VNIa |..| VNIn | | | | VNIa |..| VNIm | |
NVE1 | ++----++ ++----++ | | ++----++ ++----++ | NVE2 NVE1 | ++----++ ++----++ | | ++----++ ++----++ | NVE2
| |VAPs| |VAPs| | | |VAPs| |VAPs| | | |VAPs| |VAPs| | | |VAPs| |VAPs| |
+---+----+----+----+--+ +---+----+----+----+---+ +---+----+----+----+--+ +---+----+----+----+---+
| | | | | | | | | | | | | | | |
------+----+----+----+------ -----+----+----+----+----- ------+----+----+----+------ -----+----+----+----+-----
| .. | | .. | Tenant | .. | | .. | | .. | | .. | | .. | | .. |
| | | | Service IF | | | | | | | | | | | |
Tenant End Systems Tenant End Systems Tenant End Systems Tenant End Systems
Figure 1 NVo3 for Tenant End-System interconnection Figure 1 NVo3 for Tenant End-System interconnection
One virtual network may have many NVE members and interconnect
several thousands of TESs (as a matter of policy), the capability of
supporting a lot of TESs per tenant instance and TES mobility is
critical for NVO3 solution no matter where an NVE resides.
It is worth to mention two distinct cases here. The first is when
TES and NVE are co-located on a same physical device, which means
that the NVE is aware of the TES state at any time via internal API.
The second is when TES and NVE are remotely connected, i.e.
connected via a switched network or point-to-point link. In this
case, a protocol is necessary for NVE to know TES state.
Note that if all NVEs are co-located with TESes in a CUG, the
communication in the CUG is in a true virtual environment. If a TES
connects to a NVE remotely, the communication from this TES to other
TESes in the CUG is not in a true virtual environment. The packets
to/from this TES are exposed to a physical network directly, i.e. on
a wire.
Individual virtual networks may use its own address space and the Individual virtual networks may use its own address space and the
space is isolated from DC infrastructure. This eliminates the route space is isolated from DC infrastructure. This eliminates the route
changes in the DC underlying network when VMs move. Note that the changes in the DC underlying network when VMs move. Note that the
NVO3 solutions still have to address VM move in the overlay network, NVO3 solutions still have to address VM move in the overlay network,
i.e. the TES/NVE association change when a VM moves. i.e. the TES/NVE association change when a VM moves.
It is worth mentioning two scenarios regarding to the NVE location. If a virtual network spans across multiple DC sites, one design is
At first an NVE resides on a server, a server manager system such as to allow the corresponding NVO3 instance seamlessly span across
vCenter [VMWARE] is responsible to create NVE/VNs and VMs, and also those sites without DC gateway routers' termination In this case,
responsible to assign a VM to a VN that has unique identification, the tunnel between a pair of NVEs may in turn be tunneled over other
the server software just makes it works properly and securely. intermediate tunnels over the Internet or other WANs, or the intra
Second an NVE resides on physical switch such as ToR, when a server DC and inter DC tunnels are stitched together to form an end-to-end
manger system creates a VM and add it to a VN, the server will send tunnel between two NVEs.
a notification of TES participating in a VN to the local NVE.
[ESYS][VDP] Note that if non-virtualized server is used, local
configuration on NVE is necessary to attach the TES (server) to a VN.
In both cases, when a local NVE notices the new attached TES in a VN,
it will announce the TES to remote NVEs or to a mapping server via a
control plane protocol. In the case of using mapping server, the
remote NVEs can query the server for any TES location and cache it
in the VNI.
If a tenant virtual network spans across multiple DC sites, one
design is to allow the corresponding NVO3 instance seamlessly span
across those sites without DC gateway routers' termination (see
section 4.3). In this case, the tunnel between a pair of NVEs may in
turn be tunneled over other intermediate tunnels over the Internet
or other WANs, or the intra DC and inter DC tunnels are stitched
together to form an end-to-end tunnel between two NVEs.
4. Interconnecting DC Virtual Network and External Networks 4. Interconnecting DC Virtual Network and External Networks
For customers (an enterprise or individuals) who want to utilize the For customers (an enterprise or individuals) who want to utilize the
DC provider's compute and storage resources to run their DC provider's compute and storage resources to run their
applications, they need to access those end systems hosted in a DC applications, they need to access those end systems hosted in a DC
through Carrier WANs or Internet. A DC provider may want to use an through Carrier WANs or Internet. A DC provider may want to use an
NVO3 virtual network to connect these end systems; then it, in turn, NVO3 virtual network to connect these end systems; then it, in turn,
becomes the case of interconnecting DC virtual network and external becomes the case of interconnecting DC virtual network and external
networks. Two cases are described here. networks. Two cases are described here.
skipping to change at page 7, line 47 skipping to change at page 8, line 10
L3VPN between PE1 and PE2 in its IP/MPLS network. An Ethernet L3VPN between PE1 and PE2 in its IP/MPLS network. An Ethernet
Interface physically connects the DC GW and PE2 devices. The local Interface physically connects the DC GW and PE2 devices. The local
VLAN over the Ethernet interface [VRF-LITE] is configured to connect VLAN over the Ethernet interface [VRF-LITE] is configured to connect
the L3VNI/NVE2 and VRF, which makes the interconnection between the the L3VNI/NVE2 and VRF, which makes the interconnection between the
L3 VN in the DC and the L3VPN in IP/MPLS network. An Ethernet L3 VN in the DC and the L3VPN in IP/MPLS network. An Ethernet
Interface may be used between PE1 and CE to connect the L3VPN and Interface may be used between PE1 and CE to connect the L3VPN and
enterprise physical networks. enterprise physical networks.
This configuration allows the enterprise networks communicating to This configuration allows the enterprise networks communicating to
the L3 VN as if its own networks but not communicating with DC the L3 VN as if its own networks but not communicating with DC
provider physical networks as well as not other overlay networks in provider underlying physical networks as well as not other overlay
the DC. The enterprise may use its own address space on the L3 VN. networks in the DC. The enterprise may use its own address space on
the L3 VN. The DC provider can manage the VM and storage assignment
The DC provider can manage the VM and storage assignment to the L3 to the L3 VN for the enterprise customer. The enterprise customer
VN for the enterprise customer. The enterprise customer can can determine and run their applications on the VMs. From the L3 VN
determine and load the applications running on the VMs. From the L3 perspective, an end point in the enterprise location appears as the
VN perspective, an end point in the enterprise location appears as end point associating to the NVE2. The NVE2 on the DC GW has to
the end point associating to the NVE2. The NVE2 on the DC GW has to
perform both the GRE tunnel termination [RFC4797] and the local VLAN perform both the GRE tunnel termination [RFC4797] and the local VLAN
termination and forward the packets in between. The DC provider and termination and forward the packets in between. The DC provider and
Carrier negotiate the local VLAN ID used on the Ethernet interface. Carrier negotiate the local VLAN ID used on the Ethernet interface.
This configuration makes the L3VPN over the WANs only has the This configuration makes the L3VPN over the WANs only has the
reachbility of the L3 VN. It does not have the reachability of DC reachbility to the TES in the L3 VN. It does not have the
physical networks and other VNs in the DC. However, the L3VPN has reachability of DC physical networks and other VNs in the DC.
the reachbility of enterprise networks. Note that both the DC However, the L3VPN has the reachbility of enterprise networks. Note
provider and enterprise may have multiple network locations that both the DC provider and enterprise may have multiple network
connecting to the L3VPN. locations connecting to the L3VPN.
The eBGP protocol can be used between DC GW and PE2 for the route The eBGP protocol can be used between DC GW and PE2 for the route
population in between. In fact, this is like the Option A in population in between. In fact, this is like the Option A in
[RFC4364]. This configuration can work with any NVO3 solution. The [RFC4364]. This configuration can work with any NVO3 solution. The
eBGP, OSPF, or other can be used between PE1 and CE for the route eBGP, OSPF, or other can be used between PE1 and CE for the route
population. population.
+-----------------+ +-------------+ +-----------------+ +-------------+
| +----------+ | | +-------+ | | +----------+ | | +-------+ |
NVE2 | | L3 VNI +---+===========+-+ VRF | | NVE2 | | L3 VNI +---+===========+-+ VRF | |
skipping to change at page 9, line 21 skipping to change at page 9, line 28
If an enterprise only has one location, it may use P2P VPWS [RFC4664] If an enterprise only has one location, it may use P2P VPWS [RFC4664]
or L2TP [RFC5641] to connect one DC provider site. In this case, one or L2TP [RFC5641] to connect one DC provider site. In this case, one
edge connects to a physical network and another edge connects to an edge connects to a physical network and another edge connects to an
overlay network. overlay network.
The interesting feature in this use case is that the L3 VN and The interesting feature in this use case is that the L3 VN and
compute resource are managed by the DC provider. The DC operator can compute resource are managed by the DC provider. The DC operator can
place them at any location without notifying the enterprise and place them at any location without notifying the enterprise and
carrier because the DC physical network is completely isolated from carrier because the DC physical network is completely isolated from
the carrier and enterprise network. Furthermore, the DC operator may the carrier and enterprise network. Furthermore, the DC operator may
move the compute resources assigned to the enterprise from one place move the compute resources assigned to the enterprise from one sever
to another in the DC without the enterprise customer awareness, i.e. to another in the DC without the enterprise customer awareness, i.e.
no impact on the enterprise 'live' applications running these no impact on the enterprise 'live' applications running these
resources. Such advanced feature brings some new requirements for resources. Such advanced feature brings some requirements for NVO3
NVO3 [NVO3PRBM]. [NVO3PRBM].
5. DC Applications Using NVO3 5. DC Applications Using NVO3
NVO3 brings DC operators the flexibility to design different NVO3 brings DC operators the flexibility to design different
applications in a virtual environment without worry about physical applications in a true virtual environment without worry about
network configuration in the Data Center. DC operators may build physical network configuration in the Data Center. DC operators may
several virtual networks and interconnect them directly to form a build several virtual networks and interconnect them directly to
tenant virtual network; or may allocate some VMs to run tenant form a tenant virtual network and implement the communication rules
applications and some to run net service applications such as through policy; or may allocate some VMs to run tenant applications
Firewall, DNS for the tenant. Several use cases are given in this and some to run net service applications such as Firewall, DNS for
section. the tenant. Several use cases are given in this section.
5.1. Supporting Multi Technologies in a Data Center 5.1. Supporting Multi Technologies in a Data Center
Most likely servers deployed in a large data center are rolled in at Most likely servers deployed in a large data center are rolled in at
different times and may have different capacities/features. Some different times and may have different capacities/features. Some
servers may be virtualized, some may not; some may be equipped with servers may be virtualized, some may not; some may be equipped with
virtual switches, some may not. For the ones equipped with virtual switches, some may not. For the ones equipped with
hypervisor based virtual switches, some may support VxLAN [VXLAN] hypervisor based virtual switches, some may support VxLAN [VXLAN]
encapsulation, some may support NvGRE encapsulation [NVGRE], and encapsulation, some may support NvGRE encapsulation [NVGRE], and
some may not support any types of encapsulation. To construct a some may not support any types of encapsulation. To construct a
skipping to change at page 11, line 29 skipping to change at page 11, line 29
| |L2VNI| | | |L2VNI| | | |L2VNI| | | |L2VNI| | | |L2VNI| | | |L2VNI| | | |L2VNI| | | |L2VNI| |
| ++---++ | | ++---++ | | ++---++ | | ++---++ | | ++---++ | | ++---++ | | ++---++ | | ++---++ |
+--+---+--+ +--+---+--+ +--+---+--+ +--+---+--+ +--+---+--+ +--+---+--+ +--+---+--+ +--+---+--+
|...| |...| |...| |...| |...| |...| |...| |...|
TESs TESs TESs TESs TESs TESs TESs TESs
DC Site A DC Site Z DC Site A DC Site Z
Figure 4 Tenant Virtual Network with Bridging/Routing Figure 4 Tenant Virtual Network with Bridging/Routing
5.3. Virtual Data Center 5.3. Virtual Data Center (VDC)
Enterprise DC's today may often use several routers, switches, and Enterprise DC's today may often use several routers, switches, and
service devices to construct its internal network, DMZ, and external service devices to construct its internal network, DMZ, and external
network access. A DC Provider may offer a virtual DC to an network access. A DC Provider may offer a virtual DC to an
enterprise customer to run enterprise applications such as enterprise customer to run enterprise applications such as
website/emails. Instead of using many hardware devices, with the website/emails. Instead of using many hardware devices, with the
overlay and virtualization technology of NVO3, DC operators can overlay and virtualization technology of NVO3, DC operators can
build them on top of a common network infrastructure for many build them on top of a common network infrastructure for many
customers and run service applications per customer basis. The customers and run service applications per customer basis. The
service applications may include firewall, gateway, DNS, load service applications may include firewall, gateway, DNS, load
skipping to change at page 13, line 6 skipping to change at page 13, line 6
....... ....... ....... ....... ....... .......
|..| |..| |..| |..| |..| |..|
| | | | | | | | | | | |
Web Apps Mail Apps VoIP Apps Web Apps Mail Apps VoIP Apps
Provider DC Site Provider DC Site
* firewall/gateway may run on a server or VMs * firewall/gateway may run on a server or VMs
Figure 5 Virtual Data Center by Using NVO3 Figure 5 Virtual Data Center by Using NVO3
5.4. Federating NV03 Domains
Two general cases are 1) Federating AS managed by a single operator;
2) Federating AS managed by different Operators. The detail will be
described in next version.
6. OAM Considerations 6. OAM Considerations
NVO3 brings the ability for a DC provider to segregate tenant NVO3 brings the ability for a DC provider to segregate tenant
traffic. A DC provider needs to manage and maintain NVO3 instances. traffic. A DC provider needs to manage and maintain NVO3 instances.
Similarly, the tenant needs to be informed about tunnel failures Similarly, the tenant needs to be informed about tunnel failures
impacting tenant applications. impacting tenant applications.
Various OAM and SOAM tools and procedures are defined in [IEEE Various OAM and SOAM tools and procedures are defined in [IEEE
802.1ag, ITU-T Y.1731, RFC4378, RFC5880, ITU-T Y.1564] for L2 and L3 802.1ag, ITU-T Y.1731, RFC4378, RFC5880, ITU-T Y.1564] for L2 and L3
networks, and for user, including continuity check, loopback, link networks, and for user, including continuity check, loopback, link
skipping to change at page 15, line 39 skipping to change at page 15, line 46
2007 2007
[RFC5641] McGill, N., "Layer 2 Tunneling Protocol Version 3 (L2TPv3) [RFC5641] McGill, N., "Layer 2 Tunneling Protocol Version 3 (L2TPv3)
Extended Circuit Status Values", rfc5641, April 2009. Extended Circuit Status Values", rfc5641, April 2009.
[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.
11.2. Informative References 11.2. Informative References
[ESYS] Marques,P., "End-System support for BGP-signaled IP/VPNs",
draft-marques-l3vpn-end-system-07, August 2012
[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-01, July 2012 nvgre-01, July 2012
[NVO3PRBM] Narten, T., etc "Problem Statement: Overlays for Network [NVO3PRBM] Narten, T., etc "Problem Statement: Overlays for Network
Virtualization", draft-narten-nvo3-overlay-problem- Virtualization", draft-ietf-nvo3-overlay-problem-
statement-04, August 2012 statement-00, September 2012
[NVO3FRWK] Lasserre, M., Motin, T., and etc, "Framework for DC [NVO3FRWK] Lasserre, M., Motin, T., and etc, "Framework for DC
Network Virtualization", draft-lasserre-nvo3-framework-03, Network Virtualization", draft-ietf-nvo3-framework-01,
July 2012 October 2012
[VDP] "IEEE P802.1Qbg Edge Virtual Bridging".
[VMWARE] VMware, "vCenter", http://www.vmware.com
[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-02.txt, Networks", draft-mahalingam-dutt-dcops-vxlan-02.txt,
August 2012 August 2012
Authors' Addresses Authors' Addresses
 End of changes. 27 change blocks. 
113 lines changed or deleted 118 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/