[arp222] Some concerns about SEATTLE
xuxiaohu 41208 <xuxh@huawei.com> Thu, 29 July 2010 09:20 UTC
Return-Path: <xuxh@huawei.com>
X-Original-To: arp222@core3.amsl.com
Delivered-To: arp222@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AE1C3A69C3 for <arp222@core3.amsl.com>; Thu, 29 Jul 2010 02:20:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.105
X-Spam-Level:
X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_35=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7fi0kUS7etp for <arp222@core3.amsl.com>; Thu, 29 Jul 2010 02:20:40 -0700 (PDT)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 61DF83A69A0 for <arp222@ietf.org>; Thu, 29 Jul 2010 02:20:40 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6B002CTBAT4X@szxga01-in.huawei.com> for arp222@ietf.org; Thu, 29 Jul 2010 17:20:53 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6B00IJ9BATTP@szxga01-in.huawei.com> for arp222@ietf.org; Thu, 29 Jul 2010 17:20:53 +0800 (CST)
Received: from [172.24.1.3] (Forwarded-For: [130.129.116.197]) by szxmc04-in.huawei.com (mshttpd); Thu, 29 Jul 2010 17:20:53 +0800
Date: Thu, 29 Jul 2010 17:20:53 +0800
From: xuxiaohu 41208 <xuxh@huawei.com>
To: arp222@ietf.org
Message-id: <fbafc6b5d65.d65fbafc6b5@huawei.com>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006)
Content-type: text/plain; charset="us-ascii"
Content-language: zh-CN
Content-transfer-encoding: 7bit
Content-disposition: inline
X-Accept-Language: zh-CN
Priority: normal
Subject: [arp222] Some concerns about SEATTLE
X-BeenThere: arp222@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." <arp222.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/arp222>, <mailto:arp222-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/arp222>
List-Post: <mailto:arp222@ietf.org>
List-Help: <mailto:arp222-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/arp222>, <mailto:arp222-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Jul 2010 09:20:41 -0000
Hi, If I understood the SEATTLE correctly, the keys used in ARP resolution and location resolution is IP address and MAC address respectively. Hence I have the following two doubts: 1.Have the scenario where different VLANs are associated with overlapping addressses been considered in SETTLE? 2.Have the scenario where different hosts are configured with the same MAC address occasionally but located in different VLANs been considered in SETTLE? By the way, since the SEATTLE uses the idea of map&encap scheme and the cache scheme, let's consider more about the cache issues which have been discussed many times in the RRG mailing-list: 1.How to keep the location mapping caches on the ingress tunnel devices up to date, especially in the case of VM mobility? Xiaohu
- [arp222] Some concerns about SEATTLE xuxiaohu 41208