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

Melinda Shore <melinda.shore@gmail.com> Tue, 11 October 2011 14:46 UTC

Return-Path: <melinda.shore@gmail.com>
X-Original-To: sami@ietfa.amsl.com
Delivered-To: sami@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B381021F8B5A for <sami@ietfa.amsl.com>; 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 <sami@ietfa.amsl.com>; 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 <sami@ietf.org>; Tue, 11 Oct 2011 07:46:07 -0700 (PDT)
Received: by vws5 with SMTP id 5so6956077vws.31 for <sami@ietf.org>; 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 <melinda.shore@gmail.com>
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 <j.schoenwaelder@jacobs-university.de>
References: <CAB+71L3btz_h8Lkm9jW-WHUeS4=K-Jq-r9mmX94=NdHiepkJ-Q@mail.gmail.com> <2CE4AB2F9CD06543A3F2B0FE76661E12125C8295@fzex.ruijie.com.cn> <20111009160138.GB99820@elstar.local> <000601cc86eb$829967f0$87cc37d0$@com> <2CE4AB2F9CD06543A3F2B0FE76661E12125C85F9@fzex.ruijie.com.cn> <4A95BA014132FF49AE685FAB4B9F17F61209F3D1@dfweml506-mbx> <169529F73649BF469B4F61792955CD5C125E230D@fzex.ruijie.com.cn> <20111011075143.GB9466@elstar.local>
In-Reply-To: <20111011075143.GB9466@elstar.local>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "Yingjie Gu(yingjie)" <guyingjie@huawei.com>, "\"卓志强(研七 福州)\"" <zhuozq@ruijie.com.cn>, Linda Dunbar <linda.dunbar@huawei.com>, 'A tao' <yangjingtao@gmail.com>, "\"刘茗(研六 福州)\"" <lium@ruijie.com.cn>, "sami@ietf.org" <sami@ietf.org>
Subject: Re: [sami] A new draft on state migration use cases is submitted.
X-BeenThere: sami@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: State Migration <sami.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sami>, <mailto:sami-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sami>
List-Post: <mailto:sami@ietf.org>
List-Help: <mailto:sami-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sami>, <mailto:sami-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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