Re: [sami] Trying to figure out where we are

"Yingjie Gu(yingjie)" <guyingjie@huawei.com> Wed, 24 August 2011 05:39 UTC

Return-Path: <guyingjie@huawei.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 7AD9D21F8B25 for <sami@ietfa.amsl.com>; Tue, 23 Aug 2011 22:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.151
X-Spam-Level:
X-Spam-Status: No, score=-103.151 tagged_above=-999 required=5 tests=[AWL=0.659, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, 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 u1wMhHQ0+x1i for <sami@ietfa.amsl.com>; Tue, 23 Aug 2011 22:39:45 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id A448C21F8BAD for <sami@ietf.org>; Tue, 23 Aug 2011 22:39:45 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQF0057C3OWUV@szxga04-in.huawei.com> for sami@ietf.org; Wed, 24 Aug 2011 13:38:56 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQF00CHW3OW4Q@szxga04-in.huawei.com> for sami@ietf.org; Wed, 24 Aug 2011 13:38:56 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADJ47152; Wed, 24 Aug 2011 13:38:55 +0800 (CST)
Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 24 Aug 2011 13:38:52 +0800
Received: from g00107907 (10.138.41.134) by szxeml412-hub.china.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 24 Aug 2011 13:38:55 +0800
Date: Wed, 24 Aug 2011 13:39:45 +0800
From: "Yingjie Gu(yingjie)" <guyingjie@huawei.com>
In-reply-to: <4E541EE7.1080605@gmail.com>
X-Originating-IP: [10.138.41.134]
To: 'Melinda Shore' <melinda.shore@gmail.com>, sami@ietf.org
Message-id: <000c01cc6220$3b18fa70$b14aef50$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset="gb2312"
Content-language: zh-cn
Content-transfer-encoding: quoted-printable
Thread-index: Acxh3bbVu6B/JRyFQG6Szg/adcVTmwAQGBGQ
X-CFilter-Loop: Reflected
References: <CA77E180.13DD5%bschlies@cisco.com> <4E541EE7.1080605@gmail.com>
Subject: Re: [sami] Trying to figure out where we are
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: Wed, 24 Aug 2011 05:39:46 -0000

I think we are still on the right way to move forward. 
We need to hear different voice so that we can know what go to people's mind
when they see "State Migration".

For now, we have heard different opinions, e.g. 
'state migration for service failover' 
'need differentiate requirements for Optimization-based migration and
restoration-based migration', 
'layer 2 connectivity over L3 infrastructure', 
'think about IP mobility instead of state migration'
'services running on VM will impact the way of state migration' and many
others. 
Sorry that I don't list all of the input. 
Though not all of them will finally be in scope, or we finally fail to
charter a workable scope in IETF, they are highly valuable input for scope
discussion. 
Thank you very much.

Meanwhile, I also try to ask DC provider to share their use cases. China
Telecom and China Mobile, who are also looking forward to become DC
provider, see the concrete requirements and prepare to write down a draft to
introduce the use cases in real scenarios. But they may introduce some use
cases to mail list before the draft is completed.


Best Regards
Gu Yingjie


-----邮件原件-----
发件人: sami-bounces@ietf.org [mailto:sami-bounces@ietf.org] 代表 Melinda
Shore
发送时间: 2011年8月24日 乐乐5:43
收件人: sami@ietf.org
主题: [sami] Trying to figure out where we are

As the discussion has progressed it's become more-or-less clear
that there might possibly perhaps be one or two interesting
problems here, maybe, although the people pushing for the
chartering of something-or-other (anything!) to do with
data centers and virtualization seem to be working very hard
indeed to obscure anything that might turn out to have some
value.

First, there appears to be a substantial problem related to
moving flow-associated state in middleboxes when a network
connection (deliberately keeping "connection" vague for the
moment) fails over.  This has certainly come up in the context
of multihomed connections in sctp, and to be honest I
haven't followed that as closely as I should.  Still, even
if sctp has something that works brilliantly there would be
questions about applying their mechanism in a different
context.

Second, there appears to be another substantial problem,
this one related to how to handle routing and network
state when a VM is migrated from one hypervisor to a
network-topographically-remote hypervisor when both are
on the same layer 2 subnet being tunneled over a layer
3 transport (or when they're not on the same subnet
at all, which I gather is considerably less common).

The problem here is that it's not at all clear that there's
a constituency for the work.  I'm not talking about people
to write and review internet drafts, but rather companies
standing up and saying "We want this problem solved and we
think it should be solved through an open standards process,"
and data centers/service providers standing up and saying
"We would deploy this."  Saying that you're absolutely
certain that somebody else would say one of these things
does not count.

It would be unfortunate if the IETF were to sink valuable
resources into another effort that nobody cares about
other than people looking for stuff to put on their CV.
Is there an audience for this work?

Melinda
_______________________________________________
sami mailing list
sami@ietf.org
https://www.ietf.org/mailman/listinfo/sami