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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Fri, 19 August 2011 13:45 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 C41C621F86E0 for <sami@ietfa.amsl.com>; Fri, 19 Aug 2011 06:45:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.088
X-Spam-Level:
X-Spam-Status: No, score=-103.088 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 haDqmr7lcotd for <sami@ietfa.amsl.com>; Fri, 19 Aug 2011 06:45:22 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B316321F8B32 for <sami@ietf.org>; Fri, 19 Aug 2011 06:45:21 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 424E320C1D; Fri, 19 Aug 2011 15:46:16 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XSYivolhoooc; Fri, 19 Aug 2011 15:46:15 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0AFE320C18; Fri, 19 Aug 2011 15:45:44 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 6D3FF1A34CC8; Fri, 19 Aug 2011 15:45:37 +0200 (CEST)
Date: Fri, 19 Aug 2011 15:45:37 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "Yingjie Gu(yingjie)" <guyingjie@huawei.com>
Message-ID: <20110819134536.GC28373@elstar.local>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <004c01cc5da6$5adb5660$10920320$@com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: 'Melinda Shore' <melinda.shore@gmail.com>, 'Fan Yongbing' <fanyb@gsta.com>, sami@ietf.org
Subject: Re: [sami] Welcome to SAMI and something you may like to know.
X-BeenThere: sami@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
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: Fri, 19 Aug 2011 13:45:22 -0000

On Thu, Aug 18, 2011 at 08:57:15PM +0800, Yingjie Gu(yingjie) wrote:

> The scope of State migration, i.e. the scope of VM migration, is
> within a Layer 2 subnet, which guarantees that VM's IP address can
> keep unchanged. Though some technologies can enable VM migrates
> between different subnets and keep the IP address unchanged, most
> requirements for VM migration is within the same L2 subnet for now.

Those setups that I have seen (but I have not seen too many and
usually smaller onces) have a single L2 network _behind_ firewalls and
load balancers and hence there is almost no state to migrate when a VM
moves. It appears to me that people design their networks to make
migration feasible (by making it a single L2 network) instead of
trying to migrate across arbitrary network topologies.

For me, the problem becomes interesting for the IETF when someone
wants to migrate a VM from one IP subnet to another IP subnet. In that
case, we have some form of IP mobility (since the IP connectivity
changes) and depending on the nature of the applications running on
the VMs, there might be some period in which some tunneling is needed
(because the state associated with existing transport connections in
middleboxes is likely harder to migrate correctly than doing some
mobile IP like tunneling). Some people said in Quebec that we can
ignore the IP addressing issues and just focus on the state migration
but I feel that is wrong because the way you deal with the mobility at
the IP level will have impact on how much state needs migration or
whether any operational state needs to be migrated at all (and my
personal preference would be to design the network to avoid the need
for state migration - that is to produce guidelines or best practices
to follow rather than producing more special purpose standards).

To what extend this is a real-world problem and to what extend vendors
of middle-boxes are interested to implement a standard in this area, I
do not know. But a good indication of interest is usually that some of
those vendors actively participate in the specification of a solution.

As stated in Quebec, to me this still sounds more like a research
effort than a standardization effort but I am happy to get convinced
otherwise.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>