Re: [nvo3] Draft NVO3 WG Charter

[<[e-mail]>]

John,

> This basically is a re-statement of what is done by L3/L2 VPNs.  It'
> might be useful to do a gap analysis of these existing technologies,
> in particular E-VPNs (http://tools.ietf.org/html/draft-raggarwa-sajassi-l2vpn-evpn-04),
> before asserting that something new is required.
BGP and MPLS are non-starters for a lot of datacenter-internal networks.
Some of the more important NVO deployment scenarios involve map-and-encap
in a hypervisor software network switch.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]<mailto:[e-mail]>        Mobile: [phone]
----------------------------------------------------
________________________________
From: [e-mail] [[e-mail]] On Behalf Of John E Drake [[e-mail]]
Sent: Friday, February 17, 2012 10:00 AM
To: Thomas Narten; [e-mail]
Cc: Ronald Bonica; Nitin Bahadur; Adrian Farrel
Subject: Re: [nvo3] Draft NVO3 WG Charter

Thomas,

This basically is a re-statement of what is done by L3/L2 VPNs.  It might be useful to do a gap analysis of these existing technologies, in particular E-VPNs (http://tools.ietf.org/html/draft-raggarwa-sajassi-l2vpn-evpn-04), before asserting that something new is required.

Thanks,

John

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Thomas Narten
> Sent: Friday, February 17, 2012 6:52 AM
> To: [e-mail]
> Subject: [nvo3] Draft NVO3 WG Charter
>
> 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
_______________________________________________
nvo3 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nvo3