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

"Yingjie Gu(yingjie)" <guyingjie@huawei.com> Wed, 12 October 2011 02:57 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 20B2221F8C82 for <sami@ietfa.amsl.com>; Tue, 11 Oct 2011 19:57:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.003
X-Spam-Level:
X-Spam-Status: No, score=-102.003 tagged_above=-999 required=5 tests=[AWL=-2.700, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345, 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 FwN3aa+ySY0w for <sami@ietfa.amsl.com>; Tue, 11 Oct 2011 19:57:10 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5A29721F8B3B for <sami@ietf.org>; Tue, 11 Oct 2011 19:57:10 -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 <0LSX00FS8MRSG6@szxga05-in.huawei.com> for sami@ietf.org; Wed, 12 Oct 2011 10:55:05 +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 <0LSX00E0QMQYLL@szxga05-in.huawei.com> for sami@ietf.org; Wed, 12 Oct 2011 10:55:04 +0800 (CST)
Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEJ46354; Wed, 12 Oct 2011 10:55:02 +0800
Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 12 Oct 2011 10:54:59 +0800
Received: from g00107907 (10.138.41.134) by szxeml410-hub.china.huawei.com (10.82.67.137) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 12 Oct 2011 10:54:54 +0800
Date: Wed, 12 Oct 2011 10:57:04 +0800
From: "Yingjie Gu(yingjie)" <guyingjie@huawei.com>
In-reply-to: <CAB+71L1Ltu4TMTwejEzBDPuKcC+_cwF5YqV1fJc_o0t3WhW2gg@mail.gmail.com>
X-Originating-IP: [10.138.41.134]
To: 'A tao' <yangjingtao@gmail.com>, 'Juergen Schoenwaelder' <j.schoenwaelder@jacobs-university.de>
Message-id: <003c01cc888a$a0a230b0$e1e69210$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: multipart/alternative; boundary="Boundary_(ID_IizqdI9p7MOKUo5WfA+Vdw)"
Content-language: zh-cn
Thread-index: AcyILymeFeromhJ5TyCuUOE2xAo8ZQAW0SDw
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>
Cc: "'卓志强(研七 福州)'" <zhuozq@ruijie.com.cn>, sami@ietf.org, "'刘茗(研六 福州)'" <lium@ruijie.com.cn>, 'Linda Dunbar' <linda.dunbar@huawei.com>
Subject: [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 02:57:12 -0000

I would say that the goal of this test should not be regarded as a proof to
show which model is better, security functions deployed inside of
server/Hypervisor or outside. People need to choose a way based on their
real scenario.

 

I think there are some knowledge that should be the base of SAMI, they are:

 

1. IT staff in DCs or in enterprise networks hope to see clear edge of
Network and Computing. That is let the Network do the network things,e.g.
forwarding and security, and Servers do the computing things. Argument
exists in this topic, but at least some providers we know of show the
requirements on clear edge. 

 

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. 

 

(The performance test results, if we have, can be used as a side proof to
support DC providers' requirements.)

(I know some IDC/DC providers register this mail list, and I really look
forward to hear their opinions)

 

3. There are many existing DCs where ACLs and firewalls are deployed on
network side. Hypervisor can run some part of security functions, but not
all of the security functions are deployed on Hypervisor. 

 

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.

 

Of course, I am willing to hear people's opinions on these knowledge.

 

If we agree on the above knowledge, we can move forward, to discuss whether
the states and scenarios make sense to you, 

 

 

  _____  

Best Regards
Gu Yingjie

 

发件人: A tao [mailto:yangjingtao@gmail.com] 
发送时间: 2011年10月12日 乐乐0:02
收件人: Juergen Schoenwaelder
抄送: 卓志强(研七 福州); Linda Dunbar; 刘茗(研六 福州); Yingjie Gu(yingjie);
sami@ietf.org
主题: Re: [sami] A new draft on state migration use cases is submitted.

 

No doubt that a performance test results can help people to understand, to
some extent, why there are requirements and implementations to move security
functions, such as firewall/DHCP snooping/ACLs, out of Hypervisor or
servers.

 

If Ming can provide this results, that will be best. 

 

We don't have the data but we also talked with DC providers, and they gave
me an example to explain why they want the firewall being executed by
network side. They deployed a VM to run Firewall functions on a x86 server.
And by test, they find the firewall consumes more than large amount of CPU
capacity which otherwise can be used to support 2-3 VMs. I don't get the
real data and the test situation, this is only a information. 

 

2011/10/11 Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>

On Tue, Oct 11, 2011 at 06:06:34AM +0000, 卓志强(研七 福州) wrote:
> I have the following documents to get some reference data,
> http://people.netfilter.org/kadlec/nftest.pdf
>
> The "filtering rules" is like ACLs. As the numbers increase, the
> performance of different software have declined.

Your proposition is that moving filtering rules from the endpoint (the
hypervisor) into the network is cheaper and easier to scale. To make
any sense of the above quoted document, I would need to know what the
performance of middleboxes is going to be and I would need to know how
many hypervisors are going to be behind a middlebox. If its lets say
1:10 (one switch to ten hypervisors), then the middleboxes would need
to outperform a kernel software filter by a factor significant larger
than 10. I guess you have done this calculation so it should be easy
to provide a concrete data point.

Once the scalability trade-off is clear, one can look at the costs of
the various options (essentially more hypervisors vs. fancier switches
that peak into L4 and perhaps even beyond). I would love if problem
statement documents would go into exactly this level of detail.


/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/>