Re: [nvo3] Draft NVO3 WG Charter

[<[e-mail]>]

Yakov,

> However, I don't recall seeing
> an e-mail from you suggesting to remove item 4 from the charter.
> Did I miss it ?

Nope.  The original question was about why BGP and MPLS might be non-starters
for some data centers.  I explained in terms of the level of disruption for data
centers that aren't running either BGP or MPLS (and there are a lot of them).

Now, you seem to be advocating that a data center that can't accept the
disruptive introduction of BGP and MPLS can't accept any level of disruption
(independent of the attempt to ascribe that reasoning to me, it's not what I
wrote).  Needless to say, that's silly.  Are you really advocating that position?

The disruption under discussion is not binary, but ranges across a scale of impact
depending on the degree of change.  There are likely to be alternative approaches
to the scaling problem in charter item 4 that are less disruptive than
introduction of BGP/MPLS, and degree of disruption is something that should be
germane to looking at alternative approaches to this problem area.

For example, Pedro appears to have just confirmed that the l3vpn-end-system draft
made a design choice that breaks existing live VM migration implementations in
favor of improving network convergence.  A data center currently running one of
those existing VM live migration implementations may well prefer a less disruptive
scaling approach that doesn't have that side effect.

Thanks,
--David

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Yakov Rekhter
> Sent: Tuesday, February 21, 2012 8:32 AM
> To: Black, David
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail];
 > [e-mail]
> Subject: Re: [nvo3] Draft NVO3 WG Charter
> 
> 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.
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3