Re: [sami] First SAMI email in the new year, can we go further? Look forward to your opinions.

zhangyunfei <zhangyunfei@chinamobile.com> Fri, 02 March 2012 01:49 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 A75B921E8044 for <sami@ietfa.amsl.com>; Thu, 1 Mar 2012 17:49:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.691
X-Spam-Level:
X-Spam-Status: No, score=-97.691 tagged_above=-999 required=5 tests=[AWL=0.932, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 9v5voqFD3WrE for <sami@ietfa.amsl.com>; Thu, 1 Mar 2012 17:49:10 -0800 (PST)
Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C185621E8024 for <sami@ietf.org>; Thu, 1 Mar 2012 17:49:09 -0800 (PST)
Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 373CFE492; Fri, 2 Mar 2012 09:49:05 +0800 (CST)
Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 288EDE493; Fri, 2 Mar 2012 09:49:05 +0800 (CST)
Received: from zyf-PC ([10.1.4.171]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012030209490290-2623 ; Fri, 2 Mar 2012 09:49:02 +0800
Date: Fri, 02 Mar 2012 09:48:56 +0800
From: zhangyunfei <zhangyunfei@chinamobile.com>
To: Thomas Narten <narten@us.ibm.com>, "Yingjie Gu(yingjie)" <guyingjie@huawei.com>
References: <A27496C192613C44A82D819E1B98DB5721DAE9A6@SZXEML511-MBS.china.huawei.com>, <201203011329.q21DTbkD023885@cichlid.raleigh.ibm.com>
X-Priority: 3 (Normal)
X-Mailer: Foxmail 7.0.1.85[cn]
Mime-Version: 1.0
Message-ID: <201203020948563939893@chinamobile.com>
X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-02 09:49:02, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-02 09:49:04, Serialize complete at 2012-03-02 09:49:04
Content-Type: multipart/alternative; boundary="----=_001_NextPart425812438238_=----"
X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18746.003
X-TM-AS-Result: No--17.003-7.0-31-10
X-imss-scan-details: No--17.003-7.0-31-10;No--17.003-7.0-31-10
X-TM-AS-User-Approved-Sender: No;No
X-TM-AS-User-Blocked-Sender: No;No
Cc: "sami@ietf.org" <sami@ietf.org>
Subject: Re: [sami] First SAMI email in the new year, can we go further? Look forward to your opinions.
X-BeenThere: sami@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: zhangyunfei <zhangyunfei@chinamobile.com>
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, 02 Mar 2012 01:49:10 -0000

Totally agree. I do suggest to involve some Internet service operator, like Google, baidu (who may be the potential SAMI users) in the discussion if possible, which'll convince IETF that it's a real problem we encounter.

BR
Yunfei




zhangyunfei

From: Thomas Narten
Date: 2012-03-01 21:29
To: Yingjie Gu(yingjie)
CC: sami@ietf.org
Subject: Re: [sami] First SAMI email in the new year, can we go further? Look forward to your opinions.
Hi.

> According to previous discussion, one of the arguement is that we
>  don't need State Migration if there is no VM Migration, we can, for
>  example running active-active VMs mechanism to replace VM
>  Migration.

I think this is a bit of a strawman.

I would expect pretty much everyone on this list would agree that VM
migration takes place, under a wide range of conditions. So let's just
take it as a given that VM migration exists.

Personally, I can see the theoretical benefit of state migration
(e.g., of a firewall). But for me, the biggest reason I have been
skeptical of this effort so far is that I don't see real operators
stepping forwarding saying they need "state migration" in a real
concrete sense.

The IETF does much better when it has a real operational problem
driving a solution. We need such a problem in order to privide a
verification that should we attempt to develop a solution, the
solution actually solves a real world problem.

Thomas

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