Re: [nvo3] Draft NVO3 WG Charter

[Igor Gashinsky <[e-mail]>]

I think this is a great charter, but, do we really need to bother with L2 
over L2 type of overlays here? Does anybody actually plan on building 
something like that? 

-igor

On Fri, 17 Feb 2012, Thomas Narten wrote:

:: Below is a draft charter for this effort. One detail is that we
:: started out calling this effort NVO3 (Network Virtualization Over L3),
:: but have subsequently realized that we should not focus on just "over
:: L3". One goal of this effort is to develop an overlay standard that
:: works over L3, but we do not want to restrict ourselves only to "over
:: L3". The framework and architecture that we are proposing to work on
:: should be applicable to other overlays as well (e.g., L2 over
:: L2). This is (hopefully) captured in the proposed charter.
:: 
:: Comments?
:: 
:: Thomas
:: 
:: NVO: Network Virtualization Overlays 
:: 
:: Support for multi-tenancy has become a core requirement of data
:: centers, especially in the context of data centers which include
:: virtualized servers known as virtual machines (VMs).  With
:: multi-tenancy, a data center can support the needs of many thousands
:: of individual tenants, ranging from individual groups or departments
:: within a single organization all the way up to supporting thousands of
:: individual customers.  A key multi-tenancy requirement is traffic
:: isolation, so that a tenant's traffic (and internal address usage) is
:: not visible to any other tenant and does not collide with addresses
:: used within the data center itself.  Such isolation can be achieved by
:: creating and assigning one or more virtual networks to each tenant
:: such that traffic within a virtual network is isolated from traffic in
:: other virtual networks.
:: 
:: Tenant isolation is primarily achieved today within data centers using
:: Ethernet VLANs. But the 12-bit VLAN tag field isn't large enough to
:: support existing and future needs. A number of approaches to extending
:: VLANs and scaling L2s have been proposed or developed, including IEEE
:: 802.1ah Shortest Path Bridging (SPB) and TRILL (with the proposed
:: fine-grained labeling extension).  At the L3 (IP) level, VXLAN and
:: NVGRE have also been proposed. As outlined in
:: draft-narten-nvo3-overlay-problem-statement-01.txt, however, existing
:: L2 approaches are not satisfactory for all data center operators,
:: e.g., larger data centers that desire to keep L2 domains small or push
:: L3 further into the data center (e.g., all the way to top-of-rack
:: switches). Furthermore, there is a desire to decouple the
:: configuration of the data center network from the configuration
:: associated with individual tenant applications and to seamlessly and
:: rapidly update the network state to handle live VM migrations or fast
:: spin-up and spin-down of new tenant VMs (or servers). Such tasks are
:: complicated by the need to simultaneously reconfigure and update data
:: center network state (e.g., VLAN settings on individual switches).
:: 
:: This WG will develop an approach to multi-tenancy that does not rely
:: on any underlying L2 mechanisms to support multi-tenancy. In
:: particular, the WG will develop an approach where multitenancy is
:: provided at the IP layer using an encapsulation header that resides
:: above IP. This effort is explicitly intended to leverage the interest
:: in L3 overlay approaches as exemplified by VXLAN
:: (draft-mahalingam-dutt-dcops-vxlan-00.txt) and NVGRE
:: (draft-sridharan-virtualization-nvgre-00.txt).
:: 
:: Overlays are a form of "map and encap", where an ingress node maps the
:: destination address of an arriving packet (e.g., from a source tenant
:: VM) into the address of an egress node to which the packet can be
:: tunneled to. The ingress node then encapsulates the packet in an outer
:: header and tunnels it to the egress node, which decapsulates the
:: packet and forwards the original (unmodified) packet to its ultimate
:: destination (e.g., a destination tenant VM). All map-and-encap
:: approaches must address two issues: the encapsulation format (i.e.,
:: the contents of the outer header) and how to distribute and manage the
:: mapping tables used by the tunnel end points.
:: 
:: The first area of work concerns encapsulation formats. This WG will
:: develop requirements and desirable properties for any encapsulation
:: format. Given the number of already existing encapsulation formats,
:: it is not an explicit goal of this effort to choose exactly one format
:: or to develop yet another new one.
:: 
:: A second work area is in the control plane, which allows an ingress
:: node to map the "inner" (tenant VM) address into an "outer"
:: (underlying transport network) address in order to tunnel a packet
:: across the data center. We propose to develop two control planes. One
:: control plane will use a learning mechanism similar to IEEE 802.1D
:: learning, and could be appropriate for smaller data centers. A second,
:: more scalable control plane would be aimed at large sites, capable of
:: scaling to hundreds of thousands of nodes. Both control planes will
:: need to handle the case of VMs moving around the network in a dynamic
:: fashion, meaning that they will need to support tunnel endpoints
:: registering and deregistering mappings as VMs change location and
:: ensuring that out-of-date mapping tables are only used for short
:: periods of time. Finally, the second control plane must also be
:: applicable to geographically dispersed data centers.
:: 
:: Although a key objective of this WG is to produce a solution that
:: supports an L2 over L3 overlay, an important goal is to develop a
:: "layer agnostic" framework and architecture, so that any specific
:: overlay approach can reuse the output of this working group. For
:: example, there is no inherent reason why the same framework could not
:: be used to provide for L2 over L2 or L3 over L3. The main difference
:: would be in the address formats of the inner and outer headers and the
:: encapsulation header itself.
:: 
:: Finally, some work may be needed in connecting an overlay network with
:: traditional L2 or L3 VPNs (e.g., VPLS). One approach appears straight
:: forward, in that there is a clear boundary between a VPN device and
:: the edge of an overlay network. Packets forwarded across the boundary
:: would simply need to have the tenant identifier on the overlay side
:: mapped into a corresponding VPN identifier on the VPN
:: side. Conceptually, this would appear to be analogous to what is done
:: already today when interfacing between L2 VLANs and VPNs.
:: 
:: The specific deliverables for this group include:
:: 
:: 1) Finalize and publish the overall problem statement as an
:: Informational RFC (basis:
:: draft-narten-nvo3-overlay-problem-statement-01.txt)
:: 
:: 2) Develop requirements and desirable properties for any encapsulation
:: format, and identify suitable encapsulations. Given the number of
:: already existing encapsulation formats, it is not an explicit goal of
:: this effort to choose exactly one format or to develop a new one.
:: 
:: 3) Produce a Standards Track control plane document that specifies how
:: to build mapping tables using a "learning" approach. This document is
:: expected to be short, as the algorithm itself will use a mechanism
:: similar to IEEE 802.1D learning.
:: 
:: 4) Develop requirements (and later a Standards Track protocol) for a
:: more scalable control plane for managing and distributing the mappings
:: of "inner" to "outer" addresses. We will develop a reusable framework
:: suitable for use by any mapping function in which there is a need to
:: map "inner" to outer addresses. Starting point:
:: draft-kreeger-nvo3-overlay-cp-00.txt
:: 
:: _______________________________________________
:: nvo3 mailing list
:: [e-mail]
:: https://www.ietf.org/mailman/listinfo/nvo3
:: 

--------------------+----------------------+------------------
   Igor Gashinsky   | Network Architecture | Yahoo! Inc.
 [e-mail] |  cell 917.807.2213   | Do You... Yahoo?
--------------------+----------------------+------------------