Re: [nvo3] Draft NVO3 WG Charter

[Yakov Rekhter <[e-mail]>]

David,

> Hi John,
> 
> > > BGP and MPLS are non-starters for a lot of datacenter-internal
> > > networks.
> >
> > [JD]  This is an assertion.  It is also the misses the fact that MPLS
> > is only required to mux/demux packets at the edges of the VPN network.
> 
> Indeed it is, but I stand by it.  The interesting "edges of the VPN
> network" for NVO include datacenter ToR switches, datacenter access
> switches and hypervisor softswitches - there are plenty of examples of
> these for which MPLS and BGP are non-starters.

What are the specific *technical* reason(s) why MPLS over GRE is
a "non-starter" for (a) ToR switches, (b) datacenter access switches,
and (c) hypervisor softswitches ?

Yakov.

> I suggest reading the NVGRE and VXLAN drafts for more context:
> 
>    http://tools.ietf.org/html/draft-sridharan-virtualization-nvgre-00
>    http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-00
> 
> 
> 
> 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]
754
> ----------------------------------------------------
> ________________________________
> From: John E Drake [[e-mail]]
> Sent: Friday, February 17, 2012 11:13 AM
> To: Black, David; [e-mail]; [e-mail]
> Cc: Ronald Bonica; Nitin Bahadur; Adrian Farrel
> Subject: RE: [nvo3] Draft NVO3 WG Charter
> 
> Comments inline
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Friday, February 17, 2012 8:04 AM
> > To: John E Drake; [e-mail]; [e-mail]
> > Cc: Ronald Bonica; Nitin Bahadur; Adrian Farrel
> > Subject: RE: [nvo3] Draft NVO3 WG Charter
> >
> > 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.
> 
> [JD]  This is an assertion.  It is also the misses the fact that MPLS is only
 required to mux/demux packets at the edges of the VPN network.
> 
> > Some of the more important NVO deployment scenarios involve map-and-
> > encap in a hypervisor software network switch.
> 
> [JD]  Your point eludes me.
> 
> >
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Distinguished Engineer
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > [phone]             FAX: [phone]
> > [e-mail]<mailto:[e-mail]>        Mobile: +1 (978)
> > 394-7754
> > ----------------------------------------------------
> > ________________________________
> > 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
> 
> 
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3