Re: [nvo3] Draft NVO3 WG Charter

[Yakov Rekhter <[e-mail]>]

David,

> Yakov,
> 
> > 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 ?
> 
> Sure, that was on my list of things to do, so thanks for asking, but
> my original assertion was:
> 
> > > > > BGP and MPLS are non-starters for a lot of datacenter-internal
> > > > > networks.
> 
> Let's start with one of the more important problems that has motivated
> interest in overlays for virtual networking.  From the proposed charter:
> 
>    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).  
> 
> In these datacenters, there is a sizeable population of virtual machines
> running using VLANs.  In a bit more detail, that means:
> 	- Data Plane: TCP/IP, Ethernet VLANs
> 	- Control Plane: IP Routing based on IGPs (e.g., OSPF), VLAN
> 		configuration, LLDP, etc.
> Beyond that, management, operational practices and network admin skills
> are matched to the environment.
> 
> Again from the proposed charter:
> 
>    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.
> 
> This is an incremental growth problem - the datacenter is running fine
> with VLANs, but VLAN address space is being exhausted.  The solution
> should be incremental in impact and incrementally deployable.
> 
> Taking a look at MPLS and BGP, and assuming that the gaps previously
> pointed out in the marques-l3vpn-end-system draft are addressed, I see
> the following:
> 	- Introduce new data plane: MPLS
> 	- Introduce new control plane: BGP
> 	- Significant changes to management and operational practices
> 	- New network admin skills required
> That's not the best incremental impact story.  The last one is particularly
> important.

>From the proposed charter:

  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

Developing a new (Standards Track) protocol would introduce:

   - new control plane 
   - significant changes to management and operational practices
   - new network admin skills required

So, developing a new protocol, as proposed in the charter, is
certainly "not the best incremental impact story". Thus, following
your line of reasoning, item 4 (developing a Standards Track protocol)
should be removed from the charter. However, I don't recall seeing
an e-mail from you suggesting to remove item 4 from the charter.
Did I miss it ?

Yakov.