Skip to main content

Use Cases for DC Network Virtualization Overlays
draft-ietf-nvo3-use-case-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8151.
Authors Lucy Yong , Mehmet Toy , Aldrin Isaac , Vishwas Manral , Linda Dunbar
Last updated 2013-02-15
Replaces draft-mity-nvo3-use-case
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-nvo3-use-case-00
Network working group                                           L. Yong
Internet Draft                                                   Huawei
Category: Informational                                          M. Toy
                                                                Comcast
                                                               A. Isaac
                                                              Bloomberg
                                                              V. Manral
                                                        Hewlett-Packard
                                                              L. Dunbar
                                                                 Huawei

Expires: August 2013                                  February 15, 2013

             Use Cases for DC Network Virtualization Overlays

                       draft-ietf-nvo3-use-case-00

Abstract

   This draft describes the general NVO3 use cases. The work intention
   is to help validate the NVO3 framework and requirements as along
   with the development of the solutions.

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 August, 2013.

MITY                     Expires August 2013                   [Page 1]
Internet-Draft          NVO3 Use Case                     February 2012

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

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

   1. Introduction...................................................3
   2. Terminology....................................................4
   3. Basic Virtual Networks in a Data Center........................4
   4. Interconnecting DC Virtual Network and External Networks.......6
      4.1. DC Virtual Network Access via Internet....................7
      4.2. DC Virtual Network and WAN VPN Interconnection............7
   5. DC Applications Using NVO3.....................................9
      5.1. Supporting Multi Technologies in a Data Center...........10
      5.2. Tenant Virtual Network with Bridging/Routing.............10
      5.3. Virtual Data Center (VDC)................................11
      5.4. Federating NV03 Domains..................................13
   6. OAM Considerations............................................13
   7. Summary.......................................................13
   8. Security Considerations.......................................14
   9. IANA Considerations...........................................14
   10. Acknowledgements.............................................15
   11. References...................................................15
      11.1. Normative References....................................15
      11.2. Informative References..................................16
   Authors' Addresses...............................................16

MITY                     Expires August 2013                   [Page 2]
Internet-Draft          NVO3 Use Case                     February 2012

1. Introduction

   Compute Virtualization has dramatically and quickly changed IT
   industry in terms of efficiency, cost, and the speed in providing a
   new applications and/or services. However the problems in today's
   data center hinder the support of an elastic cloud service and
   dynamic virtual tenant networks [NVO3PRBM]. The goal of DC Network
   Virtualization Overlays, i.e. NVO3, is to decouple tenant system
   communication networking from DC physical networks and to allow one
   physical network infrastructure to provide: 1) traffic isolation
   among virtual networks over the same physical network; 2)
   independent address space in each virtual network and address
   isolation from the infrastructure's; 3) Flexible VM placement and
   move from one server to another without any physical network
   limitation. These characteristics will help address the issues in
   the data centers [NVO3PRBM].

   Although NVO3 may enable a true virtual environment where VMs and
   network service appliances communicate, the NVO3 solution has to
   address the communication between a virtual network and one physical
   network. 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 cooperation users on physical networks; 3) some
   applications like Big Data analytics which are CPU bound may not
   want the virtualization capability.

   This document is to describe general NVO3 use cases that apply to
   various data center networks to ensure nvo3 framework and solutions
   can meet the demands. Three types of the use cases described here
   are:

   o  A virtual network connects many tenant systems within a Data
      Center and form one L2 or L3 communication domain. A virtual
      network segregates its traffic from others and allows the VMs in
      the network moving from one server to another. The case may be
      used for DC internal applications that constitute the DC East-
      West traffic.

   o  A DC provider offers a secure DC service to an enterprise
      customer and/or Internet users. In these cases, the enterprise
      customer may use a traditional VPN provided by a carrier or an
      IPsec tunnel over Internet connecting to an overlay virtual
      network offered by a Data Center provider. This is mainly
      constitutes DC North-South traffic.

MITY                     Expires August 2013                   [Page 3]
Internet-Draft          NVO3 Use Case                     February 2012

   o  A DC provider uses NVO3 to design a variety of cloud applications
      that make use of the network service appliance, virtual compute,
      storage, and networking. In this case, the NVO3 provides the
      virtual networking functions for the applications.

   The document uses the architecture reference model and terminologies
   defined in [NVO3FRWK] to describe the use cases.

2.  Terminology

   This document uses the terminologies defined in [NVO3FRWK],
   [RFC4364]. Some additional terms used in the document are listed
   here.

   CUG: Closed User Group

   L2 VNI: L2 Virtual Network Instance

   L3 VNI: L3 Virtual Network Instance

   ARP: Address Resolution Protocol

   CPE: Customer Premise Equipment

   DNS: Domain Name Service

   DMZ: DeMilitarized Zone

   NAT: Network Address Translation

   VNIF: Virtual Network Interconnection Interface

3. Basic Virtual Networks in a Data Center

   A virtual network may exist within a DC. The network enables a
   communication among tenant systems (TSs) that are in a Closed User
   Group (CUG). A TS may be a physical server or virtual machine (VM)
   on a server. A virtual network has a unique virtual network
   identifier (may be local or global unique) for switches/routers to
   properly differentiate it from other virtual networks. The CUGs are
   formed so that proper policies can be applied when the TSs in one
   CUG communicate with the TSs in other CUGs.

   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
   server or ToR. Each NVE may be the member of one or more virtual
   networks. Each virtual network may be L2 or L3 basis. In this

MITY                     Expires August 2013                   [Page 4]
Internet-Draft          NVO3 Use Case                     February 2012

   illustration, three virtual networks with VN context Ta, Tn, and Tm
   are shown. The VN 'Ta' terminates on both NVE1 and NVE2; The VN 'Tn'
   terminates on NVE1 and the VN 'Tm' at NVE2 only. If an NVE is a
   member of a VN, one or more virtual network instances (VNI) (i.e.
   routing and forwarding table) exist on the NVE. Each NVE has one
   overlay module to perform frame encapsulation/decapsulation and
   tunneling initiation/termination. In this scenario, a tunnel between
   NVE1 and NVE2 is necessary for the virtual network Ta.

   A TS attaches to a virtual network (VN) via a virtual access point
   (VAP) on an NVE. One TS may participate in one or more virtual
   networks via VAPs; one NVE may be configured with multiple VAPs for
   a VN. Furthermore if individual virtual networks use different
   address spaces, the TS participating in all of them will be
   configured with multiple addresses as well. A TS as a gateway is an
   example for this. In addition, multiple TSs may use one VAP to
   attach to a VN. For example, VMs are on a server and NVE is on ToR,
   then some VMs may attach to NVE via a VLAN.

   A VNI on an NVE is a routing and forwarding table that caches and/or
   maintains the mapping of a tenant system and its attached NVE. The
   table entry may be updated by the control plane, data plane,
   management plane, or the combination of them.

                      +------- L3 Network ------+
                      |       Tunnel Overlay    |
         +------------+--------+       +--------+-------------+
         | +----------+------+ |       | +------+----------+  |
         | | Overlay Module  | |       | | Overlay Module  |  |
         | +---+---------+---+ |       | +--+----------+---+  |
         |     |Ta       |Tn   |       |    |Ta        |Tm    |
         |  +--+---+  +--+---+ |       |  +-+----+  +--+---+  |
         |  | VNIa |..| VNIn | |       |  | VNIa |..| VNIm |  |
    NVE1 |  ++----++  ++----++ |       |  ++----++  ++----++  | NVE2
         |   |VAPs|    |VAPs|  |       |   |VAPs|    |VAPs|   |
         +---+----+----+----+--+       +---+----+----+----+---+
             |    |    |    |              |    |    |    |
       ------+----+----+----+------   -----+----+----+----+-----
             | .. |    | .. |              | .. |    | .. |
             |    |    |    |              |    |    |    |
              Tenant systems                Tenant systems

MITY                     Expires August 2013                   [Page 5]
Internet-Draft          NVO3 Use Case                     February 2012

              Figure 1    NVO3 for Tenant System Networking

  One virtual network may have many NVE members and interconnect
  several thousands of TSs (as a matter of policy), the capability of
  supporting a lot of TSs per tenant instance and TS 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 TS
  and NVE are co-located on a same physical device, which means that
  the NVE is aware of the TS state at any time via internal API. The
  second is when TS 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 TS state.

  Note that if all NVEs are co-located with TSs in a CUG, the
  communication in the CUG is in a true virtual environment. If a TS
  connects to a NVE remotely, the communication from this TS to other
  TSs in the CUG is not in a true virtual environment. The packets
  to/from this TS are directly carried over a physical network, i.e.
  on the wire. This may require some necessary configuration on the
  physical network to facilitate the communication.

   Individual virtual networks may use its own address space and the
   space is isolated from DC infrastructure. This eliminates the route
   reconfiguration in the DC underlying network when VMs move. Note
   that the NVO3 solutions still have to address VM move in the overlay
   network, i.e. the TS/NVE association change when a VM moves.

   If a 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. 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 in different DCs.

4. Interconnecting DC Virtual Network and External Networks

   For customers (an enterprise or individuals) who want to utilize the
   DC provider's compute and storage resources to run their
   applications, they need to access their systems hosted in a DC
   through Carrier WANs or Internet. A DC provider may use an NVO3
   virtual network for such customer to access their systems; then it,
   in turn, becomes the case of interconnecting DC virtual network and
   external networks. Two cases are described here.

MITY                     Expires August 2013                   [Page 6]
Internet-Draft          NVO3 Use Case                     February 2012

4.1. DC Virtual Network Access via Internet

   A user or an enterprise customer connects to a DC virtual network
   via Internet but securely. Figure 2 illustrates this case. An L3
   virtual network is configured on NVE1 and NVE2 and two NVEs are
   connected via an L3 tunnel in the Data Center. A set of tenant
   systems attach to NVE1. The NVE2 connects to one (may be more) TS
   that runs the VN gateway and NAT applications (known as network
   service appliance). A user or customer can access their systems via
   Internet by using IPsec tunnel [RFC4301]. The encrypted tunnel is
   established between the VN GW and the user machine or CPE at
   enterprise location. The VN GW provides authentication scheme and
   encryption. Note that VN GW function may be performed by a network
   service appliance device or on a DC GW.

                       +--------------+ +----------+
                       |    +------+  | | Firewall | TS
                  +----+(OM)+L3 VNI+--+-+ NAT      | (VN GW)
                  |    |    +------+  | +----+-----+
             L3 Tunnel +--------------+      ^
                  |               NVE2       |IPsec Tunnel
         +--------+---------+            .--.  .--.
         | +------+-------+ |           (    :'   '.--.
         | |Overlay Module| |        .-.'    :         )
         | +------+-------+ |       (    Internet       )
         |  +-----+------+  |       (        :         /
         |  |   L3 VNI   |  |        '-'     :      '-'
    NVE1 |  +-+--------+-+  |            \../+\.--/'
         +----+--------+----+                |
              |  ...   |                     V
            Tenant Systems               User Access

             DC Provider Site

      OM: Overlay Module;

             Figure 2 DC Virtual Network Access via Internet

4.2. DC Virtual Network and WAN VPN Interconnection

   A DC Provider and Carrier may build a VN and VPN independently and
   interconnect the VN and VPN at the DC GW and PE for an enterprise
   customer. Figure 3 depicts this case in an L3 overlay (L2 overlay is
   the same). The DC provider constructs an L3 VN between the NVE1 on a
   server and the NVE2 on the DC GW in the DC site; the carrier

MITY                     Expires August 2013                   [Page 7]
Internet-Draft          NVO3 Use Case                     February 2012

   constructs an L3VPN between PE1 and PE2 in its IP/MPLS network. An
   Ethernet Interface physically connects the DC GW and PE2 devices.
   The local VLAN over the Ethernet interface [VRF-LITE] is configured
   to connect 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 Interface may be used between PE1 and CE to connect the
   L3VPN and enterprise physical networks.

   This configuration allows the enterprise networks communicating to
   the tenant systems attached to the L3 VN without interfering with DC
   provider underlying physical networks and other overlay networks in
   the DC. The enterprise may use its own address space on the tenant
   systems attached to the L3 VN. The DC provider can manage the VMs
   and storage attached to the L3 VN for the enterprise customer. The
   enterprise customer can determine and run their applications on the
   VMs. From the L3 VN perspective, an end point in the enterprise
   location appears as 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 termination and forward the packets in between.
   The DC provider and Carrier negotiate the local VLAN ID used on the
   Ethernet interface.

   This configuration makes the L3VPN over the WANs only has the
   reachbility to the TS in the L3 VN. It does not have the
   reachability of DC physical networks and other VNs in the DC.
   However, the L3VPN has the reachbility of enterprise networks. Note
   that both the DC provider and enterprise may have multiple network
   locations connecting to the L3VPN.

   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
   [RFC4364]. This configuration can work with any NVO3 solution. The
   eBGP, OSPF, or other can be used between PE1 and CE for the route
   population.

         +-----------------+           +-------------+
         |  +----------+   |           | +-------+   |
    NVE2 |  | L3 VNI   +---+===========+-+ VRF   |   |
         |  +----+-----+   |   VLAN    | +---+---+   | PE2
         |       |         |           |     |       |
         | +-----+-------+ |          /+-----+-------+--\
         | |Overly Module| |         (       :           '
         | +-------------+ |        {        :            }
         +--------+--------+        {        : LSP Tunnel }
                  |                  ;       :            ;
                  |IP Tunnel         {  IP/MPLS Network }

MITY                     Expires August 2013                   [Page 8]
Internet-Draft          NVO3 Use Case                     February 2012

                  |                    \     :          /
         +--------+---------+           +----+------+  -
         | +------+-------+ |           | +--+---+  | '
         | |Overlay Module| |           | | VRF  |  |
         | +------+-------+ |           | +--+---+  | PE1
         |        |Ta       |           |    |      |
         |  +-----+------+  |           +----+------+
         |  |   L3 VNI   |  |                |
    NVE1 |  +-+--------+-+  |                |
         |    |  VAPs  |    |               CE Site
         +----+--------+----+
              |  ...   |                Enterprise Site
            Tenant systems

             DC Provider Site

     Figure 3 L3 VNI and L3VPN interconnection across multi networks

   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
   edge connects to a physical network and another edge connects to an
   overlay network.

   Various alternatives can be configured between DC GW and SP PE to
   achieve the same capability. Option B, C, or D in RFC4364 [RFC4364]
   can be used and the characteristics of each option are described
   there.

   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
   place them at any location without notifying the enterprise and
   carrier because the DC physical network is completely isolated from
   the carrier and enterprise network. Furthermore, the DC operator may
   move the VMs assigned to the enterprise from one sever to another in
   the DC without the enterprise customer awareness, i.e. no impact on
   the enterprise 'live' applications running these resources. Such
   advanced feature brings some requirements for NVO3 [NVO3PRBM].

5. DC Applications Using NVO3

   NVO3 brings DC operators the flexibility to design different
   applications in a true virtual environment (or nearly true) without
   worrying about physical network configuration in the Data Center. DC
   operators may build several virtual networks and interconnect them
   directly to form a tenant virtual network and implement the

MITY                     Expires August 2013                   [Page 9]
Internet-Draft          NVO3 Use Case                     February 2012

   communication rules, i.e. policy between different virtual networks;
   or may allocate some VMs to run tenant applications and some to run
   network service application such as Firewall and DNS for the tenant.
   Several use cases are given in this section.

5.1. Supporting Multi Technologies in a Data Center

   Most likely servers deployed in a large data center are rolled in at
   different times and may have different capacities/features. Some
   servers may be virtualized, some may not; some may be equipped with
   virtual switches, some may not. For the ones equipped with
   hypervisor based virtual switches, some may support VxLAN [VXLAN]
   encapsulation, some may support NVGRE encapsulation [NVGRE], and
   some may not support any types of encapsulation. To construct a
   tenant virtual network among these servers and the ToRs, it may use
   two virtual networks and a gateway to allow different
   implementations working together. For example, one virtual network
   uses VxLAN encapsulation and another virtual network uses
   traditional VLAN.

   The gateway entity, either on VMs or standalone one, participates in
   to both virtual networks, and maps the services and identifiers and
   changes the packet encapsulations.

5.2. Tenant Virtual Network with Bridging/Routing

   A tenant virtual network may span across multiple Data Centers. DC
   operator may want to use L2VN within a DC and L3VN outside DCs for a
   tenant network. This is very similar to today's DC physical network
   configuration. L2 bridging has the simplicity and endpoint awareness
   while L3 routing has advantages in policy based routing, aggregation,
   and scalability. For this configuration, the virtual L2/L3 gateway
   function is necessary to interconnect L2VN and L3VN in each DC.
   Figure 4 illustrates this configuration.

   Figure 4 depicts two DC sites. The site A constructs an L2VN that
   terminates on NVE1, NVE2, and GW1. An L3VN is configured between the
   GW1 at site A and the GW2 at site Z. An internal Virtual Network
   Interconnection Interface (VNIF) connects to L2VNI and L3VNI on GW1.
   Thus the GW1 is the members of the L2VN and L3VN. The L2VNI is the
   MAC/NVE mapping table and the L3VNI is IP prefix/NVE mapping table.
   Note that a VNI also has the mapping of TS and VAP at the local NVE.
   The site Z has the similar configuration. A packet coming to the GW1
   from L2VN will be descapulated and converted into an IP packet and
   then encapsulated and sent to the site Z. The Gateway uses ARP
   protocol to obtain MAC/IP address mapping.

MITY                     Expires August 2013                  [Page 10]
Internet-Draft          NVO3 Use Case                     February 2012

   Note that both the L2VN and L3VN in the figure are carried by the
   tunnels supported by the underlying networks which are not shown in
   the figure.

            +------------+                  +-----------+
         GW1| +-----+    | '''''''''''''''' |   +-----+ |GW2
            | |L3VNI+----+'    L3VN        '+---+L3VNI| |
            | +--+--+    | '''''''''''''''' |   +--+--+ |
            |    |VNIF   |                  |  VNIF|    |
            | +--+--+    |                  |   +--+--+ |
            | |L2VNI|    |                  |   |L2VNI| |
            | +--+--+    |                  |   +--+--+ |
            +----+-------+                  +------+----+
             ''''|''''''''''                 ''''''|'''''''
            '     L2VN      '               '     L2VN     '
        NVE1 ''/'''''''''\'' NVE2      NVE3  '''/'''''''\'' NVE4
        +-----+---+  +----+----+        +------+--+ +----+----+
        | +--+--+ |  | +--+--+ |        | +---+-+ | | +--+--+ |
        | |L2VNI| |  | |L2VNI| |        | |L2VNI| | | |L2VNI| |
        | ++---++ |  | ++---++ |        | ++---++ | | ++---++ |
        +--+---+--+  +--+---+--+        +--+---+--+ +--+---+--+
           |...|        |...|              |...|       |...|

             Tenant Systems                  Tenant Systems

                DC Site A                    DC Site Z

          Figure 4 Tenant Virtual Network with Bridging/Routing

5.3. Virtual Data Center (VDC)

   Enterprise DC's today may often use several routers, switches, and
   service devices to construct its internal network, DMZ, and external
   network access. A DC Provider may offer a virtual DC to an
   enterprise customer to run enterprise applications such as
   website/emails. Instead of using many hardware devices, with the
   overlay and virtualization technology of NVO3, DC operators can
   build them on top of a common network infrastructure for many
   customers and run service applications per customer basis. The
   service applications may include firewall, gateway, DNS, load
   balancer, NAT, etc.

MITY                     Expires August 2013                  [Page 11]
Internet-Draft          NVO3 Use Case                     February 2012

   Figure 5 below illustrates this scenario. For the simple
   illustration, it only shows the L3VN or L2VN as virtual and overlay
   routers or switches. In this case, DC operators construct several L2
   VNs (L2VNx, L2VNy, L2VNz in Figure 5) to group the end tenant
   systems together per application basis, create an L3VNa for the
   internal routing. A server or VM runs firewall/gateway applications
   and connects to the L3VNa and Internet. A VPN tunnel is also built
   between the gateway and enterprise router. The design runs
   Enterprise Web/Mail/Voice applications at the provider DC site; lets
   the users at Enterprise site to access the applications via the VPN
   tunnel and Internet via a gateway at the Enterprise site; let
   Internet users access the applications via the gateway in the
   provider DC. The enterprise operators can also use the VPN tunnel or
   IPsec over Internet to access the vDC for the management purpose.
   The firewall/gateway provides application-level and packet-level
   gateway function and/or NAT function.

   The Enterprise customer decides which applications are accessed by
   intranet only and which by both intranet and extranet; DC operators
   then design and configure the proper security policy and gateway
   function. DC operators may further set different QoS levels for the
   different applications for a customer.

   This application requires the NVO3 solution to provide the DC
   operator an easy way to create NVEs and VNIs for any design and to
   quickly assign TSs to a VNI, easily place and configure policies on
   an NVE, and support VM mobility.

                         Internet                      ^ Internet
                                                       |
                            ^                        +-+----+
                            |                        |  GW  |
                            |                        +--+---+
                            |                           |
                    +-------+--------+                +-+----+
                    |FireWall/Gateway+---VPN Tunnel---+Router|
                    +-------+--------+                +-+--+-+
                            |                           |  |
                         ...+...                        |..|
                  +-----: L3VNa :--------+              LANs
                  |      .......         |
                  |          |           |         Enterprise Site
               ...+...    ...+...     ...+...
              : L2VNx :  : L2VNy :   : L2VNz :
               .......    .......     .......

MITY                     Expires August 2013                  [Page 12]
Internet-Draft          NVO3 Use Case                     February 2012

                 |..|       |..|        |..|
                 |  |       |  |        |  |
               Web Apps   Mail Apps    VoIP Apps

                        Provider DC Site

     * firewall/gateway may run on a server or VMs

                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

   NVO3 brings the ability for a DC provider to segregate tenant
   traffic. A DC provider needs to manage and maintain NVO3 instances.
   Similarly, the tenant needs to be informed about tunnel failures
   impacting tenant applications.

   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 networks, and for user, including continuity check,
   loopback, link trace, testing, alarms such as AIS/RDI, and on-demand
   and periodic measurements. These procedures may apply to tenant
   overlay networks and tenants not only for proactive maintenance, but
   also to ensure support of Service Level Agreements (SLAs).

   As the tunnel traverses different networks, OAM messages need to be
   translated at the edge of each network to ensure end-to-end OAM.

   It is important that failures at lower layers which do not affect
   NVo3 instance are to be suppressed.

7. Summary

   The document describes some basic potential use cases of NVO3. The
   combination of these cases should give operators flexibility and
   capability to design more sophisticated cases for various purposes.

   The key requirements for NVO3 are 1) traffic segregation; 2)
   supporting a large scale number of virtual networks in a common
   infrastructure; 3) supporting highly distributed virtual network

MITY                     Expires August 2013                  [Page 13]
Internet-Draft          NVO3 Use Case                     February 2012

   with sparse memberships 3) VM mobility 4) auto or easy to construct
   a NVE and its associated TS; 5) Security 6) NVO3 Management
   [NVO3PRBM].

   Difference between other overlay network technologies and NVO3 is
   that the client edges of the NVO3 network are individual and
   virtualized hosts, not network sites or LANs. NVO3 enables these
   virtual hosts communicating in a true virtual environment without
   constraints in physical networks.

   NVO3 allows individual tenant virtual networks to use their own
   address space and isolates the space from the network infrastructure.
   The approach not only segregates the traffic from multi tenants on a
   common infrastructure but also makes VM placement and move easier.

   DC services may vary from infrastructure as a service (IaaS),
   platform as a service (PaaS), to software as a service (SaaS), in
   which the network virtual overlay is just a portion of an
   application service. NVO3 decouples the services from DC network
   infrastructure configuration.

   NVO3's underlying network provides the tunneling between NVEs so
   that two NVEs appear as one hop to each other. Many tunneling
   technologies can serve this function. The tunneling may in turn be
   tunneled over other intermediate tunnels over the Internet or other
   WANs. It is also possible that intra DC and inter DC tunnels are
   stitched together to form an end-to-end tunnel between two NVEs.

   A DC virtual network may be accessed via an external network in a
   secure way. Many existing technologies can help achieve this.

8. Security Considerations

   Security is a concern. DC operators need to provide a tenant a
   secured virtual network, which means one tenant's traffic isolated
   from the other tenant's traffic and non-tenant's traffic; they also
   need to prevent DC underlying network from any tenant application
   attacking through the tenant virtual network or one tenant
   application attacking another tenant application via DC networks.
   For example, a tenant application attempts to generate a large
   volume of traffic to overload DC underlying network. The NVO3
   solution has to address these issues.

9. IANA Considerations

   This document does not request any action from IANA.

MITY                     Expires August 2013                  [Page 14]
Internet-Draft          NVO3 Use Case                     February 2012

10. Acknowledgements

   Authors like to thank Sue Hares, Young Lee, David Black, Pedro
   Marques, Mike McBride, David McDysan, Randy Bush, and Uma Chunduri
   for the review, comments, and suggestions.

11. References

11.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
             Networks (VPNs)", RFC 4364, February 2006.

   [IEEE 802.1ag]  "Virtual Bridged Local Area Networks - Amendment 5:
             Connectivity Fault Management", December 2007.

   [ITU-T G.8013/Y.1731] OAM Functions and Mechanisms for Ethernet
             based Networks, 2011.

   [ITU-T Y.1564] "Ethernet service activation test methodology", 2011.

   [RFC4378] Allan, D., Nadeau, T., "A Framework for Multi-Protocol
             Label Switching (MPLS) Operations and Management (OAM)",
             RFC4378, February 2006

   [RFC4301] Kent, S., "Security Architecture for the Internet
             Protocol", rfc4301, December 2005

   [RFC4664] Andersson, L., "Framework for Layer 2 Virtual Private
             Networks (L2VPNs)", rfc4664, September 2006

   [RFC4797] Rekhter, Y., et al, "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.

   [RFC5880] Katz, D. and Ward, D., "Bidirectional Forwarding Detection
             (BFD)", rfc5880, June 2010.

MITY                     Expires August 2013                  [Page 15]
Internet-Draft          NVO3 Use Case                     February 2012

11.2. Informative References

   [NVGRE]  Sridharan, M., "NVGRE: Network Virtualization using Generic
             Routing Encapsulation", draft-sridharan-virtualization-
             nvgre-01, work in progress.

   [NVO3PRBM] Narten, T., etc "Problem Statement: Overlays for Network
             Virtualization", draft-ietf-nvo3-overlay-problem-
             statement-02, work in progress.

   [NVO3FRWK] Lasserre, M., Motin, T., and etc, "Framework for DC
             Network Virtualization", draft-ietf-nvo3-framework-02,
             work in progress.

   [VRF-LITE] Cisco, "Configuring VRF-lite", http://www.cisco.com

   [VXLAN]  Mahalingam,M., Dutt, D., etc "VXLAN: A Framework for
             Overlaying Virtualized Layer 2 Networks over Layer 3
             Networks", draft-mahalingam-dutt-dcops-vxlan-02.txt, work
             in progress.

 Authors' Addresses

   Lucy Yong
   Huawei Technologies,
   4320 Legacy Dr.
   Plano, Tx75025 US

   Phone: +1-469-277-5837
   Email: lucy.yong@huawei.com

   Mehmet Toy
   Comcast
   1800 Bishops Gate Blvd.,
   Mount Laurel, NJ 08054

   Phone : +1-856-792-2801
   E-mail : mehmet_toy@cable.comcast.com

   Aldrin Isaac
   Bloomberg
   E-mail: aldrin.isaac@gmail.com

   Vishwas Manral
   Hewlett-Packard Corp.
   191111 Pruneridge Ave.

MITY                     Expires August 2013                  [Page 16]
Internet-Draft          NVO3 Use Case                     February 2012

   Cupertino, CA  95014

   Phone: 408-447-1497
   Email: vishwas.manral@hp.com

   Linda Dunbar
   Huawei Technologies,
   4320 Legacy Dr.
   Plano, Tx75025 US

   Phone: +1-469-277-5840
   Email: linda.dunbar@huawei.com

MITY                     Expires August 2013                  [Page 17]