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

<david.black@emc.com> Tue, 31 January 2012 17:25 UTC

Return-Path: <david.black@emc.com>
X-Original-To: dc@ietfa.amsl.com
Delivered-To: dc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A3321F8600 for <dc@ietfa.amsl.com>; Tue, 31 Jan 2012 09:25:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.322
X-Spam-Level:
X-Spam-Status: No, score=-109.322 tagged_above=-999 required=5 tests=[AWL=1.276, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyfHP6ZxbSDV for <dc@ietfa.amsl.com>; Tue, 31 Jan 2012 09:25:01 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6823A21F85F0 for <dc@ietf.org>; Tue, 31 Jan 2012 09:25:01 -0800 (PST)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0VHOuXf002165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jan 2012 12:24:57 -0500
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 31 Jan 2012 12:24:41 -0500
Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com [10.254.141.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0VHOfwM006050; Tue, 31 Jan 2012 12:24:41 -0500
Received: from mx14a.corp.emc.com ([169.254.1.94]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Tue, 31 Jan 2012 12:24:40 -0500
From: david.black@emc.com
To: vumip1@gmail.com
Date: Tue, 31 Jan 2012 12:24:40 -0500
Thread-Topic: [dc] OVF "control plane" - Not a good idea
Thread-Index: AczgOzAWxjO01PWTQ6yUQnbpuZ2vwQAAcyhw
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05AD13AF5A@MX14A.corp.emc.com>
References: <CAH==cJxfmae0u0bSF4cn_haLgY1T-vnw2102PApzYtj5Aty=GQ@mail.gmail.com> <CANtnpwhFJ746ooi9GUCxfBqsOXu14hDka0D9inhh5pPq3U_ZTA@mail.gmail.com> <201201171540.q0HFeNan008591@cichlid.raleigh.ibm.com> <CANtnpwjexDPazOXLYHHjn3+JDi-o49Bv5ptDExAZHAA8Ra2m-A@mail.gmail.com> <201201191419.q0JEJTLF010649@cichlid.raleigh.ibm.com> <1326989277.2513.4.camel@ecliptic.extremenetworks.com> <201201191747.q0JHlS5J015128@cichlid.raleigh.ibm.com> <618BE8B40039924EB9AED233D4A09C5102CB2304@XMB-BGL-416.cisco.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7BB90E7@MX14A.corp.emc.com> <618BE8B40039924EB9AED233D4A09C5102CB2326@XMB-BGL-416.cisco.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7CF1290@MX14A.corp.emc.com> <CANtnpwi8eHBBFDohoMQBi7bSJWdvvqn4yas8A3GXm5+JCAi-qw@mail.gmail.com>
In-Reply-To: <CANtnpwi8eHBBFDohoMQBi7bSJWdvvqn4yas8A3GXm5+JCAi-qw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7C4DFCE962635144B8FAE8CA11D0BF1E05AD13AF5AMX14Acorpemcc_"
MIME-Version: 1.0
X-EMM-MHVC: 1
Cc: adalela@cisco.com, dc@ietf.org
Subject: Re: [dc] OVF "control plane" - Not a good idea
X-BeenThere: dc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Data Center Mailing List <dc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dc>, <mailto:dc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dc>
List-Post: <mailto:dc@ietf.org>
List-Help: <mailto:dc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dc>, <mailto:dc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Jan 2012 17:25:05 -0000

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
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of Bhumip Khasnabish
Sent: Tuesday, January 31, 2012 12:10 PM
To: Black, David
Cc: adalela@cisco.com; dc@ietf.org
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<mailto:i-d-announce@DOMAIN.HIDDEN>
 *   Subject: I-D Action: draft-kreeger-nvo3-overlay-cp-00.txt
 *   From: internet-drafts at ietf.org<mailto:internet-drafts@DOMAIN.HIDDEN>
 *   Date: Mon, 30 Jan 2012 11:39:16 -0800
 *   Delivered-to: i-d-announce at ietfa.amsl.com<mailto:i-d-announce@DOMAIN.HIDDEN>
 *   List-archive: <http://www.ietf.org/mail-archive/web/i-d-announce>
 *   List-help: <mailto:i-d-announce-request@ietf.org?subject=help>
 *   List-id: Internet Draft Announcements only <i-d-announce.ietf.org<http://i-d-announce.ietf.org>>
 *   List-post: <mailto:i-d-announce@ietf.org>
 *   List-subscribe: <https://www.ietf.org/mailman/listinfo/i-d-announce>, <mailto:i-d-announce-request@ietf.org?subject=subscribe>
 *   List-unsubscribe: <https://www.ietf.org/mailman/options/i-d-announce>, <mailto:i-d-announce-request@ietf.org?subject=unsubscribe>
 *   Reply-to: internet-drafts at ietf.org<mailto:internet-drafts@DOMAIN.HIDDEN>

________________________________

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, <david.black@emc.com<mailto:david.black@emc.com>> 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:adalela@cisco.com<mailto:adalela@cisco.com>]
> Sent: Thursday, January 19, 2012 11:10 PM
> To: Black, David
> Cc: dc@ietf.org<mailto:dc@ietf.org>
> 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: david.black@emc.com<mailto:david.black@emc.com> [mailto:david.black@emc.com<mailto:david.black@emc.com>]
> Sent: Friday, January 20, 2012 8:18 AM
> To: Ashish Dalela (adalela)
> Cc: dc@ietf.org<mailto:dc@ietf.org>
> 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
> +1 (508) 293-7953<tel:%2B1%20%28508%29%20293-7953>             FAX: +1 (508) 293-7786<tel:%2B1%20%28508%29%20293-7786>
> david.black@emc.com<mailto:david.black@emc.com>        Mobile: +1 (978) 394-7754<tel:%2B1%20%28978%29%20394-7754>
> ----------------------------------------------------
> ________________________________________
> From: dc-bounces@ietf.org<mailto:dc-bounces@ietf.org> [dc-bounces@ietf.org<mailto:dc-bounces@ietf.org>] On Behalf Of Ashish
> Dalela (adalela) [adalela@cisco.com<mailto:adalela@cisco.com>]
> Sent: Thursday, January 19, 2012 8:20 PM
> To: Thomas Narten; Steven Blake
> Cc: dc@ietf.org<mailto:dc@ietf.org>
> 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: dc-bounces@ietf.org<mailto:dc-bounces@ietf.org> [mailto:dc-bounces@ietf.org<mailto:dc-bounces@ietf.org>] On Behalf Of
> Thomas Narten
> Sent: Thursday, January 19, 2012 11:17 PM
> To: Steven Blake
> Cc: dc@ietf.org<mailto:dc@ietf.org>
> 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
> dc@ietf.org<mailto:dc@ietf.org>
> https://www.ietf.org/mailman/listinfo/dc
> _______________________________________________
> dc mailing list
> dc@ietf.org<mailto:dc@ietf.org>
> https://www.ietf.org/mailman/listinfo/dc

_______________________________________________
dc mailing list
dc@ietf.org<mailto:dc@ietf.org>
https://www.ietf.org/mailman/listinfo/dc