Re: [sami] A new draft on state migration use cases is submitted.

"Yingjie Gu(yingjie)" <guyingjie@huawei.com> Wed, 12 October 2011 06:50 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 DC4BB21F84CE for <sami@ietfa.amsl.com>; Tue, 11 Oct 2011 23:50:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.581
X-Spam-Level:
X-Spam-Status: No, score=-103.581 tagged_above=-999 required=5 tests=[AWL=0.229, 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 T9EsGm-npQEp for <sami@ietfa.amsl.com>; Tue, 11 Oct 2011 23:50:36 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id AACC521F84C5 for <sami@ietf.org>; Tue, 11 Oct 2011 23:50:34 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSX00BUMXNWBJ@szxga05-in.huawei.com> for sami@ietf.org; Wed, 12 Oct 2011 14:50:20 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSX00A34XNV22@szxga05-in.huawei.com> for sami@ietf.org; Wed, 12 Oct 2011 14:50:20 +0800 (CST)
Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEJ60505; Wed, 12 Oct 2011 14:49:29 +0800
Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 12 Oct 2011 14:49:25 +0800
Received: from g00107907 (10.138.41.134) by szxeml401-hub.china.huawei.com (10.82.67.31) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 12 Oct 2011 14:49:23 +0800
Date: Wed, 12 Oct 2011 14:51:39 +0800
From: "Yingjie Gu(yingjie)" <guyingjie@huawei.com>
In-reply-to: <20111012061738.GB13515@elstar.local>
X-Originating-IP: [10.138.41.134]
To: 'Juergen Schoenwaelder' <j.schoenwaelder@jacobs-university.de>
Message-id: <005a01cc88ab$650e4180$2f2ac480$@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: AcyIprPWPe1rsRcMRDK43lZpxZqemwAAjv5w
X-CFilter-Loop: Reflected
References: <CAB+71L3btz_h8Lkm9jW-WHUeS4=K-Jq-r9mmX94=NdHiepkJ-Q@mail.gmail.com> <2CE4AB2F9CD06543A3F2B0FE76661E12125C8295@fzex.ruijie.com.cn> <20111009160138.GB99820@elstar.local> <000601cc86eb$829967f0$87cc37d0$@com> <2CE4AB2F9CD06543A3F2B0FE76661E12125C85F9@fzex.ruijie.com.cn> <4A95BA014132FF49AE685FAB4B9F17F61209F3D1@dfweml506-mbx> <169529F73649BF469B4F61792955CD5C125E230D@fzex.ruijie.com.cn> <20111011075143.GB9466@elstar.local> <CAB+71L1Ltu4TMTwejEzBDPuKcC+_cwF5YqV1fJc_o0t3WhW2gg@mail.gmail.com> <003c01cc888a$a0a230b0$e1e69210$@com> <20111012061738.GB13515@elstar.local>
Cc: 'A tao' <yangjingtao@gmail.com>, "'卓志强(研七 福州)'" <zhuozq@ruijie.com.cn>, "'刘茗(研六 福州)'" <lium@ruijie.com.cn>, 'Linda Dunbar' <linda.dunbar@huawei.com>, sami@ietf.org
Subject: Re: [sami] A new draft on state migration use cases is submitted.
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, 12 Oct 2011 06:50:37 -0000

Well, I won't try to answer why ISPs and DC providers raise these
requirments. I am sure not all of ISPs and DC providers ask for the same
thing, but we do get the requirements from our customers, at least they can
represent part of the operation views. 

As for your point of "neither Hypervisors nor switches support state live
migration", that is not big deal. Because we make all these discussions here
to figure out whether this is a problem and whether we can resolve it,
instead of whether there is existing solutions for this. 

I think Software Driven Network has no clear relationship to State Migration
after I read the drafts. I may be wrong, could you give some hints based on
your knowledge?

Thanks.

Best Regards
Gu Yingjie

-----邮件原件-----
发件人: sami-bounces@ietf.org [mailto:sami-bounces@ietf.org] 代表 Juergen
Schoenwaelder
发送时间: 2011年10月12日 乐乐14:18
收件人: Yingjie Gu(yingjie)
抄送: 'A tao'; '卓志强(研七 福州)'; sami@ietf.org; '刘茗(研六 福州)'; 'Linda
Dunbar'
主题: Re: [sami] 答复: A new draft on state migration use cases is
submitted.

On Wed, Oct 12, 2011 at 10:57:04AM +0800, Yingjie Gu(yingjie) wrote:

> 2. Some large ISPs we talked with, who are also DC service providers,
> require to move additional network functions to network side, so that they
> can save CPU processing capability to create more VMs, and selling VMs is
> the way they can earn money. 

I assume security functions embedded in network equipment do not come
for free either. So these ISPs seem to believe that security functions
in network devices are easier to manage and cheaper to scale.
 
> 4. Even for the security functions deployed on Hyperviser, not all of the
> Hypervisor vendors can support state live migration. This is another
reason,
> mentioned by Ming also, why people want to move network functions to
> network.

My understanding is that today neither hypervisors nor 'switches'
support the state live migration you want. Hence, these ISPs seem to
believe that 'switches' are easier to get updated with state migration
functions than hypervisors (even though there is quite some software
out there to manage VM infrastructures).

Since I am not a big ISP, I can't really judge any of this. But those
two arguments at least seem somewhat counter intuitive to me. Anyway,
I like to point your attention to the "Software Driven Networks" BOF
(scroll down on http://trac.tools.ietf.org/bof/trac/wiki/WikiStart).
This might actually be the solution to your problem.

/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/>
_______________________________________________
sami mailing list
sami@ietf.org
https://www.ietf.org/mailman/listinfo/sami