IETF Logo Mail Archive

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

"zhuozq" <zhuozq@gmail.com> Mon, 10 October 2011 08:11 UTC

Return-Path: <zhuozq@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 3699821F8AF7 for <sami@ietfa.amsl.com>; 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 <sami@ietfa.amsl.com>; 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 <sami@ietf.org>; Mon, 10 Oct 2011 01:11:28 -0700 (PDT)
Received: by iaby26 with SMTP id y26so8803778iab.31 for <sami@ietf.org>; 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" <zhuozq@gmail.com>
To: "sami" <sami@ietf.org>
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 <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: Mon, 10 Oct 2011 08:11:29 -0000

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

v2.8.7 | Report a Bug | By Email