[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Internet Engineering Task Force                               L. Kreeger
Internet-Draft                                                     Cisco
Intended status: Informational                                 T. Narten
Expires: August 29, 2013                                             IBM
                                                                D. Black
                                                                     EMC
                                                       February 25, 2013


   Network Virtualization Hypervisor-to-NVE Overlay Control Protocol
                              Requirements
                draft-kreeger-nvo3-hypervisor-nve-cp-01

Abstract

   The document "Problem Statement: Overlays for Network Virtualization"
   discusses the needs for network virtualization using overlay networks
   in highly virtualized data centers.  The problem statement outlines a
   need for control protocols to facilitate running these overlay
   networks.  This document outlines the high level requirements related
   to the interaction between hypervisors and the Network Virtualization
   Edge device when the two entities are not co-located on the same
   physical device.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on August 29, 2013.

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



Kreeger, et al.          Expires August 29, 2013                [Page 1]


Internet-Draft  NVO3 Hypervisor-NVE Control Protocol Reqs  February 2013


   (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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Entity Relationships . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  VNIC Containment Relationship  . . . . . . . . . . . . . .  6
       3.1.1.  Layer 2 Virtual Network Service  . . . . . . . . . . .  7
       3.1.2.  Layer 3 Virtual Network Service  . . . . . . . . . . .  8
   4.  Hypervisor-to-NVE Control Plane Protocol Functionality . . . .  9
     4.1.  VN Connect/Disconnect  . . . . . . . . . . . . . . . . . . 11
     4.2.  VNIC Address Association . . . . . . . . . . . . . . . . . 12
     4.3.  VNIC Address Disassociation  . . . . . . . . . . . . . . . 12
     4.4.  VNIC Shutdown/Startup/Migration  . . . . . . . . . . . . . 13
     4.5.  VN Profile . . . . . . . . . . . . . . . . . . . . . . . . 14
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Informative References . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
























Kreeger, et al.          Expires August 29, 2013                [Page 2]


Internet-Draft  NVO3 Hypervisor-NVE Control Protocol Reqs  February 2013


1.  Introduction

   Note: the contents of this document were originally in
   [I-D.kreeger-nvo3-overlay-cp].  The content has been pulled into its
   own document because the problem area covered is distinct and
   different from what most folk think of as a "control protocol" for
   NVO3.  Other related documents on this same general topic include
   [I-D.kompella-nvo3-server2nve], [I-D.gu-nvo3-overlay-cp-arch], and
   [I-D.gu-nvo3-tes-nve-mechanism].

   "Problem Statement: Overlays for Network Virtualization"
   [I-D.ietf-nvo3-overlay-problem-statement] discusses the needs for
   network virtualization using overlay networks in highly virtualized
   data centers and provides a general motivation for building such
   networks.  "Framework for DC Network Virtualization"
   [I-D.ietf-nvo3-framework] provides a framework for discussing overlay
   networks generally and the various components that must work together
   in building such systems.  The reader is assumed to be familiar with
   both documents.

   Section 4.5 of [I-D.ietf-nvo3-overlay-problem-statement] describes
   three separate work areas that fall under the general category of a
   control protocol for NVO3.  This document focuses entirely on the
   control protocol related to the hypervisor-to-NVE interaction,
   labeled as the "third work item" in
   [I-D.ietf-nvo3-overlay-problem-statement].  Requirements for the
   interaction between an NVE and the "oracle" are described in
   [I-D.kreeger-nvo3-overlay-cp].

   The NVO3 WG needs to decide on a better term for "oracle".  This
   document will use Information Mapping Authority (IMA) until a
   decision is made.

   This document uses the term "hypervisor" throughout when describing
   the scenario where NVE functionality is implemented on a separate
   device from the "hypervisor" that contains a VM connected to a VN.
   In this context, the term "hypervisor" is meant to cover any device
   type where the NVE functionality is offloaded in this fashion, e.g.,
   a Network Service Appliance.

   This document often uses the term "VM" and "Tenant System" (TS)
   interchangeably, even though a VM is just one type of Tenant System
   that may connect to a VN.  For example, a service instance within a
   Network Service Appliance may be another type of TS.  When this
   document uses the term VM, it will in most cases apply to other types
   of TSs.





Kreeger, et al.          Expires August 29, 2013                [Page 3]


Internet-Draft  NVO3 Hypervisor-NVE Control Protocol Reqs  February 2013


2.  Terminology

   This document uses the same terminology as found in the NVO3
   Framework document, [I-D.ietf-nvo3-framework].  Some of the terms
   defined in the Framework document have been repeated in this section
   for the convenience of the reader, along with additional terminology
   that is used by this document.

   IMA:  Information Mapping Authority.
      [I-D.ietf-nvo3-overlay-problem-statement] uses the term "oracle"
      to describe this.  It is a back-end system that is responsible for
      distributing and maintaining the mapping information for the
      entire overlay system.  Note that the WG never reached consensus
      on what to call this architectural entity within the overlay
      system, so this term is subject to change.

   Tenant System:  A physical or virtual system that can play the role
      of a host, or a forwarding element such as a router, switch,
      firewall, etc.  It belongs to a single tenant and connects to one
      or more VNs of that tenant.

   End Device:  A physical system to which networking service is
      provided.  Examples include hosts (e.g. server or server blade),
      storage systems (e.g., file servers, iSCSI storage systems), and
      network devices (e.g., firewall, load-balancer, IPSec gateway).
      An end device may include internal networking functionality that
      interconnects the device's components (e.g. virtual switches that
      interconnect VMs running on the same server).  NVE functionality
      may be implemented as part of that internal networking.

   Network Service Appliance:  A stand-alone physical device or a
      virtual device that provides a network service, such as a
      firewall, load balancer, etc.  Such appliances may embed Network
      Virtualization Edge (NVE) functionality within them in order to
      more efficiently operate as part of a virtualized network.

   VN:  Virtual Network.  This is a virtual L2 or L3 domain that belongs
      to a tenant.

   VDC:  Virtual Data Center.  A container for virtualized compute,
      storage and network services.  Managed by a single tenant, a VDC
      can contain multiple VNs and multiple Tenant Systems that are
      connected to one or more of these VNs.

   VN Alias:  A string name for a VN as used by administrators and
      customers to name a specific VN.  A VN Alias is a human-usable
      string that can be listed in contracts, customer forms, email,
      configuration files, etc. and that can be communicated easily



Kreeger, et al.          Expires August 29, 2013                [Page 4]


Internet-Draft  NVO3 Hypervisor-NVE Control Protocol Reqs  February 2013


      vocally (e.g., over the phone).  A VN Name is independent of the
      underlying technology used to implement a VN and will generally
      not be carried in protocol fields of control protocols used in
      virtual networks.  Rather, a VN Alias will be mapped into a VN
      Name where precision is required.

   VN Name:  A globally unique identifier for a VN suitable for use
      within network protocols.  A VN Name will usually be paired with a
      VN Alias, with the VN Alias used by humans as a shorthand way to
      name and identify a specific VN.  A VN Name should have a compact
      representation to minimize protocol overhead where a VN Name is
      carried in a protocol field.  Using a Universally Unique
      Identifier (UUID) as discussed in RFC 4122, may work well because
      it is both compact and a fixed size and can be generated locally
      with a very high likelihood of global uniqueness.

   VN ID:  A unique and compact identifier for a VN within the scope of
      a specific NVO3 administrative domain.  It will generally be more
      efficient to carry VN IDs as fields in control protocols than VN
      Aliases.  There is a one-to-one mapping between a VN Name and a VN
      ID within an NVO3 Administrative Domain.  Depending on the
      technology used to implement an overlay network, the VN ID could
      be used as the Context Identifier in the data plane, or would need
      to be mapped to a locally-significant Context Identifier.

   VN Profile:  Meta data associated with a VN that is used by an NVE
      when ingressing/egressing packets to/from a specific VN.  Meta
      data could include such information as ACLs, QoS settings, etc.
      The VN Profile contains parameters that apply to the VN as a
      whole.  Control protocols could use the VN ID or VN Name to obtain
      the VN Profile.

   VNIC:  A Virtual NIC that connects a Tenant System to a Virtual
      Network Instance (VNI).  Virtual NICs have virtual MAC addresses
      that may not be globally unique, but must be unique within a VN
      for proper network operation.

   VNIC Name:  A globally unique identifier for a VNIC suitable for use
      within network protocols.  Note that because VNIC MAC addresses
      may not be globally unique, they cannot be used as the VNIC Name.
      A VNIC Name should have a compact representation to minimize
      protocol overhead where a VNIC Name is carried in a protocol
      field.  Using a Universally Unique Identifier (UUID) as discussed
      in RFC 4122, may work well because it is both compact and a fixed
      size and can be generated locally with a very high likelihood of
      global uniqueness.





Kreeger, et al.          Expires August 29, 2013                [Page 5]


Internet-Draft  NVO3 Hypervisor-NVE Control Protocol Reqs  February 2013


3.  Entity Relationships

   This section describes the relationships between the entities
   involved in the Hypervisor-to-NVE control protocol.

3.1.  VNIC Containment Relationship

   The root of the containment tree is a VNIC.  Even though a VM may
   have multiple VNICs, from the point of view of an NVE, each VNIC can
   be treated independently.  There is no need to identify the VM itself
   within the Hypervisor-to-NVE protocol.

   Each VNIC can connect to multiple VNs.  Within each VNIC-VN pair,
   multiple MAC addresses may be reachable.  Within each VNIC-VN-MAC
   triplet, there may be multiple IP addresses.  This containment
   hierarchy is depicted below.

         VNIC-+-VN-+-MAC-+-IP
              |    |     +-IP ...
              |    |
              |    +-MAC-+-IP
              |          +-IP ...
              |
              +-VN-+-MAC-+-IP
                   |     +-IP ...
                   |
                   +-MAC-+-IP
                         +-IP ...


   VNIC Containment Relationship

                                 Figure 1

   Any of these entities can be added or removed dynamically at any
   time.

   The relationship implies that if one entity in the hierarchy is
   deleted then all the entities it contains are also deleted.  For
   example, if a given VNIC disassociates from one VN, all the MAC and
   IP addresses are also disassociated.  There is no need to signal the
   deletion of every entity within a VNIC when the VNIC is brought down
   or deleted (or the VM it is attached to is powered off or migrates
   away from the hypervisor).

   If a VNIC provides connectivity to a range of IP addresses (e.g. the
   VM is a load balancer with many Virtual IP addresses), it will be
   more efficient to signal a range or address mask in place of



Kreeger, et al.          Expires August 29, 2013                [Page 6]


Internet-Draft  NVO3 Hypervisor-NVE Control Protocol Reqs  February 2013


   individual IP addresses.

   In the majority of cases, a VM will be acting as a simple host that
   will have the following containment tree:

         VNIC--VN--MAC--IP

                                 Figure 2

   Since this is the most common case, the Hypervisor-to-NVE protocol
   should be optimized to handle this case.

   Tenant Systems (TS) that are providing network services (such as
   firewall, load balancer, VPN gateway) are likely to have a more
   complex containment hierarchy.  For example, a TS acting as a load
   balancer is quite likely to terminate multiple IP addresses, one for
   each application, or farm of servers that it is providing the front
   end for.

   Hypervisors often have a limit on the number of VNICs that a VM can
   have (e.g. in the range of 8 to 10 VNICs).  If a VM has the need to
   connect to more networks than the number of VNICs the hypervisor
   supports, the solutions is often to configure the VNIC (and the
   associated virtual port on the virtual switch the VNIC connects to)
   as an 802.1Q trunk.  In the case of a virtual switch that supports
   only VLANs, the VLAN tags used by all the VNICs connected to the
   switch (as well as the bridged network the hypervisor is physically
   connected to) share a common VLAN ID.

   In a multi-tenant scenario using overlay Virtual Networks instead of
   VLANs, VNICs can still use 802.1Q tagging to isolate traffic from
   different VNs as it crosses the virtual link between the VNIC and the
   virtual switch; However, The tags would have only local significance
   across that virtual link, with the virtual switch mapping each tag
   value to a different VN.  This implies that two different virtual
   links may use different 802.1Q tag values but with each mapped to the
   same VN by the virtual switch.  Similarly, two VNICs could use the
   same VLAN tag value but the virtual switch can map each vPort/Tag
   pair to a different VN.

   Each VNIC must attach to at least one VN and have at minimum one MAC
   address.  An IP address can be optional depending on whether the VN
   is providing L2 or L3 service.

3.1.1.  Layer 2 Virtual Network Service

   When the Virtual Network is providing only Layer 2 forwarding, the
   NVEs only require knowledge of the Tenant System's MAC addresses,



Kreeger, et al.          Expires August 29, 2013                [Page 7]


Internet-Draft  NVO3 Hypervisor-NVE Control Protocol Reqs  February 2013


   while layer 3 termination and routing happens only in the Tenant
   Systems.

   For example, if a VM is acting as a router to connect together two
   layer 2 VNs, the overlay system will forward frames to this router VM
   based on the VNIC's MAC address, but inside the frames may be packets
   destined to many different IP addresses.  There is no need for the
   NVEs to know the IP address of the router VM itself, nor the IP
   addresses of other TS that have packets routing through the VM.
   However, it may be useful for the NVE to know the IP address of the
   router itself for either troubleshooting, or for providing other
   network optimizations such as local termination of ARP (even though
   ARP optimizations are not strictly layer 2).  It is recommended (but
   optional) for an End Device to provide an IP address for a VNIC even
   if the NVE is providing an L2 service.

   When the overlay VN is forwarding at layer 2, it is possible for
   Tenant Systems to perform bridging between two VNs belonging to that
   tenant (provided the tenant MAC addresses do not overlap between the
   two VNs that are being bridged).  Reasons for VMs to do this are the
   same as in the physical world, such as the insertion of a transparent
   firewall device.  For example, a VM running firewall software can be
   inserted in between two groups of Tenant Systems on the same subnet
   by putting each group on a different VN and having the firewall VM
   bridge between them.

   When a VM is acting as a transparent bridge, it will appear to the
   overlay system that the VM is terminating multiple MAC addresses -
   one for each TS that exists on the other VN the VM is bridging to.
   In order for the overlay system to properly forward traffic to the
   bridging VM, it must know the MAC addresses of all the tenant systems
   the VM is bridging towards.  This is one case where a VNIC can appear
   to terminate more than one MAC address for the same VNIC/VN.

3.1.2.  Layer 3 Virtual Network Service

   When the Virtual Network is providing Layer 3 forwarding, the NVEs
   must have knowledge of the Tenant System IP addresses.  In the case
   where there is a Tenant System providing L3 forwarding for the tenant
   (e.g. an L3 VPN gateway), The TS VNIC may only terminate frames with
   a single MAC address, but will be forwarding IP packets on the behalf
   of other Tenant Systems.  This scenario requires more exploration to
   determine how the TS forwarding interacts with the VN forwarding;
   However, in one scenario, the TS VNIC may be seen as containing many
   IP addresses.

   Note that a MAC address is required even for a pure L3 VN service
   because VNICs filter out frames with destination MAC addresses that



Kreeger, et al.          Expires August 29, 2013                [Page 8]


Internet-Draft  NVO3 Hypervisor-NVE Control Protocol Reqs  February 2013


   do not match the VNIC's address; Therefore, the NVE providing an L3
   service must first encapsulate an IP packet in an Ethernet frame with
   the VNIC's destination MAC before it is sent to the End Device
   containing the VNIC.


4.  Hypervisor-to-NVE Control Plane Protocol Functionality

   The problem statement [I-D.ietf-nvo3-overlay-problem-statement],
   discusses the needs for a control plane protocol (or protocols) to
   populate each NVE with the state needed to perform its functions.

   In one common scenario, an NVE provides overlay encapsulation/
   decapsulation packet forwarding services to Tenant Systems (TSs) that
   are co-resident with the NVE on the same End Device (e.g. when the
   NVE is embedded within a hypervisor or a Network Service Appliance).
   In such cases, there is no need for a standardized protocol between
   the hypervisor and NVE, as the interaction is implemented via
   software on a single device.

   Alternatively, a Tenant System may use an externally connected NVE.
   An external NVE can provide an offload of the encapsulation /
   decapsulation function, network policy enforcement, as well as the VN
   Overlay protocol overheads.  This offloading may provide performance
   improvements and/or resource savings to the End Device (e.g.
   hypervisor) making use of the external NVE.

   The following figures give example scenarios where the Tenant System
   and NVE are on different devices separated by an access network.

        Hypervisor             Access Switch
   +------------------+       +-----+-------+
   | +--+   +-------+ |       |     |       |
   | |VM|---|       | | VLAN  |     |       |
   | +--+   |Virtual|---------+ NVE |       +--- Underlying
   | +--+   |Switch | | Trunk |     |       |    Network
   | |VM|---|       | |       |     |       |
   | +--+   +-------+ |       |     |       |
   +------------------+       +-----+-------+


   Hypervisor with an External NVE.

                                 Figure 3







Kreeger, et al.          Expires August 29, 2013                [Page 9]


Internet-Draft  NVO3 Hypervisor-NVE Control Protocol Reqs  February 2013


                               Access
        Hypervisor             Switch         NVE
   +------------------+       +-----+       +-----+
   | +--+   +-------+ |       |     |       |     |
   | |VM|---|       | | VLAN  |     | VLAN  |     |
   | +--+   |Virtual|---------+     +-------+     +--- Underlying
   | +--+   |Switch | | Trunk |     | Trunk |     |    Network
   | |VM|---|       | |       |     |       |     |
   | +--+   +-------+ |       |     |       |     |
   +------------------+       +-----+       +-----+


   Hypervisor with an External NVE across an Ethernet Access Switch.

                                 Figure 4


    Network Service Appliance         Access Switch
   +--------------------------+      +-----+-------+
   | +------------+    |\     |      |     |       |
   | |Net Service |----| \    |      |     |       |
   | |Instance    |    |  \   | VLAN |     |       |
   | +------------+    |   |---------+ NVE |       +--- Underlying
   | +------------+    |   |  | Trunk|     |       |    Network
   | |Net Service |----|  /   |      |     |       |
   | |Instance    |    | /    |      |     |       |
   | +------------+    |/     |      |     |       |
   +--------------------------+      +-----+-------+


   Physical Network Service Appliance with an External NVE.

                                 Figure 5

   In the examples above, the physical VLAN Trunk from the Hypervisor or
   Network Services Appliance towards the external NVE only needs to
   carry locally significant VLAN tag values.  How "local" the
   significance is depends on whether the Hypervisor has a direct
   physical connection to the NVE (in which case the significance is
   local to the physical link), or whether there is an Ethernet switch
   (e.g. a blade switch) connecting the Hypervisor to the NVE (in which
   case the significance is local to the intervening switch and all the
   links connected to it).

   These VLAN tags are used to differentiate between different VNs as
   packets cross the shared access network to the external NVE.  When
   the NVE receives packets, it uses the VLAN tag to identify the VN of
   packets coming from a given Tenant System's VNIC, strips the tag, and



Kreeger, et al.          Expires August 29, 2013               [Page 10]


Internet-Draft  NVO3 Hypervisor-NVE Control Protocol Reqs  February 2013


   adds the appropriate overlay encapsulation for that VN.

   On the hypervisor-facing side of the NVE, a control plane protocol is
   necessary to provide an NVE with the information it needs to provide
   connectivity across the Virtual Network for a given VNIC.
   Specifically, the Hypervisor (or Network Service Appliance) utilizing
   an external NVE needs to "attach to" and "detach from" a VN, as well
   as communicate the addresses within that VN that are reachable within
   it.  Thus, they will need a protocol that runs across the access
   network between the two devices that identifies the Tenant System
   (TS) VNIC addresses and VN Name (or ID) for which the NVE is
   providing service.  In addition, such a protocol will identify a
   locally significant tag (e.g., an 802.1Q VLAN tag) that can be used
   to identify the data frames that flow between the TS VNIC and the VN.

4.1.  VN Connect/Disconnect

   In the previous figures, NVEs reside on an external networking device
   (e.g. an access switch).  When an NVE is external, a protocol is
   needed between the End Device (e.g.  Hypervisor) making use of the
   external NVE and the external NVE in order to make the NVE aware of
   the changing VN membership requirements of the Tenant Systems within
   the End Device.

   A key driver for using a protocol rather than using static
   configuration of the external NVE is because the VN connectivity
   requirements can change frequently as VMs are brought up, moved and
   brought down on various hypervisors throughout the data center.

   The NVE must be notified when an End Device requires connection to a
   particular VN and when it no longer requires connection.  In
   addition, the external NVE must provide a local tag value for each
   connected VN to the End Device to use for exchange of packets between
   the End Device and the NVE (e.g. a locally significant 802.1Q tag
   value).

   The Identification of the VN in this protocol could either be through
   a VN Name or a VN ID.  A globally unique VN Name facilitates
   portability of a Tenant's Virtual Data Center.  When a VN within a
   VDC is instantiated within a particular administrative domain, it can
   be allocated a VN Context which only the NVE needs to use.  Once an
   NVE receives a VN connect indication, the NVE needs a way to get a VN
   Context allocated (or receive the already allocated VN Context) for a
   given VN Name or ID (as well as any other information needed to
   transmit encapsulated packets).  How this is done is the subject of
   the NVE-to-oracle (called NVE-to-IMA in this document) protocol which
   are part of work items 1 and 2 in
   [I-D.ietf-nvo3-overlay-problem-statement].



Kreeger, et al.          Expires August 29, 2013               [Page 11]


Internet-Draft  NVO3 Hypervisor-NVE Control Protocol Reqs  February 2013


   An End Device that is making use of an offloaded NVE only needs to
   communicate the VN Name or ID to the NVE, and get back a locally
   significant tag value.

4.2.  VNIC Address Association

   Typically, a VNIC is assigned a single MAC address and all frames
   transmitted and received on that VNIC use that single MAC address.
   As discussed in the section above on the containment hierarch, it is
   also possible for a Tenant System to exchange frames using multiple
   MAC addresses (ones that are not assigned to the VNIC) or packets
   with multiple IP addresses.

   Particularly in the case of a TS that is forwarding frames or packets
   from other TSs, the NVE will need to communicate the mapping between
   the NVE's IP address (on the underlying network) and ALL the
   addresses the TS is forwarding on behalf of to the Information
   Mapping Authority (IMA).

   The NVE has two ways in which it can discover the tenant addresses
   for which frames must be forwarded to a given End Device (and
   ultimately to the TS within that End Device).

   1.  It can glean the addresses by inspecting the source addresses in
       packets it receives from the End Device.

   2.  The End Device can explicitly signal the addresses to the NVE.
       The End Device could have discovered the addresses for a given
       VNIC by gleaning them itself from data packets sent by the VNIC,
       or by some other internal means within the End Device itself.

   To perform the second approach above, the "hypervisor-to-NVE"
   protocol requires a means to allow End Devices to communicate new
   tenant addresses associations for a given VNIC within a given VN.

4.3.  VNIC Address Disassociation

   When a VNIC within an End Device terminates function (due to events
   such as VNIC shutdown, Tenant System (TS) shutdown, or VM migration
   to another hypervisor), all addresses associated with that VNIC must
   be disassociated with the End Device on the connected NVE.

   If the VNIC only has a single address associated with it, then this
   can be a single address disassociate message to the NVE.  However, if
   the VNIC had hundreds of addresses associated with it, then the
   protocol with the NVE would be better optimized to simply
   disassociate the VNIC with the NVE, and the NVE can automatically
   disassociate all addresses that were associated with the VNIC.



Kreeger, et al.          Expires August 29, 2013               [Page 12]


Internet-Draft  NVO3 Hypervisor-NVE Control Protocol Reqs  February 2013


   Having TS addresses associated with a VNIC can also provide
   scalability benefits when the VM migrates between hypervisors that
   are connected to the same NVE.  When a VM migrates to another
   hypervisor connected to the same NVE, if the NVE is aware of the
   migration, there is no need for all the addresses to be purged from
   NVE (and IMA) only to be immediately re-established again when the VM
   migration completes.

   If the device containing the NVE is supporting many hypervisors, it
   may be quite likely that the VM migration will result in the VNICs
   still being associated with the same NVE, but simply on a different
   port.  From the point of view of the IMA, nothing has changed and it
   would be inefficent to signal these changes to the IMA for no
   benefit.  The NVE only needs to associate the addresses with a
   different port/tag pair.

   It is possible for the NVE to handle a VM migration by using a timer
   to retain the VNIC addresses for a short time to see if the
   disassociated VNIC re-assocatiates on another NVE port, but this could
   be better handled if the NVE knew the difference between a VNIC/VM
   shutdown and a VM migration.  This leads to the next section.

4.4.  VNIC Shutdown/Startup/Migration

   As discussed above, the NVE can make optimizations if it knows which
   addresses are associated with which VNICs within an End Device and
   also is notified of state changes of that VNIC, specifically the
   difference between VNIC shutdown/startup and VNIC migration arrival/
   departure.

   Upon VNIC shutdown, the NVE can immediately signal to the IMA that
   the bindings of the VNIC's addresses to the NVE's IP address can be
   removed.

   Upon VNIC arrival, the NVE could either start a timer to hold the
   VNIC address bindings waiting to see if the VNIC arrives on a
   different port, or if there is a pre-arrival handshake with the NVE,
   then it will already know that the VNIC is going to be reassociated
   with the same NVE.

   Upon VNIC arrival, the NVE knows that any addresses previously bound
   to the VNIC are still present and has no need to signal any change in
   address mappings to the IMA.

   Note that if the IMA is also aware of VNIC address bindings, it can
   similarly participate efficiently in a VM migration that occurs
   across two different NVEs.




Kreeger, et al.          Expires August 29, 2013               [Page 13]


Internet-Draft  NVO3 Hypervisor-NVE Control Protocol Reqs  February 2013


4.5.  VN Profile

   Once an NVE (embedded or external) receives a VN connect indication
   with a specified VN Name or ID, the NVE must determine the VN Context
   value to encapsulate packets with as well as other information that
   may be needed (e.g., QoS settings).  The NVE serving that hypervisor
   needs a way to get a VN Context allocated or receive the already
   allocated VN Context for a given VN Name or ID (as well as any other
   information needed to transmit encapsulated packets).  A protocol for
   an NVE to get this mapping may be a useful function, but would be the
   subject of work items 1 and 2 in
   [I-D.ietf-nvo3-overlay-problem-statement].


5.  Security Considerations

   Editor's Note: This is an initial start on the security
   considerations section; it will need to be expanded, and suggestions
   for material to add are welcome.

   NVEs must ensure that only properly authorized Tenant Systems are
   allowed to join and become a part of any specific Virtual Network.
   In addition, NVEs will need appropriate mechanisms to ensure that any
   hypervisor wishing to use the services of an NVE are properly
   authorized to do so.  One design point is whether the hypervisor
   should supply the NVE with necessary information (e.g., VM addresses,
   VN information, or other parameters) that the NVE uses directly, or
   whether the hypervisor should only supply a VN ID and an identifier
   for the associated VM (e.g., its MAC address), with the NVE using
   that information to obtain the information needed to validate the
   hypervisor-provided parameters or obtain related parameters in a
   secure manner.


6.  Acknowledgements

   Thanks to the following people for reviewing and providing feedback:
   Vipin Jain and Shyam Kapadia.


7.  Informative References

   [I-D.gu-nvo3-overlay-cp-arch]
              Yingjie, G. and W. Hao, "Analysis of external assistance
              to NVE and consideration of architecture",
              draft-gu-nvo3-overlay-cp-arch-00 (work in progress),
              July 2012.




Kreeger, et al.          Expires August 29, 2013               [Page 14]


Internet-Draft  NVO3 Hypervisor-NVE Control Protocol Reqs  February 2013


   [I-D.gu-nvo3-tes-nve-mechanism]
              Yingjie, G. and L. Yizhou, "The mechanism and signalling
              between TES and NVE", draft-gu-nvo3-tes-nve-mechanism-01
              (work in progress), October 2012.

   [I-D.ietf-nvo3-framework]
              Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
              Rekhter, "Framework for DC Network Virtualization",
              draft-ietf-nvo3-framework-02 (work in progress),
              February 2013.

   [I-D.ietf-nvo3-overlay-problem-statement]
              Narten, T., Gray, E., Black, D., Dutt, D., Fang, L.,
              Kreeger, L., Napierala, M., and M. Sridharan, "Problem
              Statement: Overlays for Network Virtualization",
              draft-ietf-nvo3-overlay-problem-statement-02 (work in
              progress), February 2013.

   [I-D.kompella-nvo3-server2nve]
              Kompella, K., Rekhter, Y., and T. Morin, "Signaling
              Virtual Machine Activity to the Network Virtualization
              Edge", draft-kompella-nvo3-server2nve-01 (work in
              progress), October 2012.

   [I-D.kreeger-nvo3-overlay-cp]
              Kreeger, L., Dutt, D., Narten, T., and M. Sridharan,
              "Network Virtualization Overlay Control Protocol
              Requirements", draft-kreeger-nvo3-overlay-cp-02 (work in
              progress), October 2012.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.


Authors' Addresses

   Lawrence Kreeger
   Cisco

   Email: kreeger@cisco.com


   Thomas Narten
   IBM

   Email: narten@us.ibm.com





Kreeger, et al.          Expires August 29, 2013               [Page 15]


Internet-Draft  NVO3 Hypervisor-NVE Control Protocol Reqs  February 2013


   David Black
   EMC

   Email: david.black@emc.com















































Kreeger, et al.          Expires August 29, 2013               [Page 16]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/