Re: [nvo3] Draft NVO3 WG Charter

[Pedro Marques <[e-mail]>]

David,

On Tue, Feb 21, 2012 at 8:38 AM,  <[e-mail]> wrote:
> 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.

You misunderstood my message. My point is that for live migration L2
transparency is not relevant but convergence time is quite critical.

I've not understood why you believe that the proposal "breaks live
migration" specially after i pointed out that the routing
configuration on the VM is a non-issue.

>  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.

It is unclear to me whether you the "existing VM live migration
implementations" that you are referring to perform storage access via
direct L2 protocols. Direct L2 storage access is indeed a tradeoff
versus scaling.

That tradeoff maybe attractive to small scale deployments while
completely unacceptable to large scale ones. That is one of the things
to keep in mind when the IETF considers data from "existing
implementations".

>
> 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
>
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3