[sami] Scope [was Re: Welcome to SAMI and something you may like to know.]

Melinda Shore <melinda.shore@gmail.com> Thu, 18 August 2011 20:29 UTC

Return-Path: <melinda.shore@gmail.com>
X-Original-To: sami@ietfa.amsl.com
Delivered-To: sami@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4CB21F8AA9 for <sami@ietfa.amsl.com>; Thu, 18 Aug 2011 13:29:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level:
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 nK2YnDcYk25o for <sami@ietfa.amsl.com>; Thu, 18 Aug 2011 13:29:53 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 92EC421F8A69 for <sami@ietf.org>; Thu, 18 Aug 2011 13:29:53 -0700 (PDT)
Received: by pzk33 with SMTP id 33so5881588pzk.18 for <sami@ietf.org>; Thu, 18 Aug 2011 13:30:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=u3H/KfLCm7gm5Uiu083zIaTvCujUsLvGy3PKZ0ydISw=; b=YIVokIj1+vXkt2Y1xM8TxUC/qr6z+DFlQQBZu40CftjAzhPPsmObQT01yRgh8LPc53 v1qYsMXmtAUOBbSH1vQpNiph+yhoXuN71MTnhF13Dxt8pr2quKN+C6P/3sgNbB4oZR77 8K7QILWEcK8qFuQmDSxo/ZdDpzq50H+lz0swg=
Received: by 10.142.215.4 with SMTP id n4mr625208wfg.187.1313699448475; Thu, 18 Aug 2011 13:30:48 -0700 (PDT)
Received: from [137.229.12.236] (drake.swits.alaska.edu [137.229.12.236]) by mx.google.com with ESMTPS id i8sm1726824pbi.76.2011.08.18.13.30.46 (version=SSLv3 cipher=OTHER); Thu, 18 Aug 2011 13:30:47 -0700 (PDT)
Message-ID: <4E4D767C.3090909@gmail.com>
Date: Thu, 18 Aug 2011 12:30:52 -0800
From: Melinda Shore <melinda.shore@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10
MIME-Version: 1.0
To: sami@ietf.org
References: <004c01cc57ec$7f602ed0$7e208c70$@com> <20110811074034.GA12533@elstar.local> <005701cc5806$03cd8370$0b688a50$@com> <4A95BA014132FF49AE685FAB4B9F17F605189C80@dfweml504-mbx.china.huawei.com> <006001cc5cbb$de6c48e0$9b44daa0$@com> <4E4C6214.3010800@gmail.com> <12969308CE9E48DEAB5B5745D9482303@fanybP> <004c01cc5da6$5adb5660$10920320$@com>
In-Reply-To: <004c01cc5da6$5adb5660$10920320$@com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [sami] Scope [was Re: Welcome to SAMI and something you may like to know.]
X-BeenThere: sami@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: State Migration <sami.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sami>, <mailto:sami-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sami>
List-Post: <mailto:sami@ietf.org>
List-Help: <mailto:sami-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sami>, <mailto:sami-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Aug 2011 20:29:54 -0000

I have to admit that I'm becoming more confused rather than less
as the discussions progress.

1) My understanding earlier was that we were talking about failing
    over services between existing VMs rather than copying a VM as
    part of a failover.  Is anybody actually doing that?  Aren't you
    concerned that you'll be copying the failed state?

2) If you're copying a live VM, along with its runtime  state
    (i.e. memory), things like IP addresses, MAC addresses, and
    so on will be moving with it.  If the VM stays on the same
    subnet presumably it will be behind the same middlebox.  The
    only thing I could think of that might become an issue is the
    MAC address being mapped to a particular switch port.  What
    network state do you think will need to move with a VM
    relocation on the same subnet?

It seems to me that there's some interesting work here regarding
transferring middlebox state when the service is being failed over,
not so much when a VM is just being shuttled around a subnet (and
I'm not sure that really happens, anyway).  That said, if what's
at issue is middlebox state moving that probably belongs in the
transport area rather than the ops area.  But first, let's figure
out what's actually under discussion.

Melinda