Re: [sami] Trying to figure out where we are
"zhangyunfei" <zhangyunfei@chinamobile.com> Wed, 24 August 2011 06:04 UTC
Return-Path: <zhangyunfei@chinamobile.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 5716B21F8B3F for <sami@ietfa.amsl.com>;
Tue, 23 Aug 2011 23:04:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.733
X-Spam-Level:
X-Spam-Status: No, score=-95.733 tagged_above=-999 required=5 tests=[AWL=0.101,
BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753,
MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, 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 vPr6WugGQl5o for
<sami@ietfa.amsl.com>; Tue, 23 Aug 2011 23:04:04 -0700 (PDT)
Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135])
by ietfa.amsl.com (Postfix) with ESMTP id BF42421F86DD for <sami@ietf.org>;
Tue, 23 Aug 2011 23:04:03 -0700 (PDT)
Received: from imss.chinamobile.com (localhost [127.0.0.1]) by
localhost.chinamobile.com (Postfix) with ESMTP id 4A194A473;
Wed, 24 Aug 2011 14:05:10 +0800 (CST)
Received: from mail.chinamobile.com (unknown [10.1.28.22]) by
imss.chinamobile.com (Postfix) with ESMTP id 2D994A45B;
Wed, 24 Aug 2011 14:05:10 +0800 (CST)
Received: from zyf-PC ([10.2.2.8]) by mail.chinamobile.com (Lotus Domino
Release 6.5.6) with ESMTP id 2011082414042969-9592 ;
Wed, 24 Aug 2011 14:04:29 +0800
Date: Wed, 24 Aug 2011 14:03:54 +0800
From: "zhangyunfei" <zhangyunfei@chinamobile.com>
To: "Yingjie Gu(yingjie)" <guyingjie@huawei.com>,
"'Melinda Shore'" <melinda.shore@gmail.com>, "sami@ietf.org" <sami@ietf.org>
References: <CA77E180.13DD5%bschlies@cisco.com> <4E541EE7.1080605@gmail.com>
<000c01cc6220$3b18fa70$b14aef50$@com>
Message-ID: <201108241403546051654@chinamobile.com>
X-mailer: Foxmail 6, 2, 103, 20 [cn]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release
6.5.6|March 06, 2007) at 2011-08-24 14:04:30,
Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06,
2007) at 2011-08-24 14:05:09, Serialize complete at 2011-08-24 14:05:09
Content-Type: multipart/alternative;
boundary="=====003_Dragon584666206555_====="
X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18342.005
X-TM-AS-Result: No--27.489-7.0-31-10
X-imss-scan-details: No--27.489-7.0-31-10;No--27.489-7.0-31-10
X-TM-AS-User-Approved-Sender: No;No
X-TM-AS-User-Blocked-Sender: No
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 06:04:05 -0000
I can share a use case here from our point of view in data center operation(will detail this in the upcoming draft as Yingjie said): We are considering running different services (e.g., VoIP and streaming services) by VM in the same cluster withinn data center. We know different services show different user visiting behaviors. For example, in the midnight, there are few VoIP usage while there are still large amount of streaming usage( this is just an example, maybe not so accurate to fit with the reality). In such case, we'd like merge the existing VoIP and streaming services into fewer machines and cut down the machines running only few VoIP usage to reduce the power consumption. In this senario, we need to consider how to migrate the existing VM states. Looking forward to discussing more use cases in the mailing list. BR Yunfei zhangyunfei 2011-08-24 发件人: Yingjie Gu(yingjie) 发送时间: 2011-08-24 13:41:04 收件人: 'Melinda Shore'; sami@ietf.org 抄送: 主题: Re: [sami] Trying to figure out where we are 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 _______________________________________________ sami mailing list sami@ietf.org https://www.ietf.org/mailman/listinfo/sami
- [sami] Welcome to SAMI and something you may like… Yingjie Gu(yingjie)
- Re: [sami] Welcome to SAMI and something you may … Juergen Schoenwaelder
- Re: [sami] Welcome to SAMI and something you may … Yingjie Gu(yingjie)
- Re: [sami] Welcome to SAMI and something you may … Linda Dunbar
- Re: [sami] Welcome to SAMI and something you may … Yingjie Gu(yingjie)
- Re: [sami] Welcome to SAMI and something you may … So, Ning
- Re: [sami] Welcome to SAMI and something you may … Melinda Shore
- Re: [sami] Welcome to SAMI and something you may … Yingjie Gu(yingjie)
- Re: [sami] Welcome to SAMI and something you may … Yingjie Gu(yingjie)
- Re: [sami] Welcome to SAMI and something you may … So, Ning
- Re: [sami] Welcome to SAMI and something you may … Melinda Shore
- [sami] Scope [was Re: Welcome to SAMI and somethi… Melinda Shore
- Re: [sami] Bringing new work into the IETF Yingjie Gu(yingjie)
- [sami] Bringing new work into the IETF David Harrington
- Re: [sami] Bringing new work into the IETF Melinda Shore
- Re: [sami] Bringing new work into the IETF Thomas Narten
- Re: [sami] Welcome to SAMI and something you may … Juergen Schoenwaelder
- Re: [sami] Bringing new work into the IETF So, Ning
- Re: [sami] Bringing new work into the IETF Melinda Shore
- Re: [sami] Bringing new work into the IETF Thomas Narten
- Re: [sami] Bringing new work into the IETF So, Ning
- Re: [sami] Bringing new work into the IETF david.black
- Re: [sami] Bringing new work into the IETF Melinda Shore
- Re: [sami] Bringing new work into the IETF Benson Schliesser
- Re: [sami] Bringing new work into the IETF So, Ning
- Re: [sami] Welcome to SAMI and something you may … Warren Kumari
- [sami] Trying to figure out where we are Melinda Shore
- Re: [sami] Trying to figure out where we are Yingjie Gu(yingjie)
- Re: [sami] Trying to figure out where we are zhangyunfei
- Re: [sami] Trying to figure out where we are Thomas Narten
- Re: [sami] Trying to figure out where we are Jamal Hadi Salim
- Re: [sami] Trying to figure out where we are Yingjie Gu(yingjie)
- Re: [sami] Trying to figure out where we are Thomas Narten
- Re: [sami] Trying to figure out where we are Warren Kumari
- [sami] 答复: Trying to figure out where we are Yingjie Gu(yingjie)