Re: [dc] OVF "control plane" - Not a good idea

[Bhumip Khasnabish <[e-mail]>]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Network Virtualization Overlay Control Protocol Requirements
	Author(s)       : Lawrence Kreeger
                          Dinesh Dutt
                          Thomas Narten
                          David Black
                          Murari Sridharan
	Filename        : draft-kreeger-nvo3-overlay-cp-00.txt
	Pages           : 13
	Date            : 2012-01-30

   The document draft-narten-nvo3-overlay-problem-statement-01 discusses
   the needs for network virtualization using overlay networks in highly
   virtualized data centers.  The problem statement outlines a need for
   control protocols to facilitate running these overlay networks.  This
   document outlines the high level requirements to be fulfilled by the
   control protocols.


A URL for this Internet-Draft
is:http://www.ietf.org/internet-drafts/draft-kreeger-nvo3-overlay-cp-00.txt

Internet-Drafts are also available by anonymous FTP
at:ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved
at:ftp://ftp.ietf.org/internet-drafts/draft-kreeger-nvo3-overlay-cp-00.txt

I-D Action: draft-kreeger-nvo3-overlay-cp-00.txt
------------------------------

   - *To*: i-d-announce at ietf.org <[e-mail]>
   - *Subject*: I-D Action: draft-kreeger-nvo3-overlay-cp-00.txt
   - *From*: internet-drafts at ietf.org <[e-mail]>
   - *Date*: Mon, 30 Jan 2012 11:39:16 -0800
   - *Delivered-to*: i-d-announce at ietfa.amsl.com<[e-mail]>
   - *List-archive*: <http://www.ietf.org/mail-archive/web/i-d-announce>
   - *List-help*:
<mailto:[e-mail]?subject=help<[e-mail]?subject=help>>

   - *List-id*: Internet Draft Announcements only <i-d-announce.ietf.org>
   - *List-post*: <mailto:[e-mail] <[e-mail]>>
   - *List-subscribe*: <https://www.ietf.org/mailman/listinfo/i-d-announce>,
   <mailto:[e-mail]?subject=subscribe<[e-mail]?subject=subscribe>>

   - *List-unsubscribe*: <https://www.ietf.org/mailman/options/i-d-announce>,
   <mailto:[e-mail]?subject=unsubscribe<[e-mail]?subject=unsubscribe>>

   - *Reply-to*: internet-drafts at ietf.org <[e-mail]>

------------------------------

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Network Virtualization Overlay Control Protocol Requirements
	Author(s)       : Lawrence Kreeger
                          Dinesh Dutt
                          Thomas Narten

On Fri, Jan 20, 2012 at 8:22 PM, <[e-mail]> wrote:

> Ashish,
>
> Unfortunately, this is digging in the "wrong place" because it recreates
> the
> problem that OVF was designed to solve.  OVF is intended to be a
> self-contained
> packaging and distribution format that contains everything needed to
> instantiate
> one or more VMs.  As such, OVF can be moved by all of the protocols noted
> below,
> plus a variety of other means, such as sneaker-net.
>
> If OVF is insufficient for the portability use case, then I suggest going
> to DMTF
> to work on adding what's missing instead of inventing a "control plane"
> that is
> at odds with OVF's design intent.
>
> Thanks,
> --David
>
> > -----Original Message-----
> > From: Ashish Dalela (adalela) [mailto:[e-mail]]
> > Sent: Thursday, January 19, 2012 11:10 PM
> > To: Black, David
> > Cc: [e-mail]
> > Subject: RE: [dc] draft-khasnabish-vmmi-problems-00.txt
> >
> >
> > >> Was that supposed to be a serious question?
> >
> > Yes, it is a serious question, because VM mobility goes beyond the VM.
> >
> > >> If it was, I suggest FTP or NFS, both of which are already used to
> > move VM
> > >> images in practice, and are already specified in RFCs ;-).  OVF is
> > fundamentally
> > >> a VM image format.
> >
> > That's one approach. Another approach is to use a SOAP/REST APIs. Yet
> > another one is to define a cloud control plane, that does more than just
> > move VMs. E.g. when you move a VM, you have to move the firewall rules,
> > the VLAN association, the bandwidth, VRF configuration, GRE tunnel
> > configuration, etc.
> >
> > Thanks, Ashish
> >
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Friday, January 20, 2012 8:18 AM
> > To: Ashish Dalela (adalela)
> > Cc: [e-mail]
> > Subject: RE: [dc] draft-khasnabish-vmmi-problems-00.txt
> >
> > > - Do we need a "control plane" to transfer OVF specification from
> > point
> > > A to B - the portability problem?
> >
> > Was that supposed to be a serious question?
> >
> > If it was, I suggest FTP or NFS, both of which are already used to move
> > VM
> > images in practice, and are already specified in RFCs ;-).  OVF is
> > fundamentally
> > a VM image format.
> >
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Distinguished Engineer
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > [phone]             FAX: [phone]
> > [e-mail]        Mobile: [phone]
> > ----------------------------------------------------
> > ________________________________________
> > From: [e-mail] [[e-mail]] On Behalf Of Ashish
> > Dalela (adalela) [[e-mail]]
> > Sent: Thursday, January 19, 2012 8:20 PM
> > To: Thomas Narten; Steven Blake
> > Cc: [e-mail]
> > Subject: Re: [dc] draft-khasnabish-vmmi-problems-00.txt
> >
> > I think it is fair to say that there is a difference between mobility
> > and portability. Mobility is live migration, but portability is
> > specifying a VM's properties, delete in one location and create in
> > another. The new location can be another hypervisor. In many cases, you
> > don't need mobility, just portability. E.g. if you have a disaster
> > recovery situation, then you aren't going to get mobility anyway.
> >
> > DMTF has specified a standard called OVF (Open Virtualization Format)
> > that addresses the "description" of the VM. This format is supported by
> > various hypervisor vendors. So, some level of VM migration
> > standardization has already happened (albeit portability and not
> > mobility).
> >
> > The questions are:
> >
> > - Do we need a "control plane" to transfer VM state from point A to B -
> > the mobility problem?
> > - Do we need a "control plane" to transfer OVF specification from point
> > A to B - the portability problem?
> >
> > The problem is relevant in the inter-datacenter, public-private, or
> > inter-cloud spaces, where there will be more than one hypervisor
> > controller by definition. Are we hitting the live migration issue today?
> > Maybe not. Is it conceivable that we will hit this issue? I think so.
> >
> > However, the question has to be asked to the provider/operators and not
> > to the vendors.
> >
> > Thanks, Ashish
> >
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
> > Thomas Narten
> > Sent: Thursday, January 19, 2012 11:17 PM
> > To: Steven Blake
> > Cc: [e-mail]
> > Subject: Re: [dc] draft-khasnabish-vmmi-problems-00.txt
> >
> > Steven,
> >
> > > Several system vendors (myself included) stood up in Taipei and said
> > > "one encapsulation, please".  If IETF can facilitate industry
> > > convergence on a small set of NVO3 encapsulations (preferably one),
> > that
> > > would be a big win for Ethernet switch vendors.
> >
> > I agree completely.
> >
> > But my questions were asking about the apparent lack of  interest from
> > operators/implementers/market players regarding Bhumip's draft and the
> > apparent desire to have some sort of standards work related to the
> > general VM migration problem.
> >
> > Is there such interest?
> >
> > Thomas
> >
> > _______________________________________________
> > dc mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dc
> > _______________________________________________
> > dc mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dc
>
> _______________________________________________
> dc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dc
>