Re: [dc] draft-khasnabish-vmmi-problems-00.txt

Bhumip Khasnabish <vumip1@gmail.com> Wed, 18 January 2012 06:33 UTC

Return-Path: <vumip1@gmail.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 58DEE21F8691 for <dc@ietfa.amsl.com>; Tue, 17 Jan 2012 22:33:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.44
X-Spam-Level:
X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 REZPPDoyURzN for <dc@ietfa.amsl.com>; Tue, 17 Jan 2012 22:33:50 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA64D21F8693 for <dc@ietf.org>; Tue, 17 Jan 2012 22:33:50 -0800 (PST)
Received: by iaae16 with SMTP id e16so12714534iaa.31 for <dc@ietf.org>; Tue, 17 Jan 2012 22:33:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EJcU/EzZ/N7uM+9hW/32cbjYtsUzkVcH4TqboXrUg5s=; b=Lp0K2wvfhNLoS/OtKOzSgJGy5vyLwnW98c7Wja1Pp9Uwc20rfWmgIFXNlpLmuc0l2v FO/SfSAPHkiJBzROfYb3UHyZW/x3nXj09erw6bsxvzoZUytlxvPGKiHa8Wth/UuiInP1 Zg0tzZPJam1zBff3sSpHU7Z0ldi/GF2Cm5UA8=
MIME-Version: 1.0
Received: by 10.50.195.227 with SMTP id ih3mr21191117igc.19.1326868430288; Tue, 17 Jan 2012 22:33:50 -0800 (PST)
Received: by 10.50.209.98 with HTTP; Tue, 17 Jan 2012 22:33:50 -0800 (PST)
In-Reply-To: <201201171540.q0HFeNan008591@cichlid.raleigh.ibm.com>
References: <CAH==cJxfmae0u0bSF4cn_haLgY1T-vnw2102PApzYtj5Aty=GQ@mail.gmail.com> <CANtnpwhFJ746ooi9GUCxfBqsOXu14hDka0D9inhh5pPq3U_ZTA@mail.gmail.com> <201201171540.q0HFeNan008591@cichlid.raleigh.ibm.com>
Date: Wed, 18 Jan 2012 01:33:50 -0500
Message-ID: <CANtnpwjexDPazOXLYHHjn3+JDi-o49Bv5ptDExAZHAA8Ra2m-A@mail.gmail.com>
From: Bhumip Khasnabish <vumip1@gmail.com>
To: Thomas Narten <narten@us.ibm.com>
Content-Type: multipart/alternative; boundary="14dae934127373753b04b6c7a154"
Cc: dc@ietf.org
Subject: Re: [dc] draft-khasnabish-vmmi-problems-00.txt
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: Wed, 18 Jan 2012 06:33:51 -0000

Tom,

Thanks.

Yes, seamless migration of VM and VNE can be problematic in both intra- and
inter-data-center environments, especially in multi-hypervisor case.

It may be very helpful to bring one or more of these
proprietary VM migration approaches to IETF for consideration
for standardization, if that is appropriate.
Sure, we'll update the draft to articulate these requirements.

Best.

Bhumip


On Tue, Jan 17, 2012 at 10:40 AM, Thomas Narten <narten@us.ibm.com> wrote:

> Bhumip,
>
> I skimmed this document and am having trouble figuring out what it is
> intended to do.
>
> The draft name itself has "problem" in it, but there is no single (or
> small set of) succinct problems listed. It's all very high level and
> hand wavy. I need help making the connection to an IETF action that
> could come out of this document.
>
> For example, it talks about VM migration.
>
> Is VM Migration a "problem" today? There are properietary approaches
> that the market seems to like OK.
>
> What is wrong with the current approaches? What is "broken" that needs
> fixing? Why should the IETF get involved in this space? What value
> would the IETF bring?
>
> Do you want to be able to do VM migration from one vendor's hypervisor
> to another vendor's?  If so, please just say so. Then we can see
> whether others here think that is an area the IETF (or some other SDO)
> should get involved in.
>
> Thomas
>
>