[OPSAWG] Request a timeslot for presentation on a DCI solution

Xuxiaohu <xuxiaohu@huawei.com> Thu, 03 November 2011 05:07 UTC

Return-Path: <xuxiaohu@huawei.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DFD1F0C54 for <opsawg@ietfa.amsl.com>; Wed, 2 Nov 2011 22:07:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.453
X-Spam-Level:
X-Spam-Status: No, score=-4.453 tagged_above=-999 required=5 tests=[AWL=1.546, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 USW59tg14qah for <opsawg@ietfa.amsl.com>; Wed, 2 Nov 2011 22:07:31 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id DAE4A1F0C43 for <opsawg@ietf.org>; Wed, 2 Nov 2011 22:07:30 -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 <0LU2005JVJK3TX@szxga05-in.huawei.com> for opsawg@ietf.org; Thu, 03 Nov 2011 13:07:15 +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 <0LU2008V0JK1LF@szxga05-in.huawei.com> for opsawg@ietf.org; Thu, 03 Nov 2011 13:07:15 +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 AES55770; Thu, 03 Nov 2011 13:07:12 +0800
Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 03 Nov 2011 13:07:06 +0800
Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.181]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0270.001; Thu, 03 Nov 2011 13:07:03 +0800
Date: Thu, 03 Nov 2011 05:07:02 +0000
From: Xuxiaohu <xuxiaohu@huawei.com>
X-Originating-IP: [10.108.4.59]
To: "sob@harvard.edu" <sob@harvard.edu>, "ietf@cdl.asgaard.org" <ietf@cdl.asgaard.org>, "rbonica@juniper.net" <rbonica@juniper.net>, "dromasca@avaya.com" <dromasca@avaya.com>
Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73CD13@szxeml525-mbs.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-language: zh-CN
Content-transfer-encoding: 7bit
Accept-Language: zh-CN, en-US
Thread-topic: Request a timeslot for presentation on a DCI solution
Thread-index: AcyZ6F76orxGETr0QZalsOze36BrKQ==
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-CFilter-Loop: Reflected
Cc: "opsawg@ietf.org" <opsawg@ietf.org>
Subject: [OPSAWG] Request a timeslot for presentation on a DCI solution
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsawg>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Nov 2011 05:07:31 -0000

Dear OPS WG co-chairs and OPS Area directors,

I would like to request a timeslot for presenting Virtual Subnet (http://tools.ietf.org/html/draft-xu-virtual-subnet-06) which realizes subnet extension across geographically dispersed data centers by using proven L3VPN and ARP proxy technologies. Subnet extension across data centers is a basic requirement for VM mobility across data centers.

Since it has no change to L3VPN protocol, I think OPSWG/OPSArea is a good place to talk about it. Has there been a DCOPS WG/BOF in OPS AREA before?

Abstract of Virtual Subnet:

Virtual Subnet (VS) provides a scalable data center interconnection service (e.g., subnet extension across data centers) by reusing the proven BGP/MPLS IP VPN [RFC4364] and ARP proxy [RFC925][RFC1027] technologies.  In contrast with the existing VPLS solutions, VS could bring us many attractive benefits: First, it alleviates the broadcast storm impact on the network performance to a great extent by splitting the otherwise whole ARP broadcast and unknown unicast flooding domain associated with the IP subnet that has been extended across multiple data centers, into multiple isolated parts; Second, the forwarding table scalability issue on data center switches (e.g., ToR switches) is successfully solved by splitting the MAC learning domain associated with the same subnet into multiple segments due to the usage of ARP proxy; Third, it can support active-active data center exits and path optimization....

Best regards,
Xiaohu