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

[Bhumip Khasnabish <[e-mail]>]

Bhumip Khasnabish [e-mail]
To Christopher LILJENSTOLPE [e-mail]
ccThomas Narten <[e-mail]>, Ronald Bonica <[e-mail]>,
[e-mail],"So, Ning" <[e-mail]>
date Fri, Dec 30, 2011 at 12:56 PM
subjectRe: [dc] Elevator Pitch (was: Scoping the Interim meeting)

mailed-bygmail.com

hide details 12/30/11

Hello Chris,

Thank you very much for your comments and suggestions.

If you do not mind, please provide write ups, as appropriate, on Amazon
API, ONF, OpenFlow, Open Stack, etc. that you mention below for inclusion
in the next version of the SDO survey draft.

For the work item survey draft, the intention is to provide a list. We have
seen many follow up drafts during the last two IETF mtgs articulating
problems and possible solutions  (VDCS, VPN4DC, VEPC, VPN-O-CS, VPN-O-DCS,
VRM, security framework for VDCS, etc.) from both service providers and
solution providers.

We'll be updating this draft soon, and can work on providing priority, if
that is helpful.

*If we want to work on one near-term high-priority work item, may be
virtual machine (and virtual network element) mobility and interconnection
can be the focus..(may be we need to use distributed control, distributed
hash, etc.) *

Any others?

Thanks and best wishes.

Bhumip
===========================================================

On Tue, Jan 31, 2012 at 12:24 PM, <[e-mail]> wrote:

>  OVF is not mentioned anywhere in that draft because:****
>
> ** **
>
> “OVF is intended to be a self-contained packaging and distribution format”
> ****
>
> ** **
>
> OVF is not generally used as a runtime execution format for VMs.****
>
> ** **
>
> Thanks,
> --David (draft co-author)
>
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
> ****
>
> ** **
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of *Bhumip
> Khasnabish
> *Sent:* Tuesday, January 31, 2012 12:10 PM
> *To:* Black, David
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [dc] OVF "control plane" - Not a good idea****
>
> ** **
>
> *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****
>
>
>
>
>   ****
>