Network working group                                           L. Yong
Internet Draft                                                   Huawei
Category: Informational                                          M. Toy
                                                               A. Isaac
                                                              V. Manral

Expires: December 2012                                    June 22, 2012

             Use Cases for DC Network Virtualization Overlays


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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on November 30, 2012.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of

MITY                    Expires November 2012                  [Page 1]

Internet-Draft          NVO3 Use Case                         June 2012

   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.


   This draft describes NVO3 use cases. The framework draft [NVO3FRWK]
   layouts the NVO3 architecture reference model, functional modules,
   and NVO3 and VPN interworking aspects and challenges. This draft
   presents the use cases that help in validating the framework and
   requirements as well as the solution development.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC-2119 [RFC2119].

Table of Contents

   1. Introduction...................................................3
   2. Terminology....................................................4
   3. Multiple virtual networks across multiple DCs..................4
   4. Interconnection of DC Virtual Network and Carrier VPN..........6
      4.1. One virtual network method across DCs and WAN networks....6
      4.2. NVO3 and VPN Interconnections between DC and WAN networks.7
   5. Cloud Services Using NVO3......................................9
      5.1. Public Cloud Service......................................9
      5.2. Private Cloud Service....................................10
      5.3. Virtual Data Center......................................11
   6. OAM Considerations............................................13
   7. Summary.......................................................13
   8. Security Considerations.......................................14
   9. IANA Considerations...........................................14
   10. Acknowledgements.............................................14
   11. References...................................................14
      11.1. Normative References....................................14
      11.2. Informative References..................................15
   Authors' Addresses...............................................15

MITY                    Expires December 2012                  [Page 2]

Internet-Draft          NVO3 Use Case                         June 2012

1. Introduction

   This document provides the use cases for Network Virtualization
   Overlay, i.e. NVO3, which is driven by Data Center Networks. These
   use cases are intended to help in validating the framework and
   requirements as well as the solution development.

   The advent of the hypervisor eliminated the tight coupling of an
   endpoint from the physical computer on which it ran.  This change
   has allowed the physical computer to become a service point rather
   than a client.  The goal of NVO3 is to no longer treat the physical
   computer as a client of the network but as a native service point of
   the network.

   Although overlay networks have been around for many years,
   hypervisor-aware overlay networks have certain characteristics that
   are suited for the DC environment.  The main characteristic
   difference between other overlay network technology and NVO3 is that
   the client edges of the NVO3 network are individual virtualized
   hosts and not network sites or LANs.  Other differentiating
   characteristics include (1) the potential for lower overall costs
   when compared to comparable network-based overlays, (2) better loop-
   free scaling over traditional DC network virtualization solutions (3)
   better virtual host access and mobility.

   The NVO3 framework [NVO3FRWK] provides the architecture reference
   model, functional modules, and the overlay/underlying network
   aspects, which empowers Data Center service designs. Data Center
   service is to provide applications and/or virtual compute and/or
   storage and networking. The key requirements for Data Center service
   networks are to enable secure, virtual, and segregation networks
   that are highly scalable in number and size, native extension of
   these virtual networks to the virtual interface of virtual machines,
   flexible operator-defined virtual network topologies, natural
   interconnection of networks and interposing of network services, and
   the simple and rapid enablement of network access and services.
   Either an L3 or L2 virtual network instance can be constructed over
   the underlying networks.

   Use cases for the NVO3 framework [NVO3FRWK] can be highly varied.
   This document outlines some basic scenarios and groups them into
   three set.

   One set of NVO3 use cases is connecting many, many tenant end
   systems in one and/or multiple DC sites and forming an L2 or L3
   communication domain. Using overlay tenant virtual network instances

MITY                    Expires December 2012                  [Page 3]

Internet-Draft          NVO3 Use Case                         June 2012

   segregate the traffic from different tenants, allows each tenant
   instance having its own address space and isolating the space from
   DC infrastructure. In addition, support VM move.

   The second set of NVO3 use cases is for a DC provider to offer a
   secure DC service to an enterprise customer. In these cases, the
   enterprise customer may use a traditional L3/L2 VPN provided by a
   carrier connecting to an overlay virtual network instance offered by
   a Data Center provider, and offload its applications on to the
   servers located in provider Data Center sites.

   The third set of NVO3 use cases is to enable DC provider design
   various cloud services through the applications, compute, storage,
   and the networking. In this case, NVO3 provides the networking
   functions of a service rather than the service itself.

2. Terminology

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

   VNIF: VNI Interconnection Interface on an NVE

   L2 VPI: L2 Virtual Network Instance

   L3 VNI: L3 Virtual Network Instance

   ARP: Address Resolution Protocol

   DNS: Domain Name Service

   NAT: Network Address Translation

3. Multiple virtual networks across multiple DCs

  A DC operator may have multiple DC sites for space, regional
  proximity, availability or other reasons. The DC operator may
  furthermore require the ability to group and segregate end systems
  at the network level to securely host customer or internal end
  systems. To satisfy these requirements, the DC operator may choose
  the NVO3 to interconnect and segregate end systems within and/or
  across his DC sites. In this scenario, the DC operator is required
  to span a single NVO3 instance to interconnect end-systems across
  multiple DCs.  The NVO3 instance may be an L2 or L3 based virtual
  network instance.

MITY                    Expires December 2012                  [Page 4]

Internet-Draft          NVO3 Use Case                         June 2012

  Figure 1 depicts NVE1 and NVE2 in two DC locations, respectively.
  Each NVE are configured with multiple virtual network instances that
  have different topologies. In this illustration, three virtual
  network instances with VN context Ta, Tn, and Tm are shown. VNIa
  terminates on both NVE1 and NVE2; VNIn terminates on NVE1 and VNIm
  at NVE2 only. In general, each NVE has one overlay module to perform
  frame encapsulation/decapsulation and tunneling
  initiation/termination. It is possible that two NVO3 instances use
  different encapsulation and/or tunneling schemes, thus more than one
  overlay modules on an NVE may be required.

  In this scenario, the end-to-end tunneling between NVE1 and NVE2 is
  necessary for the VNIa and consists of intra and inter DC tunnels.
  The tunneling may in turn be tunneled over other intermediate
  tunnels over the Internet or other WAN. It is also possible that
  intra DC and inter DC tunnels are stitched together to form an end-
  to-end tunnel between two NVEs.[PION] Note: if both NVE1 and NVE2
  are in the same DC, only intra DC tunnel is necessary.

  An VNI terminated on an NVE may locally associate to one or more
  VAPs each of which may associate with one of more TESs. It is
  possible that the VNI does not attach to any VAP (see section 5).
  One VAP associates to one VNI terminated on an NVE. One tenant
  virtual network instance may terminate on many NVEs and interconnect
  several thousands of TESs across multiple DC sites, the ability of
  supporting a large number of TESs per tenant instance is critical
  for NVO3 solution.

                      +------- L3 Network ------+
                      |       Tunnel Overlay    |
         +------------+--------+       +--------+-------------+
         | +----------+------+ |       | +------+----------+  |
         | | Overlay Module  | |       | | Overlay Module  |  |
         | +---+---------+---+ |       | +--+----------+---+  |
         |     |Ta       |Tn   |       |    |Ta        |Tm    |
         |  +--+---+  +--+---+ |       |  +-+----+  +--+---+  |
         |  | VNIa |..| VNIn | |       |  | VNIa |..| VNIm |  |
    NVE1 |  ++----++  ++----++ |       |  ++----++  ++----++  | NVE2
         |   |VAPs|    |VAPs|  |       |   |VAPs|    |VAPs|   |
         +---+----+----+----+--+       +---+----+----+----+---+
             |    |    |    |              |    |    |    |
       ------+----+----+----+------   -----+----+----+----+-----
             | .. |    | .. |     Tenant   | .. |    | .. |
             |    |    |    |   Service IF |    |    |    |
            Tenant End Systems            Tenant End Systems

MITY                    Expires December 2012                  [Page 5]

Internet-Draft          NVO3 Use Case                         June 2012

                DC Site A                        DC Site Z

                 Figure 1    NVo3 for DC interconnection

   Individual virtual network instances may use its own address space
   and the space is isolated from DC infrastructure. This eliminates IP
   subnet constraints in the infrastructure when moving VMs. Note: the
   NVO3 solution still have to address the discovery of VM move.

4. Interconnection of DC Virtual Network and Carrier VPN

   In this scenario, the enterprise customer utilizes the DC provider's
   compute and storage resources to run its applications, and the DC
   provider allows the customer to access his hosted end systems
   through a Carrier WAN.  This use case requires a tenant instance in
   the DC to interconnect with a carrier VPN for customer access.  The
   enterprise customer may also utilize the Carrier's VPN to connect
   its corporate locations, and/or the DC provider's locations where
   his tenant instance exists.  The DC provider creates a tenant
   instance for the enterprise customer that interconnects all the VMs
   and storage resources allocated to the customer.  The customer
   unique instance provides the customer with traffic segregation from
   other customers and free selection of the address space. Both DC VNI
   and carrier VPN instance can run at either L2 or L3.

  4.1. One virtual network method across DCs and WAN networks

   If both DC Provider and Carrier use the same encapsulation and
   tunneling technology, it is possible to configure one overlay
   virtual network instance across DC networks and Carrier networks.
   For example, if both DC provider and Carrier use existing MPLS-based
   VPN solutions [RFC4364] and IP tunnel, the NVE in DC and the PE in
   WAN can be members of one VN instance. Figure 2 illustrates this
   scenario. The left side of the figure presents a NVE (NVE1) in DC
   Provider site and the right shows Provider Edge (PE1) in a WAN
   network connecting to Customer Edge (CE) at an Enterprise site. The
   CE is often a network site and contains routers and/or switches and
   terminal systems.

   In this case, an L3 VNI and L3VPN instance are configured on NVE1
   and PE1, respectively. If the MPLS label is used as VN context/VPN
   identifier and IP tunnel is established between NVE1 and PE1, the
   configuration will provide the L3 connectivity between a TES and CE.
   The MPLS label for the L3 VNI identifier (Ta) on NVE1 can be
   different from the MPLS label for the L3VPN identifier (VPNID) on
   PE1 since MPLS labels are locally significant. Although the figure

MITY                    Expires December 2012                  [Page 6]

Internet-Draft          NVO3 Use Case                         June 2012

   shows Overlay Module on NVE1 and Encap/Decap
   (Encapsulation/Decapsulation) on PE1, both perform the same
   functions; it is just matter of using different terminologies in
   NVO3 framework [NVO3FRWK] and L3VPN [RFC4364].

   The DC and WAN networks may belong to different ASs, control plane
   protocol or management plane can facilitate the VN configuration.
   Note: A TES is an end system, not a network site as the CE in figure
   2; more than likely it does not run any routing protocol. Thus the
   routing between NVE1 and TES are static routing, which may be done
   by the API or software assisted configuration in a secured way.
   Routing and forwarding between NVE1 and PE1 and between PE1 and CE
   are specified in RFC4364 [RFC4364].

                      DC          (     WAN
                  +----------- IP tunnel -------+
                  |               (             |
                  |                )            |
         +--------+------------+  (     +-------+--------+
         | +------+----------+ |        | +-----+------+ |
         | | Overlay Module  | |        | | Encap/Decap| |
         | +--------+--------+ |        | +-----+------+ |
         |          |Ta        |        |       |VPNID   |PE1
         |          |          |        |   +---+---+    |
         |  +-------+-------+  |        |   |  VRF  |    |
         |  |    L3 VNI     |  |        |   +---+---+    |
    NVE1 |  +-+-----------+-+  |        +-------+--------+
         |    |   VAPs    |    |                |
         +----+-----------+----+                |
              |   ...     |               Customer Edge (CE)
            Tenant End Systems

             DC Provider Site             Enterprise Site

         Figure 2 One VN solution across DCs and Carrier Networks

  4.2. NVO3 and VPN Interconnections between DC and WAN networks

   DC Provider and Carrier may build a tenant instance and VPN instance
   for an enterprise customer independently and interconnect two
   together at DC GW. Figure 3 depicts this case. The GW supports both
   NVE and PE capability. Here an L3 VNI instance is built between NVE1
   and DC GW and an L3VPN instance is configured on DC GW and PE1,

MITY                    Expires December 2012                  [Page 7]

Internet-Draft          NVO3 Use Case                         June 2012

   respectively. The GW performs L3 VNI function, NVO3 encapsulation,
   and tunneling toward the DC; it also performs L3VPN function toward
   the WAN. Both L2 tunnel and LSP Tunnel terminate at DC GW. The
   packets are processed at the L3 VNI on DC GW. Operator may choose
   use of one routing table for both instances as shown in the figure
   or one for each. This implementation is more complex than one in
   figure 2. However it provides DC network and WAN network demarcation
   clearly and allows each network use of different VN implementations,
   which is necessary in some situations.

   The alternative of this case is physically split the gateway
   function on to DC GW and WAN PE devices. In this case, the tenant
   instance is terminated on the DC GW and L3VPN instance terminates at
   a PE in WAN. An Ethernet interface is used to physically connect to
   the DC GW and PE devices and an Ethernet VLAN is configured on both
   devices for interconnecting two instances.

                        DC           DC GW               WAN
                              '|    +--+---+     |'
                  +-L2 Tunnel--+(OM)+L3VNI +(E/D)+-- MPLS/LSP Tunnel
                  |           '|    +--+---+     |'     |
                  |           '+-------+---------+'     |
                  |           '   NVE        PE   '     |
                  |           '''''''''''''''''''''     |
         +--------+---------+                    +------+--------+
         | +------+-------+ |                    | +----+------+ |
         | |Overlay Module| |                    | |Encap/Decap| |
         | +------+-------+ |                    | +-----+-----+ |PE1
         |        |Ta       |                    |    +--+--+    |
         |  +-----+------+  |                    |    | VRF |    |
         |  |   L3 VNI   |  |                    |    +--+--+    |
    NVE1 |  +-+--------+-+  |                    +-------+-------+
         |    |  VAPs  |    |                            |
         +----+--------+----+                            CE
              |  ...   |
          Tenant End Systems

             DC Provider Site                    Enterprise Site

      Note: OM: Overlay Module; E/D: Encap/Decap

     Figure 3 L3 VNI and L3VPN interconnection across multi networks

MITY                    Expires December 2012                  [Page 8]

Internet-Draft          NVO3 Use Case                         June 2012

   If an enterprise only has few locations, it may use P2P VPWS
   connecting to the DC GW. Further some enterprises may connect to DC
   GW via Internet by using IPsec. In this case, DC GW needs to provide
   some authentication scheme for the security.

   Such interconnection may also apply to one or across multiple DC
   sites. During the migration process, it is possible that some
   portion of DC site may be able to support NVE and other may not.
   Such gateway function may be used to interconnect a tenant instance
   and a regular underlying VPN that provides the connectivity to the
   VMs belonging to the same tenant.

5. Cloud Services Using NVO3

   NVO3 brings DC operators power and flexibility to design different
   applications for cloud services. DC operators construct VMs, storage,
   applications, and interconnect them together via an VNI. Since DC
   operator manages both tenant end systems and NVEs, they can assign
   some functions on VMs and some on NVEs. For example, designate a VM
   for running firewall and/or a VM for DNS for a tenant; apply
   forwarding policies and/or access list on an VNI terminated on an
   NVE. Operators may dedicate some VMs and/or storages for these
   applications and allocate other VMs/storages for running tenant
   specific applications. Furthermore, the design of a cloud service
   for a customer may often require creating both L2 VNI and L3 VNI per
   a tenant on one or more NVEs and interconnecting the VNIs together
   like physical router and switch devices in a traditional DC.

  5.1. Public Cloud Service

   Figure 4 depicts that an L2 VNI is used to connect all the TESs
   together and provides a simple LAN among TESs; an L3 VNI is used for
   public Internet Access and firewall access. Note: An L3 VNI provides
   virtualized IP routing and forwarding and an L2 VNI provides
   Ethernet LAN emulation. The firewall application runs on a tenant
   end system connecting to the L3 VNI terminated on NVE1 and NVE2. Ta
   in Figure 4 is the VN context of the L2 VNI. Internal VNI
   interconnecting interface (VNIF) is used to connect the L2 VNI and
   L3 VNI on NVE1 and NVE2. In this case, the L3 VNI connects to
   external switch directly, not to an overlay module. Operator defined
   policies can directly apply to the L3 VNI terminated on NVE.
   Furthermore, the L3 VNI does not have to co-exist with the L2 VNI on
   every NVEs; the several NVEs where the L2 VNI terminates can connect
   to one NVE where the L3 VNI terminates. In this case, VNIF
   reachability should be known by these NVEs.

MITY                    Expires December 2012                  [Page 9]

Internet-Draft          NVO3 Use Case                         June 2012

             Internet    +--IP GRE Tunnel ---+      Internet
               |         |                   |        |
               |         |                   |        |
          +----+---------+-----+       +-----+--------+-----+
          |    |      +--+---+ |       | +---+--+     |     |
          |    |      |  OM  | |       | |  OM  |     |     |
          |    |      +--+---+ |       | +--+---+     |     |
          |    |         |Ta   |       |    |Ta       |     |
          | +--+--+VNIF+-+---+ |       | +--+--+VNIF+--+--+ |
          | |L3VNI+----+L2VNI| |       | |L2VNI+----+L3VNI| |
     NVE1 | +--+--+    ++----+ |       | ++----+    +--+--+ | NVE2
          |    |        |VAPs| |       |  |VAPs|       |    |
          +----+--------|----|-+       +--+----+-------+----+
               |        |    |            |    |       |
        -------+--------+----+---    -----+----+-------+-----
               |        | .. |            | .. |       |
               |        |    |            |    |       |
             FW TES       TESs              TESs     FW TES

                  DC Site A                   DC Site Z

    Figure 4 L2 VNI for connecting TESs and L3 VNI for public Internet

   In this case, if the tenant uses private IP addresses on Tenant End
   Systems, the NAT is needed for public Internet access. Operator may
   allocate another TES connecting to L3 VNI and run NAT application on

  5.2. Private Cloud Service

   Figure 5 below illustrates another overlay bridging and routing
   example. A L2 VNI is used for local LAN switching and L3 VNI is used
   for interconnecting NVEs remotely and providing IETF IP VPN
   functionality. In this case, the L2 VNI terminated on an NVE only
   has local significance.

MITY                    Expires December 2012                 [Page 10]

Internet-Draft          NVO3 Use Case                         June 2012

                            +----IP Tunnel -----+
                            |                   |
            +---------------+-----+       +-----+---------------+
            | +-------------+---+ |       | +---+-----------+   |
            | |  Overlay Module | |       | | Overlay Module|   |
            | +---+-------------+ |       | +-------------+-+   |
            |     |Ta             |       |             Ta|     |
            |     |               |       |               |     |
            |  +--+---+   +-----+ |       |  +------+  +--+--+  |
            |  | L3VNI+---+L2VNI| |       |  | L2VNI+--+L3VNI|  |
       NVE1 |  +------+   ++----+ |       |  ++----++  +-----+  | NVE2
            |              |VAPs| |       |   |VAPs|            |
            +--------------|----|-+       +---+----+------------+
                           |    |             |    |
          -----------------+----+---    ------+----+-------------
                           | .. |   Tenant    | .. |
                           |    | Service IF  |    |
                   Tenant End Systems        Tenant End Systems

                    DC Site A                     DC Site Z

        Figure 5 NVO3 for Virtual Bridging and Routing Per Tenant

   The DC provider may also create an NVE on DC GW and configure the L3
   VNI on the NVE (instead of co-resident with L2 VNI on the same NVE).
   Thus L2 overlay is used within a DC, and L3 overlay is used for

  5.3. Virtual Data Center

   Enterprise DC today may often uses several routers and switches
   devices to construct a secure network for intranet and extranet.
   [SANS] DC Provider may want to offer Virtual DC called
   Infrastructure as service (IaaS) to such enterprise customers.
   Instead of using many router/switch 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 applications per customer basis. The applications
   may include firewall, DNS, load balancer, NAT, etc.

MITY                    Expires December 2012                 [Page 11]

Internet-Draft          NVO3 Use Case                         June 2012

   Figure 6 below illustrates this scenario. For the simplification, it
   only shows the VNIs as logic routers or switches. In this case, DC
   operators construct several L2 VNIs (x, y, z in figure 6) to group
   the end tenant systems together per application basis, create an L3
   VNI (L3 VNIa in the figure) for internal routing and another L3 VNI
   (L3 VNIb in the figure) for broad routing. Allocate a TES to run a
   firewall application between L3 VNIa and L3 VNIb. The design
   implements the security policy with the appropriate firewall rules
   and Layer 3 access list.  Configure an interconnection between the
   L3VNIa to an L3VPN over the WAN to reach Enterprise Sites.

   The Enterprise as a 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. DC
   operators can further set different QoS levels for the different
   applications for a customer.

   This application requires NVO3 solution to provide DC operator an
   easy way to create NVEs and VNIs for any design and to quickly
   assign TESs to an VNI, and configure policies on an NVE easily.

                        ^ Internet
                    +---+-----+         WAN
                    |FireWall*|      /^^^^^^^^^\
                    +------+--+ /---|  VPN/MPLS |-- CE
                           |   /     \vvvvvvvvv/
                         +-+--+-+                Enterprise Site
                  |      +---+--+        |
                  |          |           |
               +--+---+   +--+---+    +--+---+
               |L2VNIx|   |L2VNIy|    |L2VNIz|
               +-+--+-+   +-+--+-+    +-+--+-+
                 |..|       |..|        |..|
                 |  |       |  |        |  |
               App1 TESs   App2 TESs    App3 TESs

                        DC Provider Site

     * firewall may run on VMs

MITY                    Expires December 2012                 [Page 12]

Internet-Draft          NVO3 Use Case                         June 2012

               Figure 6 Secure Cloud Service by Using NVO3

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, 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 intends to illustrate some basic potential use cases.
   The combination of these cases should give operators flexibility and
   power to design more sophisticated cases for various purposes.

   The main characteristic difference between other overlay network
   technologies and NVO3 is that the client edges of the NVO3 network
   are individual virtualized hosts and not network sites or LANs. NVO3
   is to no longer treat the physical computer as a client of the
   network but as a native service point of the network. The same
   operator manages both NVO3 network and its clients.

   NVO3 lets individual virtual network instances use its own address
   space and isolate the space from the network infrastructure. The
   approach not only segregates the traffic from multi tenants on a
   common infrastructure but also makes VM mobility easier within a

   Cloud services are about providing virtual processing/storage,
   applications, and networking in a secured and virtualized manner, in
   which the NV03 is just a portion of a service, not a service itself.
   NVO3 decouples cloud services and DC network infrastructure.

MITY                    Expires December 2012                 [Page 13]

Internet-Draft          NVO3 Use Case                         June 2012

   NVO3 underlying network provides the tunneling between NVEs so that
   two NVEs appear as one hop 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 WAN.  It is
   also possible that intra DC and inter DC tunnels are stitched
   together to form an end-to-end tunnel between two NVEs.

   The key requirements for NVO3 are 1) traffic segregation; 2) support
   a large scale number of TESs in an VNI; 3) VM mobility 4) easy to
   construct an VNI and its associated TES; 5) NVO3 Management.

8. Security Considerations

   Please see it in NVO3 Framework. [NVO3FMWK]

9. IANA Considerations

   This document does not request any action from IANA.

10. Acknowledgements

   Authors like to thank Linda Dunbar, Sue Hares, and Young Lee for the
   review 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], A Framework for Multi-Protocol Label Switching (MPLS)
             Operations and Management (OAM)

MITY                    Expires December 2012                 [Page 14]

Internet-Draft          NVO3 Use Case                         June 2012

  11.2. Informative References

   [NVO3FRWK] Lasserre, M., Motin, T., and etc, "Framework for DC
             Network Virtualization", draft-lasserre-NVO3-framework-02,
             June 2012.

   [PION] Jin, L. and Khasnabish, B., "Architecture of PSN Independent
             Overlay Network (PION)", draft-kj-nvo3-pion-architecture-
             00, May 2012

   [SANS] Daniel Oxenhander, "Designing a Secure Local Area Network",

 Authors' Addresses

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

   Phone: +1-469-277-5837

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

   Phone : +1-856-792-2801
   E-mail :

   Aldrin Isaac

   Vishwas Manral
   Hewlett-Packard Corp.
   191111 Pruneridge Ave.
   Cupertino, CA  95014

   Phone: 408-447-1497

MITY                    Expires December 2012                 [Page 15]