One of ou= r customers, the leader of online shopping provider in china, have the same= requirement. They run VMs on the power x86 machine with KVM hypervis= or. For some security reasons, they applied the ACLs through the Linux=A1= =AFs IPtable running on the Hypervisor. But when the VM floating , the IPta= ble profile can not be migrated to the other machine. So they hope the swit= ch can replace the IPTable and can migrates the ACL profiles for the = VM when floating .

&n= bsp;

From: A tao [mailto:yangjingtao@gma= il.com]
Sent: Monday, October 03, 2011 10:50 PM
To: sa= mi@ietf.org
Subject: [sami] A new draft on state migration use ca= ses is submitted.

Hi all,

We have submited a draft on state migration use cases.

You can find it at

http://www.ietf.org/id/draft-yan= g-opsawg-policies-migration-use-case-00.txt

We = talked with persons from the DC providers (China Mobile, China Telecom, Ten= cent), Firewall & Switch vendors (Huawei Symantec, Ruijie, and etc.) to= make sure the states and use cases in the draft are reasonable. =

<= p class=3DMsoNormal>We appreciate your comments and suggestions.

BTW, it's a public holiday in China from 1st to 7th Oct. So = I may not respond to your comments in time.

Best R= egards.

= --_000_2CE4AB2F9CD06543A3F2B0FE76661E12125C8295fzexruijiecomcn_-- From j.schoenwaelder@jacobs-university.de Sun Oct 9 09:01:55 2011 Return-Path: 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 35BDC21F8B1C for ; Sun, 9 Oct 2011 09:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.349 X-Spam-Level: X-Spam-Status: No, score=-100.349 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, 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 HTHvfM8LbTJ3 for ; Sun, 9 Oct 2011 09:01:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 837D621F8B17 for ; Sun, 9 Oct 2011 09:01:54 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8771820D06; Sun, 9 Oct 2011 18:01:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vPkkRlSrK8TZ; Sun, 9 Oct 2011 18:01:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0369E20D00; Sun, 9 Oct 2011 18:01:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C35A71B17CF0; Sun, 9 Oct 2011 18:01:38 +0200 (CEST) Date: Sun, 9 Oct 2011 18:01:38 +0200 From: Juergen Schoenwaelder To: =?utf-8?B?5YiY6IyXKOeglOWFrSDnpo/lt54p?= Message-ID: <20111009160138.GB99820@elstar.local> References: <2CE4AB2F9CD06543A3F2B0FE76661E12125C8295@fzex.ruijie.com.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2CE4AB2F9CD06543A3F2B0FE76661E12125C8295@fzex.ruijie.com.cn> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: A tao , "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 Reply-To: Juergen Schoenwaelder List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 16:01:55 -0000 On Sun, Oct 09, 2011 at 01:41:24PM +0000, 刘茗(研六福州) wrote: > One of our customers, the leader of online shopping provider in china, have the same requirement. They run VMs on the power x86 machine with KVM hypervisor. For some security reasons, they applied the ACLs through the Linux’s IPtable running on the Hypervisor. But when the VM floating , the IPtable profile can not be migrated to the other machine. So they hope the switch can replace the IPTable and can migrates the ACL profiles for the VM when floating . The switches really have nothing to do with ACLs sitting in the hypervisor. Making the switches responsible for migrating the ACLs seems broken to me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From guyingjie@huawei.com Sun Oct 9 18:24:29 2011 Return-Path: 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 ED91421F8B46 for ; Sun, 9 Oct 2011 18:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.149 X-Spam-Level: X-Spam-Status: No, score=-105.149 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 mnGtpVvMoabZ for ; Sun, 9 Oct 2011 18:24:29 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1679721F8B39 for ; Sun, 9 Oct 2011 18:24:29 -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 <0LST00ACXT7SVQ@szxga05-in.huawei.com> for sami@ietf.org; Mon, 10 Oct 2011 09:23:53 +0800 (CST) Received: from szxrg02-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 <0LST00C1XT7RJQ@szxga05-in.huawei.com> for sami@ietf.org; Mon, 10 Oct 2011 09:23:52 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AED25497; Mon, 10 Oct 2011 09:23:51 +0800 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 10 Oct 2011 09:23:50 +0800 Received: from g00107907 (10.138.41.134) by szxeml408-hub.china.huawei.com (10.82.67.95) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 10 Oct 2011 09:23:28 +0800 Date: Mon, 10 Oct 2011 09:25:30 +0800 From: "Yingjie Gu(yingjie)" In-reply-to: <20111009160138.GB99820@elstar.local> X-Originating-IP: [10.138.41.134] To: 'Juergen Schoenwaelder' , =?utf-8?B?J+WImOiMlyjnoJTlha0g56aP5beeKSc=?= Message-id: <000601cc86eb$829967f0$87cc37d0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcyGnSN4kEx9sHE4TZK7uRwrTcdb8AATcvhA X-CFilter-Loop: Reflected References: <2CE4AB2F9CD06543A3F2B0FE76661E12125C8295@fzex.ruijie.com.cn> <20111009160138.GB99820@elstar.local> Cc: 'A tao' , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 01:24:30 -0000 Ming, you'd better introduce yourself :) My understanding of these words is that, instead of deploying ACLs on = Hypervisor and try to migrate ACLs between Hypervisors, the customer = would like the ACLs be deployed on switches and migrate ACLs between = switches.=20 Is this what you mean, Ming? Best Regards Gu Yingjie -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: sami-bounces@ietf.org = [mailto:sami-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Juergen Schoenwaelder =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2011=E5=B9=B410=E6=9C=8810=E6=97=A5 =E4=B9=90=E4=B9=900:02 =E6=94=B6=E4=BB=B6=E4=BA=BA: =E5=88=98=E8=8C=97(=E7=A0=94=E5=85=AD = =E7=A6=8F=E5=B7=9E) =E6=8A=84=E9=80=81: A tao; sami@ietf.org =E4=B8=BB=E9=A2=98: Re: [sami] A new draft on state migration use cases = is submitted. On Sun, Oct 09, 2011 at 01:41:24PM +0000, = =E5=88=98=E8=8C=97(=E7=A0=94=E5=85=AD =E7=A6=8F=E5=B7=9E) wrote: > One of our customers, the leader of online shopping provider in china, = have the same requirement. They run VMs on the power x86 machine with = KVM hypervisor. For some security reasons, they applied the ACLs through = the Linux=E2=80=99s IPtable running on the Hypervisor. But when the VM = floating , the IPtable profile can not be migrated to the other machine. = So they hope the switch can replace the IPTable and can migrates the = ACL profiles for the VM when floating . The switches really have nothing to do with ACLs sitting in the hypervisor. Making the switches responsible for migrating the ACLs seems broken to me. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ sami mailing list sami@ietf.org https://www.ietf.org/mailman/listinfo/sami From lichen.cmcc@gmail.com Sun Oct 9 19:31:39 2011 Return-Path: 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 9E37F21F86FF for ; Sun, 9 Oct 2011 19:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 8tByPZqcUSrr for ; Sun, 9 Oct 2011 19:31:39 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1736321F8490 for ; Sun, 9 Oct 2011 19:31:39 -0700 (PDT) Received: by gyd12 with SMTP id 12so6122093gyd.31 for ; Sun, 09 Oct 2011 19:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ZkJ5Jm8k0w9OpsKFEfIBr4YfN3mCNg9UdfWgv6CGtpc=; b=uMzW0hnJauiYGS2cUAPcMm6jc36KCELG/D3Km4mbwOJHaIC3XOXPZGHFvB8cpNVXwr BYkzpfgZ6FVfVqlmfjyQeZAKffQhMODFFVv9PTJy7QVWr9WiqpCo2WGP/2ntHKK0Yc7m ffk8COqqFib0WBFZSgKyFK2gbVHO+E5IV3Y28= MIME-Version: 1.0 Received: by 10.68.19.35 with SMTP id b3mr33459363pbe.25.1318213898412; Sun, 09 Oct 2011 19:31:38 -0700 (PDT) Received: by 10.143.91.6 with HTTP; Sun, 9 Oct 2011 19:31:38 -0700 (PDT) Date: Mon, 10 Oct 2011 10:31:38 +0800 Message-ID: From: chen li To: j.schoenwaelder@jacobs-university.de, lium@ruijie.com.cn, sami@ietf.org Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 02:34:27 -0000 Sun, 9 Oct 2011 18:01:38 +0200 ,j.schoenwaelder wrote: >The switches really have nothing to do with ACLs sitting in the hypervisor. Making the switches responsible for migrating the ACLs seems broken to me. actually, it's necessroy to deploy vlan ACL on hypervisor. The introduction of Virtualization and cloud computing technologies brings new characteristics to DC service. One of the most important features is the variation of VM location. The basic policy dealing with this situation is to migrate related state/parameter information on network equipment to meet VM's requirements. During the research we have talked with related providers and network equipment vendors. We consider this problem to be an question needed to be handled when providing virtualization based DC services. And also=A3=ACwe hope the draft can receive more requirements of equipment state migration besides "DHCP Snooping..." etc. Li Chen Research Institute of China Mobile From melinda.shore@gmail.com Sun Oct 9 19:44:23 2011 Return-Path: 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 3FC4A21F8B0C for ; Sun, 9 Oct 2011 19:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 zkOs4w1Y5Mgj for ; Sun, 9 Oct 2011 19:44:22 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id D1A1E21F8B09 for ; Sun, 9 Oct 2011 19:44:22 -0700 (PDT) Received: by pzk37 with SMTP id 37so15853265pzk.9 for ; Sun, 09 Oct 2011 19:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=CmplrnTzHlk1zjJZ8A4bWoULux7t2W8h4ag2THZEuQ0=; b=B1DjtCD31J1VUYIMTe3YeHTOmnasXI2v7zfnbA3tnGkesJ5zKuLjBttO8Zlo5sxArG Mv1Y2q2VplNz1q3Bo3VaiQv/U9yrzEeCbV2W6dLnwvmp4ZqTvz+Igd73ASN/TS1xZQiN UK4iicyImvh32f8fzBX55ZOQ/095zDBA9w/BE= Received: by 10.68.16.166 with SMTP id h6mr33496352pbd.103.1318214662573; Sun, 09 Oct 2011 19:44:22 -0700 (PDT) Received: from polypro.local (216-67-46-106-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.46.106]) by mx.google.com with ESMTPS id ki1sm62501124pbb.3.2011.10.09.19.44.20 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 09 Oct 2011 19:44:21 -0700 (PDT) Message-ID: <4E925C03.6040107@gmail.com> Date: Sun, 09 Oct 2011 18:44:19 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.23) Gecko/20110920 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: sami@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 02:44:23 -0000 On 10/9/11 6:31 PM, chen li wrote: > During the research we have talked with related providers and network > equipment vendors. We consider this problem to be an question needed > to be handled when providing virtualization based DC services. That really doesn't address the question raised by Juergen: why is the *switch* involved in migrating ACLs located on hypervisors? I've read these documents a few times and I still don't have a very clear picture of where you think network state and "flow"-coupled state are located. Melinda From lichen.cmcc@gmail.com Sun Oct 9 20:14:37 2011 Return-Path: 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 2699021F877F for ; Sun, 9 Oct 2011 20:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.204 X-Spam-Level: X-Spam-Status: No, score=-3.204 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 iaPvrlzpQvD2 for ; Sun, 9 Oct 2011 20:14:36 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A704B21F8726 for ; Sun, 9 Oct 2011 20:14:36 -0700 (PDT) Received: by ggnk3 with SMTP id k3so5119582ggn.31 for ; Sun, 09 Oct 2011 20:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=pcxYAnR7TWDxJwRlxEy3fj+bKJpDB7D9dNu2g9qmZ0g=; b=YIqbj6uFiJUflD37fFQKiq4dwR0PAUGCx8gWZoG7X3jJAtnnEJ/Rg3M3elp5cVvp9d OkHGRLT9jD934Wg+sQnn4RQNljaI0AVdtSYexUgKh/v7JB9+liM7Dtq+vw4rNx7oXRGD MqUlzGMVTYXGuMfYrB9kPe97gJQeVaS2hNoug= MIME-Version: 1.0 Received: by 10.68.17.4 with SMTP id k4mr33735883pbd.8.1318216476082; Sun, 09 Oct 2011 20:14:36 -0700 (PDT) Received: by 10.143.91.6 with HTTP; Sun, 9 Oct 2011 20:14:36 -0700 (PDT) Date: Mon, 10 Oct 2011 11:14:36 +0800 Message-ID: From: chen li To: melinda.shore@gmail.com, sami@ietf.org Content-Type: text/plain; charset=ISO-8859-1 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 03:14:37 -0000 On 10/9/11 6:31 PM, Melinda wrote: >That really doesn't address the question raised by Juergen: why is the >*switch* involved in migrating ACLs located on hypervisors? I've read >these documents a few times and I still don't have a very clear picture of >where you think network state and "flow"-coupled state are located. for Juergen's question, i mean that it's necessroy to deploy vlan ACL on hypervisor. and aslo, the hypervisor supports limited functions. such as DHCP Snooping that we need cannot be support yet. Li Chen _______________________________________________ sami mailing list sami@ietf.org https://www.ietf.org/mailman/listinfo/sami From zhuozq@gmail.com Mon Oct 10 01:11:29 2011 Return-Path: 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 3699821F8AF7 for ; Mon, 10 Oct 2011 01:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 68K3qD7rGsdd for ; Mon, 10 Oct 2011 01:11:28 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4D221F8AD1 for ; Mon, 10 Oct 2011 01:11:28 -0700 (PDT) Received: by iaby26 with SMTP id y26so8803778iab.31 for ; Mon, 10 Oct 2011 01:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type; bh=Q6FuScrRjfLmFi3Ynw6HxpVZK9TrIfxGZqHd12s9DnY=; b=wXsVY+uif4V6vcz/WaR/BKMu71Zdql4bT/zzhO/iwLklWmoOI2uy05owByLPtJbbrE HGx/eHiyFkWHf+1A13AP0uWC69Hak5qZB/i8TqqaSglijf/iewM/1r9/ok3qs8yskZDj B4Zfi1Skukls9kRRJ6vkywwdC+MpLVL/wlpGc= Received: by 10.42.148.198 with SMTP id s6mr15096657icv.56.1318234286130; Mon, 10 Oct 2011 01:11:26 -0700 (PDT) Received: from R00107 ([110.90.119.113]) by mx.google.com with ESMTPS id fy35sm45013386ibb.4.2011.10.10.01.11.07 (version=SSLv3 cipher=OTHER); Mon, 10 Oct 2011 01:11:25 -0700 (PDT) Date: Mon, 10 Oct 2011 16:11:07 +0800 From: "zhuozq" To: "sami" Message-ID: <201110101610172579956@gmail.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon631870074525_=====" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 08:11:29 -0000 This is a multi-part message in MIME format. --=====003_Dragon631870074525_===== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes, I find that ACLs on hypervisor will consume a large amount of server performance. So I think that VM's ACLs on *switch* will release the server performance. Zhiqiang zhuo -----Original Message----- From: sami-bounces@ietf.org [mailto:sami-bounces@ietf.org] On Behalf Of chen li Sent: Monday, October 10, 2011 11:15 AM To: melinda.shore@gmail.com; sami@ietf.org Subject: Re: [sami] A new draft on state migration use cases is submitted. On 10/9/11 6:31 PM, Melinda wrote: >That really doesn't address the question raised by Juergen: why is the >*switch* involved in migrating ACLs located on hypervisors? I've read >these documents a few times and I still don't have a very clear picture >of where you think network state and "flow"-coupled state are located. for Juergen's question, i mean that it's necessroy to deploy vlan ACL on hypervisor. and aslo, the hypervisor supports limited functions. such as DHCP Snooping that we need cannot be support yet. Li Chen _______________________________________________ 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 --=====003_Dragon631870074525_===== Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit

Yes, I find that ACLs on hypervisor will consume a large amount of server performance. So I think that VM's ACLs on *switch* will release the server performance.

Zhiqiang zhuo

-----Original Message-----

From: sami-bounces@ietf.org [mailto:sami-bounces@ietf.org] On Behalf Of chen li

Sent: Monday, October 10, 2011 11:15 AM

To: melinda.shore@gmail.com; sami@ietf.org

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

On 10/9/11 6:31 PM, Melinda wrote:

>That really doesn't address the question raised by Juergen: why is the

>*switch* involved in migrating ACLs located on hypervisors? I've read

>these documents a few times and I still don't have a very clear picture

>of where you think network state and "flow"-coupled state are located.

for Juergen's question, i mean that it's necessroy to deploy vlan ACL on hypervisor.

and aslo, the hypervisor supports limited functions. such as DHCP Snooping that we need cannot be support yet.

Li Chen

_______________________________________________

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

--=====003_Dragon631870074525_=====-- From guyingjie@huawei.com Mon Oct 10 07:01:45 2011 Return-Path: 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 DEB6621F8B11 for ; Mon, 10 Oct 2011 07:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.48 X-Spam-Level: X-Spam-Status: No, score=-104.48 tagged_above=-999 required=5 tests=[AWL=-0.669, 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 ZC5aiv-HC7g9 for ; Mon, 10 Oct 2011 07:01:45 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB7721F8AD1 for ; Mon, 10 Oct 2011 07:01:44 -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 <0LSU00AFSS91OS@szxga05-in.huawei.com> for sami@ietf.org; Mon, 10 Oct 2011 22:00:37 +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 <0LSU00IJTS8ZOR@szxga05-in.huawei.com> for sami@ietf.org; Mon, 10 Oct 2011 22:00:37 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEI72767; Mon, 10 Oct 2011 22:00:19 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 10 Oct 2011 22:00:17 +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; Mon, 10 Oct 2011 22:00:09 +0800 Date: Mon, 10 Oct 2011 22:02:56 +0800 From: "Yingjie Gu(yingjie)" In-reply-to: <4E925C03.6040107@gmail.com> X-Originating-IP: [10.138.41.134] To: 'Melinda Shore' , sami@ietf.org Message-id: <004a01cc8755$502936f0$f07ba4d0$@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: AcyG9tpVlsAhgxeyTIu0fCgzkYP7CQABqfCQ X-CFilter-Loop: Reflected References: <4E925C03.6040107@gmail.com> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 14:01:46 -0000 I think the state we are talking about is the flow-coupled network state located on such devices as physical switches and firewalls. We don't try = to migrate the states on Hypervisor. The figures in the use case draft give some examples on the states on physical switches and firewalls.=20 Best Regards Gu Yingjie -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: sami-bounces@ietf.org [mailto:sami-bounces@ietf.org] = =B4=FA=B1=ED Melinda Shore =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C210=C8=D5 =C0=D6=C0=D610:44 =CA=D5=BC=FE=C8=CB: sami@ietf.org =D6=F7=CC=E2: Re: [sami] A new draft on state migration use cases is = submitted. On 10/9/11 6:31 PM, chen li wrote: > During the research we have talked with related providers and network > equipment vendors. We consider this problem to be an question needed > to be handled when providing virtualization based DC services. That really doesn't address the question raised by Juergen: why is the *switch* involved in migrating ACLs located on hypervisors? I've read these documents a few times and I still don't have a very clear picture = of where you think network state and "flow"-coupled state are located. Melinda _______________________________________________ sami mailing list sami@ietf.org https://www.ietf.org/mailman/listinfo/sami From lium@ruijie.com.cn Mon Oct 10 07:24:41 2011 Return-Path: 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 5E18821F8B80 for ; Mon, 10 Oct 2011 07:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.729 X-Spam-Level: * X-Spam-Status: No, score=1.729 tagged_above=-999 required=5 tests=[AWL=2.477, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] 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 J6hRT+c6NsYp for ; Mon, 10 Oct 2011 07:24:40 -0700 (PDT) Received: from fzex.ruijie.com.cn (unknown [120.35.11.201]) by ietfa.amsl.com (Postfix) with ESMTP id 15D4621F8B7D for ; Mon, 10 Oct 2011 07:24:39 -0700 (PDT) Received: from FZEX.ruijie.com.cn ([::1]) by fzex.ruijie.com.cn ([::1]) with mapi; Mon, 10 Oct 2011 22:24:40 +0800 From: =?utf-8?B?5YiY6IyXKOeglOWFrSDnpo/lt54p?= To: "Yingjie Gu(yingjie)" , 'Juergen Schoenwaelder' Thread-Topic: [sami] A new draft on state migration use cases is submitted. Thread-Index: AQHMhpy5nCrU58T5iEGiJqyRp80qr5V0Q6kAgAFUROA= Date: Mon, 10 Oct 2011 14:24:35 +0000 Message-ID: <2CE4AB2F9CD06543A3F2B0FE76661E12125C85F9@fzex.ruijie.com.cn> References: <2CE4AB2F9CD06543A3F2B0FE76661E12125C8295@fzex.ruijie.com.cn> <20111009160138.GB99820@elstar.local> <000601cc86eb$829967f0$87cc37d0$@com> In-Reply-To: <000601cc86eb$829967f0$87cc37d0$@com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: 'A tao' , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 14:24:41 -0000 RGVhciAgWWluZ2ppZSwNCg0KWWVzLCB5b3UgZ290IG15IHBvaW50LiBPdXIgY3VzdG9tZXJzIGRl cGxveSB0aGUgdmlydHVhbGl6YXRpb24gaW4gb3JkZXIgdG8gaW1wcm92ZSB0aGUgdXRpbGl0eSBv ZiBoYXJkd2FyZSByZXNvdXJjZXMsIGVzcGVjaWFsbHkgdGhlIENQVSAuIEJ1dCB0aGUgc2VjdXJp dHkgcG9saWN5IGV4ZWN1dGVkIGJ5IHRoZSBoeXBlcnZpc29yIHdpbGwgY29uc3VtZSB0aGUgQ1BV IHJlc291cmNlIHdpdGhvdXQgbW9uZXkgYmFjay4gU28gaWYgdGhlIHN3aXRjaGVzIGNhbiBtaWdy YXRlIHRoZSBzZWN1cml0eSBwb2xpY3kgYWNyb3NzIHRoZSBwaHlzaWNhbCBtYWNoaW5lLCBpdCB3 aWxsIG1ha2UgbW9yZSBtb25leSBiYWNrLiANCg0KT2gsIEkgZm9yZ290IGludHJvZHVjaW5nIG15 c2VsZi4gTXkgbmFtZSBpcyBNaW5nIExpdS4gSSdtICBhIHByb2R1Y3QgbWFuYWdlciBmcm9tIGEg bmV0d29yayBwcm9kdWN0IHZlbmRvciBpbiBDaGluYSBtYWlubGFuZCBhbmQgaW4gY2hhcmdlIG9m IHNvbHV0aW9ucyBhbmQgcHJvZHVjdHMgZm9yIERhdGEgQ2VudGVyLiBBbmQgb3VyIGN1c3RvbWVy cyBpbmNsdWRlIGdvdmVybm1lbnQsIHVuaXZlcnNpdGllcywgSUNQIGFuZCBzbyBvbiAuDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBZaW5namllIEd1KHlpbmdqaWUpIFttYWls dG86Z3V5aW5namllQGh1YXdlaS5jb21dIA0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDEwLCAyMDEx IDk6MjUgQU0NClRvOiAnSnVlcmdlbiBTY2hvZW53YWVsZGVyJzsg5YiY6IyXKOeglOWFrSDnpo/l t54pDQpDYzogJ0EgdGFvJzsgc2FtaUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzYW1pXSBBIG5l dyBkcmFmdCBvbiBzdGF0ZSBtaWdyYXRpb24gdXNlIGNhc2VzIGlzIHN1Ym1pdHRlZC4NCg0KTWlu ZywgeW91J2QgYmV0dGVyIGludHJvZHVjZSB5b3Vyc2VsZiA6KQ0KDQpNeSB1bmRlcnN0YW5kaW5n IG9mIHRoZXNlIHdvcmRzIGlzIHRoYXQsIGluc3RlYWQgb2YgZGVwbG95aW5nIEFDTHMgb24gSHlw ZXJ2aXNvciBhbmQgdHJ5IHRvIG1pZ3JhdGUgQUNMcyBiZXR3ZWVuIEh5cGVydmlzb3JzLCB0aGUg Y3VzdG9tZXIgd291bGQgbGlrZSB0aGUgQUNMcyBiZSBkZXBsb3llZCBvbiBzd2l0Y2hlcyBhbmQg bWlncmF0ZSBBQ0xzIGJldHdlZW4gc3dpdGNoZXMuIA0KDQpJcyB0aGlzIHdoYXQgeW91IG1lYW4s IE1pbmc/DQoNCg0KQmVzdCBSZWdhcmRzDQpHdSBZaW5namllDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2 LS0tLS0NCuWPkeS7tuS6ujogc2FtaS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2FtaS1ib3Vu Y2VzQGlldGYub3JnXSDku6PooaggSnVlcmdlbiBTY2hvZW53YWVsZGVyDQrlj5HpgIHml7bpl7Q6 IDIwMTHlubQxMOaciDEw5pelIOS5kOS5kDA6MDINCuaUtuS7tuS6ujog5YiY6IyXKOeglOWFrSDn po/lt54pDQrmioTpgIE6IEEgdGFvOyBzYW1pQGlldGYub3JnDQrkuLvpopg6IFJlOiBbc2FtaV0g QSBuZXcgZHJhZnQgb24gc3RhdGUgbWlncmF0aW9uIHVzZSBjYXNlcyBpcyBzdWJtaXR0ZWQuDQoN Ck9uIFN1biwgT2N0IDA5LCAyMDExIGF0IDAxOjQxOjI0UE0gKzAwMDAsIOWImOiMlyjnoJTlha0g 56aP5beeKSB3cm90ZToNCj4gT25lIG9mIG91ciBjdXN0b21lcnMsIHRoZSBsZWFkZXIgb2Ygb25s aW5lIHNob3BwaW5nIHByb3ZpZGVyIGluIGNoaW5hLCBoYXZlIHRoZSBzYW1lIHJlcXVpcmVtZW50 LiAgVGhleSBydW4gVk1zIG9uIHRoZSBwb3dlciB4ODYgbWFjaGluZSB3aXRoIEtWTSBoeXBlcnZp c29yLiBGb3Igc29tZSBzZWN1cml0eSByZWFzb25zLCB0aGV5IGFwcGxpZWQgdGhlIEFDTHMgdGhy b3VnaCB0aGUgTGludXjigJlzIElQdGFibGUgcnVubmluZyBvbiB0aGUgSHlwZXJ2aXNvci4gQnV0 IHdoZW4gdGhlIFZNIGZsb2F0aW5nICwgdGhlIElQdGFibGUgcHJvZmlsZSBjYW4gbm90IGJlIG1p Z3JhdGVkIHRvIHRoZSBvdGhlciBtYWNoaW5lLiBTbyB0aGV5IGhvcGUgdGhlIHN3aXRjaCBjYW4g cmVwbGFjZSB0aGUgSVBUYWJsZSAgYW5kIGNhbiBtaWdyYXRlcyB0aGUgQUNMIHByb2ZpbGVzIGZv ciB0aGUgVk0gd2hlbiBmbG9hdGluZyAuDQoNClRoZSBzd2l0Y2hlcyByZWFsbHkgaGF2ZSBub3Ro aW5nIHRvIGRvIHdpdGggQUNMcyBzaXR0aW5nIGluIHRoZSBoeXBlcnZpc29yLiBNYWtpbmcgdGhl IHN3aXRjaGVzIHJlc3BvbnNpYmxlIGZvciBtaWdyYXRpbmcgdGhlIEFDTHMgc2VlbXMgYnJva2Vu IHRvIG1lLg0KDQovanMNCg0KLS0gDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEph Y29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAg ICAgICBDYW1wdXMgUmluZyAxLCAyODc1OSBCcmVtZW4sIEdlcm1hbnkNCkZheDogICArNDkgNDIx IDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNhbWkgbWFpbGlu ZyBsaXN0DQpzYW1pQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NhbWkNCg0K From j.schoenwaelder@jacobs-university.de Mon Oct 10 10:50:10 2011 Return-Path: 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 DDF2B21F8C22 for ; Mon, 10 Oct 2011 10:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.374 X-Spam-Level: X-Spam-Status: No, score=-102.374 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, 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 L3JMwhmXI5jN for ; Mon, 10 Oct 2011 10:50:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2C99321F8C20 for ; Mon, 10 Oct 2011 10:50:09 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1419520DB8; Mon, 10 Oct 2011 19:50:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FBXHKUrWpC9k; Mon, 10 Oct 2011 19:50:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 83CD520DB7; Mon, 10 Oct 2011 19:50:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CE50C1B1AEFF; Mon, 10 Oct 2011 19:49:52 +0200 (CEST) Date: Mon, 10 Oct 2011 19:49:52 +0200 From: Juergen Schoenwaelder To: =?utf-8?B?5YiY6IyXKOeglOWFrSDnpo/lt54p?= Message-ID: <20111010174952.GA7901@elstar.local> References: <2CE4AB2F9CD06543A3F2B0FE76661E12125C8295@fzex.ruijie.com.cn> <20111009160138.GB99820@elstar.local> <000601cc86eb$829967f0$87cc37d0$@com> <2CE4AB2F9CD06543A3F2B0FE76661E12125C85F9@fzex.ruijie.com.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2CE4AB2F9CD06543A3F2B0FE76661E12125C85F9@fzex.ruijie.com.cn> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Yingjie Gu$yingjie$" , "sami@ietf.org" , 'A tao' 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 Reply-To: Juergen Schoenwaelder List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 17:50:11 -0000 On Mon, Oct 10, 2011 at 02:24:35PM +0000, 刘茗(研六福州) wrote: > Dear Yingjie, > > Yes, you got my point. Our customers deploy the virtualization in > order to improve the utility of hardware resources, especially the > CPU . But the security policy executed by the hypervisor will > consume the CPU resource without money back. So if the switches can > migrate the security policy across the physical machine, it will > make more money back. Do you have any data to share with us how much of your hypervisor CPU time is spent on ACL processing? I hear you saying that you are short on hypervisor CPU cycles but have plenty of CPU cycles on the switches (or that it is cheaper to buy CPU cycles on switches than on hypervisor platforms). Since it is the first time I hear this argument, I am wondering whether you have some numbers to share. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From linda.dunbar@huawei.com Mon Oct 10 13:45:53 2011 Return-Path: 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 1ED3521F8C7C for ; Mon, 10 Oct 2011 13:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 jRn+CONxH3rE for ; Mon, 10 Oct 2011 13:45:52 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 34C7421F8C6A for ; Mon, 10 Oct 2011 13:45:52 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSV002OFB0E5O@usaga04-in.huawei.com> for sami@ietf.org; Mon, 10 Oct 2011 15:45:51 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSV00N9MB0D3M@usaga04-in.huawei.com> for sami@ietf.org; Mon, 10 Oct 2011 15:45:50 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 10 Oct 2011 13:45:50 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Mon, 10 Oct 2011 13:45:39 -0700 Date: Mon, 10 Oct 2011 20:45:39 +0000 From: Linda Dunbar In-reply-to: <2CE4AB2F9CD06543A3F2B0FE76661E12125C85F9@fzex.ruijie.com.cn> X-Originating-IP: [10.47.139.108] To: =?utf-8?B?5YiY6IyXKOeglOWFrSDnpo/lt54p?= , "Yingjie Gu(yingjie)" , 'Juergen Schoenwaelder' Message-id: <4A95BA014132FF49AE685FAB4B9F17F61209F3D1@dfweml506-mbx> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [sami] A new draft on state migration use cases is submitted. Thread-index: AQHMgdvJusSHqGlyAkCWTLPzhBKd/JV0g+YAgAAnLwCAAJ2KAIAA2a2A///oKQA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <2CE4AB2F9CD06543A3F2B0FE76661E12125C8295@fzex.ruijie.com.cn> <20111009160138.GB99820@elstar.local> <000601cc86eb$829967f0$87cc37d0$@com> <2CE4AB2F9CD06543A3F2B0FE76661E12125C85F9@fzex.ruijie.com.cn> Cc: 'A tao' , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 20:45:53 -0000 VGFvLCANCg0KVGhhdCBpcyBhbiBpbnRlcmVzdGluZyBkZXNjcmlwdGlvbi4gQ2FuIHlvdSBlbGFi b3JhdGUgYSBsaXR0bGUgYml0IG9uIHByb3MgYW5kIGNvbnMgb2YgaHlwZXJ2aXNvciBDUFUgdGFr ZW4gYnkgdGhlIHNlY3VyaXR5IHZzLiB0aGUgZXh0cmEgcHJvY2Vzc2luZyBvbiBzd2l0Y2hlcz8g DQoNCkxpbmRhIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNhbWkt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNhbWktYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mDQo+IOWImOiMlyjnoJTlha0g56aP5beeKQ0KPiBTZW50OiBNb25kYXksIE9jdG9iZXIgMTAs IDIwMTEgOToyNSBBTQ0KPiBUbzogWWluZ2ppZSBHdSh5aW5namllKTsgJ0p1ZXJnZW4gU2Nob2Vu d2FlbGRlcicNCj4gQ2M6ICdBIHRhbyc7IHNhbWlAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtz YW1pXSBBIG5ldyBkcmFmdCBvbiBzdGF0ZSBtaWdyYXRpb24gdXNlIGNhc2VzIGlzDQo+IHN1Ym1p dHRlZC4NCj4gDQo+IERlYXIgIFlpbmdqaWUsDQo+IA0KPiBZZXMsIHlvdSBnb3QgbXkgcG9pbnQu IE91ciBjdXN0b21lcnMgZGVwbG95IHRoZSB2aXJ0dWFsaXphdGlvbiBpbiBvcmRlcg0KPiB0byBp bXByb3ZlIHRoZSB1dGlsaXR5IG9mIGhhcmR3YXJlIHJlc291cmNlcywgZXNwZWNpYWxseSB0aGUg Q1BVIC4gQnV0DQo+IHRoZSBzZWN1cml0eSBwb2xpY3kgZXhlY3V0ZWQgYnkgdGhlIGh5cGVydmlz b3Igd2lsbCBjb25zdW1lIHRoZSBDUFUNCj4gcmVzb3VyY2Ugd2l0aG91dCBtb25leSBiYWNrLiBT byBpZiB0aGUgc3dpdGNoZXMgY2FuIG1pZ3JhdGUgdGhlDQo+IHNlY3VyaXR5IHBvbGljeSBhY3Jv c3MgdGhlIHBoeXNpY2FsIG1hY2hpbmUsIGl0IHdpbGwgbWFrZSBtb3JlIG1vbmV5DQo+IGJhY2su DQo+IA0KPiBPaCwgSSBmb3Jnb3QgaW50cm9kdWNpbmcgbXlzZWxmLiBNeSBuYW1lIGlzIE1pbmcg TGl1LiBJJ20gIGEgcHJvZHVjdA0KPiBtYW5hZ2VyIGZyb20gYSBuZXR3b3JrIHByb2R1Y3QgdmVu ZG9yIGluIENoaW5hIG1haW5sYW5kIGFuZCBpbiBjaGFyZ2UNCj4gb2Ygc29sdXRpb25zIGFuZCBw cm9kdWN0cyBmb3IgRGF0YSBDZW50ZXIuIEFuZCBvdXIgY3VzdG9tZXJzIGluY2x1ZGUNCj4gZ292 ZXJubWVudCwgdW5pdmVyc2l0aWVzLCBJQ1AgYW5kIHNvIG9uIC4NCj4gDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFlpbmdqaWUgR3UoeWluZ2ppZSkgW21haWx0bzpndXlp bmdqaWVAaHVhd2VpLmNvbV0NCj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDEwLCAyMDExIDk6MjUg QU0NCj4gVG86ICdKdWVyZ2VuIFNjaG9lbndhZWxkZXInOyDliJjojJco56CU5YWtIOemj+W3nikN Cj4gQ2M6ICdBIHRhbyc7IHNhbWlAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzYW1pXSBBIG5l dyBkcmFmdCBvbiBzdGF0ZSBtaWdyYXRpb24gdXNlIGNhc2VzIGlzDQo+IHN1Ym1pdHRlZC4NCj4g DQo+IE1pbmcsIHlvdSdkIGJldHRlciBpbnRyb2R1Y2UgeW91cnNlbGYgOikNCj4gDQo+IE15IHVu ZGVyc3RhbmRpbmcgb2YgdGhlc2Ugd29yZHMgaXMgdGhhdCwgaW5zdGVhZCBvZiBkZXBsb3lpbmcg QUNMcyBvbg0KPiBIeXBlcnZpc29yIGFuZCB0cnkgdG8gbWlncmF0ZSBBQ0xzIGJldHdlZW4gSHlw ZXJ2aXNvcnMsIHRoZSBjdXN0b21lcg0KPiB3b3VsZCBsaWtlIHRoZSBBQ0xzIGJlIGRlcGxveWVk IG9uIHN3aXRjaGVzIGFuZCBtaWdyYXRlIEFDTHMgYmV0d2Vlbg0KPiBzd2l0Y2hlcy4NCj4gDQo+ IElzIHRoaXMgd2hhdCB5b3UgbWVhbiwgTWluZz8NCj4gDQo+IA0KPiBCZXN0IFJlZ2FyZHMNCj4g R3UgWWluZ2ppZQ0KPiANCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IHNh bWktYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNhbWktYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGo DQo+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcg0KPiDlj5HpgIHml7bpl7Q6IDIwMTHlubQxMOaciDEw 5pelIOS5kOS5kDA6MDINCj4g5pS25Lu25Lq6OiDliJjojJco56CU5YWtIOemj+W3nikNCj4g5oqE 6YCBOiBBIHRhbzsgc2FtaUBpZXRmLm9yZw0KPiDkuLvpopg6IFJlOiBbc2FtaV0gQSBuZXcgZHJh ZnQgb24gc3RhdGUgbWlncmF0aW9uIHVzZSBjYXNlcyBpcyBzdWJtaXR0ZWQuDQo+IA0KPiBPbiBT dW4sIE9jdCAwOSwgMjAxMSBhdCAwMTo0MToyNFBNICswMDAwLCDliJjojJco56CU5YWtIOemj+W3 nikgd3JvdGU6DQo+ID4gT25lIG9mIG91ciBjdXN0b21lcnMsIHRoZSBsZWFkZXIgb2Ygb25saW5l IHNob3BwaW5nIHByb3ZpZGVyIGluIGNoaW5hLA0KPiBoYXZlIHRoZSBzYW1lIHJlcXVpcmVtZW50 LiAgVGhleSBydW4gVk1zIG9uIHRoZSBwb3dlciB4ODYgbWFjaGluZSB3aXRoDQo+IEtWTSBoeXBl cnZpc29yLiBGb3Igc29tZSBzZWN1cml0eSByZWFzb25zLCB0aGV5IGFwcGxpZWQgdGhlIEFDTHMN Cj4gdGhyb3VnaCB0aGUgTGludXjigJlzIElQdGFibGUgcnVubmluZyBvbiB0aGUgSHlwZXJ2aXNv ci4gQnV0IHdoZW4gdGhlIFZNDQo+IGZsb2F0aW5nICwgdGhlIElQdGFibGUgcHJvZmlsZSBjYW4g bm90IGJlIG1pZ3JhdGVkIHRvIHRoZSBvdGhlciBtYWNoaW5lLg0KPiBTbyB0aGV5IGhvcGUgdGhl IHN3aXRjaCBjYW4gcmVwbGFjZSB0aGUgSVBUYWJsZSAgYW5kIGNhbiBtaWdyYXRlcyB0aGUNCj4g QUNMIHByb2ZpbGVzIGZvciB0aGUgVk0gd2hlbiBmbG9hdGluZyAuDQo+IA0KPiBUaGUgc3dpdGNo ZXMgcmVhbGx5IGhhdmUgbm90aGluZyB0byBkbyB3aXRoIEFDTHMgc2l0dGluZyBpbiB0aGUNCj4g aHlwZXJ2aXNvci4gTWFraW5nIHRoZSBzd2l0Y2hlcyByZXNwb25zaWJsZSBmb3IgbWlncmF0aW5n IHRoZSBBQ0xzDQo+IHNlZW1zIGJyb2tlbiB0byBtZS4NCj4gDQo+IC9qcw0KPiANCj4gLS0NCj4g SnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4g Z0dtYkgNCj4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxLCAy ODc1OSBCcmVtZW4sIEdlcm1hbnkNCj4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8 aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNhbWkgbWFpbGluZyBsaXN0DQo+IHNhbWlA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYW1pDQo+ IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBz YW1pIG1haWxpbmcgbGlzdA0KPiBzYW1pQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2FtaQ0K From zhuozq@ruijie.com.cn Mon Oct 10 23:06:40 2011 Return-Path: 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 6E4B321F8D53 for ; Mon, 10 Oct 2011 23:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.991 X-Spam-Level: ** X-Spam-Status: No, score=2.991 tagged_above=-999 required=5 tests=[AWL=3.739, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] 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 Lyq-2USwa70B for ; Mon, 10 Oct 2011 23:06:39 -0700 (PDT) Received: from fzex.ruijie.com.cn (unknown [120.35.11.201]) by ietfa.amsl.com (Postfix) with ESMTP id EABE921F8D46 for ; Mon, 10 Oct 2011 23:06:38 -0700 (PDT) Received: from FZEX.ruijie.com.cn ([::1]) by fzex.ruijie.com.cn ([::1]) with mapi; Tue, 11 Oct 2011 14:06:37 +0800 From: =?utf-8?B?5Y2T5b+X5by6KOeglOS4gyDnpo/lt54p?= To: Linda Dunbar , =?utf-8?B?5YiY6IyXKOeglOWFrSDnpo/lt54p?= , "Yingjie Gu(yingjie)" , 'Juergen Schoenwaelder' Thread-Topic: [sami] A new draft on state migration use cases is submitted. Thread-Index: AQHMgdu7ms9tl0Rqcky/axuIq0CnsZVziHEAgAAnLwCAAJ2LAIAA2ayAgABqeICAAR49wA== Date: Tue, 11 Oct 2011 06:06:34 +0000 Message-ID: <169529F73649BF469B4F61792955CD5C125E230D@fzex.ruijie.com.cn> References: <2CE4AB2F9CD06543A3F2B0FE76661E12125C8295@fzex.ruijie.com.cn> <20111009160138.GB99820@elstar.local> <000601cc86eb$829967f0$87cc37d0$@com> <2CE4AB2F9CD06543A3F2B0FE76661E12125C85F9@fzex.ruijie.com.cn> <4A95BA014132FF49AE685FAB4B9F17F61209F3D1@dfweml506-mbx> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F61209F3D1@dfweml506-mbx> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: 'A tao' , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 06:06:40 -0000 SSBoYXZlIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnRzIHRvIGdldCBzb21lIHJlZmVyZW5jZSBkYXRh LA0KaHR0cDovL3Blb3BsZS5uZXRmaWx0ZXIub3JnL2thZGxlYy9uZnRlc3QucGRmDQoNClRoZSAi ZmlsdGVyaW5nIHJ1bGVzIiBpcyBsaWtlIEFDTHMuIEFzIHRoZSBudW1iZXJzIGluY3JlYXNlLCB0 aGUgcGVyZm9ybWFuY2Ugb2YgZGlmZmVyZW50IHNvZnR3YXJlIGhhdmUgZGVjbGluZWQuDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNhbWktYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOnNhbWktYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExpbmRhIER1bmJhcg0K U2VudDogVHVlc2RheSwgT2N0b2JlciAxMSwgMjAxMSA0OjQ2IEFNDQpUbzog5YiY6IyXKOeglOWF rSDnpo/lt54pOyBZaW5namllIEd1KHlpbmdqaWUpOyAnSnVlcmdlbiBTY2hvZW53YWVsZGVyJw0K Q2M6ICdBIHRhbyc7IHNhbWlAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2FtaV0gQSBuZXcgZHJh ZnQgb24gc3RhdGUgbWlncmF0aW9uIHVzZSBjYXNlcyBpcyBzdWJtaXR0ZWQuDQoNClRhbywgDQoN ClRoYXQgaXMgYW4gaW50ZXJlc3RpbmcgZGVzY3JpcHRpb24uIENhbiB5b3UgZWxhYm9yYXRlIGEg bGl0dGxlIGJpdCBvbiBwcm9zIGFuZCBjb25zIG9mIGh5cGVydmlzb3IgQ1BVIHRha2VuIGJ5IHRo ZSBzZWN1cml0eSB2cy4gdGhlIGV4dHJhIHByb2Nlc3Npbmcgb24gc3dpdGNoZXM/IA0KDQpMaW5k YSANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzYW1pLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpzYW1pLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiDl iJjojJco56CU5YWtIOemj+W3nikNCj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDEwLCAyMDExIDk6 MjUgQU0NCj4gVG86IFlpbmdqaWUgR3UoeWluZ2ppZSk7ICdKdWVyZ2VuIFNjaG9lbndhZWxkZXIn DQo+IENjOiAnQSB0YW8nOyBzYW1pQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc2FtaV0gQSBu ZXcgZHJhZnQgb24gc3RhdGUgbWlncmF0aW9uIHVzZSBjYXNlcyBpcw0KPiBzdWJtaXR0ZWQuDQo+ IA0KPiBEZWFyICBZaW5namllLA0KPiANCj4gWWVzLCB5b3UgZ290IG15IHBvaW50LiBPdXIgY3Vz dG9tZXJzIGRlcGxveSB0aGUgdmlydHVhbGl6YXRpb24gaW4gb3JkZXINCj4gdG8gaW1wcm92ZSB0 aGUgdXRpbGl0eSBvZiBoYXJkd2FyZSByZXNvdXJjZXMsIGVzcGVjaWFsbHkgdGhlIENQVSAuIEJ1 dA0KPiB0aGUgc2VjdXJpdHkgcG9saWN5IGV4ZWN1dGVkIGJ5IHRoZSBoeXBlcnZpc29yIHdpbGwg Y29uc3VtZSB0aGUgQ1BVDQo+IHJlc291cmNlIHdpdGhvdXQgbW9uZXkgYmFjay4gU28gaWYgdGhl IHN3aXRjaGVzIGNhbiBtaWdyYXRlIHRoZQ0KPiBzZWN1cml0eSBwb2xpY3kgYWNyb3NzIHRoZSBw aHlzaWNhbCBtYWNoaW5lLCBpdCB3aWxsIG1ha2UgbW9yZSBtb25leQ0KPiBiYWNrLg0KPiANCj4g T2gsIEkgZm9yZ290IGludHJvZHVjaW5nIG15c2VsZi4gTXkgbmFtZSBpcyBNaW5nIExpdS4gSSdt ICBhIHByb2R1Y3QNCj4gbWFuYWdlciBmcm9tIGEgbmV0d29yayBwcm9kdWN0IHZlbmRvciBpbiBD aGluYSBtYWlubGFuZCBhbmQgaW4gY2hhcmdlDQo+IG9mIHNvbHV0aW9ucyBhbmQgcHJvZHVjdHMg Zm9yIERhdGEgQ2VudGVyLiBBbmQgb3VyIGN1c3RvbWVycyBpbmNsdWRlDQo+IGdvdmVybm1lbnQs IHVuaXZlcnNpdGllcywgSUNQIGFuZCBzbyBvbiAuDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBZaW5namllIEd1KHlpbmdqaWUpIFttYWlsdG86Z3V5aW5namllQGh1 YXdlaS5jb21dDQo+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAxMCwgMjAxMSA5OjI1IEFNDQo+IFRv OiAnSnVlcmdlbiBTY2hvZW53YWVsZGVyJzsg5YiY6IyXKOeglOWFrSDnpo/lt54pDQo+IENjOiAn QSB0YW8nOyBzYW1pQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc2FtaV0gQSBuZXcgZHJhZnQg b24gc3RhdGUgbWlncmF0aW9uIHVzZSBjYXNlcyBpcw0KPiBzdWJtaXR0ZWQuDQo+IA0KPiBNaW5n LCB5b3UnZCBiZXR0ZXIgaW50cm9kdWNlIHlvdXJzZWxmIDopDQo+IA0KPiBNeSB1bmRlcnN0YW5k aW5nIG9mIHRoZXNlIHdvcmRzIGlzIHRoYXQsIGluc3RlYWQgb2YgZGVwbG95aW5nIEFDTHMgb24N Cj4gSHlwZXJ2aXNvciBhbmQgdHJ5IHRvIG1pZ3JhdGUgQUNMcyBiZXR3ZWVuIEh5cGVydmlzb3Jz LCB0aGUgY3VzdG9tZXINCj4gd291bGQgbGlrZSB0aGUgQUNMcyBiZSBkZXBsb3llZCBvbiBzd2l0 Y2hlcyBhbmQgbWlncmF0ZSBBQ0xzIGJldHdlZW4NCj4gc3dpdGNoZXMuDQo+IA0KPiBJcyB0aGlz IHdoYXQgeW91IG1lYW4sIE1pbmc/DQo+IA0KPiANCj4gQmVzdCBSZWdhcmRzDQo+IEd1IFlpbmdq aWUNCj4gDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBzYW1pLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpzYW1pLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqA0KPiBKdWVy Z2VuIFNjaG9lbndhZWxkZXINCj4g5Y+R6YCB5pe26Ze0OiAyMDEx5bm0MTDmnIgxMOaXpSDkuZDk uZAwOjAyDQo+IOaUtuS7tuS6ujog5YiY6IyXKOeglOWFrSDnpo/lt54pDQo+IOaKhOmAgTogQSB0 YW87IHNhbWlAaWV0Zi5vcmcNCj4g5Li76aKYOiBSZTogW3NhbWldIEEgbmV3IGRyYWZ0IG9uIHN0 YXRlIG1pZ3JhdGlvbiB1c2UgY2FzZXMgaXMgc3VibWl0dGVkLg0KPiANCj4gT24gU3VuLCBPY3Qg MDksIDIwMTEgYXQgMDE6NDE6MjRQTSArMDAwMCwg5YiY6IyXKOeglOWFrSDnpo/lt54pIHdyb3Rl Og0KPiA+IE9uZSBvZiBvdXIgY3VzdG9tZXJzLCB0aGUgbGVhZGVyIG9mIG9ubGluZSBzaG9wcGlu ZyBwcm92aWRlciBpbiBjaGluYSwNCj4gaGF2ZSB0aGUgc2FtZSByZXF1aXJlbWVudC4gIFRoZXkg cnVuIFZNcyBvbiB0aGUgcG93ZXIgeDg2IG1hY2hpbmUgd2l0aA0KPiBLVk0gaHlwZXJ2aXNvci4g Rm9yIHNvbWUgc2VjdXJpdHkgcmVhc29ucywgdGhleSBhcHBsaWVkIHRoZSBBQ0xzDQo+IHRocm91 Z2ggdGhlIExpbnV44oCZcyBJUHRhYmxlIHJ1bm5pbmcgb24gdGhlIEh5cGVydmlzb3IuIEJ1dCB3 aGVuIHRoZSBWTQ0KPiBmbG9hdGluZyAsIHRoZSBJUHRhYmxlIHByb2ZpbGUgY2FuIG5vdCBiZSBt aWdyYXRlZCB0byB0aGUgb3RoZXIgbWFjaGluZS4NCj4gU28gdGhleSBob3BlIHRoZSBzd2l0Y2gg Y2FuIHJlcGxhY2UgdGhlIElQVGFibGUgIGFuZCBjYW4gbWlncmF0ZXMgdGhlDQo+IEFDTCBwcm9m aWxlcyBmb3IgdGhlIFZNIHdoZW4gZmxvYXRpbmcgLg0KPiANCj4gVGhlIHN3aXRjaGVzIHJlYWxs eSBoYXZlIG5vdGhpbmcgdG8gZG8gd2l0aCBBQ0xzIHNpdHRpbmcgaW4gdGhlDQo+IGh5cGVydmlz b3IuIE1ha2luZyB0aGUgc3dpdGNoZXMgcmVzcG9uc2libGUgZm9yIG1pZ3JhdGluZyB0aGUgQUNM cw0KPiBzZWVtcyBicm9rZW4gdG8gbWUuDQo+IA0KPiAvanMNCj4gDQo+IC0tDQo+IEp1ZXJnZW4g U2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+ IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSwgMjg3NTkgQnJl bWVuLCBHZXJtYW55DQo+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93 d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBzYW1pIG1haWxpbmcgbGlzdA0KPiBzYW1pQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FtaQ0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2FtaSBtYWls aW5nIGxpc3QNCj4gc2FtaUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NhbWkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpzYW1pIG1haWxpbmcgbGlzdA0Kc2FtaUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYW1pDQo= From melinda.shore@gmail.com Mon Oct 10 23:30:07 2011 Return-Path: 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 EC2EC21F8B1F for ; Mon, 10 Oct 2011 23:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 C49c-xGfy899 for ; Mon, 10 Oct 2011 23:30:07 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 68F9021F8AB0 for ; Mon, 10 Oct 2011 23:30:07 -0700 (PDT) Received: by gyd12 with SMTP id 12so7576501gyd.31 for ; Mon, 10 Oct 2011 23:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6d47eSvoKHcnzw7RBOzIVZ4juPyXwkqUJ6KdGMC9xxQ=; b=x5kArcHH5kcL/aE05dC7OOdhvuTykhp5UjgCrFw9TcA9YrYOKJiiMEvTE+fV6VpKIe LMpIdpzttEcg8RylqUfn0ZBbtD2bxVFnDFvtW0Vpa+lR6OCe/PG2uLCgdujAj4XaWN7p HxfnBau+pZwxxto+2blUj5nF90YT1tfxQsIG4= Received: by 10.68.57.3 with SMTP id e3mr42901820pbq.86.1318314606540; Mon, 10 Oct 2011 23:30:06 -0700 (PDT) Received: from polypro.local (216-67-46-106-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.46.106]) by mx.google.com with ESMTPS id o6sm19858549pbb.1.2011.10.10.23.30.04 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Oct 2011 23:30:05 -0700 (PDT) Message-ID: <4E93E26A.3060803@gmail.com> Date: Mon, 10 Oct 2011 22:30:02 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.23) Gecko/20110920 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: zhuozq@ruijie.com.cn References: <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> In-Reply-To: <169529F73649BF469B4F61792955CD5C125E230D@fzex.ruijie.com.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 06:30:08 -0000 On 10/10/11 10:06 PM, 卓志强(研七福州) wrote: > The "filtering rules" is like ACLs. As the numbers increase, the performance of different software have declined. I read that paper. If you go to section 4.3 you'll see that performance varies with the underlying data structures, and while ipfilter uses a really witless linear search the others mentioned do not, and don't show the same performance impacts from large numbers of installed filter rules: "The lines for iptables on both figures show clearly the non-scaling behaviour of iptables. However both nf- hipac and ipset performed almost indifferently with regard of the number of rules. ipset was a tiny bit better than nf-hipac, but ipset is more lighter and simpler than nf-hipac. The last figure shows the required time to add the given number of rules to the kernel. Again, iptables suffers from its linear algorithms (which produces exponential behaviour in rule-addition due to the cumulating effect) while nf-hipac and ipset are immune from such problems." Melinda From j.schoenwaelder@jacobs-university.de Tue Oct 11 00:52:01 2011 Return-Path: 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 3A62421F8D6E for ; Tue, 11 Oct 2011 00:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, 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 OLKQSdcgAihT for ; Tue, 11 Oct 2011 00:52:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6014421F8D36 for ; Tue, 11 Oct 2011 00:52:00 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 46EF420DEB; Tue, 11 Oct 2011 09:51:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gBdLPEcqA-JR; Tue, 11 Oct 2011 09:51:58 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B3FA920DC2; Tue, 11 Oct 2011 09:51:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0C0D11B1B7B6; Tue, 11 Oct 2011 09:51:44 +0200 (CEST) Date: Tue, 11 Oct 2011 09:51:43 +0200 From: Juergen Schoenwaelder To: =?utf-8?B?5Y2T5b+X5by6KOeglOS4gyDnpo/lt54p?= Message-ID: <20111011075143.GB9466@elstar.local> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <169529F73649BF469B4F61792955CD5C125E230D@fzex.ruijie.com.cn> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Yingjie Gu$yingjie$" , =?utf-8?B?5YiY6IyXKOeglOWFrSDnpo/lt54p?= , "sami@ietf.org" , 'A tao' , Linda Dunbar 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 Reply-To: Juergen Schoenwaelder List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 07:52:01 -0000 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 From melinda.shore@gmail.com Tue Oct 11 07:46:08 2011 Return-Path: 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 B381021F8B5A for ; Tue, 11 Oct 2011 07:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 WHW57QMMbIge for ; Tue, 11 Oct 2011 07:46:08 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 270F321F8B30 for ; Tue, 11 Oct 2011 07:46:07 -0700 (PDT) Received: by vws5 with SMTP id 5so6956077vws.31 for ; Tue, 11 Oct 2011 07:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=kTxI5c21crOojU9iGeADJT8lMEewTo0oixVOt3YS3ZE=; b=vmjOiYhk/EQiidCKH7kwPSoXCwjG3QYVy8UhIjNcj5vIwmWEwe7nAx6qtldZ/s3RRn mrCAQOtVOII6KqM11g3cLGZU/VMg9MTh5QVdNMb1tEPfMQr/ZifDsfqOOq4RsoKL1LOk p4fIqg6YpnjDb8UaIBm3imgSyaA/0c+b+pJcc= Received: by 10.68.12.71 with SMTP id w7mr21920553pbb.53.1318344367016; Tue, 11 Oct 2011 07:46:07 -0700 (PDT) Received: from polypro.local (216-67-46-106-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.46.106]) by mx.google.com with ESMTPS id u1sm79895706pbr.9.2011.10.11.07.46.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Oct 2011 07:46:05 -0700 (PDT) Message-ID: <4E9456AA.5020708@gmail.com> Date: Tue, 11 Oct 2011 06:46:02 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.23) Gecko/20110920 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: Juergen Schoenwaelder References: <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> In-Reply-To: <20111011075143.GB9466@elstar.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Yingjie Gu$yingjie$" , =?UTF-8?B?IuWNk+W/l+W8uijnoJTkuIMg56aP5beeKSI=?= , Linda Dunbar , 'A tao' , =?UTF-8?B?IuWImOiMlyjnoJTlha0g56aP5beeKSI=?= , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 14:46:08 -0000 On 10/10/11 11:51 PM, Juergen Schoenwaelder wrote: > 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. Well, I'm not sure. It seems to me that "easier to scale" is an issue only if what's being done fails to scale with the number of rules. The cited paper doesn't do that - in fact, it says that if you use freely available open source software, the marginal cost of adding more rules is 0. I agree with your point more generally, however. It's counterintuitive to think that it's cheaper to aggregate rulesets in network devices than it is to push the platform-specific ones out to the edges. But, unless there's a real problem here I think the discussion is irrelevant, at least in the context of trying to figure out whether or not to charter some IETF work. Melinda From yangjingtao@gmail.com Tue Oct 11 09:02:01 2011 Return-Path: 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 5839B21F8EE0 for ; Tue, 11 Oct 2011 09:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] 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 Qf5EAmuarANe for ; Tue, 11 Oct 2011 09:02:00 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 99B5F21F8EB3 for ; Tue, 11 Oct 2011 09:01:53 -0700 (PDT) Received: by vws5 with SMTP id 5so7059609vws.31 for ; Tue, 11 Oct 2011 09:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N1Hj6MfrUVWeVHkq54d4rtw2xP28ni5qT9dWVeIlWpA=; b=TwRUrHV2klTpY6FU+IiYnKjxSldHa5Q16fLKXl4hCbjT59Lo3jnaOdg4pV42IvLcpc 2OJfmMavEOkdmVPif3obIk497xrDaG3RmZI36xNnsdo96jBuGYAPTdRWh9DGMCMjgxH4 wDKXjjTX+djNS0+qIBS75AF4dBTKCGuJOmX9s= MIME-Version: 1.0 Received: by 10.52.36.41 with SMTP id n9mr19108386vdj.41.1318348911614; Tue, 11 Oct 2011 09:01:51 -0700 (PDT) Received: by 10.52.108.100 with HTTP; Tue, 11 Oct 2011 09:01:51 -0700 (PDT) In-Reply-To: <20111011075143.GB9466@elstar.local> References: <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> Date: Wed, 12 Oct 2011 00:01:51 +0800 Message-ID: From: A tao To: Juergen Schoenwaelder Content-Type: multipart/alternative; boundary=20cf3079ba76911a1904af08060d Cc: "Yingjie Gu$yingjie$" , =?GB2312?B?17/Wvse/KNHQxt8guKPW3Sk=?= , "sami@ietf.org" , =?GB2312?B?wfXc+CjR0MH5ILij1t0p?= , Linda Dunbar 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 16:02:01 -0000 --20cf3079ba76911a1904af08060d Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable No doubt that a performance test results can help people to understand, to some extent, why there are requirements and implementations to move securit= y 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 > On Tue, Oct 11, 2011 at 06:06:34AM +0000, =D7=BF=D6=BE=C7=BF(=D1=D0=C6=DF= =B8=A3=D6=DD) 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 > --20cf3079ba76911a1904af08060d Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

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

If Ming can provide this results, that will be best.&nb= sp;

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 Firewal= l functions on a x86 server. And by test, they find the firewall consumes m= ore than large amount of CPU capacity which otherwise can be used to suppor= t 2-3 VMs. I don't get the real data and the test situation, this is on= ly a information.

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

On Tue, Oct 11, 2011 at 06:06:34AM +0000, =D7=BF=D6=BE=C7= =BF(=D1=D0=C6=DF =B8=A3=D6=DD) 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 (th= e
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 Br= emen, Germany
Fax: +49 421 200 3103 <http://www.jacobs-universi= ty.de/>

--20cf3079ba76911a1904af08060d-- From guyingjie@huawei.com Tue Oct 11 19:57:12 2011 Return-Path: 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 ; 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 ; 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 ; 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)" In-reply-to: X-Originating-IP: [10.138.41.134] To: 'A tao' , 'Juergen Schoenwaelder' 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: <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> Cc: =?gb2312?B?J9e/1r7HvyjR0MbfILij1t0pJw==?= , sami@ietf.org, =?gb2312?B?J8H13Pgo0dDB+SC4o9bdKSc=?= , 'Linda Dunbar' Subject: [sami] =?gb2312?b?tPC4tDogIEEgbmV3IGRyYWZ0IG9uIHN0YXRlIG1pZ3Jh?= =?gb2312?b?dGlvbiB1c2UgY2FzZXMgaXMgc3VibWl0dGVkLg==?= X-BeenThere: sami@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 02:57:12 -0000 --Boundary_(ID_IizqdI9p7MOKUo5WfA+Vdw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable 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. =20 I think there are some knowledge that should be the base of SAMI, they = are: =20 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.=20 =20 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.=20 =20 (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) =20 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.=20 =20 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. =20 Of course, I am willing to hear people's opinions on these knowledge. =20 If we agree on the above knowledge, we can move forward, to discuss = whether the states and scenarios make sense to you,=20 =20 =20 _____ =20 Best Regards Gu Yingjie =20 =B7=A2=BC=FE=C8=CB: A tao [mailto:yangjingtao@gmail.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C212=C8=D5 =C0=D6=C0=D60:02 =CA=D5=BC=FE=C8=CB: Juergen Schoenwaelder =B3=AD=CB=CD: =D7=BF=D6=BE=C7=BF(=D1=D0=C6=DF =B8=A3=D6=DD); Linda = Dunbar; =C1=F5=DC=F8(=D1=D0=C1=F9 =B8=A3=D6=DD); Yingjie Gu(yingjie); sami@ietf.org =D6=F7=CC=E2: Re: [sami] A new draft on state migration use cases is = submitted. =20 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. =20 If Ming can provide this results, that will be best.=20 =20 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.=20 =20 2011/10/11 Juergen Schoenwaelder On Tue, Oct 11, 2011 at 06:06:34AM +0000, = =D7=BF=D6=BE=C7=BF(=D1=D0=C6=DF =B8=A3=D6=DD) 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 =20 --Boundary_(ID_IizqdI9p7MOKUo5WfA+Vdw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

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.

<= /span>

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

<= /span>

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.

<= /span>

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.

<= /span>

(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)

<= /span>

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.

<= /span>

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.

<= /span>

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

<= /span>

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

B= est Regards
Gu Yingjie

=B7=A2=BC=FE=C8=CB: A tao [mailto:yangjingtao@gmail.com] =
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C212=C8=D5 =C0=D6=C0=D60:02
=CA=D5=BC=FE=C8=CB: Juergen = Schoenwaelder
=B3=AD=CB=CD: = =D7=BF=D6=BE=C7=BF(=D1=D0=C6=DF = =B8=A3=D6=DD); Linda Dunbar; =C1=F5=DC=F8(=D1=D0=C1=F9 =B8=A3=D6=DD); = Yingjie Gu(yingjie); sami@ietf.org
=D6=F7=CC=E2: 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@jaco= bs-university.de>

On Tue, Oct 11, 2011 = at 06:06:34AM +0000, =D7=BF=D6=BE=C7=BF(=D1=D0=C6=DF =B8=A3=D6=DD) = wrote:
> I have the following documents to get some reference = data,
> http://people.netfilter.org/kadlec/nftest.pdf
&g= t;
> 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/>

= --Boundary_(ID_IizqdI9p7MOKUo5WfA+Vdw)-- From j.schoenwaelder@jacobs-university.de Tue Oct 11 23:17:58 2011 Return-Path: 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 05B2021F8C4F for ; Tue, 11 Oct 2011 23:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.782 X-Spam-Level: X-Spam-Status: No, score=-102.782 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8x2=0.246, 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 ngA5-wiDp58A for ; Tue, 11 Oct 2011 23:17:57 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8E42021F8BEB for ; Tue, 11 Oct 2011 23:17:55 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EFB4820DB9; Wed, 12 Oct 2011 08:17:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id p1ZWyWl8to1i; Wed, 12 Oct 2011 08:17:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CBE4320D22; Wed, 12 Oct 2011 08:17:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9670A1B1D5FD; Wed, 12 Oct 2011 08:17:38 +0200 (CEST) Date: Wed, 12 Oct 2011 08:17:38 +0200 From: Juergen Schoenwaelder To: "Yingjie Gu(yingjie)" Message-ID: <20111012061738.GB13515@elstar.local> References: <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> <003c01cc888a$a0a230b0$e1e69210$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003c01cc888a$a0a230b0$e1e69210$@com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 'A tao' , =?utf-8?B?J+WNk+W/l+W8uijnoJTkuIMg56aP5beeKSc=?= , sami@ietf.org, =?utf-8?B?J+WImOiMlyjnoJTlha0g56aP5beeKSc=?= , 'Linda Dunbar' Subject: Re: [sami] =?utf-8?b?562U5aSNOiAgQSBuZXcgZHJhZnQgb24gc3RhdGUgbWlncmF0?= =?utf-8?q?ion_use_cases_is_submitted=2E?= X-BeenThere: sami@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 06:17:58 -0000 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 From melinda.shore@gmail.com Tue Oct 11 23:41:22 2011 Return-Path: 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 B381521F8B0A for ; Tue, 11 Oct 2011 23:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.373 X-Spam-Level: X-Spam-Status: No, score=-3.373 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] 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 e75hYTdNWDjc for ; Tue, 11 Oct 2011 23:41:22 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0C021F8B0C for ; Tue, 11 Oct 2011 23:41:22 -0700 (PDT) Received: by ggnk3 with SMTP id k3so462321ggn.31 for ; Tue, 11 Oct 2011 23:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WTZz5IJo/f+VnOeFrGZB4FWKHyR3e/N6EHbNQvKZVW0=; b=Xt2zGMMolfJylLrB94kLnkwuanZU4lzOtFOCK0zWhKVniQWTgzWYh4ixSIV2UP7+Fr n390k0M6MxFKsAS93guN14jVfnhQtIjboI3MsXzDRKkN9uvw+8w/QwyRb/Mth3MjL7sg RhMiUMPUMstiLXM2UIKgQ5YNdNlFN73+LOhcE= Received: by 10.68.31.131 with SMTP id a3mr51369095pbi.24.1318401681521; Tue, 11 Oct 2011 23:41:21 -0700 (PDT) Received: from polypro.local (216-67-46-106-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.46.106]) by mx.google.com with ESMTPS id ml4sm4422879pbc.0.2011.10.11.23.41.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Oct 2011 23:41:20 -0700 (PDT) Message-ID: <4E95368D.7000406@gmail.com> Date: Tue, 11 Oct 2011 22:41:17 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.23) Gecko/20110920 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: Juergen Schoenwaelder References: <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> <003c01cc888a$a0a230b0$e1e69210$@com> <20111012061738.GB13515@elstar.local> In-Reply-To: <20111012061738.GB13515@elstar.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Yingjie Gu$yingjie$" , =?UTF-8?B?IifljZPlv5flvLoo56CU5LiDIOemj+W3niknIg==?= , 'Linda Dunbar' , 'A tao' , =?UTF-8?B?IifliJjojJco56CU5YWtIOemjw==?= =?UTF-8?B?5beeKSci?= , sami@ietf.org Subject: Re: [sami] =?utf-8?b?562U5aSNOiAgQSBuZXcgZHJhZnQgb24gc3RhdGUgbWlncmF0?= =?utf-8?q?ion_use_cases_is_submitted=2E?= X-BeenThere: sami@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 06:41:22 -0000 On 10/11/11 10:17 PM, Juergen Schoenwaelder wrote: > My understanding is that today neither hypervisors nor 'switches' > support the state live migration you want. There's been some work done around a more static scenario - SCTP and NAT - although I'm not sure what state it's in. Probably worth checking out whether anything's been done with regard to this in mobile IP. I will say, based on the midcom architectural work and the follow-on stuff with route-coupled signaling protocols that the topology-related problems with moving flow-coupled state around the network is exceptionally difficult - sufficiently difficult, I think, that it really is a good idea to avoid it when possible. I still think there's a core of an interesting idea here and I'm pretty frustrated that on the one hand its advocates have not been able to make a stronger case and that on the other hand they won't let it stew quietly at the back of the stove for a little while. In particular, in a crunchy-on-the-outside network security model there's state associated with firewalling and with NAT *in* *network* *devices* that will probably need to move, but the authors haven't presented a case for that, the service providers are apparently not asking for that, and it seems to have drifted out of the picture. Instead, we're getting some fairly confusing (and unsupported) assertions about performance and DHCP sniffing and all sorts of things that mostly leave me doubting what I'm reading (they're not helped much by the early history of the cloud/datacenter advocacy at the IETF). If you can forgive a badly-mixed metaphor I think this particular stewpot has run out of track. Melinda From guyingjie@huawei.com Tue Oct 11 23:50:37 2011 Return-Path: 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 ; 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 ; 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 ; 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)" In-reply-to: <20111012061738.GB13515@elstar.local> X-Originating-IP: [10.138.41.134] To: 'Juergen Schoenwaelder' 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: <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> <003c01cc888a$a0a230b0$e1e69210$@com> <20111012061738.GB13515@elstar.local> Cc: 'A tao' , =?gb2312?B?J9e/1r7HvyjR0MbfILij1t0pJw==?= , =?gb2312?B?J8H13Pgo0dDB+SC4o9bdKSc=?= , 'Linda Dunbar' , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.=20 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.=20 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 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: sami-bounces@ietf.org [mailto:sami-bounces@ietf.org] = =B4=FA=B1=ED Juergen Schoenwaelder =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C212=C8=D5 =C0=D6=C0=D614:18 =CA=D5=BC=FE=C8=CB: Yingjie Gu(yingjie) =B3=AD=CB=CD: 'A tao'; '=D7=BF=D6=BE=C7=BF(=D1=D0=C6=DF =B8=A3=D6=DD)'; = sami@ietf.org; '=C1=F5=DC=F8(=D1=D0=C1=F9 =B8=A3=D6=DD)'; 'Linda Dunbar' =D6=F7=CC=E2: Re: [sami] =B4=F0=B8=B4: 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.=20 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. =20 > 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 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ sami mailing list sami@ietf.org https://www.ietf.org/mailman/listinfo/sami From j.schoenwaelder@jacobs-university.de Wed Oct 12 00:42:28 2011 Return-Path: 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 C29A521F8B1D for ; Wed, 12 Oct 2011 00:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.065 X-Spam-Level: X-Spam-Status: No, score=-103.065 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 TCQHf1pEXqF3 for ; Wed, 12 Oct 2011 00:42:28 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 13DD721F8A6F for ; Wed, 12 Oct 2011 00:42:28 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C21F20DA9; Wed, 12 Oct 2011 09:42:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id spLDhIjS8mtJ; Wed, 12 Oct 2011 09:42:26 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC81820DA6; Wed, 12 Oct 2011 09:42:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 811391B1D979; Wed, 12 Oct 2011 09:42:11 +0200 (CEST) Date: Wed, 12 Oct 2011 09:42:11 +0200 From: Juergen Schoenwaelder To: "Yingjie Gu(yingjie)" Message-ID: <20111012074211.GC13898@elstar.local> References: <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> <003c01cc888a$a0a230b0$e1e69210$@com> <20111012061738.GB13515@elstar.local> <005a01cc88ab$650e4180$2f2ac480$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005a01cc88ab$650e4180$2f2ac480$@com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 'A tao' , =?utf-8?B?J+WNk+W/l+W8uijnoJTkuIMg56aP5beeKSc=?= , =?utf-8?B?J+WImOiMlyjnoJTlha0g56aP5beeKSc=?= , 'Linda Dunbar' , 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 Reply-To: Juergen Schoenwaelder List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 07:42:28 -0000 On Wed, Oct 12, 2011 at 02:51:39PM +0800, Yingjie Gu(yingjie) wrote: > 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? Software Driven Network seems to be a different name for what is known as OpenFlow networks , where the control logic of a network is separated from the hardware taking care of packet forwarding. If you have OpenFlow switches in front of your hypervisors, than you control the flow processing behaviour of the switches from a logically centralized external controller. Moving a VM then just requires to inform the controller and the controller in turn will "reprogram" the OpenFlow switches to move the data where it needs to be. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From guyingjie@huawei.com Wed Oct 12 02:22:37 2011 Return-Path: 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 1502421F886A for ; Wed, 12 Oct 2011 02:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.022 X-Spam-Level: X-Spam-Status: No, score=-105.022 tagged_above=-999 required=5 tests=[AWL=1.577, BAYES_00=-2.599, 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 zgSsmFQIhc6l for ; Wed, 12 Oct 2011 02:22:36 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0962721F877F for ; Wed, 12 Oct 2011 02:22:36 -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 <0LSY00J3K4MZM0@szxga04-in.huawei.com> for sami@ietf.org; Wed, 12 Oct 2011 17:20:59 +0800 (CST) Received: from szxrg02-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 <0LSY00GK44MYQM@szxga04-in.huawei.com> for sami@ietf.org; Wed, 12 Oct 2011 17:20:59 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEE70615; Wed, 12 Oct 2011 17:20:30 +0800 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 12 Oct 2011 17:20:23 +0800 Received: from g00107907 (10.138.41.134) by szxeml411-hub.china.huawei.com (10.82.67.138) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 12 Oct 2011 17:20:21 +0800 Date: Wed, 12 Oct 2011 17:22:39 +0800 From: "Yingjie Gu(yingjie)" In-reply-to: <4E95368D.7000406@gmail.com> X-Originating-IP: [10.138.41.134] To: 'Melinda Shore' , 'Juergen Schoenwaelder' Message-id: <005e01cc88c0$7d3315a0$779940e0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=UTF-8 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcyIqfgWaK0wcm+jSG+IvfzNac+anwAAX1kw X-CFilter-Loop: Reflected References: <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> <003c01cc888a$a0a230b0$e1e69210$@com> <20111012061738.GB13515@elstar.local> <4E95368D.7000406@gmail.com> Cc: 'A tao' , =?UTF-8?B?JyIn5Y2T5b+X5by6KOeglOS4gyDnpo/lt54pJyIn?= , =?UTF-8?B?JyIn5YiY6IyXKOeglOWFrSDnpo/lt54pJyIn?= , 'Linda Dunbar' , 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 List-Unsubscribe: , List-Archive: List-Post: