Re: [nvo3] Draft NVO3 WG Charter

[<[e-mail]>]

Pedro,

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

Could you supply the details of how it's a non-issue, including the
network response to the gratuitous ARPs and RARPs issued by existing
hypervisors?  Those details are not in the draft, and you might want
to put them into a revised version of the draft.

My interest is not so much in the requirements of VMs in principle,
but how this will co-exist in practice with existing hypervisor deployments.

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

They generally do not use direct L2 storage access.  An FCoE initiator
in a VM would perform direct L2 storage access, but that's not a good
idea because most hypervisor softswitches do not support the DCB Ethernet
functionality required by FCoE.  Hypervisor use of FCoE is typically a
static configuration - a moved VM uses the destination hypervisor's FCoE
to access its storage, and does not move its FCoE session/connection
across hypervisors.  iSCSI, NFS and CIFS all use IP.

Thanks,
--David

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