From martin.vigoureux@alcatel-lucent.com Mon Jul 1 03:02:23 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E7A21F942D for ; Mon, 1 Jul 2013 03:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, 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 qMFWjoBezNFL for ; Mon, 1 Jul 2013 03:02:16 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9C621F9360 for ; Mon, 1 Jul 2013 03:02:16 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r61A2DQm023939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 1 Jul 2013 05:02:15 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r61A1Tnf010699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Jul 2013 12:01:59 +0200 Received: from [172.27.205.220] (135.239.27.41) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 1 Jul 2013 12:01:42 +0200 Message-ID: <51D15386.4090303@alcatel-lucent.com> Date: Mon, 1 Jul 2013 12:01:42 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Subject: Slots requests for L3VPN Session - IETF 87 - Berlin Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.41] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 10:02:23 -0000 Dear all, the L3VPN WG will meet in Berlin. The session (still subject to change) is scheduled on Tuesday (30th), Morning Session I, 09:00-11:30. This is thus a call for presentation slots. Could you please send to Thomas and I, copying Dan, your requests, before the 16th of July, indicating: draft name, speaker and desired duration (presentation + Q&As). Thank you. Martin for the L3VPN co-chairs From thomas.morin@orange.com Mon Jul 1 06:17:57 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C4111E84EF for ; Mon, 1 Jul 2013 06:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] 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 KdoCGbWk6FlD for ; Mon, 1 Jul 2013 06:17:53 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 182EB11E823A for ; Mon, 1 Jul 2013 06:13:45 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 3089C2643A2; Mon, 1 Jul 2013 15:13:43 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 138EE4C015; Mon, 1 Jul 2013 15:13:43 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Mon, 1 Jul 2013 15:13:42 +0200 From: To: Xuxiaohu Subject: Re: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Topic: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Index: Ac5thMS2t8EppEHAQo6a5WxySmdDhQIdhP9gABRMqAA= Date: Mon, 1 Jul 2013 13:13:42 +0000 Message-ID: <6463_1372684423_51D18087_6463_1266_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D074D1A7D@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CAD74@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CAD74@NKGEML512-MBS.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.28.101520 Cc: "l3vpn-chairs@tools.ietf.org" , L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 13:17:57 -0000 SGVsbG8gWHV4aWFvaHUsDQoNCkJlZm9yZSBldmVudHVhbGx5IHN0YXJ0aW5nIGEgZGlzY3Vzc2lv biBvbiB0aGUgYWRvcHRpb24gb24gdGhpcyANCmRvY3VtZW50LCB3ZSBjaGFpcnMgd291bGQgbGlr ZSB0byBzZWUgbW9yZSBkaXNjdXNzaW9uIGFuZCBoYXZlIHRoZSANCmZlZWRiYWNrIGZyb20gbW9y ZSByZWFkZXJzIChkdXJpbmcgdGhlIDIgcHJldmlvdXMgbWVldGluZ3MsIG9ubHkgNSB0byAxMCAN CnBlb3BsZSByYWlzZWQgdGhlaXIgaGFuZCB3aGVuIHRoZSByb29tIHdhcyBwb2xsZWQgb24gaGF2 aW5nIHJlYWQgdGhlIA0KZG9jdW1lbnQpLg0KDQpSZWdhcmRzLA0KDQotVGhvbWFzIGFuZCBNYXJ0 aW4sDQpsM3ZwbiBjby1jaGFpcnMNCg0KDQoyMDEzLTA3LTAxLCBYdXhpYW9odToNCj4gSGkgVGhv bWFzIGFuZCBNYXJ0aW4sDQo+DQo+IEkgaGF2ZW4ndCByZWNlaXZlZCBhbnkgcmVzcG9uc2UgZnJv bSBhbnkgb2YgeW91LiBIZW5jZSBJIHJlc2VuZCBpdC4NCj4NCj4gQmVzdCByZWdhcmRzLA0KPiBY aWFvaHUNCj4NCj4+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4+IOWPkeS7tuS6ujogWHV4aWFv aHUNCj4+IOWPkemAgeaXtumXtDogMjAxM+W5tDbmnIgyMOaXpSAxNTowNw0KPj4g5pS25Lu25Lq6 OiAnbDN2cG4tY2hhaXJzQHRvb2xzLmlldGYub3JnJzsgJ3Rob21hcy5tb3JpbkBvcmFuZ2UuY29t JzsNCj4+ICdtYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwtbHVjZW50LmNvbScNCj4+IOaKhOmAgTog TDNWUE4NCj4+IOS4u+mimDogUmVxdWVzdCBhIFdHIGFkb3B0aW9uIHBvbGwgZm9yIGRyYWZ0LXh1 LXZpcnR1YWwtc3VibmV0LTEwDQo+Pg0KPj4gSGkgV0cgY28tY2hhaXJzLA0KPj4NCj4+IEFzIG1l bnRpb25lZCBiZWZvcmUsIHRoaXMgZHJhZnQNCj4+IChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC14dS12aXJ0dWFsLXN1Ym5ldC0xMCkgZGVzY3JpYmVzIGhvdyB0byByZXVzZQ0KPj4g dGhlIHByb3ZlbiBMM1ZQTiB0ZWNobm9sb2d5IHRvIHJlYWxpemUgc3VibmV0IGV4dGVuc2lvbiBm b3IgZGF0YSBjZW50ZXINCj4+IGludGVyY29ubmVjdCwgd2l0aCB0aGUgYWlkIG9mIG1hbnkgY29u Y3JldGUgZXhwZXJpbWVudHMgYW5kIHZlcmlmaWNhdGlvbnMuDQo+Pg0KPj4gV2UgY28tYXV0aG9y cyBiZWxpZXZlIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBkcmFmdCB3b3VsZCBi ZSB2YWx1YWJsZQ0KPj4gZm9yIGNsb3VkIHNlcnZpY2UgcHJvdmlkZXJzIHRvIGV2YWx1YXRlIHRo ZSBmZWFzaWJpbGl0eSBvZiBhZG9wdGluZyB0aGUgcHJvdmVuDQo+PiBMM1ZQTiB0ZWNobm9sb2d5 IGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3Rpb24gKGJ5IHRoZSB3YXksIHNvbWUgcGVvcGxl DQo+PiBoYWQgc2hvd24gdGhlaXIgaW50ZXJlc3RzIG9uIHRoZSBzY2hlbWUgZGVzY3JpYmVkIGlu IHRoaXMgZHJhZnQgd2hlbiB2aXNpdGluZw0KPj4gb3VyIGltcGxlbWVudGF0aW9uIGRlbW8gb2Yg dGhpcyBzY2hlbWUgYXQgdGhlIEJpdHMtTi1CaXRlcyBldmVudCBvZiBJRVRGODYpLg0KPj4gSGVu Y2Ugd2Ugd291bGQgbGlrZSBjby1jaGFpcnMgdG8gc3RhcnQgYSBXRyBhZG9wdGlvbiBwb2xsIGZv ciB0aGlzIGRyYWZ0Lg0KPj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+IFhpYW9odSAob24gYmVoYWxm IG9mIGFsbCBjby1hdXRob3JzKQ0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBq b2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMg b3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhw bG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2Ug bWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVj bGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVm b3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0 IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQs IHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxl dGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From wesley.george@twcable.com Mon Jul 1 06:43:26 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8072921F9F47; Mon, 1 Jul 2013 06:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] 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 2qOMcm+LDKsU; Mon, 1 Jul 2013 06:43:22 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 150BB21F9F44; Mon, 1 Jul 2013 06:43:21 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.87,974,1363147200"; d="scan'208";a="98170762" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 01 Jul 2013 09:40:59 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 1 Jul 2013 09:42:53 -0400 From: "George, Wes" To: "mpls@ietf.org" Date: Mon, 1 Jul 2013 09:42:50 -0400 Subject: IPv6-only MPLS gap analysis Thread-Topic: IPv6-only MPLS gap analysis Thread-Index: Ac52YN0rty2KcGKdS1SHtmzwtosE3w== Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230435B0ECC4@PRVPEXVS15.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "l2vpn@ietf.org" , "draft-ietf-l2vpn-evpn@tools.ietf.org" , "l3vpn@ietf.org" , "draft-mpls-ipv6-only-gap@tools.ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 13:43:26 -0000 QXMgZGlzY3Vzc2VkIGluIE9ybGFuZG8gaW4gdGhlIE1QTFMgV0csIHdlIGhhdmUgYmVndW4gd29y ayBvbiBhIEdhcCBBbmFseXNpcyBmb3IgTVBMUyBvcGVyYXRpb24gb24gYW4gSVB2Ni1vbmx5IG5l dHdvcmsuIEkgYW0gY29weWluZyB0aGUgTDJWUE4gYW5kIEwzVlBOIFdHcywgYXMgdGhlIGF1dGhv cnMgd291bGQgY2VydGFpbmx5IHZhbHVlIHRoZWlyIHJldmlldyBhbmQgaW5wdXQsIGFuZCB3ZSBh bHNvIHdhbnRlZCB0byBtYWtlIHRob3NlIFdHcyBhd2FyZSBvZiB0aGUgbmVlZCB0byBiZWdpbiBj b25zaWRlcmluZyBJUHY2LW9ubHkgb3BlcmF0aW9uIGluIGFueSBuZXcgc3RhbmRhcmRzIHdvcmsg dGhhdCB0aGV5IG1pZ2h0IHVuZGVydGFrZSwgZS5nLiBFVlBOLiBUaGlzIG1heSB0YWtlIHRoZSBm b3JtIG9mIHJlZmVycmluZyB0byBleGlzdGluZyBnYXBzIGZyb20gdGhpcyBkb2N1bWVudCB0aGF0 IG11c3QgYmUgYWRkcmVzc2VkIGJlZm9yZSB0aGUgZGVwZW5kZW5jeSBpcyByZXNvbHZlZCwgb3Ig aXQgbWF5IHRha2UgdGhlIGZvcm0gb2YgY2hhbmdlcyB0byB0aGUgZHJhZnQgdG8gZXhwbGljaXRs eSBhbGxvdyBJUHY2LW9ubHkgb3BlcmF0aW9uLCBidXQgd2UgbGltaXRlZCBvdXIgc2NvcGUgdG8g ZXhpc3RpbmcgUkZDcyBpbiBvcmRlciB0byBrZWVwIHdoYXQgaXMgYWxyZWFkeSBhIGZhaXJseSBs YXJnZSB1bmRlcnRha2luZyBtYW5hZ2VhYmxlLg0KDQpUaGlzIGlzIHN0aWxsIHZlcnkgbXVjaCBh IHdvcmsgaW4gcHJvZ3Jlc3MuIFdlJ3JlIGVzcGVjaWFsbHkgaW50ZXJlc3RlZCBpbiBmZWVkYmFj ayBvbiB0aGUgc3RydWN0dXJlIG9mIHRoZSBkb2N1bWVudCAoZG8gdGhlIGNhdGVnb3JpZXMgbWFr ZSBzZW5zZSkgYW5kIHdoZXRoZXIgd2UgYXJlIG1pc3NpbmcgbWFqb3IgaXRlbXMgdG8gaW5jbHVk ZSBpbiB0aGUgZ2FwIGFuYWx5c2lzLCBhY3Jvc3MgY29udHJvbCBwbGFuZSwgYXBwbGljYXRpb25z LCBvciBPQU0uDQoNClRoYW5rcywNCg0KV2VzIEdlb3JnZSwgb24gYmVoYWxmIG9mIHRoZSBvdGhl ciBhdXRob3JzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQpTZW50OiBN b25kYXksIEp1bHkgMDEsIDIwMTMgOToyMyBBTQ0KVG86IFJvbiBCb25pY2E7IFJhaml2IFBhcG5l amE7IERocnV2IERob2R5OyBHZW9yZ2UsIFdlczsgQ2FybG9zIFBpZ25hdGFybzsgS2FtcmFuIFJh emE7IFJvbmFsZCBCb25pY2E7IFZpc2h3YXMgTWFucmFsOyBSYWppdiBBc2F0aQ0KU3ViamVjdDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1tcGxzLWlwdjYtb25seS1nYXAtMDAu dHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1wbHMtaXB2Ni1vbmx5LWdhcC0w MC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgV2VzbGV5IEdlb3JnZSBh bmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZTogICAgICAgIGRy YWZ0LW1wbHMtaXB2Ni1vbmx5LWdhcA0KUmV2aXNpb246ICAgICAgICAwMA0KVGl0bGU6ICAgICAg ICAgICBHYXAgQW5hbHlzaXMgZm9yIE9wZXJhdGluZyBJUHY2LW9ubHkgTVBMUyBOZXR3b3Jrcw0K Q3JlYXRpb24gZGF0ZTogICAyMDEzLTA3LTAxDQpHcm91cDogICAgICAgICAgIEluZGl2aWR1YWwg U3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAyMA0KVVJMOiAgICAgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tcGxzLWlwdjYtb25seS1nYXAtMDAu dHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtbXBscy1pcHY2LW9ubHktZ2FwDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LW1wbHMtaXB2Ni1vbmx5LWdhcC0wMA0KDQoNCkFic3RyYWN0Og0KICAg VGhpcyBkb2N1bWVudCByZXZpZXdzIHRoZSBNUExTIHByb3RvY29sIHN1aXRlIGluIHRoZSBjb250 ZXh0IG9mIElQdjYNCiAgIGFuZCBpZGVudGlmaWVzIGdhcHMgdGhhdCBtdXN0IGJlIGFkZHJlc3Nl ZCBpbiBvcmRlciB0byBhbGxvdyBNUExTLQ0KICAgcmVsYXRlZCBwcm90b2NvbHMgYW5kIGFwcGxp Y2F0aW9ucyB0byBiZSB1c2VkIHdpdGggSVB2Ni1vbmx5DQogICBuZXR3b3Jrcy4gIFRoaXMgZG9j dW1lbnQgaXMgbm90IGludGVuZGVkIHRvIGhpZ2hsaWdodCBhIHBhcnRpY3VsYXINCiAgIHZlbmRv cidzIGltcGxlbWVudGF0aW9uIChvciBsYWNrIHRoZXJlb2YpIGluIHRoZSBjb250ZXh0IG9mIElQ djYtb25seQ0KICAgTVBMUyBmdW5jdGlvbmFsaXR5LCBidXQgcmF0aGVyIHRvIGZvY3VzIG9uIGdh cHMgaW4gdGhlIHN0YW5kYXJkcw0KICAgZGVmaW5pbmcgdGhlIE1QTFMgc3VpdGUuDQoNCg0KDQoN ClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0 YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3Jt YXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBj b3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBp bnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRv IHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlz c2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVs YXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBp cyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5 IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= From internet-drafts@ietf.org Mon Jul 1 10:40:33 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DE911E8197; Mon, 1 Jul 2013 10:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 bQWw7KxzDtBv; Mon, 1 Jul 2013 10:40:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9476E11E8160; Mon, 1 Jul 2013 10:40:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l3vpn-virtual-hub-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130701174029.24176.60766.idtracker@ietfa.amsl.com> Date: Mon, 01 Jul 2013 10:40:29 -0700 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 17:40:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 3 Virtual Private Networks Working = Group of the IETF. Title : Virtual Hub-and-Spoke in BGP/MPLS VPNs Author(s) : Huajin Jeng James Uttaro Luay Jalil Bruno Decraene Yakov Rekhter Rahul Aggarwal Filename : draft-ietf-l3vpn-virtual-hub-07.txt Pages : 26 Date : 2013-07-01 Abstract: With BGP/MPLS VPNs, providing any-to-any connectivity among sites of a given Virtual Private Network would require each Provider Edge router that has one or more of these sites connected to it to hold all the routes of that Virtual Private Network. The approach described in this document allows the VPN service provider to reduce the number of Provider Edge routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes. Furthermore, when Provider Edge routers use ingress replication to carry multicast traffic of VPN customers, the approach described in this document may under certain circumstances allow to reduce bandwidth inefficiency associated with ingress replication, and to redistribute the replication load among Provider Edge routers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l3vpn-virtual-hub There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l3vpn-virtual-hub-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l3vpn-virtual-hub-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 1 12:26:49 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4402411E8240; Mon, 1 Jul 2013 12:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 vEXu1OuMed+u; Mon, 1 Jul 2013 12:26:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B34B11E8247; Mon, 1 Jul 2013 12:26:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l3vpn-virtual-hub-08.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130701192631.18423.5250.idtracker@ietfa.amsl.com> Date: Mon, 01 Jul 2013 12:26:31 -0700 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 19:26:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 3 Virtual Private Networks Working = Group of the IETF. Title : Virtual Hub-and-Spoke in BGP/MPLS VPNs Author(s) : Huajin Jeng James Uttaro Luay Jalil Bruno Decraene Yakov Rekhter Rahul Aggarwal Filename : draft-ietf-l3vpn-virtual-hub-08.txt Pages : 26 Date : 2013-07-01 Abstract: With BGP/MPLS VPNs, providing any-to-any connectivity among sites of a given Virtual Private Network would require each Provider Edge router that has one or more of these sites connected to it to hold all the routes of that Virtual Private Network. The approach described in this document allows the VPN service provider to reduce the number of Provider Edge routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes. Furthermore, when Provider Edge routers use ingress replication to carry multicast traffic of VPN customers, the approach described in this document may under certain circumstances allow to reduce bandwidth inefficiency associated with ingress replication, and to redistribute the replication load among Provider Edge routers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l3vpn-virtual-hub There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l3vpn-virtual-hub-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l3vpn-virtual-hub-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From xuxiaohu@huawei.com Mon Jul 1 23:52:40 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3294A11E82F3; Mon, 1 Jul 2013 23:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.728 X-Spam-Level: X-Spam-Status: No, score=-3.728 tagged_above=-999 required=5 tests=[AWL=2.271, 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 Lo9x+hMdgw99; Mon, 1 Jul 2013 23:52:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4D83C11E82F0; Mon, 1 Jul 2013 23:52:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATA79594; Tue, 02 Jul 2013 06:52:18 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 2 Jul 2013 07:52:05 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 2 Jul 2013 07:52:13 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.134]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Tue, 2 Jul 2013 14:52:08 +0800 From: Xuxiaohu To: L3VPN Subject: Why not use L3VPN for data center interconnect?//re: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Topic: Why not use L3VPN for data center interconnect?//re: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Index: Ac5thMS2t8EppEHAQo6a5WxySmdDhQIdhP9gABRMqAAAIYUh4A== Date: Tue, 2 Jul 2013 06:52:07 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CB31D@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CAD74@NKGEML512-MBS.china.huawei.com> <6463_1372684423_51D18087_6463_1266_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D074D1A7D@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <6463_1372684423_51D18087_6463_1266_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D074D1A7D@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 06:52:40 -0000 SGkgYWxsLA0KDQpUaWxsIG5vdywgaXQgc2VlbXMgdGhhdCB0b28gbXVjaCBhdHRlbnRpb24gaGFz IGJlZW4gcGFpZCB0byB0aGUgdXNlIG9mIEwyVlBOIGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5l Y3QuIEFsdGhvdWdoIHRoZXJlIGFyZSBzdGlsbCBhIGZldyBjbHVzdGVyaW5nIGFwcGxpY2F0aW9u cyB3aGljaCByZWx5IG9uIG5vbi1JUCBvciBub24tcm91dGFibGUgSVAgY29tbXVuaWNhdGlvbnMg KGUuZy4sIGhlYXJ0YmVhdCBtZXNzYWdlcyBiZXR3ZWVuIGNsdXN0ZXIgbm9kZXMpLCBtb3JlIGFu ZCBtb3JlIGNsdXN0ZXIgdmVuZG9ycyBhcmUgb2ZmZXJpbmcgY2x1c3RlcmluZyBhcHBsaWNhdGlv bnMgYmFzZWQgb24gTGF5ZXIgMyBpbnRlcmNvbm5lY3Rpb24uIEluIGFkZGl0aW9uLCBnZW9ncmFw aGljYWwgaGlnaC1hdmFpbGFiaWxpdHkgY2x1c3RlcnMgaXMgbm90IGEgbXVzdCBpbiBtYW55IGRh dGEgY2VudGVyIGludGVyY29ubmVjdCBjYXNlcy4NCg0KQXMgTDNWUE4gaGFzIG1hbnkgZGlzdGlu Y3QgYWR2YW50YWdlcyBvdmVyIEwyVlBOIGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3Qgc3Vj aCBhczogc2NhbGluZyBmb3J3YXJkaW5nIHRhYmxlcyBvZiBkYXRhIGNlbnRlciBzd2l0Y2hlcywg cGF0aCBvcHRpbWl6YXRpb24sIHVua25vd24gdW5pY2FzdCBhbmQgQVJQIHN1cHByZXNzaW9uLi4u IHdoeSBub3QgdHJ5IHRvIHVzZSB0aGUgcHJvdmVuIEwzVlBOIHRlY2hub2xvZ3kgZm9yIGRhdGEg Y2VudGVyIGludGVyY29ubmVjdCBpbiB0aGUgc2NlbmFyaW8gd2hlcmUgdGhlIGxpbWl0YXRpb25z IGFzIG1lbnRpb25lZCBhYm92ZSBkb24ndCBleGlzdD8NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1 DQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IHRob21hcy5tb3JpbkBv cmFuZ2UuY29tIFttYWlsdG86dGhvbWFzLm1vcmluQG9yYW5nZS5jb21dDQo+IOWPkemAgeaXtumX tDogMjAxM+W5tDfmnIgx5pelIDIxOjE0DQo+IOaUtuS7tuS6ujogWHV4aWFvaHUNCj4g5oqE6YCB OiBsM3Zwbi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IG1hcnRpbi52aWdvdXJldXhAYWxjYXRlbC1s dWNlbnQuY29tOw0KPiBMM1ZQTg0KPiDkuLvpopg6IFJlOiBSZXF1ZXN0IGEgV0cgYWRvcHRpb24g cG9sbCBmb3IgZHJhZnQteHUtdmlydHVhbC1zdWJuZXQtMTANCj4gDQo+IEhlbGxvIFh1eGlhb2h1 LA0KPiANCj4gQmVmb3JlIGV2ZW50dWFsbHkgc3RhcnRpbmcgYSBkaXNjdXNzaW9uIG9uIHRoZSBh ZG9wdGlvbiBvbiB0aGlzDQo+IGRvY3VtZW50LCB3ZSBjaGFpcnMgd291bGQgbGlrZSB0byBzZWUg bW9yZSBkaXNjdXNzaW9uIGFuZCBoYXZlIHRoZQ0KPiBmZWVkYmFjayBmcm9tIG1vcmUgcmVhZGVy cyAoZHVyaW5nIHRoZSAyIHByZXZpb3VzIG1lZXRpbmdzLCBvbmx5IDUgdG8gMTANCj4gcGVvcGxl IHJhaXNlZCB0aGVpciBoYW5kIHdoZW4gdGhlIHJvb20gd2FzIHBvbGxlZCBvbiBoYXZpbmcgcmVh ZCB0aGUNCj4gZG9jdW1lbnQpLg0KPiANCj4gUmVnYXJkcywNCj4gDQo+IC1UaG9tYXMgYW5kIE1h cnRpbiwNCj4gbDN2cG4gY28tY2hhaXJzDQo+IA0KPiANCj4gMjAxMy0wNy0wMSwgWHV4aWFvaHU6 DQo+ID4gSGkgVGhvbWFzIGFuZCBNYXJ0aW4sDQo+ID4NCj4gPiBJIGhhdmVuJ3QgcmVjZWl2ZWQg YW55IHJlc3BvbnNlIGZyb20gYW55IG9mIHlvdS4gSGVuY2UgSSByZXNlbmQgaXQuDQo+ID4NCj4g PiBCZXN0IHJlZ2FyZHMsDQo+ID4gWGlhb2h1DQo+ID4NCj4gPj4gLS0tLS3pgq7ku7bljp/ku7Yt LS0tLQ0KPiA+PiDlj5Hku7bkuro6IFh1eGlhb2h1DQo+ID4+IOWPkemAgeaXtumXtDogMjAxM+W5 tDbmnIgyMOaXpSAxNTowNw0KPiA+PiDmlLbku7bkuro6ICdsM3Zwbi1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmcnOyAndGhvbWFzLm1vcmluQG9yYW5nZS5jb20nOw0KPiA+PiAnbWFydGluLnZpZ291cmV1 eEBhbGNhdGVsLWx1Y2VudC5jb20nDQo+ID4+IOaKhOmAgTogTDNWUE4NCj4gPj4g5Li76aKYOiBS ZXF1ZXN0IGEgV0cgYWRvcHRpb24gcG9sbCBmb3IgZHJhZnQteHUtdmlydHVhbC1zdWJuZXQtMTAN Cj4gPj4NCj4gPj4gSGkgV0cgY28tY2hhaXJzLA0KPiA+Pg0KPiA+PiBBcyBtZW50aW9uZWQgYmVm b3JlLCB0aGlzIGRyYWZ0DQo+ID4+IChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14 dS12aXJ0dWFsLXN1Ym5ldC0xMCkgZGVzY3JpYmVzIGhvdyB0bw0KPiByZXVzZQ0KPiA+PiB0aGUg cHJvdmVuIEwzVlBOIHRlY2hub2xvZ3kgdG8gcmVhbGl6ZSBzdWJuZXQgZXh0ZW5zaW9uIGZvciBk YXRhIGNlbnRlcg0KPiA+PiBpbnRlcmNvbm5lY3QsIHdpdGggdGhlIGFpZCBvZiBtYW55IGNvbmNy ZXRlIGV4cGVyaW1lbnRzIGFuZCB2ZXJpZmljYXRpb25zLg0KPiA+Pg0KPiA+PiBXZSBjby1hdXRo b3JzIGJlbGlldmUgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGRyYWZ0IHdvdWxk IGJlDQo+IHZhbHVhYmxlDQo+ID4+IGZvciBjbG91ZCBzZXJ2aWNlIHByb3ZpZGVycyB0byBldmFs dWF0ZSB0aGUgZmVhc2liaWxpdHkgb2YgYWRvcHRpbmcgdGhlIHByb3Zlbg0KPiA+PiBMM1ZQTiB0 ZWNobm9sb2d5IGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3Rpb24gKGJ5IHRoZSB3YXksIHNv bWUgcGVvcGxlDQo+ID4+IGhhZCBzaG93biB0aGVpciBpbnRlcmVzdHMgb24gdGhlIHNjaGVtZSBk ZXNjcmliZWQgaW4gdGhpcyBkcmFmdCB3aGVuDQo+IHZpc2l0aW5nDQo+ID4+IG91ciBpbXBsZW1l bnRhdGlvbiBkZW1vIG9mIHRoaXMgc2NoZW1lIGF0IHRoZSBCaXRzLU4tQml0ZXMgZXZlbnQgb2YN Cj4gSUVURjg2KS4NCj4gPj4gSGVuY2Ugd2Ugd291bGQgbGlrZSBjby1jaGFpcnMgdG8gc3RhcnQg YSBXRyBhZG9wdGlvbiBwb2xsIGZvciB0aGlzIGRyYWZ0Lg0KPiA+Pg0KPiA+PiBCZXN0IHJlZ2Fy ZHMsDQo+ID4+IFhpYW9odSAob24gYmVoYWxmIG9mIGFsbCBjby1hdXRob3JzKQ0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gDQo+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0KPiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KPiBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UNCj4gbWVzc2Fn ZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KPiBhIGwnZXhwZWRpdGV1ciBldCBs ZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMNCj4g ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KPiBPcmFuZ2Ug ZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwg ZGVmb3JtZSBvdQ0KPiBmYWxzaWZpZS4gTWVyY2kuDQo+IA0KPiBUaGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZA0KPiBp bmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KPiB0aGV5IHNob3VsZCBu b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4N Cj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcw0KPiBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMuDQo+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9y IG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuDQo+IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmll ZC4NCj4gVGhhbmsgeW91Lg0KDQo= From eosborne@cisco.com Tue Jul 2 05:06:54 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED70A11E849F; Tue, 2 Jul 2013 05:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] 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 cEM7BH8Wg+oD; Tue, 2 Jul 2013 05:06:50 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5295111E849C; Tue, 2 Jul 2013 05:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9110; q=dns/txt; s=iport; t=1372766810; x=1373976410; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LsHutmggzwpADTJsZmdv0PHQKYwWdEgMrqE/rcvfQFw=; b=cwAvqvBmk//Xh+4TGcFoCSlpT/qz+CQxbA5PkV0zjFgdt85h03zV/ul0 zp8Auom4aqBnOdiiwfJSdyhA8/sVSQhGzdAp55JvBb6c66qFL/wN18/3D eCPGC2oGiMTBroW6pXroDwEMl30jOyZLlGfLMiSD6Hq1MBcVYnF9fGaYB I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAP6/0lGtJV2Z/2dsb2JhbABagwkySYMHvEYNcxZ0giMBAQEEAQEBIBE6CwwEAgEGAhEEAQEDAgYZBAMCAgIlCxQBCAgBAQQBDQUIE4d0DI5rmz+ROYEmjHKBETEHBoJLM2cDk3eEe5AcgViBOYFxNw X-IronPort-AV: E=Sophos;i="4.87,980,1363132800"; d="scan'208";a="226900057" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 02 Jul 2013 12:06:49 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r62C6nHc026098 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Jul 2013 12:06:49 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 2 Jul 2013 07:06:49 -0500 From: "Eric Osborne (eosborne)" To: Xuxiaohu , L3VPN Subject: RE: [nvo3] Why not use L3VPN for data center interconnect?//re: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Topic: [nvo3] Why not use L3VPN for data center interconnect?//re: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Index: Ac5thMS2t8EppEHAQo6a5WxySmdDhQIdhP9gABRMqAAAIYUh4AAR3xWA Date: Tue, 2 Jul 2013 12:06:48 +0000 Message-ID: <20ECF67871905846A80F77F8F4A2757210276FCC@xmb-rcd-x09.cisco.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CAD74@NKGEML512-MBS.china.huawei.com> <6463_1372684423_51D18087_6463_1266_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D074D1A7D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CB31D@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CB31D@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.66.70] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 02 Jul 2013 05:37:32 -0700 Cc: "nvo3@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 12:06:55 -0000 SGkgWGlhb2h1LQ0KDQogIExldCBtZSBmaXJzdCBzYXkgdGhhdCBJIGFncmVlIHRoYXQgTDMgaXMg dGhlIHdheSB0aGluZ3Mgc2hvdWxkIGJlIGJ1aWx0LiAgQnV0IEknbSBub3Qgc3VyZSB0aGF0IHlv dXIgZHJhZnQgYWRkcyBtdWNoIHRvIGV4aXN0aW5nIG1ldGhvZHMsIGFuZCBpdCBzZWVtcyB0byBt YWtlIGEgbnVtYmVyIG9mIGFzc3VtcHRpb25zLg0KDQogICAiUEUgcm91dGVycyAoaS5lLiwNCiAg IFBFLTEgYW5kIFBFLTIpIHdoaWNoIGFyZSB1c2VkIGZvciBpbnRlcmNvbm5lY3RpbmcgdGhlc2Ug dHdvIGRhdGENCiAgIGNlbnRlcnMgY3JlYXRlIGhvc3Qgcm91dGVzIGZvciB0aGVpciBsb2NhbCBD RSBob3N0cyByZXNwZWN0aXZlbHkgYW5kDQogICB0aGVuIGFkdmVydGlzZSB0aGVtIHZpYSBMM1ZQ TiBzaWduYWxpbmcuLi4uIEluIGZhY3QsIHN1Y2ggc3VibmV0IGlzIGEgdmlydHVhbCAgICAgIA0K ICAgc3VibmV0IHdoaWNoIGlzIGVtdWxhdGVkIGJ5IHVzaW5nIGhvc3Qgcm91dGVzLiINCg0KDQpT byBpZiBJIGhhdmUgYSAvMjQgSSB3aWxsIGVuZCB1cCB3aXRoICh1cCB0bykgMjUzIGhvc3QgYWRk cmVzc2VzIGluIHRoZSBuZXR3b3JrPw0KDQpIb3cgZG9lcyBhIFBFIGtub3cgd2hpY2ggaG9zdHMg ZXhpc3Q/ICBEb2VzIGl0IHdhaXQgdW50aWwgaXQgc2VlcyBsb2NhbCBBUlAgaW4gb3JkZXIgdG8g ZGV0ZXJtaW5lIHRoYXQgdGhlcmUgaXMgYSB2YWxpZCAvMzI/ICANCg0KV2hhdCBoYXBwZW5zIGlm IEhvc3QgQSB3YW50cyB0byByZWFjaCBIb3N0IEMsIGhvbWVkIG9mZiBvZiBQRS0zLCBidXQgUEUt MyBkb2VzIG5vdCBrbm93IGFib3V0IEhvc3QgQyBiZWNhdXNlIGl0J3MgbmV2ZXIgcGFydGljaXBh dGVkIGluIEFSUD8gIERvIEkgbmVlZCB0byByZWxheSB0aGUgQVJQIGZyb20gUEUtMyB0byB0aGUg b3RoZXIgUEVzIGZvciB0aGUgVlBOPw0KDQpXaGF0IHNjYWxlIGJlbmVmaXRzIGFyZSB0aGVyZSBp ZiBJIGhhdmUgdG8gYWR2ZXJ0aXNlIGFsbCB0aGUgaG9zdCByb3V0ZXMgb24gbXkgbG9jYWwgcG9y dGlvbiBvZiB0aGUgc3VibmV0PyAgU3BlY2lmaWNhbGx5LCBjYW4geW91IGNvbXBhcmUgdGhlIHNj YWxlIGJlbmVmaXRzIG9mIGFkdmVydGlzaW5nIGEgYnVuY2ggb2YgLzMycyB0bywgc2F5LCBFVlBO LCB3aGVyZSBNQUMgYWRkcmVzc2VzIGFyZSBiYXNpY2FsbHkgLzQ4IGhvc3Qgcm91dGVzPw0KDQoN Cg0KSW4gc2VjdGlvbiAzLjYuMToNCg0KLS0tDQp0aGUgaW5ncmVzcyBQRSByb3V0ZXIgd2lsbCBm b3J3YXJkIHRoZSBwYWNrZXQgdG8gdGhlDQogICAgICBSUiBhY2NvcmRpbmcgdG8gb25lIG9mIHRo ZSBWUCByb3V0ZXMgbGVhcm50IGZyb20gdGhlIFJSLCB3aGljaCBpbg0KICAgICAgdHVybiBmb3J3 YXJkcyB0aGUgcGFja2V0IHRvIHRoZSByZWxldmFudCBlZ3Jlc3MgUEUgcm91dGVyDQogICAgICBh Y2NvcmRpbmcgdG8gdGhlIGhvc3Qgcm91dGUgbGVhcm50IGZyb20gdGhhdCBlZ3Jlc3MgUEUgcm91 dGVyLg0KLS0tDQoNClRoaXMgbWFrZXMgbWUgbmVydm91cywgYXMgeW91J3ZlIG5vdyBtYWRlIGEg Um91dGUgUmVmbGVjdG9yIChvZnRlbiBhIGJveCB3aXRoIGxvdHMgb2YgQ1BVIGFuZCBtZW1vcnkg YnV0IG5vdCBuZWNlc3NhcmlseSBtdWNoIGZvcndhcmRpbmcgdGhyb3VnaHB1dCkgaW50byBiYXNp Y2FsbHkgYSBCcm9hZGNhc3QvVW5rbm93biBNdWx0aWNhc3Qgc2VydmVyLiAgDQoNClRoZSB3aG9s ZSBvZiBTZWN0aW9uIDMuNiBmZWVscyBhIGxpdHRsZSBsaWtlIExJU1Agb3IgTkhSUCBvciBzb21l dGhpbmcuICBJZiB0aGlzIGlzIHJlYWxseSB3aGF0IHlvdSdyZSBhZnRlciB5b3UgbWF5IHdhbnQg dG8gbG9vayBhdCBob3cgdGhleSBhcHByb2FjaGVkIHRoaXMgcHJvYmxlbSBhbmQgc2hvdyB3aGF0 J3MgZGlmZmVyZW50IGFib3V0IHlvdXIgc29sdXRpb24uDQoNCg0KDQoNCmVyaWMNCg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG52bzMtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IFh1eGlhb2h1DQo+ IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMDIsIDIwMTMgMjo1MiBBTQ0KPiBUbzogTDNWUE4NCj4gQ2M6 IG52bzNAaWV0Zi5vcmcNCj4gU3ViamVjdDogW252bzNdIFdoeSBub3QgdXNlIEwzVlBOIGZvciBk YXRhIGNlbnRlciBpbnRlcmNvbm5lY3Q/Ly9yZToNCj4gUmVxdWVzdCBhIFdHIGFkb3B0aW9uIHBv bGwgZm9yIGRyYWZ0LXh1LXZpcnR1YWwtc3VibmV0LTEwDQo+IA0KPiBIaSBhbGwsDQo+IA0KPiBU aWxsIG5vdywgaXQgc2VlbXMgdGhhdCB0b28gbXVjaCBhdHRlbnRpb24gaGFzIGJlZW4gcGFpZCB0 byB0aGUgdXNlIG9mDQo+IEwyVlBOIGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3QuIEFsdGhv dWdoIHRoZXJlIGFyZSBzdGlsbCBhIGZldw0KPiBjbHVzdGVyaW5nIGFwcGxpY2F0aW9ucyB3aGlj aCByZWx5IG9uIG5vbi1JUCBvciBub24tcm91dGFibGUgSVANCj4gY29tbXVuaWNhdGlvbnMgKGUu Zy4sIGhlYXJ0YmVhdCBtZXNzYWdlcyBiZXR3ZWVuIGNsdXN0ZXIgbm9kZXMpLCBtb3JlDQo+IGFu ZCBtb3JlIGNsdXN0ZXIgdmVuZG9ycyBhcmUgb2ZmZXJpbmcgY2x1c3RlcmluZyBhcHBsaWNhdGlv bnMgYmFzZWQgb24NCj4gTGF5ZXIgMyBpbnRlcmNvbm5lY3Rpb24uIEluIGFkZGl0aW9uLCBnZW9n cmFwaGljYWwgaGlnaC1hdmFpbGFiaWxpdHkNCj4gY2x1c3RlcnMgaXMgbm90IGEgbXVzdCBpbiBt YW55IGRhdGEgY2VudGVyIGludGVyY29ubmVjdCBjYXNlcy4NCj4gDQo+IEFzIEwzVlBOIGhhcyBt YW55IGRpc3RpbmN0IGFkdmFudGFnZXMgb3ZlciBMMlZQTiBmb3IgZGF0YSBjZW50ZXINCj4gaW50 ZXJjb25uZWN0IHN1Y2ggYXM6IHNjYWxpbmcgZm9yd2FyZGluZyB0YWJsZXMgb2YgZGF0YSBjZW50 ZXIgc3dpdGNoZXMsDQo+IHBhdGggb3B0aW1pemF0aW9uLCB1bmtub3duIHVuaWNhc3QgYW5kIEFS UCBzdXBwcmVzc2lvbi4uLiB3aHkgbm90IHRyeSB0bw0KPiB1c2UgdGhlIHByb3ZlbiBMM1ZQTiB0 ZWNobm9sb2d5IGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3QgaW4gdGhlDQo+IHNjZW5hcmlv IHdoZXJlIHRoZSBsaW1pdGF0aW9ucyBhcyBtZW50aW9uZWQgYWJvdmUgZG9uJ3QgZXhpc3Q/DQo+ IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IFhpYW9odQ0KPiANCj4gPiAtLS0tLemCruS7tuWOn+S7ti0t LS0tDQo+ID4g5Y+R5Lu25Lq6OiB0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbSBbbWFpbHRvOnRob21h cy5tb3JpbkBvcmFuZ2UuY29tXQ0KPiA+IOWPkemAgeaXtumXtDogMjAxM+W5tDfmnIgx5pelIDIx OjE0DQo+ID4g5pS25Lu25Lq6OiBYdXhpYW9odQ0KPiA+IOaKhOmAgTogbDN2cG4tY2hhaXJzQHRv b2xzLmlldGYub3JnOyBtYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwtDQo+IGx1Y2VudC5jb207DQo+ ID4gTDNWUE4NCj4gPiDkuLvpopg6IFJlOiBSZXF1ZXN0IGEgV0cgYWRvcHRpb24gcG9sbCBmb3Ig ZHJhZnQteHUtdmlydHVhbC1zdWJuZXQtMTANCj4gPg0KPiA+IEhlbGxvIFh1eGlhb2h1LA0KPiA+ DQo+ID4gQmVmb3JlIGV2ZW50dWFsbHkgc3RhcnRpbmcgYSBkaXNjdXNzaW9uIG9uIHRoZSBhZG9w dGlvbiBvbiB0aGlzDQo+ID4gZG9jdW1lbnQsIHdlIGNoYWlycyB3b3VsZCBsaWtlIHRvIHNlZSBt b3JlIGRpc2N1c3Npb24gYW5kIGhhdmUgdGhlDQo+ID4gZmVlZGJhY2sgZnJvbSBtb3JlIHJlYWRl cnMgKGR1cmluZyB0aGUgMiBwcmV2aW91cyBtZWV0aW5ncywgb25seSA1IHRvDQo+IDEwDQo+ID4g cGVvcGxlIHJhaXNlZCB0aGVpciBoYW5kIHdoZW4gdGhlIHJvb20gd2FzIHBvbGxlZCBvbiBoYXZp bmcgcmVhZCB0aGUNCj4gPiBkb2N1bWVudCkuDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+DQo+ID4g LVRob21hcyBhbmQgTWFydGluLA0KPiA+IGwzdnBuIGNvLWNoYWlycw0KPiA+DQo+ID4NCj4gPiAy MDEzLTA3LTAxLCBYdXhpYW9odToNCj4gPiA+IEhpIFRob21hcyBhbmQgTWFydGluLA0KPiA+ID4N Cj4gPiA+IEkgaGF2ZW4ndCByZWNlaXZlZCBhbnkgcmVzcG9uc2UgZnJvbSBhbnkgb2YgeW91LiBI ZW5jZSBJIHJlc2VuZCBpdC4NCj4gPiA+DQo+ID4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gPiBYaWFv aHUNCj4gPiA+DQo+ID4gPj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiA+ID4+IOWPkeS7tuS6 ujogWHV4aWFvaHUNCj4gPiA+PiDlj5HpgIHml7bpl7Q6IDIwMTPlubQ25pyIMjDml6UgMTU6MDcN Cj4gPiA+PiDmlLbku7bkuro6ICdsM3Zwbi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcnOyAndGhvbWFz Lm1vcmluQG9yYW5nZS5jb20nOw0KPiA+ID4+ICdtYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwtbHVj ZW50LmNvbScNCj4gPiA+PiDmioTpgIE6IEwzVlBODQo+ID4gPj4g5Li76aKYOiBSZXF1ZXN0IGEg V0cgYWRvcHRpb24gcG9sbCBmb3IgZHJhZnQteHUtdmlydHVhbC1zdWJuZXQtMTANCj4gPiA+Pg0K PiA+ID4+IEhpIFdHIGNvLWNoYWlycywNCj4gPiA+Pg0KPiA+ID4+IEFzIG1lbnRpb25lZCBiZWZv cmUsIHRoaXMgZHJhZnQNCj4gPiA+PiAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt eHUtdmlydHVhbC1zdWJuZXQtMTApIGRlc2NyaWJlcw0KPiBob3cgdG8NCj4gPiByZXVzZQ0KPiA+ ID4+IHRoZSBwcm92ZW4gTDNWUE4gdGVjaG5vbG9neSB0byByZWFsaXplIHN1Ym5ldCBleHRlbnNp b24gZm9yIGRhdGENCj4gY2VudGVyDQo+ID4gPj4gaW50ZXJjb25uZWN0LCB3aXRoIHRoZSBhaWQg b2YgbWFueSBjb25jcmV0ZSBleHBlcmltZW50cyBhbmQNCj4gdmVyaWZpY2F0aW9ucy4NCj4gPiA+ Pg0KPiA+ID4+IFdlIGNvLWF1dGhvcnMgYmVsaWV2ZSB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgZHJhZnQgd291bGQNCj4gYmUNCj4gPiB2YWx1YWJsZQ0KPiA+ID4+IGZvciBjbG91 ZCBzZXJ2aWNlIHByb3ZpZGVycyB0byBldmFsdWF0ZSB0aGUgZmVhc2liaWxpdHkgb2YgYWRvcHRp bmcNCj4gdGhlIHByb3Zlbg0KPiA+ID4+IEwzVlBOIHRlY2hub2xvZ3kgZm9yIGRhdGEgY2VudGVy IGludGVyY29ubmVjdGlvbiAoYnkgdGhlIHdheSwgc29tZQ0KPiBwZW9wbGUNCj4gPiA+PiBoYWQg c2hvd24gdGhlaXIgaW50ZXJlc3RzIG9uIHRoZSBzY2hlbWUgZGVzY3JpYmVkIGluIHRoaXMgZHJh ZnQNCj4gd2hlbg0KPiA+IHZpc2l0aW5nDQo+ID4gPj4gb3VyIGltcGxlbWVudGF0aW9uIGRlbW8g b2YgdGhpcyBzY2hlbWUgYXQgdGhlIEJpdHMtTi1CaXRlcyBldmVudCBvZg0KPiA+IElFVEY4Niku DQo+ID4gPj4gSGVuY2Ugd2Ugd291bGQgbGlrZSBjby1jaGFpcnMgdG8gc3RhcnQgYSBXRyBhZG9w dGlvbiBwb2xsIGZvciB0aGlzDQo+IGRyYWZ0Lg0KPiA+ID4+DQo+ID4gPj4gQmVzdCByZWdhcmRz LA0KPiA+ID4+IFhpYW9odSAob24gYmVoYWxmIG9mIGFsbCBjby1hdXRob3JzKQ0KPiA+DQo+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+DQo+ID4gQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zDQo+ID4gY29uZmlkZW50aWVsbGVzIG91 IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCj4gPiBwYXMgZXRyZSBkaWZmdXNlcywg ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6DQo+IHJl Y3UgY2UNCj4gPiBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQo+ID4g YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzDQo+IG1lc3NhZ2VzDQo+ID4gZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLA0KPiA+IE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNp IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLA0KPiBkZWZvcm1lIG91DQo+ID4gZmFsc2lmaWUuIE1l cmNpLg0KPiA+DQo+ID4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG9yDQo+IHByaXZpbGVnZWQNCj4gPiBpbmZvcm1hdGlvbiB0aGF0IG1h eSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KPiA+IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPiA+IElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh bmQNCj4gZGVsZXRlIHRoaXMNCj4gPiBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+ID4g QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlDQo+IGJlZW4NCj4gPiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu DQo+ID4gVGhhbmsgeW91Lg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gbnZvMyBtYWlsaW5nIGxpc3QNCj4gbnZvM0BpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMNCg== From lufang@cisco.com Tue Jul 2 07:44:43 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6992A21F9C8C; Tue, 2 Jul 2013 07:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.457 X-Spam-Level: X-Spam-Status: No, score=-5.457 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] 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 nn2Pvpx0R8kI; Tue, 2 Jul 2013 07:44:38 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 73FAD21F9A05; Tue, 2 Jul 2013 07:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6434; q=dns/txt; s=iport; t=1372776268; x=1373985868; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=HvDQaoyRd4L2wRl4AvICXP87stccYa5hfKSzWprIXYw=; b=Vp6ZD9IW8e5Gzm+y/Kh+pHTtbIdx1I9Uch8t1K6vIHQ2oWhkmnfbGQiJ TEJ8WxHjDFXJ1H3yCYMUWV1quJi+l3GPEox+hIsOeIYeDBE7rgnoMiO1u WZuceEmaLD2+x58PbNhJ4jSTLPFTbABYzcE7lNHxT6NpM3TLtZJjEHvr6 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAKDl0lGtJV2Y/2dsb2JhbABagwkySYMHvEYNdBZ0giMBAQEDATRFBQcGAQYCEQMBAgUGGQQFBDAUCQgCBAENBQiIAQYMjyKbOQiRN4EijHaBDwIWGwcGgkc3ZwOYcpAcgViBOYFxNw X-IronPort-AV: E=Sophos;i="4.87,980,1363132800"; d="scan'208";a="229763109" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 02 Jul 2013 14:44:27 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r62EiRnd031805 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Jul 2013 14:44:27 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.100]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Tue, 2 Jul 2013 09:44:26 -0500 From: "Luyuan Fang (lufang)" To: Xuxiaohu , L3VPN Subject: Re: Why not use L3VPN for data center interconnect? (was //re: Request a WG adoption poll for draft-xu-virtual-subnet-10) Thread-Topic: Why not use L3VPN for data center interconnect? (was //re: Request a WG adoption poll for draft-xu-virtual-subnet-10) Thread-Index: AQHOdzKmbHVswEhesE6gJNHDWf6d9Q== Date: Tue, 2 Jul 2013 14:44:26 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD9310438A42@xmb-rcd-x03.cisco.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CB31D@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.21.115.117] Content-Type: text/plain; charset="gb2312" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "nvo3@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 14:44:43 -0000 DQo+IHdoeSBub3QgdHJ5IHRvIHVzZSB0aGUgcHJvdmVuIEwzVlBOIHRlY2hub2xvZ3kgZm9yIGRh dGEgY2VudGVyDQo+aW50ZXJjb25uZWN0Li4uDQoNCldlIHByZXNlbnRlZCBkcmFmdC1mYW5nLWwz dnBuLWRhdGEtY2VudGVyLWludGVyY29ubmVjdCBpbiBPcmxhbmRvLCBJRVRGIDg2Lg0KaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZmFuZy1sM3Zwbi1kYXRhLWNlbnRlci1pbnRlcmNv bm5lY3QtMDENCg0KQ29tbWVudHMgZnJvbSBXR3MgYXJlIHdlbGNvbWUuDQoNClRoYW5rcywNCkx1 eXVhbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBYdXhpYW9odSA8eHV4 aWFvaHVAaHVhd2VpLmNvbT4NCkRhdGU6IFR1ZXNkYXksIEp1bHkgMiwgMjAxMyAyOjUyIEFNDQpU bzogTDNWUE4gPGwzdnBuQGlldGYub3JnPg0KQ2M6ICJudm8zQGlldGYub3JnIiA8bnZvM0BpZXRm Lm9yZz4NClN1YmplY3Q6IFdoeSBub3QgdXNlIEwzVlBOIGZvciBkYXRhIGNlbnRlciBpbnRlcmNv bm5lY3Q/Ly9yZTogUmVxdWVzdCBhDQpXRwlhZG9wdGlvbiBwb2xsIGZvciBkcmFmdC14dS12aXJ0 dWFsLXN1Ym5ldC0xMA0KDQo+SGkgYWxsLA0KPg0KPlRpbGwgbm93LCBpdCBzZWVtcyB0aGF0IHRv byBtdWNoIGF0dGVudGlvbiBoYXMgYmVlbiBwYWlkIHRvIHRoZSB1c2Ugb2YNCj5MMlZQTiBmb3Ig ZGF0YSBjZW50ZXIgaW50ZXJjb25uZWN0LiBBbHRob3VnaCB0aGVyZSBhcmUgc3RpbGwgYSBmZXcN Cj5jbHVzdGVyaW5nIGFwcGxpY2F0aW9ucyB3aGljaCByZWx5IG9uIG5vbi1JUCBvciBub24tcm91 dGFibGUgSVANCj5jb21tdW5pY2F0aW9ucyAoZS5nLiwgaGVhcnRiZWF0IG1lc3NhZ2VzIGJldHdl ZW4gY2x1c3RlciBub2RlcyksIG1vcmUgYW5kDQo+bW9yZSBjbHVzdGVyIHZlbmRvcnMgYXJlIG9m ZmVyaW5nIGNsdXN0ZXJpbmcgYXBwbGljYXRpb25zIGJhc2VkIG9uIExheWVyDQo+MyBpbnRlcmNv bm5lY3Rpb24uIEluIGFkZGl0aW9uLCBnZW9ncmFwaGljYWwgaGlnaC1hdmFpbGFiaWxpdHkgY2x1 c3RlcnMNCj5pcyBub3QgYSBtdXN0IGluIG1hbnkgZGF0YSBjZW50ZXIgaW50ZXJjb25uZWN0IGNh c2VzLg0KPg0KPkFzIEwzVlBOIGhhcyBtYW55IGRpc3RpbmN0IGFkdmFudGFnZXMgb3ZlciBMMlZQ TiBmb3IgZGF0YSBjZW50ZXINCj5pbnRlcmNvbm5lY3Qgc3VjaCBhczogc2NhbGluZyBmb3J3YXJk aW5nIHRhYmxlcyBvZiBkYXRhIGNlbnRlciBzd2l0Y2hlcywNCj5wYXRoIG9wdGltaXphdGlvbiwg dW5rbm93biB1bmljYXN0IGFuZCBBUlAgc3VwcHJlc3Npb24uLi4gd2h5IG5vdCB0cnkgdG8NCj51 c2UgdGhlIHByb3ZlbiBMM1ZQTiB0ZWNobm9sb2d5IGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5l Y3QgaW4gdGhlDQo+c2NlbmFyaW8gd2hlcmUgdGhlIGxpbWl0YXRpb25zIGFzIG1lbnRpb25lZCBh Ym92ZSBkb24ndCBleGlzdD8NCj4NCj5CZXN0IHJlZ2FyZHMsDQo+WGlhb2h1DQo+DQo+PiAtLS0t LdPKvP7Urbz+LS0tLS0NCj4+ILeivP7IyzogdGhvbWFzLm1vcmluQG9yYW5nZS5jb20gW21haWx0 bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbV0NCj4+ILeiy83KsbzkOiAyMDEzxOo31MIxyNUgMjE6 MTQNCj4+IMrVvP7IyzogWHV4aWFvaHUNCj4+ILOty806IGwzdnBuLWNoYWlyc0B0b29scy5pZXRm Lm9yZzsgbWFydGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2VudC5jb207DQo+PiBMM1ZQTg0KPj4g 1vfM4jogUmU6IFJlcXVlc3QgYSBXRyBhZG9wdGlvbiBwb2xsIGZvciBkcmFmdC14dS12aXJ0dWFs LXN1Ym5ldC0xMA0KPj4gDQo+PiBIZWxsbyBYdXhpYW9odSwNCj4+IA0KPj4gQmVmb3JlIGV2ZW50 dWFsbHkgc3RhcnRpbmcgYSBkaXNjdXNzaW9uIG9uIHRoZSBhZG9wdGlvbiBvbiB0aGlzDQo+PiBk b2N1bWVudCwgd2UgY2hhaXJzIHdvdWxkIGxpa2UgdG8gc2VlIG1vcmUgZGlzY3Vzc2lvbiBhbmQg aGF2ZSB0aGUNCj4+IGZlZWRiYWNrIGZyb20gbW9yZSByZWFkZXJzIChkdXJpbmcgdGhlIDIgcHJl dmlvdXMgbWVldGluZ3MsIG9ubHkgNSB0byAxMA0KPj4gcGVvcGxlIHJhaXNlZCB0aGVpciBoYW5k IHdoZW4gdGhlIHJvb20gd2FzIHBvbGxlZCBvbiBoYXZpbmcgcmVhZCB0aGUNCj4+IGRvY3VtZW50 KS4NCj4+IA0KPj4gUmVnYXJkcywNCj4+IA0KPj4gLVRob21hcyBhbmQgTWFydGluLA0KPj4gbDN2 cG4gY28tY2hhaXJzDQo+PiANCj4+IA0KPj4gMjAxMy0wNy0wMSwgWHV4aWFvaHU6DQo+PiA+IEhp IFRob21hcyBhbmQgTWFydGluLA0KPj4gPg0KPj4gPiBJIGhhdmVuJ3QgcmVjZWl2ZWQgYW55IHJl c3BvbnNlIGZyb20gYW55IG9mIHlvdS4gSGVuY2UgSSByZXNlbmQgaXQuDQo+PiA+DQo+PiA+IEJl c3QgcmVnYXJkcywNCj4+ID4gWGlhb2h1DQo+PiA+DQo+PiA+PiAtLS0tLdPKvP7Urbz+LS0tLS0N Cj4+ID4+ILeivP7IyzogWHV4aWFvaHUNCj4+ID4+ILeiy83KsbzkOiAyMDEzxOo21MIyMMjVIDE1 OjA3DQo+PiA+PiDK1bz+yMs6ICdsM3Zwbi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcnOyAndGhvbWFz Lm1vcmluQG9yYW5nZS5jb20nOw0KPj4gPj4gJ21hcnRpbi52aWdvdXJldXhAYWxjYXRlbC1sdWNl bnQuY29tJw0KPj4gPj4gs63LzTogTDNWUE4NCj4+ID4+INb3zOI6IFJlcXVlc3QgYSBXRyBhZG9w dGlvbiBwb2xsIGZvciBkcmFmdC14dS12aXJ0dWFsLXN1Ym5ldC0xMA0KPj4gPj4NCj4+ID4+IEhp IFdHIGNvLWNoYWlycywNCj4+ID4+DQo+PiA+PiBBcyBtZW50aW9uZWQgYmVmb3JlLCB0aGlzIGRy YWZ0DQo+PiA+PiAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtdmlydHVhbC1z dWJuZXQtMTApIGRlc2NyaWJlcw0KPj5ob3cgdG8NCj4+IHJldXNlDQo+PiA+PiB0aGUgcHJvdmVu IEwzVlBOIHRlY2hub2xvZ3kgdG8gcmVhbGl6ZSBzdWJuZXQgZXh0ZW5zaW9uIGZvciBkYXRhDQo+ PmNlbnRlcg0KPj4gPj4gaW50ZXJjb25uZWN0LCB3aXRoIHRoZSBhaWQgb2YgbWFueSBjb25jcmV0 ZSBleHBlcmltZW50cyBhbmQNCj4+dmVyaWZpY2F0aW9ucy4NCj4+ID4+DQo+PiA+PiBXZSBjby1h dXRob3JzIGJlbGlldmUgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGRyYWZ0IHdv dWxkDQo+PmJlDQo+PiB2YWx1YWJsZQ0KPj4gPj4gZm9yIGNsb3VkIHNlcnZpY2UgcHJvdmlkZXJz IHRvIGV2YWx1YXRlIHRoZSBmZWFzaWJpbGl0eSBvZiBhZG9wdGluZw0KPj50aGUgcHJvdmVuDQo+ PiA+PiBMM1ZQTiB0ZWNobm9sb2d5IGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3Rpb24gKGJ5 IHRoZSB3YXksIHNvbWUNCj4+cGVvcGxlDQo+PiA+PiBoYWQgc2hvd24gdGhlaXIgaW50ZXJlc3Rz IG9uIHRoZSBzY2hlbWUgZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQgd2hlbg0KPj4gdmlzaXRpbmcN Cj4+ID4+IG91ciBpbXBsZW1lbnRhdGlvbiBkZW1vIG9mIHRoaXMgc2NoZW1lIGF0IHRoZSBCaXRz LU4tQml0ZXMgZXZlbnQgb2YNCj4+IElFVEY4NikuDQo+PiA+PiBIZW5jZSB3ZSB3b3VsZCBsaWtl IGNvLWNoYWlycyB0byBzdGFydCBhIFdHIGFkb3B0aW9uIHBvbGwgZm9yIHRoaXMNCj4+ZHJhZnQu DQo+PiA+Pg0KPj4gPj4gQmVzdCByZWdhcmRzLA0KPj4gPj4gWGlhb2h1IChvbiBiZWhhbGYgb2Yg YWxsIGNvLWF1dGhvcnMpDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gDQo+PiBDZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMN Cj4+IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQo+ PiBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlv bi4gU2kgdm91cyBhdmV6DQo+PnJlY3UgY2UNCj4+IG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxs ZXogbGUgc2lnbmFsZXINCj4+IGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcw0KPj4gZWxlY3Ryb25pcXVlcyBldGFu dCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KPj4gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVz cG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUNCj4+b3UNCj4+ IGZhbHNpZmllLiBNZXJjaS4NCj4+IA0KPj4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQNCj4+IGluZm9ybWF0aW9u IHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQo+PiB0aGV5IHNob3VsZCBub3QgYmUgZGlz dHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4+IElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQNCj4+ZGVsZXRlIHRoaXMNCj4+IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4N Cj4+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1l c3NhZ2VzIHRoYXQgaGF2ZQ0KPj5iZWVuDQo+PiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp ZWQuDQo+PiBUaGFuayB5b3UuDQo+DQoNCg== From rajiva@cisco.com Tue Jul 2 07:57:43 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3C921F9DC2; Tue, 2 Jul 2013 07:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] 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 bH4ubgZVt0Oh; Tue, 2 Jul 2013 07:57:38 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1280321F9DE4; Tue, 2 Jul 2013 07:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10794; q=dns/txt; s=iport; t=1372777056; x=1373986656; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Wp1gshXZGuPph+f+hIBeyzZV4rRVlr9kGB9Wz3n90Tk=; b=LX6fmL9GgZc8FoM4s/yD509vgx367gywpPgWo2HgQVM0Q04XHVOLJpA2 EHAx8G/6Us3ekD+2yoSAysGwqgWAs6R2wo0vsCVH71ok6yTYhG3kULjuz bq2szbQHqKGiAwesgjGojehzXKw6SEYu2KSolyOF7kV3kF5lcyUov36HQ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFABnq0lGtJXG+/2dsb2JhbABagwkySYMHvEYNdBZ0giMBAQEDAQEBASAROgsFBwQCAQYCEQQBAQMCBhkEAwICAiULFAEICAIEAQ0FCBOHbgYMjyKbP5E4gSaMcoERMQcGgkszZwOTd4R7kByBWIE5gXE3 X-IronPort-AV: E=Sophos;i="4.87,980,1363132800"; d="scan'208";a="229951038" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 02 Jul 2013 14:57:10 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r62EvAWo003935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Jul 2013 14:57:10 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.251]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 2 Jul 2013 09:57:09 -0500 From: "Rajiv Asati (rajiva)" To: "Eric Osborne (eosborne)" , Xuxiaohu , L3VPN Subject: RE: [nvo3] Why not use L3VPN for data center interconnect?//re: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Topic: [nvo3] Why not use L3VPN for data center interconnect?//re: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Index: AQHOdyD0POmhTAULWE+RkaspEKqEdJlReC8w Date: Tue, 2 Jul 2013 14:57:09 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CAD74@NKGEML512-MBS.china.huawei.com> <6463_1372684423_51D18087_6463_1266_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D074D1A7D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CB31D@NKGEML512-MBS.china.huawei.com> <20ECF67871905846A80F77F8F4A2757210276FCC@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A2757210276FCC@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.250.27] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "nvo3@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 14:57:43 -0000 DQoNCj4gVGhlIHdob2xlIG9mIFNlY3Rpb24gMy42IGZlZWxzIGEgbGl0dGxlIGxpa2UgTElTUCBv ciBOSFJQIG9yIHNvbWV0aGluZy4gIElmIHRoaXMNCg0KVmVyeSBnb29kIGFuYWxvZ3kuIE5IUlAg YmFzZWQgc29sdXRpb24gZS5nLiBETVZQTiwgd2hpY2ggaXMgY29tbW9ubHkgdXNlZCBieSBlbnRl cnByaXNlcyB0byBidWlsZCBzaXRlLXRvLXNpdGUgQ0UtYmFzZWQgb3ZlcmxheSAod2l0aCBvciB3 aXRob3V0IEwzVlBOIGluc2lkZSB0aGUgZW50ZXJwcmlzZSBuZXR3b3JrKSwgZml0cyB0aGUgYmls bCBoZXJlIChiZXlvbmQganVzdCBEQ0ksIHN0cmljdGx5IHNwZWFraW5nKSB2ZXJ5IHdlbGwuDQoN CkhhdmluZyBzYWlkIHRoYXQsIE5IUlAgaXMgbm90IHBlcmNlaXZlZCB0byBzY2FsZSBhcyB3ZWxs IGFzIHRoYXQgb2YgQkdQLg0KDQpDaGVlcnMsDQpSYWppdg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogbDN2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwzdnBu LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5l KQ0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDAyLCAyMDEzIDg6MDcgQU0NCj4gVG86IFh1eGlhb2h1 OyBMM1ZQTg0KPiBDYzogbnZvM0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW252bzNdIFdoeSBu b3QgdXNlIEwzVlBOIGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3Q/Ly9yZToNCj4gUmVxdWVz dCBhIFdHIGFkb3B0aW9uIHBvbGwgZm9yIGRyYWZ0LXh1LXZpcnR1YWwtc3VibmV0LTEwDQo+IA0K PiBIaSBYaWFvaHUtDQo+IA0KPiAgIExldCBtZSBmaXJzdCBzYXkgdGhhdCBJIGFncmVlIHRoYXQg TDMgaXMgdGhlIHdheSB0aGluZ3Mgc2hvdWxkIGJlIGJ1aWx0LiAgQnV0DQo+IEknbSBub3Qgc3Vy ZSB0aGF0IHlvdXIgZHJhZnQgYWRkcyBtdWNoIHRvIGV4aXN0aW5nIG1ldGhvZHMsIGFuZCBpdCBz ZWVtcyB0bw0KPiBtYWtlIGEgbnVtYmVyIG9mIGFzc3VtcHRpb25zLg0KPiANCj4gICAgIlBFIHJv dXRlcnMgKGkuZS4sDQo+ICAgIFBFLTEgYW5kIFBFLTIpIHdoaWNoIGFyZSB1c2VkIGZvciBpbnRl cmNvbm5lY3RpbmcgdGhlc2UgdHdvIGRhdGENCj4gICAgY2VudGVycyBjcmVhdGUgaG9zdCByb3V0 ZXMgZm9yIHRoZWlyIGxvY2FsIENFIGhvc3RzIHJlc3BlY3RpdmVseSBhbmQNCj4gICAgdGhlbiBh ZHZlcnRpc2UgdGhlbSB2aWEgTDNWUE4gc2lnbmFsaW5nLi4uLiBJbiBmYWN0LCBzdWNoIHN1Ym5l dCBpcyBhIHZpcnR1YWwNCj4gICAgc3VibmV0IHdoaWNoIGlzIGVtdWxhdGVkIGJ5IHVzaW5nIGhv c3Qgcm91dGVzLiINCj4gDQo+IA0KPiBTbyBpZiBJIGhhdmUgYSAvMjQgSSB3aWxsIGVuZCB1cCB3 aXRoICh1cCB0bykgMjUzIGhvc3QgYWRkcmVzc2VzIGluIHRoZQ0KPiBuZXR3b3JrPw0KPiANCj4g SG93IGRvZXMgYSBQRSBrbm93IHdoaWNoIGhvc3RzIGV4aXN0PyAgRG9lcyBpdCB3YWl0IHVudGls IGl0IHNlZXMgbG9jYWwgQVJQDQo+IGluIG9yZGVyIHRvIGRldGVybWluZSB0aGF0IHRoZXJlIGlz IGEgdmFsaWQgLzMyPw0KPiANCj4gV2hhdCBoYXBwZW5zIGlmIEhvc3QgQSB3YW50cyB0byByZWFj aCBIb3N0IEMsIGhvbWVkIG9mZiBvZiBQRS0zLCBidXQgUEUtMw0KPiBkb2VzIG5vdCBrbm93IGFi b3V0IEhvc3QgQyBiZWNhdXNlIGl0J3MgbmV2ZXIgcGFydGljaXBhdGVkIGluIEFSUD8gIERvIEkN Cj4gbmVlZCB0byByZWxheSB0aGUgQVJQIGZyb20gUEUtMyB0byB0aGUgb3RoZXIgUEVzIGZvciB0 aGUgVlBOPw0KPiANCj4gV2hhdCBzY2FsZSBiZW5lZml0cyBhcmUgdGhlcmUgaWYgSSBoYXZlIHRv IGFkdmVydGlzZSBhbGwgdGhlIGhvc3Qgcm91dGVzIG9uIG15DQo+IGxvY2FsIHBvcnRpb24gb2Yg dGhlIHN1Ym5ldD8gIFNwZWNpZmljYWxseSwgY2FuIHlvdSBjb21wYXJlIHRoZSBzY2FsZQ0KPiBi ZW5lZml0cyBvZiBhZHZlcnRpc2luZyBhIGJ1bmNoIG9mIC8zMnMgdG8sIHNheSwgRVZQTiwgd2hl cmUgTUFDIGFkZHJlc3Nlcw0KPiBhcmUgYmFzaWNhbGx5IC80OCBob3N0IHJvdXRlcz8NCj4gDQo+ IA0KPiANCj4gSW4gc2VjdGlvbiAzLjYuMToNCj4gDQo+IC0tLQ0KPiB0aGUgaW5ncmVzcyBQRSBy b3V0ZXIgd2lsbCBmb3J3YXJkIHRoZSBwYWNrZXQgdG8gdGhlDQo+ICAgICAgIFJSIGFjY29yZGlu ZyB0byBvbmUgb2YgdGhlIFZQIHJvdXRlcyBsZWFybnQgZnJvbSB0aGUgUlIsIHdoaWNoIGluDQo+ ICAgICAgIHR1cm4gZm9yd2FyZHMgdGhlIHBhY2tldCB0byB0aGUgcmVsZXZhbnQgZWdyZXNzIFBF IHJvdXRlcg0KPiAgICAgICBhY2NvcmRpbmcgdG8gdGhlIGhvc3Qgcm91dGUgbGVhcm50IGZyb20g dGhhdCBlZ3Jlc3MgUEUgcm91dGVyLg0KPiAtLS0NCj4gDQo+IFRoaXMgbWFrZXMgbWUgbmVydm91 cywgYXMgeW91J3ZlIG5vdyBtYWRlIGEgUm91dGUgUmVmbGVjdG9yIChvZnRlbiBhIGJveA0KPiB3 aXRoIGxvdHMgb2YgQ1BVIGFuZCBtZW1vcnkgYnV0IG5vdCBuZWNlc3NhcmlseSBtdWNoIGZvcndh cmRpbmcNCj4gdGhyb3VnaHB1dCkgaW50byBiYXNpY2FsbHkgYSBCcm9hZGNhc3QvVW5rbm93biBN dWx0aWNhc3Qgc2VydmVyLg0KPiANCj4gVGhlIHdob2xlIG9mIFNlY3Rpb24gMy42IGZlZWxzIGEg bGl0dGxlIGxpa2UgTElTUCBvciBOSFJQIG9yIHNvbWV0aGluZy4gIElmIHRoaXMNCj4gaXMgcmVh bGx5IHdoYXQgeW91J3JlIGFmdGVyIHlvdSBtYXkgd2FudCB0byBsb29rIGF0IGhvdyB0aGV5IGFw cHJvYWNoZWQgdGhpcw0KPiBwcm9ibGVtIGFuZCBzaG93IHdoYXQncyBkaWZmZXJlbnQgYWJvdXQg eW91ciBzb2x1dGlvbi4NCj4gDQo+IA0KPiANCj4gDQo+IGVyaWMNCj4gDQo+IA0KPiA+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogbnZvMy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gPiBPZiBYdXhpYW9odQ0K PiA+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMDIsIDIwMTMgMjo1MiBBTQ0KPiA+IFRvOiBMM1ZQTg0K PiA+IENjOiBudm8zQGlldGYub3JnDQo+ID4gU3ViamVjdDogW252bzNdIFdoeSBub3QgdXNlIEwz VlBOIGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3Q/Ly9yZToNCj4gPiBSZXF1ZXN0IGEgV0cg YWRvcHRpb24gcG9sbCBmb3IgZHJhZnQteHUtdmlydHVhbC1zdWJuZXQtMTANCj4gPg0KPiA+IEhp IGFsbCwNCj4gPg0KPiA+IFRpbGwgbm93LCBpdCBzZWVtcyB0aGF0IHRvbyBtdWNoIGF0dGVudGlv biBoYXMgYmVlbiBwYWlkIHRvIHRoZSB1c2Ugb2YNCj4gPiBMMlZQTiBmb3IgZGF0YSBjZW50ZXIg aW50ZXJjb25uZWN0LiBBbHRob3VnaCB0aGVyZSBhcmUgc3RpbGwgYSBmZXcNCj4gPiBjbHVzdGVy aW5nIGFwcGxpY2F0aW9ucyB3aGljaCByZWx5IG9uIG5vbi1JUCBvciBub24tcm91dGFibGUgSVAN Cj4gPiBjb21tdW5pY2F0aW9ucyAoZS5nLiwgaGVhcnRiZWF0IG1lc3NhZ2VzIGJldHdlZW4gY2x1 c3RlciBub2RlcyksIG1vcmUNCj4gPiBhbmQgbW9yZSBjbHVzdGVyIHZlbmRvcnMgYXJlIG9mZmVy aW5nIGNsdXN0ZXJpbmcgYXBwbGljYXRpb25zIGJhc2VkIG9uDQo+ID4gTGF5ZXIgMyBpbnRlcmNv bm5lY3Rpb24uIEluIGFkZGl0aW9uLCBnZW9ncmFwaGljYWwgaGlnaC1hdmFpbGFiaWxpdHkNCj4g PiBjbHVzdGVycyBpcyBub3QgYSBtdXN0IGluIG1hbnkgZGF0YSBjZW50ZXIgaW50ZXJjb25uZWN0 IGNhc2VzLg0KPiA+DQo+ID4gQXMgTDNWUE4gaGFzIG1hbnkgZGlzdGluY3QgYWR2YW50YWdlcyBv dmVyIEwyVlBOIGZvciBkYXRhIGNlbnRlcg0KPiA+IGludGVyY29ubmVjdCBzdWNoIGFzOiBzY2Fs aW5nIGZvcndhcmRpbmcgdGFibGVzIG9mIGRhdGEgY2VudGVyDQo+ID4gc3dpdGNoZXMsIHBhdGgg b3B0aW1pemF0aW9uLCB1bmtub3duIHVuaWNhc3QgYW5kIEFSUCBzdXBwcmVzc2lvbi4uLg0KPiA+ IHdoeSBub3QgdHJ5IHRvIHVzZSB0aGUgcHJvdmVuIEwzVlBOIHRlY2hub2xvZ3kgZm9yIGRhdGEg Y2VudGVyDQo+ID4gaW50ZXJjb25uZWN0IGluIHRoZSBzY2VuYXJpbyB3aGVyZSB0aGUgbGltaXRh dGlvbnMgYXMgbWVudGlvbmVkIGFib3ZlDQo+IGRvbid0IGV4aXN0Pw0KPiA+DQo+ID4gQmVzdCBy ZWdhcmRzLA0KPiA+IFhpYW9odQ0KPiA+DQo+ID4gPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ ID4gPiDlj5Hku7bkuro6IHRob21hcy5tb3JpbkBvcmFuZ2UuY29tIFttYWlsdG86dGhvbWFzLm1v cmluQG9yYW5nZS5jb21dDQo+ID4gPiDlj5HpgIHml7bpl7Q6IDIwMTPlubQ35pyIMeaXpSAyMTox NA0KPiA+ID4g5pS25Lu25Lq6OiBYdXhpYW9odQ0KPiA+ID4g5oqE6YCBOiBsM3Zwbi1jaGFpcnNA dG9vbHMuaWV0Zi5vcmc7IG1hcnRpbi52aWdvdXJldXhAYWxjYXRlbC0NCj4gPiBsdWNlbnQuY29t Ow0KPiA+ID4gTDNWUE4NCj4gPiA+IOS4u+mimDogUmU6IFJlcXVlc3QgYSBXRyBhZG9wdGlvbiBw b2xsIGZvciBkcmFmdC14dS12aXJ0dWFsLXN1Ym5ldC0xMA0KPiA+ID4NCj4gPiA+IEhlbGxvIFh1 eGlhb2h1LA0KPiA+ID4NCj4gPiA+IEJlZm9yZSBldmVudHVhbGx5IHN0YXJ0aW5nIGEgZGlzY3Vz c2lvbiBvbiB0aGUgYWRvcHRpb24gb24gdGhpcw0KPiA+ID4gZG9jdW1lbnQsIHdlIGNoYWlycyB3 b3VsZCBsaWtlIHRvIHNlZSBtb3JlIGRpc2N1c3Npb24gYW5kIGhhdmUgdGhlDQo+ID4gPiBmZWVk YmFjayBmcm9tIG1vcmUgcmVhZGVycyAoZHVyaW5nIHRoZSAyIHByZXZpb3VzIG1lZXRpbmdzLCBv bmx5IDUNCj4gPiA+IHRvDQo+ID4gMTANCj4gPiA+IHBlb3BsZSByYWlzZWQgdGhlaXIgaGFuZCB3 aGVuIHRoZSByb29tIHdhcyBwb2xsZWQgb24gaGF2aW5nIHJlYWQgdGhlDQo+ID4gPiBkb2N1bWVu dCkuDQo+ID4gPg0KPiA+ID4gUmVnYXJkcywNCj4gPiA+DQo+ID4gPiAtVGhvbWFzIGFuZCBNYXJ0 aW4sDQo+ID4gPiBsM3ZwbiBjby1jaGFpcnMNCj4gPiA+DQo+ID4gPg0KPiA+ID4gMjAxMy0wNy0w MSwgWHV4aWFvaHU6DQo+ID4gPiA+IEhpIFRob21hcyBhbmQgTWFydGluLA0KPiA+ID4gPg0KPiA+ ID4gPiBJIGhhdmVuJ3QgcmVjZWl2ZWQgYW55IHJlc3BvbnNlIGZyb20gYW55IG9mIHlvdS4gSGVu Y2UgSSByZXNlbmQgaXQuDQo+ID4gPiA+DQo+ID4gPiA+IEJlc3QgcmVnYXJkcywNCj4gPiA+ID4g WGlhb2h1DQo+ID4gPiA+DQo+ID4gPiA+PiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ID4gPiA+ PiDlj5Hku7bkuro6IFh1eGlhb2h1DQo+ID4gPiA+PiDlj5HpgIHml7bpl7Q6IDIwMTPlubQ25pyI MjDml6UgMTU6MDcNCj4gPiA+ID4+IOaUtuS7tuS6ujogJ2wzdnBuLWNoYWlyc0B0b29scy5pZXRm Lm9yZyc7ICd0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbSc7DQo+ID4gPiA+PiAnbWFydGluLnZpZ291 cmV1eEBhbGNhdGVsLWx1Y2VudC5jb20nDQo+ID4gPiA+PiDmioTpgIE6IEwzVlBODQo+ID4gPiA+ PiDkuLvpopg6IFJlcXVlc3QgYSBXRyBhZG9wdGlvbiBwb2xsIGZvciBkcmFmdC14dS12aXJ0dWFs LXN1Ym5ldC0xMA0KPiA+ID4gPj4NCj4gPiA+ID4+IEhpIFdHIGNvLWNoYWlycywNCj4gPiA+ID4+ DQo+ID4gPiA+PiBBcyBtZW50aW9uZWQgYmVmb3JlLCB0aGlzIGRyYWZ0DQo+ID4gPiA+PiAoaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtdmlydHVhbC1zdWJuZXQtMTApIGRlc2Ny aWJlcw0KPiA+IGhvdyB0bw0KPiA+ID4gcmV1c2UNCj4gPiA+ID4+IHRoZSBwcm92ZW4gTDNWUE4g dGVjaG5vbG9neSB0byByZWFsaXplIHN1Ym5ldCBleHRlbnNpb24gZm9yIGRhdGENCj4gPiBjZW50 ZXINCj4gPiA+ID4+IGludGVyY29ubmVjdCwgd2l0aCB0aGUgYWlkIG9mIG1hbnkgY29uY3JldGUg ZXhwZXJpbWVudHMgYW5kDQo+ID4gdmVyaWZpY2F0aW9ucy4NCj4gPiA+ID4+DQo+ID4gPiA+PiBX ZSBjby1hdXRob3JzIGJlbGlldmUgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGRy YWZ0DQo+ID4gPiA+PiB3b3VsZA0KPiA+IGJlDQo+ID4gPiB2YWx1YWJsZQ0KPiA+ID4gPj4gZm9y IGNsb3VkIHNlcnZpY2UgcHJvdmlkZXJzIHRvIGV2YWx1YXRlIHRoZSBmZWFzaWJpbGl0eSBvZg0K PiA+ID4gPj4gYWRvcHRpbmcNCj4gPiB0aGUgcHJvdmVuDQo+ID4gPiA+PiBMM1ZQTiB0ZWNobm9s b2d5IGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3Rpb24gKGJ5IHRoZSB3YXksDQo+ID4gPiA+ PiBzb21lDQo+ID4gcGVvcGxlDQo+ID4gPiA+PiBoYWQgc2hvd24gdGhlaXIgaW50ZXJlc3RzIG9u IHRoZSBzY2hlbWUgZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQNCj4gPiB3aGVuDQo+ID4gPiB2aXNp dGluZw0KPiA+ID4gPj4gb3VyIGltcGxlbWVudGF0aW9uIGRlbW8gb2YgdGhpcyBzY2hlbWUgYXQg dGhlIEJpdHMtTi1CaXRlcyBldmVudA0KPiA+ID4gPj4gb2YNCj4gPiA+IElFVEY4NikuDQo+ID4g PiA+PiBIZW5jZSB3ZSB3b3VsZCBsaWtlIGNvLWNoYWlycyB0byBzdGFydCBhIFdHIGFkb3B0aW9u IHBvbGwgZm9yDQo+ID4gPiA+PiB0aGlzDQo+ID4gZHJhZnQuDQo+ID4gPiA+Pg0KPiA+ID4gPj4g QmVzdCByZWdhcmRzLA0KPiA+ID4gPj4gWGlhb2h1IChvbiBiZWhhbGYgb2YgYWxsIGNvLWF1dGhv cnMpDQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPg0KPiA+ID4gQ2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z DQo+ID4gPiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9u YyBwYXMgZXRyZQ0KPiA+ID4gZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRv cmlzYXRpb24uIFNpIHZvdXMgYXZleg0KPiA+IHJlY3UgY2UNCj4gPiA+IG1lc3NhZ2UgcGFyIGVy cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUNCj4gPiA+IGRl dHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcw0KPiA+IG1lc3NhZ2VzDQo+ ID4gPiBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5n ZSBkZWNsaW5lIHRvdXRlDQo+ID4gPiByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRl IGFsdGVyZSwNCj4gPiBkZWZvcm1lIG91DQo+ID4gPiBmYWxzaWZpZS4gTWVyY2kuDQo+ID4gPg0K PiA+ID4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIG9yDQo+ID4gcHJpdmlsZWdlZA0KPiA+ID4gaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlDQo+ID4gPiBkaXN0cmlidXRlZCwg dXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPiA+ID4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+ ID4gPiBhbmQNCj4gPiBkZWxldGUgdGhpcw0KPiA+ID4gbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLg0KPiA+ID4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJs ZSBmb3IgbWVzc2FnZXMgdGhhdA0KPiA+ID4gaGF2ZQ0KPiA+IGJlZW4NCj4gPiA+IG1vZGlmaWVk LCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gPiA+IFRoYW5rIHlvdS4NCj4gPg0KPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbnZvMyBtYWls aW5nIGxpc3QNCj4gPiBudm8zQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9udm8zDQo= From xuxiaohu@huawei.com Tue Jul 2 18:11:00 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FADA11E8111; Tue, 2 Jul 2013 18:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.864 X-Spam-Level: X-Spam-Status: No, score=-4.864 tagged_above=-999 required=5 tests=[AWL=1.135, 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 xP87t3te1-io; Tue, 2 Jul 2013 18:10:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B3D0E11E810F; Tue, 2 Jul 2013 18:10:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUP76658; Wed, 03 Jul 2013 01:10:54 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 3 Jul 2013 02:10:43 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 3 Jul 2013 02:10:53 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.134]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.01.0323.007; Wed, 3 Jul 2013 09:10:48 +0800 From: Xuxiaohu To: "Eric Osborne (eosborne)" , L3VPN Subject: re: [nvo3] Why not use L3VPN for data center interconnect?//re: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Topic: [nvo3] Why not use L3VPN for data center interconnect?//re: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Index: Ac5thMS2t8EppEHAQo6a5WxySmdDhQIdhP9gABRMqAAAIYUh4AAR3xWAABrQKhA= Date: Wed, 3 Jul 2013 01:10:47 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CB5BF@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CAD74@NKGEML512-MBS.china.huawei.com> <6463_1372684423_51D18087_6463_1266_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D074D1A7D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CB31D@NKGEML512-MBS.china.huawei.com> <20ECF67871905846A80F77F8F4A2757210276FCC@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A2757210276FCC@xmb-rcd-x09.cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 01:11:00 -0000 SGkgRXJpYywNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBQbGVhc2Ugc2VlIG15IHJlcGx5 IGlubGluZS4NCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogbnZvMy1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnXSDku6PooaggRXJp Yw0KPiBPc2Jvcm5lIChlb3Nib3JuZSkNCj4g5Y+R6YCB5pe26Ze0OiAyMDEz5bm0N+aciDLml6Ug MjA6MDcNCj4g5pS25Lu25Lq6OiBYdXhpYW9odTsgTDNWUE4NCj4g5oqE6YCBOiBudm8zQGlldGYu b3JnDQo+IOS4u+mimDogUmU6IFtudm8zXSBXaHkgbm90IHVzZSBMM1ZQTiBmb3IgZGF0YSBjZW50 ZXIgaW50ZXJjb25uZWN0Py8vcmU6DQo+IFJlcXVlc3QgYSBXRyBhZG9wdGlvbiBwb2xsIGZvciBk cmFmdC14dS12aXJ0dWFsLXN1Ym5ldC0xMA0KPiANCj4gSGkgWGlhb2h1LQ0KPiANCj4gICBMZXQg bWUgZmlyc3Qgc2F5IHRoYXQgSSBhZ3JlZSB0aGF0IEwzIGlzIHRoZSB3YXkgdGhpbmdzIHNob3Vs ZCBiZSBidWlsdC4gIEJ1dA0KDQpUaGF0J3MgZ3JlYXQuDQoNCj4gSSdtIG5vdCBzdXJlIHRoYXQg eW91ciBkcmFmdCBhZGRzIG11Y2ggdG8gZXhpc3RpbmcgbWV0aG9kcywgYW5kIGl0IHNlZW1zIHRv DQo+IG1ha2UgYSBudW1iZXIgb2YgYXNzdW1wdGlvbnMuDQo+IA0KPiAgICAiUEUgcm91dGVycyAo aS5lLiwNCj4gICAgUEUtMSBhbmQgUEUtMikgd2hpY2ggYXJlIHVzZWQgZm9yIGludGVyY29ubmVj dGluZyB0aGVzZSB0d28gZGF0YQ0KPiAgICBjZW50ZXJzIGNyZWF0ZSBob3N0IHJvdXRlcyBmb3Ig dGhlaXIgbG9jYWwgQ0UgaG9zdHMgcmVzcGVjdGl2ZWx5IGFuZA0KPiAgICB0aGVuIGFkdmVydGlz ZSB0aGVtIHZpYSBMM1ZQTiBzaWduYWxpbmcuLi4uIEluIGZhY3QsIHN1Y2ggc3VibmV0IGlzIGEg dmlydHVhbA0KPiAgICBzdWJuZXQgd2hpY2ggaXMgZW11bGF0ZWQgYnkgdXNpbmcgaG9zdCByb3V0 ZXMuIg0KPiANCj4gDQo+IFNvIGlmIEkgaGF2ZSBhIC8yNCBJIHdpbGwgZW5kIHVwIHdpdGggKHVw IHRvKSAyNTMgaG9zdCBhZGRyZXNzZXMgaW4gdGhlIG5ldHdvcms/DQoNClllcy4NCg0KPiBIb3cg ZG9lcyBhIFBFIGtub3cgd2hpY2ggaG9zdHMgZXhpc3Q/ICBEb2VzIGl0IHdhaXQgdW50aWwgaXQg c2VlcyBsb2NhbCBBUlAgaW4NCj4gb3JkZXIgdG8gZGV0ZXJtaW5lIHRoYXQgdGhlcmUgaXMgYSB2 YWxpZCAvMzI/DQoNCkFSUCBpcyBqdXN0IG9uZSBwb3NzaWJsZSBhcHByb2FjaCBmb3IgQ0UgaG9z dCBkaXNjb3ZlcnkuIFlvdSBjYW4gYWxzbyB1c2Ugb3RoZXIgYXBwcm9hY2hlcyAoZS5nLiwgYW4g b3JjaGVzdHJhdGlvbiBzeXN0ZW0pIHRvIGZpbGwgdGhpcyBnb2FsLg0KDQo+IFdoYXQgaGFwcGVu cyBpZiBIb3N0IEEgd2FudHMgdG8gcmVhY2ggSG9zdCBDLCBob21lZCBvZmYgb2YgUEUtMywgYnV0 IFBFLTMNCj4gZG9lcyBub3Qga25vdyBhYm91dCBIb3N0IEMgYmVjYXVzZSBpdCdzIG5ldmVyIHBh cnRpY2lwYXRlZCBpbiBBUlA/ICBEbyBJDQo+IG5lZWQgdG8gcmVsYXkgdGhlIEFSUCBmcm9tIFBF LTMgdG8gdGhlIG90aGVyIFBFcyBmb3IgdGhlIFZQTj8NCg0KVGhlIGJhc2ljIGFzc3VtcHRpb24g b2YgdGhpcyBkcmFmdCBpcyB0aGF0IGxvY2FsIFBFIHJvdXRlcnMgY291bGQgdGltZWx5IGRpc2Nv dmVyIHRoZWlyIG93biBsb2NhbCBDRSBob3N0cyB0aHJvdWdoIGEgZ2l2ZW4gYXBwcm9hY2guIEhv d2V2ZXIsIHRoZSBhcHByb2FjaCB5b3UgcHJvcG9zZWQgbWF5IGJlIHdvcnRod2hpbGUgdG8gYmUg Y29uc2lkZXJlZCBpbiB0aGlzIGRyYWZ0Lg0KDQo+IFdoYXQgc2NhbGUgYmVuZWZpdHMgYXJlIHRo ZXJlIGlmIEkgaGF2ZSB0byBhZHZlcnRpc2UgYWxsIHRoZSBob3N0IHJvdXRlcyBvbiBteQ0KPiBs b2NhbCBwb3J0aW9uIG9mIHRoZSBzdWJuZXQ/ICBTcGVjaWZpY2FsbHksIGNhbiB5b3UgY29tcGFy ZSB0aGUgc2NhbGUgYmVuZWZpdHMgb2YNCj4gYWR2ZXJ0aXNpbmcgYSBidW5jaCBvZiAvMzJzIHRv LCBzYXksIEVWUE4sIHdoZXJlIE1BQyBhZGRyZXNzZXMgYXJlIGJhc2ljYWxseQ0KPiAvNDggaG9z dCByb3V0ZXM/DQoNCkFsbW9zdCB0aGUgc2FtZSBmcm9tIHRoZSBmb3J3YXJkaW5nIHRhYmxlIHNp emUgcGVyc3BlY3RpdmUuIEFuZCBib3RoIGNhbiBzdXBwcmVzcyB0aGUgdW5rbm93biB1bmNhc3Qg Zmxvb2RpbmcuIEhvd2V2ZXIsIGZyb20gdGhlIG1hdHVyaXR5IGRlZ3JlZSBvZiB0ZWNobm9sb2d5 IGFuZCBwcm9kdWN0IGFuZCB0aGUgb3BlcmF0aW9uIGV4cGVyaWVuY2UgcGVyc3BlY3RpdmVzLCBM M1ZQTiBpcyBhYnNvbHV0ZWx5IGEgYmV0dGVyIGNob2ljZSwgSU1ITy4NCg0KPiBJbiBzZWN0aW9u IDMuNi4xOg0KPiANCj4gLS0tDQo+IHRoZSBpbmdyZXNzIFBFIHJvdXRlciB3aWxsIGZvcndhcmQg dGhlIHBhY2tldCB0byB0aGUNCj4gICAgICAgUlIgYWNjb3JkaW5nIHRvIG9uZSBvZiB0aGUgVlAg cm91dGVzIGxlYXJudCBmcm9tIHRoZSBSUiwgd2hpY2ggaW4NCj4gICAgICAgdHVybiBmb3J3YXJk cyB0aGUgcGFja2V0IHRvIHRoZSByZWxldmFudCBlZ3Jlc3MgUEUgcm91dGVyDQo+ICAgICAgIGFj Y29yZGluZyB0byB0aGUgaG9zdCByb3V0ZSBsZWFybnQgZnJvbSB0aGF0IGVncmVzcyBQRSByb3V0 ZXIuDQo+IC0tLQ0KPiANCj4gVGhpcyBtYWtlcyBtZSBuZXJ2b3VzLCBhcyB5b3UndmUgbm93IG1h ZGUgYSBSb3V0ZSBSZWZsZWN0b3IgKG9mdGVuIGEgYm94DQo+IHdpdGggbG90cyBvZiBDUFUgYW5k IG1lbW9yeSBidXQgbm90IG5lY2Vzc2FyaWx5IG11Y2ggZm9yd2FyZGluZyB0aHJvdWdocHV0KQ0K PiBpbnRvIGJhc2ljYWxseSBhIEJyb2FkY2FzdC9Vbmtub3duIE11bHRpY2FzdCBzZXJ2ZXIuDQoN CkFzIG1lbnRpb25lZCBqdXN0IGFmdGVyIHRoZSB0ZXh0IHlvdSBxdW90ZWQsIA0KDQogICAgICIu Li4gTm90ZSB0aGF0IGluIHRoZSBjYXNlIHdoZXJlIHRoZSBSUiBpcw0KICAgICAgbm90IGF2YWls YWJsZSBmb3IgdHJhbnNmZXJyaW5nIEwzVlBOIHRyYWZmaWMgYmV0d2VlbiBQRSByb3V0ZXJzDQog ICAgICBmb3Igc29tZSByZWFzb24gKGUuZy4sIHRoZSBSUiBpcyBpbXBsZW1lbnRlZCBvbiBhIHNl cnZlciwgcmF0aGVyDQogICAgICB0aGFuIGEgcm91dGVyKSwgdGhlIEFQUiBmdW5jdGlvbiBjb3Vs ZCBhY3R1YWxseSBiZSBwZXJmb3JtZWQgYnkgYQ0KICAgICAgZ2l2ZW4gUEUgcm91dGVyIG90aGVy IHRoYW4gdGhlIFJSIGFzIGxvbmcgYXMgdGhhdCBQRSByb3V0ZXIgaGFzDQogICAgICBpbnN0YWxs ZWQgYWxsIGhvc3Qgcm91dGVzIGJlbG9uZ2luZyB0byB0aGUgdmlydHVhbCBzdWJuZXQgaW50byBp dHMNCiAgICAgIEZJQi4iDQoNCj4gVGhlIHdob2xlIG9mIFNlY3Rpb24gMy42IGZlZWxzIGEgbGl0 dGxlIGxpa2UgTElTUCBvciBOSFJQIG9yIHNvbWV0aGluZy4gIElmIHRoaXMgaXMNCj4gcmVhbGx5 IHdoYXQgeW91J3JlIGFmdGVyIHlvdSBtYXkgd2FudCB0byBsb29rIGF0IGhvdyB0aGV5IGFwcHJv YWNoZWQgdGhpcw0KPiBwcm9ibGVtIGFuZCBzaG93IHdoYXQncyBkaWZmZXJlbnQgYWJvdXQgeW91 ciBzb2x1dGlvbi4NCg0KWW91ciBvYnNlcnZhdGlvbiBpcyBjb3JyZWN0LiBUbyBzb21lIGV4dGVu dCwgTElTUCBjYW4gYmUgbG9va2VkIGFzIGFub3RoZXIgdHlwZSBvZiBMM1ZQTiBhcHByb2FjaC4g RnVydGhlcm1vcmUsIExJU1AtbW9iaWxpdHkgaXMgYW5vdGhlciB0eXBlIG9mIGhvc3Qgcm91dGUg YmFzZWQgc3VibmV0IGV4dGVuc2lvbiBhcHByb2FjaCBqdXN0IGxpa2UgdGhlIG9uZSBkZWZpbmVk IGluIHRoaXMgZHJhZnQuIEl0J3MgdXAgdG8gdGhlIGNsb3VkIHByb3ZpZGVycyB0byBtYWtlIGEg Y2hvaWNlIGJldHdlZW4gTDNWUE4gYW5kIExJU1AuIEJUVywgaWYgeW91IHdlcmUgYSBjbG91ZCBw cm92aWRlciwgd2hpY2ggb25lIHdvdWxkIHlvdSBjaG9vc2UgaW4gcHJhY3RpY2U/DQoNCkJlc3Qg cmVnYXJkcywNClhpYW9odQ0KIA0KPiBlcmljDQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+IEZyb206IG52bzMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm52bzMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ID4gWHV4aWFvaHUNCj4gPiBTZW50OiBU dWVzZGF5LCBKdWx5IDAyLCAyMDEzIDI6NTIgQU0NCj4gPiBUbzogTDNWUE4NCj4gPiBDYzogbnZv M0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFtudm8zXSBXaHkgbm90IHVzZSBMM1ZQTiBmb3IgZGF0 YSBjZW50ZXIgaW50ZXJjb25uZWN0Py8vcmU6DQo+ID4gUmVxdWVzdCBhIFdHIGFkb3B0aW9uIHBv bGwgZm9yIGRyYWZ0LXh1LXZpcnR1YWwtc3VibmV0LTEwDQo+ID4NCj4gPiBIaSBhbGwsDQo+ID4N Cj4gPiBUaWxsIG5vdywgaXQgc2VlbXMgdGhhdCB0b28gbXVjaCBhdHRlbnRpb24gaGFzIGJlZW4g cGFpZCB0byB0aGUgdXNlIG9mDQo+ID4gTDJWUE4gZm9yIGRhdGEgY2VudGVyIGludGVyY29ubmVj dC4gQWx0aG91Z2ggdGhlcmUgYXJlIHN0aWxsIGEgZmV3DQo+ID4gY2x1c3RlcmluZyBhcHBsaWNh dGlvbnMgd2hpY2ggcmVseSBvbiBub24tSVAgb3Igbm9uLXJvdXRhYmxlIElQDQo+ID4gY29tbXVu aWNhdGlvbnMgKGUuZy4sIGhlYXJ0YmVhdCBtZXNzYWdlcyBiZXR3ZWVuIGNsdXN0ZXIgbm9kZXMp LCBtb3JlDQo+ID4gYW5kIG1vcmUgY2x1c3RlciB2ZW5kb3JzIGFyZSBvZmZlcmluZyBjbHVzdGVy aW5nIGFwcGxpY2F0aW9ucyBiYXNlZCBvbg0KPiA+IExheWVyIDMgaW50ZXJjb25uZWN0aW9uLiBJ biBhZGRpdGlvbiwgZ2VvZ3JhcGhpY2FsIGhpZ2gtYXZhaWxhYmlsaXR5DQo+ID4gY2x1c3RlcnMg aXMgbm90IGEgbXVzdCBpbiBtYW55IGRhdGEgY2VudGVyIGludGVyY29ubmVjdCBjYXNlcy4NCj4g Pg0KPiA+IEFzIEwzVlBOIGhhcyBtYW55IGRpc3RpbmN0IGFkdmFudGFnZXMgb3ZlciBMMlZQTiBm b3IgZGF0YSBjZW50ZXINCj4gPiBpbnRlcmNvbm5lY3Qgc3VjaCBhczogc2NhbGluZyBmb3J3YXJk aW5nIHRhYmxlcyBvZiBkYXRhIGNlbnRlciBzd2l0Y2hlcywNCj4gPiBwYXRoIG9wdGltaXphdGlv biwgdW5rbm93biB1bmljYXN0IGFuZCBBUlAgc3VwcHJlc3Npb24uLi4gd2h5IG5vdCB0cnkgdG8N Cj4gPiB1c2UgdGhlIHByb3ZlbiBMM1ZQTiB0ZWNobm9sb2d5IGZvciBkYXRhIGNlbnRlciBpbnRl cmNvbm5lY3QgaW4gdGhlDQo+ID4gc2NlbmFyaW8gd2hlcmUgdGhlIGxpbWl0YXRpb25zIGFzIG1l bnRpb25lZCBhYm92ZSBkb24ndCBleGlzdD8NCj4gPg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBY aWFvaHUNCj4gPg0KPiA+ID4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiA+ID4g5Y+R5Lu25Lq6 OiB0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbSBbbWFpbHRvOnRob21hcy5tb3JpbkBvcmFuZ2UuY29t XQ0KPiA+ID4g5Y+R6YCB5pe26Ze0OiAyMDEz5bm0N+aciDHml6UgMjE6MTQNCj4gPiA+IOaUtuS7 tuS6ujogWHV4aWFvaHUNCj4gPiA+IOaKhOmAgTogbDN2cG4tY2hhaXJzQHRvb2xzLmlldGYub3Jn OyBtYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwtDQo+ID4gbHVjZW50LmNvbTsNCj4gPiA+IEwzVlBO DQo+ID4gPiDkuLvpopg6IFJlOiBSZXF1ZXN0IGEgV0cgYWRvcHRpb24gcG9sbCBmb3IgZHJhZnQt eHUtdmlydHVhbC1zdWJuZXQtMTANCj4gPiA+DQo+ID4gPiBIZWxsbyBYdXhpYW9odSwNCj4gPiA+ DQo+ID4gPiBCZWZvcmUgZXZlbnR1YWxseSBzdGFydGluZyBhIGRpc2N1c3Npb24gb24gdGhlIGFk b3B0aW9uIG9uIHRoaXMNCj4gPiA+IGRvY3VtZW50LCB3ZSBjaGFpcnMgd291bGQgbGlrZSB0byBz ZWUgbW9yZSBkaXNjdXNzaW9uIGFuZCBoYXZlIHRoZQ0KPiA+ID4gZmVlZGJhY2sgZnJvbSBtb3Jl IHJlYWRlcnMgKGR1cmluZyB0aGUgMiBwcmV2aW91cyBtZWV0aW5ncywgb25seSA1IHRvDQo+ID4g MTANCj4gPiA+IHBlb3BsZSByYWlzZWQgdGhlaXIgaGFuZCB3aGVuIHRoZSByb29tIHdhcyBwb2xs ZWQgb24gaGF2aW5nIHJlYWQgdGhlDQo+ID4gPiBkb2N1bWVudCkuDQo+ID4gPg0KPiA+ID4gUmVn YXJkcywNCj4gPiA+DQo+ID4gPiAtVGhvbWFzIGFuZCBNYXJ0aW4sDQo+ID4gPiBsM3ZwbiBjby1j aGFpcnMNCj4gPiA+DQo+ID4gPg0KPiA+ID4gMjAxMy0wNy0wMSwgWHV4aWFvaHU6DQo+ID4gPiA+ IEhpIFRob21hcyBhbmQgTWFydGluLA0KPiA+ID4gPg0KPiA+ID4gPiBJIGhhdmVuJ3QgcmVjZWl2 ZWQgYW55IHJlc3BvbnNlIGZyb20gYW55IG9mIHlvdS4gSGVuY2UgSSByZXNlbmQgaXQuDQo+ID4g PiA+DQo+ID4gPiA+IEJlc3QgcmVnYXJkcywNCj4gPiA+ID4gWGlhb2h1DQo+ID4gPiA+DQo+ID4g PiA+PiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ID4gPiA+PiDlj5Hku7bkuro6IFh1eGlhb2h1 DQo+ID4gPiA+PiDlj5HpgIHml7bpl7Q6IDIwMTPlubQ25pyIMjDml6UgMTU6MDcNCj4gPiA+ID4+ IOaUtuS7tuS6ujogJ2wzdnBuLWNoYWlyc0B0b29scy5pZXRmLm9yZyc7ICd0aG9tYXMubW9yaW5A b3JhbmdlLmNvbSc7DQo+ID4gPiA+PiAnbWFydGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2VudC5j b20nDQo+ID4gPiA+PiDmioTpgIE6IEwzVlBODQo+ID4gPiA+PiDkuLvpopg6IFJlcXVlc3QgYSBX RyBhZG9wdGlvbiBwb2xsIGZvciBkcmFmdC14dS12aXJ0dWFsLXN1Ym5ldC0xMA0KPiA+ID4gPj4N Cj4gPiA+ID4+IEhpIFdHIGNvLWNoYWlycywNCj4gPiA+ID4+DQo+ID4gPiA+PiBBcyBtZW50aW9u ZWQgYmVmb3JlLCB0aGlzIGRyYWZ0DQo+ID4gPiA+PiAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQteHUtdmlydHVhbC1zdWJuZXQtMTApIGRlc2NyaWJlcw0KPiA+IGhvdyB0bw0KPiA+ ID4gcmV1c2UNCj4gPiA+ID4+IHRoZSBwcm92ZW4gTDNWUE4gdGVjaG5vbG9neSB0byByZWFsaXpl IHN1Ym5ldCBleHRlbnNpb24gZm9yIGRhdGENCj4gPiBjZW50ZXINCj4gPiA+ID4+IGludGVyY29u bmVjdCwgd2l0aCB0aGUgYWlkIG9mIG1hbnkgY29uY3JldGUgZXhwZXJpbWVudHMgYW5kDQo+ID4g dmVyaWZpY2F0aW9ucy4NCj4gPiA+ID4+DQo+ID4gPiA+PiBXZSBjby1hdXRob3JzIGJlbGlldmUg dGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGRyYWZ0IHdvdWxkDQo+ID4gYmUNCj4g PiA+IHZhbHVhYmxlDQo+ID4gPiA+PiBmb3IgY2xvdWQgc2VydmljZSBwcm92aWRlcnMgdG8gZXZh bHVhdGUgdGhlIGZlYXNpYmlsaXR5IG9mIGFkb3B0aW5nDQo+ID4gdGhlIHByb3Zlbg0KPiA+ID4g Pj4gTDNWUE4gdGVjaG5vbG9neSBmb3IgZGF0YSBjZW50ZXIgaW50ZXJjb25uZWN0aW9uIChieSB0 aGUgd2F5LCBzb21lDQo+ID4gcGVvcGxlDQo+ID4gPiA+PiBoYWQgc2hvd24gdGhlaXIgaW50ZXJl c3RzIG9uIHRoZSBzY2hlbWUgZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQNCj4gPiB3aGVuDQo+ID4g PiB2aXNpdGluZw0KPiA+ID4gPj4gb3VyIGltcGxlbWVudGF0aW9uIGRlbW8gb2YgdGhpcyBzY2hl bWUgYXQgdGhlIEJpdHMtTi1CaXRlcyBldmVudCBvZg0KPiA+ID4gSUVURjg2KS4NCj4gPiA+ID4+ IEhlbmNlIHdlIHdvdWxkIGxpa2UgY28tY2hhaXJzIHRvIHN0YXJ0IGEgV0cgYWRvcHRpb24gcG9s bCBmb3IgdGhpcw0KPiA+IGRyYWZ0Lg0KPiA+ID4gPj4NCj4gPiA+ID4+IEJlc3QgcmVnYXJkcywN Cj4gPiA+ID4+IFhpYW9odSAob24gYmVoYWxmIG9mIGFsbCBjby1hdXRob3JzKQ0KPiA+ID4NCj4g PiA+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4NCj4gPiA+IENlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0KPiA+ID4gY29u ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCj4gPiA+IHBh cyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT aSB2b3VzIGF2ZXoNCj4gPiByZWN1IGNlDQo+ID4gPiBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyDQo+ID4gPiBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5z aSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMNCj4gPiBtZXNzYWdlcw0KPiA+ID4gZWxlY3Ry b25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KPiA+ID4gT3JhbmdlIGRl Y2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsDQo+ ID4gZGVmb3JtZSBvdQ0KPiA+ID4gZmFsc2lmaWUuIE1lcmNpLg0KPiA+ID4NCj4gPiA+IFRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvcg0K PiA+IHByaXZpbGVnZWQNCj4gPiA+IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBi eSBsYXc7DQo+ID4gPiB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29w aWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4gPiA+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQNCj4gPiBkZWxl dGUgdGhpcw0KPiA+ID4gbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiA+ID4gQXMgZW1h aWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhh dCBoYXZlDQo+ID4gYmVlbg0KPiA+ID4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0K PiA+ID4gVGhhbmsgeW91Lg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiBudm8zIG1haWxpbmcgbGlzdA0KPiA+IG52bzNAaWV0Zi5v cmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMNCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbnZvMyBtYWls aW5nIGxpc3QNCj4gbnZvM0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL252bzMNCg== From xuxiaohu@huawei.com Tue Jul 2 18:13:19 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA0011E8111; Tue, 2 Jul 2013 18:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.242 X-Spam-Level: X-Spam-Status: No, score=-5.242 tagged_above=-999 required=5 tests=[AWL=0.757, 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 nSiEGC3IUTcF; Tue, 2 Jul 2013 18:13:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA4711E810F; Tue, 2 Jul 2013 18:13:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUP76759; Wed, 03 Jul 2013 01:13:11 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 3 Jul 2013 02:12:11 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 3 Jul 2013 02:13:11 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.134]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.01.0323.007; Wed, 3 Jul 2013 09:13:00 +0800 From: Xuxiaohu To: Xuxiaohu , "Eric Osborne (eosborne)" , L3VPN Subject: re: [nvo3] Why not use L3VPN for data center interconnect?//re: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Topic: [nvo3] Why not use L3VPN for data center interconnect?//re: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Index: Ac5thMS2t8EppEHAQo6a5WxySmdDhQIdhP9gABRMqAAAIYUh4AAR3xWAABrQKhAAAVvBUA== Date: Wed, 3 Jul 2013 01:13:00 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CB5CC@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CAD74@NKGEML512-MBS.china.huawei.com> <6463_1372684423_51D18087_6463_1266_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D074D1A7D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CB31D@NKGEML512-MBS.china.huawei.com> <20ECF67871905846A80F77F8F4A2757210276FCC@xmb-rcd-x09.cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 01:13:19 -0000 PiBZb3VyIG9ic2VydmF0aW9uIGlzIGNvcnJlY3QuIFRvIHNvbWUgZXh0ZW50LCBMSVNQIGNhbiBi ZSBsb29rZWQgYXMgYW5vdGhlciB0eXBlDQo+IG9mIEwzVlBOIGFwcHJvYWNoLiBGdXJ0aGVybW9y ZSwgTElTUC1tb2JpbGl0eSBpcyBhbm90aGVyIHR5cGUgb2YgaG9zdCByb3V0ZQ0KPiBiYXNlZCBz dWJuZXQgZXh0ZW5zaW9uIGFwcHJvYWNoIGp1c3QgbGlrZSB0aGUgb25lIGRlZmluZWQgaW4gdGhp cyBkcmFmdC4gSXQncyB1cA0KPiB0byB0aGUgY2xvdWQgcHJvdmlkZXJzIHRvIG1ha2UgYSBjaG9p Y2UgYmV0d2VlbiBMM1ZQTiBhbmQgTElTUC4gQlRXLCBpZiB5b3UNCj4gd2VyZSBhIGNsb3VkIHBy b3ZpZGVyLCB3aGljaCBvbmUgd291bGQgeW91IGNob29zZSBpbiBwcmFjdGljZT8NCg0Kcy9MSVNQ LW1vYmlsaXR5L0xJU1AgVk0tTW9iaWxpdHkvDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0K From xuxiaohu@huawei.com Tue Jul 2 18:16:03 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F36611E8111; Tue, 2 Jul 2013 18:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.431 X-Spam-Level: X-Spam-Status: No, score=-5.431 tagged_above=-999 required=5 tests=[AWL=0.568, 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 se+Lg1ooUfLB; Tue, 2 Jul 2013 18:15:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ADAE011E810F; Tue, 2 Jul 2013 18:15:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATB52637; Wed, 03 Jul 2013 01:15:57 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 3 Jul 2013 02:15:45 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 3 Jul 2013 02:15:56 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.134]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Wed, 3 Jul 2013 09:15:51 +0800 From: Xuxiaohu To: "Rajiv Asati (rajiva)" , "Eric Osborne (eosborne)" , L3VPN Subject: re: [nvo3] Why not use L3VPN for data center interconnect?//re: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Topic: [nvo3] Why not use L3VPN for data center interconnect?//re: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Index: AQHOdzSF1zTcgrwF9UWCjR/ajSR4C5lSJxnw Date: Wed, 3 Jul 2013 01:15:50 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CB5DE@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CAD74@NKGEML512-MBS.china.huawei.com> <6463_1372684423_51D18087_6463_1266_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D074D1A7D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CB31D@NKGEML512-MBS.china.huawei.com> <20ECF67871905846A80F77F8F4A2757210276FCC@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 01:16:03 -0000 DQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IFJhaml2IEFzYXRpIChy YWppdmEpIFttYWlsdG86cmFqaXZhQGNpc2NvLmNvbV0NCj4g5Y+R6YCB5pe26Ze0OiAyMDEz5bm0 N+aciDLml6UgMjI6NTcNCj4g5pS25Lu25Lq6OiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKTsgWHV4 aWFvaHU7IEwzVlBODQo+IOaKhOmAgTogbnZvM0BpZXRmLm9yZw0KPiDkuLvpopg6IFJFOiBbbnZv M10gV2h5IG5vdCB1c2UgTDNWUE4gZm9yIGRhdGEgY2VudGVyIGludGVyY29ubmVjdD8vL3JlOg0K PiBSZXF1ZXN0IGEgV0cgYWRvcHRpb24gcG9sbCBmb3IgZHJhZnQteHUtdmlydHVhbC1zdWJuZXQt MTANCj4gDQo+IA0KPiANCj4gPiBUaGUgd2hvbGUgb2YgU2VjdGlvbiAzLjYgZmVlbHMgYSBsaXR0 bGUgbGlrZSBMSVNQIG9yIE5IUlAgb3Igc29tZXRoaW5nLiAgSWYgdGhpcw0KPiANCj4gVmVyeSBn b29kIGFuYWxvZ3kuIE5IUlAgYmFzZWQgc29sdXRpb24gZS5nLiBETVZQTiwgd2hpY2ggaXMgY29t bW9ubHkgdXNlZA0KPiBieSBlbnRlcnByaXNlcyB0byBidWlsZCBzaXRlLXRvLXNpdGUgQ0UtYmFz ZWQgb3ZlcmxheSAod2l0aCBvciB3aXRob3V0IEwzVlBODQo+IGluc2lkZSB0aGUgZW50ZXJwcmlz ZSBuZXR3b3JrKSwgZml0cyB0aGUgYmlsbCBoZXJlIChiZXlvbmQganVzdCBEQ0ksIHN0cmljdGx5 DQo+IHNwZWFraW5nKSB2ZXJ5IHdlbGwuDQo+IA0KPiBIYXZpbmcgc2FpZCB0aGF0LCBOSFJQIGlz IG5vdCBwZXJjZWl2ZWQgdG8gc2NhbGUgYXMgd2VsbCBhcyB0aGF0IG9mIEJHUC4NCg0KRnVsbHkg YWdyZWUuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IENoZWVycywNCj4gUmFqaXYNCj4g DQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogbDN2cG4tYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwzdnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0K PiA+IE9mIEVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpDQo+ID4gU2VudDogVHVlc2RheSwgSnVseSAw MiwgMjAxMyA4OjA3IEFNDQo+ID4gVG86IFh1eGlhb2h1OyBMM1ZQTg0KPiA+IENjOiBudm8zQGll dGYub3JnDQo+ID4gU3ViamVjdDogUkU6IFtudm8zXSBXaHkgbm90IHVzZSBMM1ZQTiBmb3IgZGF0 YSBjZW50ZXIgaW50ZXJjb25uZWN0Py8vcmU6DQo+ID4gUmVxdWVzdCBhIFdHIGFkb3B0aW9uIHBv bGwgZm9yIGRyYWZ0LXh1LXZpcnR1YWwtc3VibmV0LTEwDQo+ID4NCj4gPiBIaSBYaWFvaHUtDQo+ ID4NCj4gPiAgIExldCBtZSBmaXJzdCBzYXkgdGhhdCBJIGFncmVlIHRoYXQgTDMgaXMgdGhlIHdh eSB0aGluZ3Mgc2hvdWxkIGJlIGJ1aWx0LiAgQnV0DQo+ID4gSSdtIG5vdCBzdXJlIHRoYXQgeW91 ciBkcmFmdCBhZGRzIG11Y2ggdG8gZXhpc3RpbmcgbWV0aG9kcywgYW5kIGl0IHNlZW1zIHRvDQo+ ID4gbWFrZSBhIG51bWJlciBvZiBhc3N1bXB0aW9ucy4NCj4gPg0KPiA+ICAgICJQRSByb3V0ZXJz IChpLmUuLA0KPiA+ICAgIFBFLTEgYW5kIFBFLTIpIHdoaWNoIGFyZSB1c2VkIGZvciBpbnRlcmNv bm5lY3RpbmcgdGhlc2UgdHdvIGRhdGENCj4gPiAgICBjZW50ZXJzIGNyZWF0ZSBob3N0IHJvdXRl cyBmb3IgdGhlaXIgbG9jYWwgQ0UgaG9zdHMgcmVzcGVjdGl2ZWx5IGFuZA0KPiA+ICAgIHRoZW4g YWR2ZXJ0aXNlIHRoZW0gdmlhIEwzVlBOIHNpZ25hbGluZy4uLi4gSW4gZmFjdCwgc3VjaCBzdWJu ZXQgaXMgYQ0KPiB2aXJ0dWFsDQo+ID4gICAgc3VibmV0IHdoaWNoIGlzIGVtdWxhdGVkIGJ5IHVz aW5nIGhvc3Qgcm91dGVzLiINCj4gPg0KPiA+DQo+ID4gU28gaWYgSSBoYXZlIGEgLzI0IEkgd2ls bCBlbmQgdXAgd2l0aCAodXAgdG8pIDI1MyBob3N0IGFkZHJlc3NlcyBpbiB0aGUNCj4gPiBuZXR3 b3JrPw0KPiA+DQo+ID4gSG93IGRvZXMgYSBQRSBrbm93IHdoaWNoIGhvc3RzIGV4aXN0PyAgRG9l cyBpdCB3YWl0IHVudGlsIGl0IHNlZXMgbG9jYWwgQVJQDQo+ID4gaW4gb3JkZXIgdG8gZGV0ZXJt aW5lIHRoYXQgdGhlcmUgaXMgYSB2YWxpZCAvMzI/DQo+ID4NCj4gPiBXaGF0IGhhcHBlbnMgaWYg SG9zdCBBIHdhbnRzIHRvIHJlYWNoIEhvc3QgQywgaG9tZWQgb2ZmIG9mIFBFLTMsIGJ1dCBQRS0z DQo+ID4gZG9lcyBub3Qga25vdyBhYm91dCBIb3N0IEMgYmVjYXVzZSBpdCdzIG5ldmVyIHBhcnRp Y2lwYXRlZCBpbiBBUlA/ICBEbyBJDQo+ID4gbmVlZCB0byByZWxheSB0aGUgQVJQIGZyb20gUEUt MyB0byB0aGUgb3RoZXIgUEVzIGZvciB0aGUgVlBOPw0KPiA+DQo+ID4gV2hhdCBzY2FsZSBiZW5l Zml0cyBhcmUgdGhlcmUgaWYgSSBoYXZlIHRvIGFkdmVydGlzZSBhbGwgdGhlIGhvc3Qgcm91dGVz IG9uIG15DQo+ID4gbG9jYWwgcG9ydGlvbiBvZiB0aGUgc3VibmV0PyAgU3BlY2lmaWNhbGx5LCBj YW4geW91IGNvbXBhcmUgdGhlIHNjYWxlDQo+ID4gYmVuZWZpdHMgb2YgYWR2ZXJ0aXNpbmcgYSBi dW5jaCBvZiAvMzJzIHRvLCBzYXksIEVWUE4sIHdoZXJlIE1BQyBhZGRyZXNzZXMNCj4gPiBhcmUg YmFzaWNhbGx5IC80OCBob3N0IHJvdXRlcz8NCj4gPg0KPiA+DQo+ID4NCj4gPiBJbiBzZWN0aW9u IDMuNi4xOg0KPiA+DQo+ID4gLS0tDQo+ID4gdGhlIGluZ3Jlc3MgUEUgcm91dGVyIHdpbGwgZm9y d2FyZCB0aGUgcGFja2V0IHRvIHRoZQ0KPiA+ICAgICAgIFJSIGFjY29yZGluZyB0byBvbmUgb2Yg dGhlIFZQIHJvdXRlcyBsZWFybnQgZnJvbSB0aGUgUlIsIHdoaWNoIGluDQo+ID4gICAgICAgdHVy biBmb3J3YXJkcyB0aGUgcGFja2V0IHRvIHRoZSByZWxldmFudCBlZ3Jlc3MgUEUgcm91dGVyDQo+ ID4gICAgICAgYWNjb3JkaW5nIHRvIHRoZSBob3N0IHJvdXRlIGxlYXJudCBmcm9tIHRoYXQgZWdy ZXNzIFBFIHJvdXRlci4NCj4gPiAtLS0NCj4gPg0KPiA+IFRoaXMgbWFrZXMgbWUgbmVydm91cywg YXMgeW91J3ZlIG5vdyBtYWRlIGEgUm91dGUgUmVmbGVjdG9yIChvZnRlbiBhIGJveA0KPiA+IHdp dGggbG90cyBvZiBDUFUgYW5kIG1lbW9yeSBidXQgbm90IG5lY2Vzc2FyaWx5IG11Y2ggZm9yd2Fy ZGluZw0KPiA+IHRocm91Z2hwdXQpIGludG8gYmFzaWNhbGx5IGEgQnJvYWRjYXN0L1Vua25vd24g TXVsdGljYXN0IHNlcnZlci4NCj4gPg0KPiA+IFRoZSB3aG9sZSBvZiBTZWN0aW9uIDMuNiBmZWVs cyBhIGxpdHRsZSBsaWtlIExJU1Agb3IgTkhSUCBvciBzb21ldGhpbmcuICBJZiB0aGlzDQo+ID4g aXMgcmVhbGx5IHdoYXQgeW91J3JlIGFmdGVyIHlvdSBtYXkgd2FudCB0byBsb29rIGF0IGhvdyB0 aGV5IGFwcHJvYWNoZWQgdGhpcw0KPiA+IHByb2JsZW0gYW5kIHNob3cgd2hhdCdzIGRpZmZlcmVu dCBhYm91dCB5b3VyIHNvbHV0aW9uLg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gZXJpYw0KPiA+ DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBudm8z LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs Zg0KPiA+ID4gT2YgWHV4aWFvaHUNCj4gPiA+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMDIsIDIwMTMg Mjo1MiBBTQ0KPiA+ID4gVG86IEwzVlBODQo+ID4gPiBDYzogbnZvM0BpZXRmLm9yZw0KPiA+ID4g U3ViamVjdDogW252bzNdIFdoeSBub3QgdXNlIEwzVlBOIGZvciBkYXRhIGNlbnRlciBpbnRlcmNv bm5lY3Q/Ly9yZToNCj4gPiA+IFJlcXVlc3QgYSBXRyBhZG9wdGlvbiBwb2xsIGZvciBkcmFmdC14 dS12aXJ0dWFsLXN1Ym5ldC0xMA0KPiA+ID4NCj4gPiA+IEhpIGFsbCwNCj4gPiA+DQo+ID4gPiBU aWxsIG5vdywgaXQgc2VlbXMgdGhhdCB0b28gbXVjaCBhdHRlbnRpb24gaGFzIGJlZW4gcGFpZCB0 byB0aGUgdXNlIG9mDQo+ID4gPiBMMlZQTiBmb3IgZGF0YSBjZW50ZXIgaW50ZXJjb25uZWN0LiBB bHRob3VnaCB0aGVyZSBhcmUgc3RpbGwgYSBmZXcNCj4gPiA+IGNsdXN0ZXJpbmcgYXBwbGljYXRp b25zIHdoaWNoIHJlbHkgb24gbm9uLUlQIG9yIG5vbi1yb3V0YWJsZSBJUA0KPiA+ID4gY29tbXVu aWNhdGlvbnMgKGUuZy4sIGhlYXJ0YmVhdCBtZXNzYWdlcyBiZXR3ZWVuIGNsdXN0ZXIgbm9kZXMp LCBtb3JlDQo+ID4gPiBhbmQgbW9yZSBjbHVzdGVyIHZlbmRvcnMgYXJlIG9mZmVyaW5nIGNsdXN0 ZXJpbmcgYXBwbGljYXRpb25zIGJhc2VkIG9uDQo+ID4gPiBMYXllciAzIGludGVyY29ubmVjdGlv bi4gSW4gYWRkaXRpb24sIGdlb2dyYXBoaWNhbCBoaWdoLWF2YWlsYWJpbGl0eQ0KPiA+ID4gY2x1 c3RlcnMgaXMgbm90IGEgbXVzdCBpbiBtYW55IGRhdGEgY2VudGVyIGludGVyY29ubmVjdCBjYXNl cy4NCj4gPiA+DQo+ID4gPiBBcyBMM1ZQTiBoYXMgbWFueSBkaXN0aW5jdCBhZHZhbnRhZ2VzIG92 ZXIgTDJWUE4gZm9yIGRhdGEgY2VudGVyDQo+ID4gPiBpbnRlcmNvbm5lY3Qgc3VjaCBhczogc2Nh bGluZyBmb3J3YXJkaW5nIHRhYmxlcyBvZiBkYXRhIGNlbnRlcg0KPiA+ID4gc3dpdGNoZXMsIHBh dGggb3B0aW1pemF0aW9uLCB1bmtub3duIHVuaWNhc3QgYW5kIEFSUCBzdXBwcmVzc2lvbi4uLg0K PiA+ID4gd2h5IG5vdCB0cnkgdG8gdXNlIHRoZSBwcm92ZW4gTDNWUE4gdGVjaG5vbG9neSBmb3Ig ZGF0YSBjZW50ZXINCj4gPiA+IGludGVyY29ubmVjdCBpbiB0aGUgc2NlbmFyaW8gd2hlcmUgdGhl IGxpbWl0YXRpb25zIGFzIG1lbnRpb25lZCBhYm92ZQ0KPiA+IGRvbid0IGV4aXN0Pw0KPiA+ID4N Cj4gPiA+IEJlc3QgcmVnYXJkcywNCj4gPiA+IFhpYW9odQ0KPiA+ID4NCj4gPiA+ID4gLS0tLS3p gq7ku7bljp/ku7YtLS0tLQ0KPiA+ID4gPiDlj5Hku7bkuro6IHRob21hcy5tb3JpbkBvcmFuZ2Uu Y29tDQo+IFttYWlsdG86dGhvbWFzLm1vcmluQG9yYW5nZS5jb21dDQo+ID4gPiA+IOWPkemAgeaX tumXtDogMjAxM+W5tDfmnIgx5pelIDIxOjE0DQo+ID4gPiA+IOaUtuS7tuS6ujogWHV4aWFvaHUN Cj4gPiA+ID4g5oqE6YCBOiBsM3Zwbi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IG1hcnRpbi52aWdv dXJldXhAYWxjYXRlbC0NCj4gPiA+IGx1Y2VudC5jb207DQo+ID4gPiA+IEwzVlBODQo+ID4gPiA+ IOS4u+mimDogUmU6IFJlcXVlc3QgYSBXRyBhZG9wdGlvbiBwb2xsIGZvciBkcmFmdC14dS12aXJ0 dWFsLXN1Ym5ldC0xMA0KPiA+ID4gPg0KPiA+ID4gPiBIZWxsbyBYdXhpYW9odSwNCj4gPiA+ID4N Cj4gPiA+ID4gQmVmb3JlIGV2ZW50dWFsbHkgc3RhcnRpbmcgYSBkaXNjdXNzaW9uIG9uIHRoZSBh ZG9wdGlvbiBvbiB0aGlzDQo+ID4gPiA+IGRvY3VtZW50LCB3ZSBjaGFpcnMgd291bGQgbGlrZSB0 byBzZWUgbW9yZSBkaXNjdXNzaW9uIGFuZCBoYXZlIHRoZQ0KPiA+ID4gPiBmZWVkYmFjayBmcm9t IG1vcmUgcmVhZGVycyAoZHVyaW5nIHRoZSAyIHByZXZpb3VzIG1lZXRpbmdzLCBvbmx5IDUNCj4g PiA+ID4gdG8NCj4gPiA+IDEwDQo+ID4gPiA+IHBlb3BsZSByYWlzZWQgdGhlaXIgaGFuZCB3aGVu IHRoZSByb29tIHdhcyBwb2xsZWQgb24gaGF2aW5nIHJlYWQgdGhlDQo+ID4gPiA+IGRvY3VtZW50 KS4NCj4gPiA+ID4NCj4gPiA+ID4gUmVnYXJkcywNCj4gPiA+ID4NCj4gPiA+ID4gLVRob21hcyBh bmQgTWFydGluLA0KPiA+ID4gPiBsM3ZwbiBjby1jaGFpcnMNCj4gPiA+ID4NCj4gPiA+ID4NCj4g PiA+ID4gMjAxMy0wNy0wMSwgWHV4aWFvaHU6DQo+ID4gPiA+ID4gSGkgVGhvbWFzIGFuZCBNYXJ0 aW4sDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJIGhhdmVuJ3QgcmVjZWl2ZWQgYW55IHJlc3BvbnNl IGZyb20gYW55IG9mIHlvdS4gSGVuY2UgSSByZXNlbmQgaXQuDQo+ID4gPiA+ID4NCj4gPiA+ID4g PiBCZXN0IHJlZ2FyZHMsDQo+ID4gPiA+ID4gWGlhb2h1DQo+ID4gPiA+ID4NCj4gPiA+ID4gPj4g LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiA+ID4gPiA+PiDlj5Hku7bkuro6IFh1eGlhb2h1DQo+ ID4gPiA+ID4+IOWPkemAgeaXtumXtDogMjAxM+W5tDbmnIgyMOaXpSAxNTowNw0KPiA+ID4gPiA+ PiDmlLbku7bkuro6ICdsM3Zwbi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcnOyAndGhvbWFzLm1vcmlu QG9yYW5nZS5jb20nOw0KPiA+ID4gPiA+PiAnbWFydGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2Vu dC5jb20nDQo+ID4gPiA+ID4+IOaKhOmAgTogTDNWUE4NCj4gPiA+ID4gPj4g5Li76aKYOiBSZXF1 ZXN0IGEgV0cgYWRvcHRpb24gcG9sbCBmb3IgZHJhZnQteHUtdmlydHVhbC1zdWJuZXQtMTANCj4g PiA+ID4gPj4NCj4gPiA+ID4gPj4gSGkgV0cgY28tY2hhaXJzLA0KPiA+ID4gPiA+Pg0KPiA+ID4g PiA+PiBBcyBtZW50aW9uZWQgYmVmb3JlLCB0aGlzIGRyYWZ0DQo+ID4gPiA+ID4+IChodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS12aXJ0dWFsLXN1Ym5ldC0xMCkgZGVzY3JpYmVz DQo+ID4gPiBob3cgdG8NCj4gPiA+ID4gcmV1c2UNCj4gPiA+ID4gPj4gdGhlIHByb3ZlbiBMM1ZQ TiB0ZWNobm9sb2d5IHRvIHJlYWxpemUgc3VibmV0IGV4dGVuc2lvbiBmb3IgZGF0YQ0KPiA+ID4g Y2VudGVyDQo+ID4gPiA+ID4+IGludGVyY29ubmVjdCwgd2l0aCB0aGUgYWlkIG9mIG1hbnkgY29u Y3JldGUgZXhwZXJpbWVudHMgYW5kDQo+ID4gPiB2ZXJpZmljYXRpb25zLg0KPiA+ID4gPiA+Pg0K PiA+ID4gPiA+PiBXZSBjby1hdXRob3JzIGJlbGlldmUgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIGRyYWZ0DQo+ID4gPiA+ID4+IHdvdWxkDQo+ID4gPiBiZQ0KPiA+ID4gPiB2YWx1 YWJsZQ0KPiA+ID4gPiA+PiBmb3IgY2xvdWQgc2VydmljZSBwcm92aWRlcnMgdG8gZXZhbHVhdGUg dGhlIGZlYXNpYmlsaXR5IG9mDQo+ID4gPiA+ID4+IGFkb3B0aW5nDQo+ID4gPiB0aGUgcHJvdmVu DQo+ID4gPiA+ID4+IEwzVlBOIHRlY2hub2xvZ3kgZm9yIGRhdGEgY2VudGVyIGludGVyY29ubmVj dGlvbiAoYnkgdGhlIHdheSwNCj4gPiA+ID4gPj4gc29tZQ0KPiA+ID4gcGVvcGxlDQo+ID4gPiA+ ID4+IGhhZCBzaG93biB0aGVpciBpbnRlcmVzdHMgb24gdGhlIHNjaGVtZSBkZXNjcmliZWQgaW4g dGhpcyBkcmFmdA0KPiA+ID4gd2hlbg0KPiA+ID4gPiB2aXNpdGluZw0KPiA+ID4gPiA+PiBvdXIg aW1wbGVtZW50YXRpb24gZGVtbyBvZiB0aGlzIHNjaGVtZSBhdCB0aGUgQml0cy1OLUJpdGVzIGV2 ZW50DQo+ID4gPiA+ID4+IG9mDQo+ID4gPiA+IElFVEY4NikuDQo+ID4gPiA+ID4+IEhlbmNlIHdl IHdvdWxkIGxpa2UgY28tY2hhaXJzIHRvIHN0YXJ0IGEgV0cgYWRvcHRpb24gcG9sbCBmb3INCj4g PiA+ID4gPj4gdGhpcw0KPiA+ID4gZHJhZnQuDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IEJlc3Qg cmVnYXJkcywNCj4gPiA+ID4gPj4gWGlhb2h1IChvbiBiZWhhbGYgb2YgYWxsIGNvLWF1dGhvcnMp DQo+ID4gPiA+DQo+ID4gPiA+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+DQo+ID4gPiA+ IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu Zm9ybWF0aW9ucw0KPiA+ID4gPiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5l IGRvaXZlbnQgZG9uYyBwYXMgZXRyZQ0KPiA+ID4gPiBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNv cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6DQo+ID4gPiByZWN1IGNlDQo+ID4g PiA+IG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRl dXIgZXQgbGUNCj4gPiA+ID4gZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4g TGVzDQo+ID4gPiBtZXNzYWdlcw0KPiA+ID4gPiBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRp YmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlDQo+ID4gPiA+IHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLA0KPiA+ID4gZGVmb3JtZSBvdQ0KPiA+ ID4gPiBmYWxzaWZpZS4gTWVyY2kuDQo+ID4gPiA+DQo+ID4gPiA+IFRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvcg0KPiA+ID4gcHJpdmls ZWdlZA0KPiA+ID4gPiBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0 aGV5IHNob3VsZCBub3QgYmUNCj4gPiA+ID4gZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdp dGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4gPiA+ID4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+ID4gPiA+IGFuZA0KPiA+ ID4gZGVsZXRlIHRoaXMNCj4gPiA+ID4gbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiA+ ID4gPiBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt ZXNzYWdlcyB0aGF0DQo+ID4gPiA+IGhhdmUNCj4gPiA+IGJlZW4NCj4gPiA+ID4gbW9kaWZpZWQs IGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiA+ID4gPiBUaGFuayB5b3UuDQo+ID4gPg0KPiA+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IG52 bzMgbWFpbGluZyBsaXN0DQo+ID4gPiBudm8zQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMNCg== From xuxiaohu@huawei.com Tue Jul 2 18:26:41 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2352E11E8111; Tue, 2 Jul 2013 18:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.545 X-Spam-Level: X-Spam-Status: No, score=-5.545 tagged_above=-999 required=5 tests=[AWL=0.454, 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 AjpgfYfNiWVy; Tue, 2 Jul 2013 18:26:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8516911E8123; Tue, 2 Jul 2013 18:26:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUP77354; Wed, 03 Jul 2013 01:26:34 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 3 Jul 2013 02:25:33 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 3 Jul 2013 02:26:32 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.134]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Wed, 3 Jul 2013 09:26:25 +0800 From: Xuxiaohu To: "Rajiv Asati (rajiva)" Subject: re: [nvo3] Why not use L3VPN for data center interconnect?//re: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Topic: [nvo3] Why not use L3VPN for data center interconnect?//re: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Index: AQHOdzTowX/4NCfwg0ShThEmhq9GHZlSJ3UQ Date: Wed, 3 Jul 2013 01:26:25 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CB5F7@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CAD74@NKGEML512-MBS.china.huawei.com> <6463_1372684423_51D18087_6463_1266_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D074D1A7D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CB31D@NKGEML512-MBS.china.huawei.com> <20ECF67871905846A80F77F8F4A2757210276FCC@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" , L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 01:26:41 -0000 SGkgUmFqaXYNCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogUmFqaXYg QXNhdGkgKHJhaml2YSkgW21haWx0bzpyYWppdmFAY2lzY28uY29tXQ0KPiDlj5HpgIHml7bpl7Q6 IDIwMTPlubQ35pyIMuaXpSAyMzowMA0KPiDmlLbku7bkuro6IFh1eGlhb2h1DQo+IOaKhOmAgTog bnZvM0BpZXRmLm9yZw0KPiDkuLvpopg6IFJFOiBbbnZvM10gV2h5IG5vdCB1c2UgTDNWUE4gZm9y IGRhdGEgY2VudGVyIGludGVyY29ubmVjdD8vL3JlOg0KPiBSZXF1ZXN0IGEgV0cgYWRvcHRpb24g cG9sbCBmb3IgZHJhZnQteHUtdmlydHVhbC1zdWJuZXQtMTANCj4gDQo+IEhpIFhpYW9odSwNCj4g DQo+IFdoaWNoIG5vdGlmaWNhdGlvbiBtZXNzYWdlIGRvIHlvdSBhbGx1ZGUgdG8gaW4gc2VjdGlv biAzLjU/ICBBbmQgaG93IHdvdWxkDQo+IHRoZSByb3V0ZXIgcmVjZWl2ZSBzdWNoIGEgbWVzc2Fn ZT8NCj4gDQo+IC8vDQo+ICAgIDMuNS4gQ0UgSG9zdCBNb2JpbGl0eQ0KPiANCj4gICAgRHVyaW5n IHRoZSBWTSBtaWdyYXRpb24gcHJvY2VzcywgdGhlIFBFIHJvdXRlciB0byB3aGljaCB0aGUgbW92 aW5nDQo+ICAgIFZNIGlzIG5vdyBhdHRhY2hlZCB3b3VsZCBjcmVhdGUgYSBob3N0IHJvdXRlIGZv ciB0aGF0IENFIGhvc3QgdXBvbg0KPiAgICByZWNlaXZpbmcgYSBub3RpZmljYXRpb24gbWVzc2Fn ZSBvZiBWTSBhdHRhY2htZW50IHdoaWxlIHRoZSBQRQ0KPiAgICByb3V0ZXIgdG8gd2hpY2ggdGhl IG1vdmluZyBWTSB3YXMgcHJldmlvdXNseSBhdHRhY2hlZCB3b3VsZCB3aXRoZHJhdw0KPiAvLw0K DQpHcmF0dWl0b3VzIEFSUC9ORCBtZXNzYWdlIGlzIG9uZSBleGFtcGxlLiANCg0KQmVzdCByZWdh cmRzLA0KWGlhb2h1DQoNCj4gQ2hlZXJzLA0KPiBSYWppdg0KPiANCj4gDQo+ID4gPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogbnZvMy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gPiA+IE9mIFh1eGlhb2h1 DQo+ID4gPiBTZW50OiBUdWVzZGF5LCBKdWx5IDAyLCAyMDEzIDI6NTIgQU0NCj4gPiA+IFRvOiBM M1ZQTg0KPiA+ID4gQ2M6IG52bzNAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFtudm8zXSBXaHkg bm90IHVzZSBMM1ZQTiBmb3IgZGF0YSBjZW50ZXIgaW50ZXJjb25uZWN0Py8vcmU6DQo+ID4gPiBS ZXF1ZXN0IGEgV0cgYWRvcHRpb24gcG9sbCBmb3IgZHJhZnQteHUtdmlydHVhbC1zdWJuZXQtMTAN Cj4gPiA+DQo+ID4gPiBIaSBhbGwsDQo+ID4gPg0KPiA+ID4gVGlsbCBub3csIGl0IHNlZW1zIHRo YXQgdG9vIG11Y2ggYXR0ZW50aW9uIGhhcyBiZWVuIHBhaWQgdG8gdGhlIHVzZSBvZg0KPiA+ID4g TDJWUE4gZm9yIGRhdGEgY2VudGVyIGludGVyY29ubmVjdC4gQWx0aG91Z2ggdGhlcmUgYXJlIHN0 aWxsIGEgZmV3DQo+ID4gPiBjbHVzdGVyaW5nIGFwcGxpY2F0aW9ucyB3aGljaCByZWx5IG9uIG5v bi1JUCBvciBub24tcm91dGFibGUgSVANCj4gPiA+IGNvbW11bmljYXRpb25zIChlLmcuLCBoZWFy dGJlYXQgbWVzc2FnZXMgYmV0d2VlbiBjbHVzdGVyIG5vZGVzKSwgbW9yZQ0KPiA+ID4gYW5kIG1v cmUgY2x1c3RlciB2ZW5kb3JzIGFyZSBvZmZlcmluZyBjbHVzdGVyaW5nIGFwcGxpY2F0aW9ucyBi YXNlZCBvbg0KPiA+ID4gTGF5ZXIgMyBpbnRlcmNvbm5lY3Rpb24uIEluIGFkZGl0aW9uLCBnZW9n cmFwaGljYWwgaGlnaC1hdmFpbGFiaWxpdHkNCj4gPiA+IGNsdXN0ZXJzIGlzIG5vdCBhIG11c3Qg aW4gbWFueSBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3QgY2FzZXMuDQo+ID4gPg0KPiA+ID4gQXMg TDNWUE4gaGFzIG1hbnkgZGlzdGluY3QgYWR2YW50YWdlcyBvdmVyIEwyVlBOIGZvciBkYXRhIGNl bnRlcg0KPiA+ID4gaW50ZXJjb25uZWN0IHN1Y2ggYXM6IHNjYWxpbmcgZm9yd2FyZGluZyB0YWJs ZXMgb2YgZGF0YSBjZW50ZXINCj4gPiA+IHN3aXRjaGVzLCBwYXRoIG9wdGltaXphdGlvbiwgdW5r bm93biB1bmljYXN0IGFuZCBBUlAgc3VwcHJlc3Npb24uLi4NCj4gPiA+IHdoeSBub3QgdHJ5IHRv IHVzZSB0aGUgcHJvdmVuIEwzVlBOIHRlY2hub2xvZ3kgZm9yIGRhdGEgY2VudGVyDQo+ID4gPiBp bnRlcmNvbm5lY3QgaW4gdGhlIHNjZW5hcmlvIHdoZXJlIHRoZSBsaW1pdGF0aW9ucyBhcyBtZW50 aW9uZWQgYWJvdmUNCj4gPiBkb24ndCBleGlzdD8NCj4gPiA+DQo+ID4gPiBCZXN0IHJlZ2FyZHMs DQo+ID4gPiBYaWFvaHUNCj4gPiA+DQo+ID4gPiA+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g PiA+ID4g5Y+R5Lu25Lq6OiB0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbQ0KPiBbbWFpbHRvOnRob21h cy5tb3JpbkBvcmFuZ2UuY29tXQ0KPiA+ID4gPiDlj5HpgIHml7bpl7Q6IDIwMTPlubQ35pyIMeaX pSAyMToxNA0KPiA+ID4gPiDmlLbku7bkuro6IFh1eGlhb2h1DQo+ID4gPiA+IOaKhOmAgTogbDN2 cG4tY2hhaXJzQHRvb2xzLmlldGYub3JnOyBtYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwtDQo+ID4g PiBsdWNlbnQuY29tOw0KPiA+ID4gPiBMM1ZQTg0KPiA+ID4gPiDkuLvpopg6IFJlOiBSZXF1ZXN0 IGEgV0cgYWRvcHRpb24gcG9sbCBmb3IgZHJhZnQteHUtdmlydHVhbC1zdWJuZXQtMTANCj4gPiA+ ID4NCj4gPiA+ID4gSGVsbG8gWHV4aWFvaHUsDQo+ID4gPiA+DQo+ID4gPiA+IEJlZm9yZSBldmVu dHVhbGx5IHN0YXJ0aW5nIGEgZGlzY3Vzc2lvbiBvbiB0aGUgYWRvcHRpb24gb24gdGhpcw0KPiA+ ID4gPiBkb2N1bWVudCwgd2UgY2hhaXJzIHdvdWxkIGxpa2UgdG8gc2VlIG1vcmUgZGlzY3Vzc2lv biBhbmQgaGF2ZSB0aGUNCj4gPiA+ID4gZmVlZGJhY2sgZnJvbSBtb3JlIHJlYWRlcnMgKGR1cmlu ZyB0aGUgMiBwcmV2aW91cyBtZWV0aW5ncywgb25seSA1DQo+ID4gPiA+IHRvDQo+ID4gPiAxMA0K PiA+ID4gPiBwZW9wbGUgcmFpc2VkIHRoZWlyIGhhbmQgd2hlbiB0aGUgcm9vbSB3YXMgcG9sbGVk IG9uIGhhdmluZyByZWFkIHRoZQ0KPiA+ID4gPiBkb2N1bWVudCkuDQo+ID4gPiA+DQo+ID4gPiA+ IFJlZ2FyZHMsDQo+ID4gPiA+DQo+ID4gPiA+IC1UaG9tYXMgYW5kIE1hcnRpbiwNCj4gPiA+ID4g bDN2cG4gY28tY2hhaXJzDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IDIwMTMtMDctMDEsIFh1 eGlhb2h1Og0KPiA+ID4gPiA+IEhpIFRob21hcyBhbmQgTWFydGluLA0KPiA+ID4gPiA+DQo+ID4g PiA+ID4gSSBoYXZlbid0IHJlY2VpdmVkIGFueSByZXNwb25zZSBmcm9tIGFueSBvZiB5b3UuIEhl bmNlIEkgcmVzZW5kIGl0Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQmVzdCByZWdhcmRzLA0KPiA+ ID4gPiA+IFhpYW9odQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0t LS0NCj4gPiA+ID4gPj4g5Y+R5Lu25Lq6OiBYdXhpYW9odQ0KPiA+ID4gPiA+PiDlj5HpgIHml7bp l7Q6IDIwMTPlubQ25pyIMjDml6UgMTU6MDcNCj4gPiA+ID4gPj4g5pS25Lu25Lq6OiAnbDN2cG4t Y2hhaXJzQHRvb2xzLmlldGYub3JnJzsgJ3Rob21hcy5tb3JpbkBvcmFuZ2UuY29tJzsNCj4gPiA+ ID4gPj4gJ21hcnRpbi52aWdvdXJldXhAYWxjYXRlbC1sdWNlbnQuY29tJw0KPiA+ID4gPiA+PiDm ioTpgIE6IEwzVlBODQo+ID4gPiA+ID4+IOS4u+mimDogUmVxdWVzdCBhIFdHIGFkb3B0aW9uIHBv bGwgZm9yIGRyYWZ0LXh1LXZpcnR1YWwtc3VibmV0LTEwDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+ IEhpIFdHIGNvLWNoYWlycywNCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4gQXMgbWVudGlvbmVkIGJl Zm9yZSwgdGhpcyBkcmFmdA0KPiA+ID4gPiA+PiAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQteHUtdmlydHVhbC1zdWJuZXQtMTApIGRlc2NyaWJlcw0KPiA+ID4gaG93IHRvDQo+ID4g PiA+IHJldXNlDQo+ID4gPiA+ID4+IHRoZSBwcm92ZW4gTDNWUE4gdGVjaG5vbG9neSB0byByZWFs aXplIHN1Ym5ldCBleHRlbnNpb24gZm9yIGRhdGENCj4gPiA+IGNlbnRlcg0KPiA+ID4gPiA+PiBp bnRlcmNvbm5lY3QsIHdpdGggdGhlIGFpZCBvZiBtYW55IGNvbmNyZXRlIGV4cGVyaW1lbnRzIGFu ZA0KPiA+ID4gdmVyaWZpY2F0aW9ucy4NCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4gV2UgY28tYXV0 aG9ycyBiZWxpZXZlIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBkcmFmdA0KPiA+ ID4gPiA+PiB3b3VsZA0KPiA+ID4gYmUNCj4gPiA+ID4gdmFsdWFibGUNCj4gPiA+ID4gPj4gZm9y IGNsb3VkIHNlcnZpY2UgcHJvdmlkZXJzIHRvIGV2YWx1YXRlIHRoZSBmZWFzaWJpbGl0eSBvZg0K PiA+ID4gPiA+PiBhZG9wdGluZw0KPiA+ID4gdGhlIHByb3Zlbg0KPiA+ID4gPiA+PiBMM1ZQTiB0 ZWNobm9sb2d5IGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3Rpb24gKGJ5IHRoZSB3YXksDQo+ ID4gPiA+ID4+IHNvbWUNCj4gPiA+IHBlb3BsZQ0KPiA+ID4gPiA+PiBoYWQgc2hvd24gdGhlaXIg aW50ZXJlc3RzIG9uIHRoZSBzY2hlbWUgZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQNCj4gPiA+IHdo ZW4NCj4gPiA+ID4gdmlzaXRpbmcNCj4gPiA+ID4gPj4gb3VyIGltcGxlbWVudGF0aW9uIGRlbW8g b2YgdGhpcyBzY2hlbWUgYXQgdGhlIEJpdHMtTi1CaXRlcyBldmVudA0KPiA+ID4gPiA+PiBvZg0K PiA+ID4gPiBJRVRGODYpLg0KPiA+ID4gPiA+PiBIZW5jZSB3ZSB3b3VsZCBsaWtlIGNvLWNoYWly cyB0byBzdGFydCBhIFdHIGFkb3B0aW9uIHBvbGwgZm9yDQo+ID4gPiA+ID4+IHRoaXMNCj4gPiA+ IGRyYWZ0Lg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiBCZXN0IHJlZ2FyZHMsDQo+ID4gPiA+ID4+ IFhpYW9odSAob24gYmVoYWxmIG9mIGFsbCBjby1hdXRob3JzKQ0KPiA+ID4gPg0KPiA+ID4gPg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPg0KPiA+ID4gPiBDZSBtZXNzYWdlIGV0IHNlcyBw aWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCj4gPiA+ID4g Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0 cmUNCj4gPiA+ID4gZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleg0KPiA+ID4gcmVjdSBjZQ0KPiA+ID4gPiBtZXNzYWdlIHBhciBlcnJl dXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlDQo+ID4gPiA+IGRl dHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcw0KPiA+ID4gbWVzc2FnZXMN Cj4gPiA+ID4gZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBP cmFuZ2UgZGVjbGluZSB0b3V0ZQ0KPiA+ID4gPiByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl IGEgZXRlIGFsdGVyZSwNCj4gPiA+IGRlZm9ybWUgb3UNCj4gPiA+ID4gZmFsc2lmaWUuIE1lcmNp Lg0KPiA+ID4gPg0KPiA+ID4gPiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgb3INCj4gPiA+IHByaXZpbGVnZWQNCj4gPiA+ID4gaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlDQo+ ID4gPiA+IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u DQo+ID4gPiA+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlcg0KPiA+ID4gPiBhbmQNCj4gPiA+IGRlbGV0ZSB0aGlzDQo+ID4g PiA+IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4gPiA+ID4gQXMgZW1haWxzIG1heSBi ZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdA0KPiA+ID4g PiBoYXZlDQo+ID4gPiBiZWVuDQo+ID4gPiA+IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmll ZC4NCj4gPiA+ID4gVGhhbmsgeW91Lg0KPiA+ID4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBudm8zIG1haWxpbmcgbGlzdA0KPiA+ ID4gbnZvM0BpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9udm8zDQo= From rajiva@cisco.com Tue Jul 2 22:24:29 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BC721F91C4; Tue, 2 Jul 2013 22:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] 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 5O7MT7JE-oqW; Tue, 2 Jul 2013 22:24:24 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 61E3921F91BF; Tue, 2 Jul 2013 22:24:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14370; q=dns/txt; s=iport; t=1372829064; x=1374038664; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CwZ1rs7Z0Oy5f0T8DiI5MR7/yj2HWFHt64e+z9/DLLs=; b=bC1LWFK8Hp8D20dMy+TFeVd0nVDIyWN//0aP9UPNPwHxw32kIPy9zltD a2TqCoChtpXDgyDn5UIIk8mvhIEAyZqIjRmIllbXlHp2MdXceejidO23B eD5X0a0pWUdpHlPZ+PdGMZKDFZb3dYn694DtQz0aSCxRKFDBBhvOYPSJz E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAAy101GtJXG//2dsb2JhbABZgwkySYMHvRUNdhZ0giMBAQEDAQEBASAROgsMBAIBBgIRBAEBAwIGGQQDAgICJQsUAQgIAgQBCQQFCBOHbgYMjnCbP5EbgSaMfYERMQcGgkszaQOTd4R8kByBWIE5gXE3 X-IronPort-AV: E=Sophos;i="4.87,985,1363132800"; d="scan'208";a="230371646" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 03 Jul 2013 05:24:23 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r635ONim019886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Jul 2013 05:24:23 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.251]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 3 Jul 2013 00:24:22 -0500 From: "Rajiv Asati (rajiva)" To: Xuxiaohu , "Eric Osborne (eosborne)" , L3VPN Subject: RE: [nvo3] Why not use L3VPN for data center interconnect?//re: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Topic: [nvo3] Why not use L3VPN for data center interconnect?//re: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Index: AQHOdyD0POmhTAULWE+RkaspEKqEdJlSedyA///x0SA= Date: Wed, 3 Jul 2013 05:24:22 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CAD74@NKGEML512-MBS.china.huawei.com> <6463_1372684423_51D18087_6463_1266_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D074D1A7D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CB31D@NKGEML512-MBS.china.huawei.com> <20ECF67871905846A80F77F8F4A2757210276FCC@xmb-rcd-x09.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CB5BF@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CB5BF@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.237.177] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "nvo3@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 05:24:29 -0000 PiA+IFdoYXQgaGFwcGVucyBpZiBIb3N0IEEgd2FudHMgdG8gcmVhY2ggSG9zdCBDLCBob21lZCBv ZmYgb2YgUEUtMywgYnV0DQo+ID4gUEUtMyBkb2VzIG5vdCBrbm93IGFib3V0IEhvc3QgQyBiZWNh dXNlIGl0J3MgbmV2ZXIgcGFydGljaXBhdGVkIGluDQo+ID4gQVJQPyAgRG8gSSBuZWVkIHRvIHJl bGF5IHRoZSBBUlAgZnJvbSBQRS0zIHRvIHRoZSBvdGhlciBQRXMgZm9yIHRoZSBWUE4/DQoNCkkg d291bGQgc2F5IC0gTm8sIHNpbmNlIHRoYXQgd291bGQgZXF1YXRlIHRvIGZsb29kaW5nIGxheWVy IDIgZnJhbWVzIGluIGFuIEwzVlBOIGVudmlyb25tZW50Lg0KDQpUaGUgdHJhZmZpYyB0byBhbiB1 bmtub3duIGhvc3Qgc2hvdWxkIGJlIGV2ZW50dWFsbHkgZHJvcHBlZCAoY2xvc2VyIHRvIHRoZSBz b3VyY2UgcG9pbnQpIGluIGFueSBMMyBlbnZpcm9ubWVudCwgSU1PLg0KDQpDaGVlcnMsDQpSYWpp dg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbDN2cG4tYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmwzdnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBP ZiBYdXhpYW9odQ0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDAyLCAyMDEzIDk6MTEgUE0NCj4gVG86 IEVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpOyBMM1ZQTg0KPiBDYzogbnZvM0BpZXRmLm9yZw0KPiBT dWJqZWN0OiByZTogW252bzNdIFdoeSBub3QgdXNlIEwzVlBOIGZvciBkYXRhIGNlbnRlciBpbnRl cmNvbm5lY3Q/Ly9yZToNCj4gUmVxdWVzdCBhIFdHIGFkb3B0aW9uIHBvbGwgZm9yIGRyYWZ0LXh1 LXZpcnR1YWwtc3VibmV0LTEwDQo+IA0KPiBIaSBFcmljLA0KPiANCj4gVGhhbmtzIGZvciB5b3Vy IGNvbW1lbnRzLiBQbGVhc2Ugc2VlIG15IHJlcGx5IGlubGluZS4NCj4gDQo+ID4gLS0tLS3pgq7k u7bljp/ku7YtLS0tLQ0KPiA+IOWPkeS7tuS6ujogbnZvMy1ib3VuY2VzQGlldGYub3JnIFttYWls dG86bnZvMy1ib3VuY2VzQGlldGYub3JnXSDku6PooaggRXJpYw0KPiA+IE9zYm9ybmUgKGVvc2Jv cm5lKQ0KPiA+IOWPkemAgeaXtumXtDogMjAxM+W5tDfmnIgy5pelIDIwOjA3DQo+ID4g5pS25Lu2 5Lq6OiBYdXhpYW9odTsgTDNWUE4NCj4gPiDmioTpgIE6IG52bzNAaWV0Zi5vcmcNCj4gPiDkuLvp opg6IFJlOiBbbnZvM10gV2h5IG5vdCB1c2UgTDNWUE4gZm9yIGRhdGEgY2VudGVyIGludGVyY29u bmVjdD8vL3JlOg0KPiA+IFJlcXVlc3QgYSBXRyBhZG9wdGlvbiBwb2xsIGZvciBkcmFmdC14dS12 aXJ0dWFsLXN1Ym5ldC0xMA0KPiA+DQo+ID4gSGkgWGlhb2h1LQ0KPiA+DQo+ID4gICBMZXQgbWUg Zmlyc3Qgc2F5IHRoYXQgSSBhZ3JlZSB0aGF0IEwzIGlzIHRoZSB3YXkgdGhpbmdzIHNob3VsZCBi ZQ0KPiA+IGJ1aWx0LiAgQnV0DQo+IA0KPiBUaGF0J3MgZ3JlYXQuDQo+IA0KPiA+IEknbSBub3Qg c3VyZSB0aGF0IHlvdXIgZHJhZnQgYWRkcyBtdWNoIHRvIGV4aXN0aW5nIG1ldGhvZHMsIGFuZCBp dA0KPiA+IHNlZW1zIHRvIG1ha2UgYSBudW1iZXIgb2YgYXNzdW1wdGlvbnMuDQo+ID4NCj4gPiAg ICAiUEUgcm91dGVycyAoaS5lLiwNCj4gPiAgICBQRS0xIGFuZCBQRS0yKSB3aGljaCBhcmUgdXNl ZCBmb3IgaW50ZXJjb25uZWN0aW5nIHRoZXNlIHR3byBkYXRhDQo+ID4gICAgY2VudGVycyBjcmVh dGUgaG9zdCByb3V0ZXMgZm9yIHRoZWlyIGxvY2FsIENFIGhvc3RzIHJlc3BlY3RpdmVseSBhbmQN Cj4gPiAgICB0aGVuIGFkdmVydGlzZSB0aGVtIHZpYSBMM1ZQTiBzaWduYWxpbmcuLi4uIEluIGZh Y3QsIHN1Y2ggc3VibmV0IGlzIGENCj4gdmlydHVhbA0KPiA+ICAgIHN1Ym5ldCB3aGljaCBpcyBl bXVsYXRlZCBieSB1c2luZyBob3N0IHJvdXRlcy4iDQo+ID4NCj4gPg0KPiA+IFNvIGlmIEkgaGF2 ZSBhIC8yNCBJIHdpbGwgZW5kIHVwIHdpdGggKHVwIHRvKSAyNTMgaG9zdCBhZGRyZXNzZXMgaW4g dGhlDQo+IG5ldHdvcms/DQo+IA0KPiBZZXMuDQo+IA0KPiA+IEhvdyBkb2VzIGEgUEUga25vdyB3 aGljaCBob3N0cyBleGlzdD8gIERvZXMgaXQgd2FpdCB1bnRpbCBpdCBzZWVzDQo+ID4gbG9jYWwg QVJQIGluIG9yZGVyIHRvIGRldGVybWluZSB0aGF0IHRoZXJlIGlzIGEgdmFsaWQgLzMyPw0KPiAN Cj4gQVJQIGlzIGp1c3Qgb25lIHBvc3NpYmxlIGFwcHJvYWNoIGZvciBDRSBob3N0IGRpc2NvdmVy eS4gWW91IGNhbiBhbHNvIHVzZQ0KPiBvdGhlciBhcHByb2FjaGVzIChlLmcuLCBhbiBvcmNoZXN0 cmF0aW9uIHN5c3RlbSkgdG8gZmlsbCB0aGlzIGdvYWwuDQo+IA0KPiA+IFdoYXQgaGFwcGVucyBp ZiBIb3N0IEEgd2FudHMgdG8gcmVhY2ggSG9zdCBDLCBob21lZCBvZmYgb2YgUEUtMywgYnV0DQo+ ID4gUEUtMyBkb2VzIG5vdCBrbm93IGFib3V0IEhvc3QgQyBiZWNhdXNlIGl0J3MgbmV2ZXIgcGFy dGljaXBhdGVkIGluDQo+ID4gQVJQPyAgRG8gSSBuZWVkIHRvIHJlbGF5IHRoZSBBUlAgZnJvbSBQ RS0zIHRvIHRoZSBvdGhlciBQRXMgZm9yIHRoZSBWUE4/DQo+IA0KPiBUaGUgYmFzaWMgYXNzdW1w dGlvbiBvZiB0aGlzIGRyYWZ0IGlzIHRoYXQgbG9jYWwgUEUgcm91dGVycyBjb3VsZCB0aW1lbHkN Cj4gZGlzY292ZXIgdGhlaXIgb3duIGxvY2FsIENFIGhvc3RzIHRocm91Z2ggYSBnaXZlbiBhcHBy b2FjaC4gSG93ZXZlciwgdGhlDQo+IGFwcHJvYWNoIHlvdSBwcm9wb3NlZCBtYXkgYmUgd29ydGh3 aGlsZSB0byBiZSBjb25zaWRlcmVkIGluIHRoaXMgZHJhZnQuDQo+IA0KPiA+IFdoYXQgc2NhbGUg YmVuZWZpdHMgYXJlIHRoZXJlIGlmIEkgaGF2ZSB0byBhZHZlcnRpc2UgYWxsIHRoZSBob3N0DQo+ ID4gcm91dGVzIG9uIG15IGxvY2FsIHBvcnRpb24gb2YgdGhlIHN1Ym5ldD8gIFNwZWNpZmljYWxs eSwgY2FuIHlvdQ0KPiA+IGNvbXBhcmUgdGhlIHNjYWxlIGJlbmVmaXRzIG9mIGFkdmVydGlzaW5n IGEgYnVuY2ggb2YgLzMycyB0bywgc2F5LA0KPiA+IEVWUE4sIHdoZXJlIE1BQyBhZGRyZXNzZXMg YXJlIGJhc2ljYWxseQ0KPiA+IC80OCBob3N0IHJvdXRlcz8NCj4gDQo+IEFsbW9zdCB0aGUgc2Ft ZSBmcm9tIHRoZSBmb3J3YXJkaW5nIHRhYmxlIHNpemUgcGVyc3BlY3RpdmUuIEFuZCBib3RoIGNh bg0KPiBzdXBwcmVzcyB0aGUgdW5rbm93biB1bmNhc3QgZmxvb2RpbmcuIEhvd2V2ZXIsIGZyb20g dGhlIG1hdHVyaXR5IGRlZ3JlZQ0KPiBvZiB0ZWNobm9sb2d5IGFuZCBwcm9kdWN0IGFuZCB0aGUg b3BlcmF0aW9uIGV4cGVyaWVuY2UgcGVyc3BlY3RpdmVzLA0KPiBMM1ZQTiBpcyBhYnNvbHV0ZWx5 IGEgYmV0dGVyIGNob2ljZSwgSU1ITy4NCj4gDQo+ID4gSW4gc2VjdGlvbiAzLjYuMToNCj4gPg0K PiA+IC0tLQ0KPiA+IHRoZSBpbmdyZXNzIFBFIHJvdXRlciB3aWxsIGZvcndhcmQgdGhlIHBhY2tl dCB0byB0aGUNCj4gPiAgICAgICBSUiBhY2NvcmRpbmcgdG8gb25lIG9mIHRoZSBWUCByb3V0ZXMg bGVhcm50IGZyb20gdGhlIFJSLCB3aGljaCBpbg0KPiA+ICAgICAgIHR1cm4gZm9yd2FyZHMgdGhl IHBhY2tldCB0byB0aGUgcmVsZXZhbnQgZWdyZXNzIFBFIHJvdXRlcg0KPiA+ICAgICAgIGFjY29y ZGluZyB0byB0aGUgaG9zdCByb3V0ZSBsZWFybnQgZnJvbSB0aGF0IGVncmVzcyBQRSByb3V0ZXIu DQo+ID4gLS0tDQo+ID4NCj4gPiBUaGlzIG1ha2VzIG1lIG5lcnZvdXMsIGFzIHlvdSd2ZSBub3cg bWFkZSBhIFJvdXRlIFJlZmxlY3RvciAob2Z0ZW4gYQ0KPiA+IGJveCB3aXRoIGxvdHMgb2YgQ1BV IGFuZCBtZW1vcnkgYnV0IG5vdCBuZWNlc3NhcmlseSBtdWNoIGZvcndhcmRpbmcNCj4gPiB0aHJv dWdocHV0KSBpbnRvIGJhc2ljYWxseSBhIEJyb2FkY2FzdC9Vbmtub3duIE11bHRpY2FzdCBzZXJ2 ZXIuDQo+IA0KPiBBcyBtZW50aW9uZWQganVzdCBhZnRlciB0aGUgdGV4dCB5b3UgcXVvdGVkLA0K PiANCj4gICAgICAiLi4uIE5vdGUgdGhhdCBpbiB0aGUgY2FzZSB3aGVyZSB0aGUgUlIgaXMNCj4g ICAgICAgbm90IGF2YWlsYWJsZSBmb3IgdHJhbnNmZXJyaW5nIEwzVlBOIHRyYWZmaWMgYmV0d2Vl biBQRSByb3V0ZXJzDQo+ICAgICAgIGZvciBzb21lIHJlYXNvbiAoZS5nLiwgdGhlIFJSIGlzIGlt cGxlbWVudGVkIG9uIGEgc2VydmVyLCByYXRoZXINCj4gICAgICAgdGhhbiBhIHJvdXRlciksIHRo ZSBBUFIgZnVuY3Rpb24gY291bGQgYWN0dWFsbHkgYmUgcGVyZm9ybWVkIGJ5IGENCj4gICAgICAg Z2l2ZW4gUEUgcm91dGVyIG90aGVyIHRoYW4gdGhlIFJSIGFzIGxvbmcgYXMgdGhhdCBQRSByb3V0 ZXIgaGFzDQo+ICAgICAgIGluc3RhbGxlZCBhbGwgaG9zdCByb3V0ZXMgYmVsb25naW5nIHRvIHRo ZSB2aXJ0dWFsIHN1Ym5ldCBpbnRvIGl0cw0KPiAgICAgICBGSUIuIg0KPiANCj4gPiBUaGUgd2hv bGUgb2YgU2VjdGlvbiAzLjYgZmVlbHMgYSBsaXR0bGUgbGlrZSBMSVNQIG9yIE5IUlAgb3INCj4g PiBzb21ldGhpbmcuICBJZiB0aGlzIGlzIHJlYWxseSB3aGF0IHlvdSdyZSBhZnRlciB5b3UgbWF5 IHdhbnQgdG8gbG9vaw0KPiA+IGF0IGhvdyB0aGV5IGFwcHJvYWNoZWQgdGhpcyBwcm9ibGVtIGFu ZCBzaG93IHdoYXQncyBkaWZmZXJlbnQgYWJvdXQNCj4geW91ciBzb2x1dGlvbi4NCj4gDQo+IFlv dXIgb2JzZXJ2YXRpb24gaXMgY29ycmVjdC4gVG8gc29tZSBleHRlbnQsIExJU1AgY2FuIGJlIGxv b2tlZCBhcyBhbm90aGVyDQo+IHR5cGUgb2YgTDNWUE4gYXBwcm9hY2guIEZ1cnRoZXJtb3JlLCBM SVNQLW1vYmlsaXR5IGlzIGFub3RoZXIgdHlwZSBvZiBob3N0DQo+IHJvdXRlIGJhc2VkIHN1Ym5l dCBleHRlbnNpb24gYXBwcm9hY2gganVzdCBsaWtlIHRoZSBvbmUgZGVmaW5lZCBpbiB0aGlzDQo+ IGRyYWZ0LiBJdCdzIHVwIHRvIHRoZSBjbG91ZCBwcm92aWRlcnMgdG8gbWFrZSBhIGNob2ljZSBi ZXR3ZWVuIEwzVlBOIGFuZA0KPiBMSVNQLiBCVFcsIGlmIHlvdSB3ZXJlIGEgY2xvdWQgcHJvdmlk ZXIsIHdoaWNoIG9uZSB3b3VsZCB5b3UgY2hvb3NlIGluDQo+IHByYWN0aWNlPw0KPiANCj4gQmVz dCByZWdhcmRzLA0KPiBYaWFvaHUNCj4gDQo+ID4gZXJpYw0KPiA+DQo+ID4NCj4gPiA+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBudm8zLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZg0KPiA+ID4gT2YgWHV4 aWFvaHUNCj4gPiA+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMDIsIDIwMTMgMjo1MiBBTQ0KPiA+ID4g VG86IEwzVlBODQo+ID4gPiBDYzogbnZvM0BpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogW252bzNd IFdoeSBub3QgdXNlIEwzVlBOIGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3Q/Ly9yZToNCj4g PiA+IFJlcXVlc3QgYSBXRyBhZG9wdGlvbiBwb2xsIGZvciBkcmFmdC14dS12aXJ0dWFsLXN1Ym5l dC0xMA0KPiA+ID4NCj4gPiA+IEhpIGFsbCwNCj4gPiA+DQo+ID4gPiBUaWxsIG5vdywgaXQgc2Vl bXMgdGhhdCB0b28gbXVjaCBhdHRlbnRpb24gaGFzIGJlZW4gcGFpZCB0byB0aGUgdXNlDQo+ID4g PiBvZiBMMlZQTiBmb3IgZGF0YSBjZW50ZXIgaW50ZXJjb25uZWN0LiBBbHRob3VnaCB0aGVyZSBh cmUgc3RpbGwgYQ0KPiA+ID4gZmV3IGNsdXN0ZXJpbmcgYXBwbGljYXRpb25zIHdoaWNoIHJlbHkg b24gbm9uLUlQIG9yIG5vbi1yb3V0YWJsZSBJUA0KPiA+ID4gY29tbXVuaWNhdGlvbnMgKGUuZy4s IGhlYXJ0YmVhdCBtZXNzYWdlcyBiZXR3ZWVuIGNsdXN0ZXIgbm9kZXMpLA0KPiA+ID4gbW9yZSBh bmQgbW9yZSBjbHVzdGVyIHZlbmRvcnMgYXJlIG9mZmVyaW5nIGNsdXN0ZXJpbmcgYXBwbGljYXRp b25zDQo+ID4gPiBiYXNlZCBvbiBMYXllciAzIGludGVyY29ubmVjdGlvbi4gSW4gYWRkaXRpb24s IGdlb2dyYXBoaWNhbA0KPiA+ID4gaGlnaC1hdmFpbGFiaWxpdHkgY2x1c3RlcnMgaXMgbm90IGEg bXVzdCBpbiBtYW55IGRhdGEgY2VudGVyIGludGVyY29ubmVjdA0KPiBjYXNlcy4NCj4gPiA+DQo+ ID4gPiBBcyBMM1ZQTiBoYXMgbWFueSBkaXN0aW5jdCBhZHZhbnRhZ2VzIG92ZXIgTDJWUE4gZm9y IGRhdGEgY2VudGVyDQo+ID4gPiBpbnRlcmNvbm5lY3Qgc3VjaCBhczogc2NhbGluZyBmb3J3YXJk aW5nIHRhYmxlcyBvZiBkYXRhIGNlbnRlcg0KPiA+ID4gc3dpdGNoZXMsIHBhdGggb3B0aW1pemF0 aW9uLCB1bmtub3duIHVuaWNhc3QgYW5kIEFSUCBzdXBwcmVzc2lvbi4uLg0KPiA+ID4gd2h5IG5v dCB0cnkgdG8gdXNlIHRoZSBwcm92ZW4gTDNWUE4gdGVjaG5vbG9neSBmb3IgZGF0YSBjZW50ZXIN Cj4gPiA+IGludGVyY29ubmVjdCBpbiB0aGUgc2NlbmFyaW8gd2hlcmUgdGhlIGxpbWl0YXRpb25z IGFzIG1lbnRpb25lZCBhYm92ZQ0KPiBkb24ndCBleGlzdD8NCj4gPiA+DQo+ID4gPiBCZXN0IHJl Z2FyZHMsDQo+ID4gPiBYaWFvaHUNCj4gPiA+DQo+ID4gPiA+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0t LS0NCj4gPiA+ID4g5Y+R5Lu25Lq6OiB0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbSBbbWFpbHRvOnRo b21hcy5tb3JpbkBvcmFuZ2UuY29tXQ0KPiA+ID4gPiDlj5HpgIHml7bpl7Q6IDIwMTPlubQ35pyI MeaXpSAyMToxNA0KPiA+ID4gPiDmlLbku7bkuro6IFh1eGlhb2h1DQo+ID4gPiA+IOaKhOmAgTog bDN2cG4tY2hhaXJzQHRvb2xzLmlldGYub3JnOyBtYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwtDQo+ ID4gPiBsdWNlbnQuY29tOw0KPiA+ID4gPiBMM1ZQTg0KPiA+ID4gPiDkuLvpopg6IFJlOiBSZXF1 ZXN0IGEgV0cgYWRvcHRpb24gcG9sbCBmb3IgZHJhZnQteHUtdmlydHVhbC1zdWJuZXQtMTANCj4g PiA+ID4NCj4gPiA+ID4gSGVsbG8gWHV4aWFvaHUsDQo+ID4gPiA+DQo+ID4gPiA+IEJlZm9yZSBl dmVudHVhbGx5IHN0YXJ0aW5nIGEgZGlzY3Vzc2lvbiBvbiB0aGUgYWRvcHRpb24gb24gdGhpcw0K PiA+ID4gPiBkb2N1bWVudCwgd2UgY2hhaXJzIHdvdWxkIGxpa2UgdG8gc2VlIG1vcmUgZGlzY3Vz c2lvbiBhbmQgaGF2ZSB0aGUNCj4gPiA+ID4gZmVlZGJhY2sgZnJvbSBtb3JlIHJlYWRlcnMgKGR1 cmluZyB0aGUgMiBwcmV2aW91cyBtZWV0aW5ncywgb25seSA1DQo+ID4gPiA+IHRvDQo+ID4gPiAx MA0KPiA+ID4gPiBwZW9wbGUgcmFpc2VkIHRoZWlyIGhhbmQgd2hlbiB0aGUgcm9vbSB3YXMgcG9s bGVkIG9uIGhhdmluZyByZWFkDQo+ID4gPiA+IHRoZSBkb2N1bWVudCkuDQo+ID4gPiA+DQo+ID4g PiA+IFJlZ2FyZHMsDQo+ID4gPiA+DQo+ID4gPiA+IC1UaG9tYXMgYW5kIE1hcnRpbiwNCj4gPiA+ ID4gbDN2cG4gY28tY2hhaXJzDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IDIwMTMtMDctMDEs IFh1eGlhb2h1Og0KPiA+ID4gPiA+IEhpIFRob21hcyBhbmQgTWFydGluLA0KPiA+ID4gPiA+DQo+ ID4gPiA+ID4gSSBoYXZlbid0IHJlY2VpdmVkIGFueSByZXNwb25zZSBmcm9tIGFueSBvZiB5b3Uu IEhlbmNlIEkgcmVzZW5kIGl0Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQmVzdCByZWdhcmRzLA0K PiA+ID4gPiA+IFhpYW9odQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4+IC0tLS0t6YKu5Lu25Y6f5Lu2 LS0tLS0NCj4gPiA+ID4gPj4g5Y+R5Lu25Lq6OiBYdXhpYW9odQ0KPiA+ID4gPiA+PiDlj5HpgIHm l7bpl7Q6IDIwMTPlubQ25pyIMjDml6UgMTU6MDcNCj4gPiA+ID4gPj4g5pS25Lu25Lq6OiAnbDN2 cG4tY2hhaXJzQHRvb2xzLmlldGYub3JnJzsgJ3Rob21hcy5tb3JpbkBvcmFuZ2UuY29tJzsNCj4g PiA+ID4gPj4gJ21hcnRpbi52aWdvdXJldXhAYWxjYXRlbC1sdWNlbnQuY29tJw0KPiA+ID4gPiA+ PiDmioTpgIE6IEwzVlBODQo+ID4gPiA+ID4+IOS4u+mimDogUmVxdWVzdCBhIFdHIGFkb3B0aW9u IHBvbGwgZm9yIGRyYWZ0LXh1LXZpcnR1YWwtc3VibmV0LTEwDQo+ID4gPiA+ID4+DQo+ID4gPiA+ ID4+IEhpIFdHIGNvLWNoYWlycywNCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4gQXMgbWVudGlvbmVk IGJlZm9yZSwgdGhpcyBkcmFmdA0KPiA+ID4gPiA+PiAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQteHUtdmlydHVhbC1zdWJuZXQtMTApDQo+ID4gPiA+ID4+IGRlc2NyaWJlcw0KPiA+ ID4gaG93IHRvDQo+ID4gPiA+IHJldXNlDQo+ID4gPiA+ID4+IHRoZSBwcm92ZW4gTDNWUE4gdGVj aG5vbG9neSB0byByZWFsaXplIHN1Ym5ldCBleHRlbnNpb24gZm9yDQo+ID4gPiA+ID4+IGRhdGEN Cj4gPiA+IGNlbnRlcg0KPiA+ID4gPiA+PiBpbnRlcmNvbm5lY3QsIHdpdGggdGhlIGFpZCBvZiBt YW55IGNvbmNyZXRlIGV4cGVyaW1lbnRzIGFuZA0KPiA+ID4gdmVyaWZpY2F0aW9ucy4NCj4gPiA+ ID4gPj4NCj4gPiA+ID4gPj4gV2UgY28tYXV0aG9ycyBiZWxpZXZlIHRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBkcmFmdA0KPiA+ID4gPiA+PiB3b3VsZA0KPiA+ID4gYmUNCj4gPiA+ ID4gdmFsdWFibGUNCj4gPiA+ID4gPj4gZm9yIGNsb3VkIHNlcnZpY2UgcHJvdmlkZXJzIHRvIGV2 YWx1YXRlIHRoZSBmZWFzaWJpbGl0eSBvZg0KPiA+ID4gPiA+PiBhZG9wdGluZw0KPiA+ID4gdGhl IHByb3Zlbg0KPiA+ID4gPiA+PiBMM1ZQTiB0ZWNobm9sb2d5IGZvciBkYXRhIGNlbnRlciBpbnRl cmNvbm5lY3Rpb24gKGJ5IHRoZSB3YXksDQo+ID4gPiA+ID4+IHNvbWUNCj4gPiA+IHBlb3BsZQ0K PiA+ID4gPiA+PiBoYWQgc2hvd24gdGhlaXIgaW50ZXJlc3RzIG9uIHRoZSBzY2hlbWUgZGVzY3Jp YmVkIGluIHRoaXMgZHJhZnQNCj4gPiA+IHdoZW4NCj4gPiA+ID4gdmlzaXRpbmcNCj4gPiA+ID4g Pj4gb3VyIGltcGxlbWVudGF0aW9uIGRlbW8gb2YgdGhpcyBzY2hlbWUgYXQgdGhlIEJpdHMtTi1C aXRlcw0KPiA+ID4gPiA+PiBldmVudCBvZg0KPiA+ID4gPiBJRVRGODYpLg0KPiA+ID4gPiA+PiBI ZW5jZSB3ZSB3b3VsZCBsaWtlIGNvLWNoYWlycyB0byBzdGFydCBhIFdHIGFkb3B0aW9uIHBvbGwg Zm9yDQo+ID4gPiA+ID4+IHRoaXMNCj4gPiA+IGRyYWZ0Lg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ PiBCZXN0IHJlZ2FyZHMsDQo+ID4gPiA+ID4+IFhpYW9odSAob24gYmVoYWxmIG9mIGFsbCBjby1h dXRob3JzKQ0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ DQo+ID4gPiA+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVu aXIgZGVzIGluZm9ybWF0aW9ucw0KPiA+ID4gPiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZQ0KPiA+ID4gPiBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6DQo+ID4gPiByZWN1 IGNlDQo+ID4gPiA+IG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBs J2V4cGVkaXRldXIgZXQgbGUNCj4gPiA+ID4gZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMg am9pbnRlcy4gTGVzDQo+ID4gPiBtZXNzYWdlcw0KPiA+ID4gPiBlbGVjdHJvbmlxdWVzIGV0YW50 IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lDQo+ID4gPiA+IHRvdXRl IHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLA0KPiA+ID4gZGVmb3Jt ZSBvdQ0KPiA+ID4gPiBmYWxzaWZpZS4gTWVyY2kuDQo+ID4gPiA+DQo+ID4gPiA+IFRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvcg0KPiA+ ID4gcHJpdmlsZWdlZA0KPiA+ID4gPiBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQg YnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUNCj4gPiA+ID4gZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4gPiA+ID4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+ID4gPiA+ IGFuZA0KPiA+ID4gZGVsZXRlIHRoaXMNCj4gPiA+ID4gbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLg0KPiA+ID4gPiBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh YmxlIGZvciBtZXNzYWdlcyB0aGF0DQo+ID4gPiA+IGhhdmUNCj4gPiA+IGJlZW4NCj4gPiA+ID4g bW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiA+ID4gPiBUaGFuayB5b3UuDQo+ID4g Pg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiA+IG52bzMgbWFpbGluZyBsaXN0DQo+ID4gPiBudm8zQGlldGYub3JnDQo+ID4gPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMNCj4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG52bzMgbWFpbGluZyBsaXN0 DQo+ID4gbnZvM0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbnZvMw0K From martin.vigoureux@alcatel-lucent.com Wed Jul 3 08:30:34 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84A311E81B2 for ; Wed, 3 Jul 2013 08:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 NQAkg+2-S101 for ; Wed, 3 Jul 2013 08:30:28 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4194511E81AA for ; Wed, 3 Jul 2013 08:30:23 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r63FUKPo007260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 3 Jul 2013 10:30:21 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r63FUJaU027052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 3 Jul 2013 17:30:20 +0200 Received: from [172.27.205.220] (135.239.27.39) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 3 Jul 2013 17:30:19 +0200 Message-ID: <51D4438A.30808@alcatel-lucent.com> Date: Wed, 3 Jul 2013 17:30:18 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Subject: Fwd: Draft submission deadlines change References: <20130703051701.22549.85585.idtracker@ietfa.amsl.com> In-Reply-To: <20130703051701.22549.85585.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130703051701.22549.85585.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.39] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 15:30:34 -0000 for your information. -m -------- Message original -------- Sujet: Draft submission deadlines change Date : Tue, 2 Jul 2013 22:17:01 -0700 De : IETF Chair Répondre à : Pour : IETF Announcement List Please note that for IETF 87, there is only one deadline for draft submission: Monday 15th July. Previously, there had been two different deadlines, one for -00 and another one for other versions. The IESG has decided to experiment with just one deadline for now to simplify the set of deadlines and enable easier submission of new drafts. While we realise that the change comes near the deadline, we hope that you find the extra time useful. But please do note that working group chairs will continue to make smart decisions about what topics are worthwhile for discussing in a session in the upcoming meeting, and will also set their agendas in a timely manner and create deadlines for their working groups that must be adhered to. The earlier new drafts are submitted, the more time there is to talk about them on the mailing lists and consider them for the session agendas. This is particularly important for BoFs. Jari Arkko for the IESG From zzhang@juniper.net Fri Jul 12 13:02:14 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E1221F9CEC for ; Fri, 12 Jul 2013 13:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.826 X-Spam-Level: X-Spam-Status: No, score=-0.826 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] 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 LOrb+UMHIQ1E for ; Fri, 12 Jul 2013 13:02:08 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 79D7121F9D80 for ; Fri, 12 Jul 2013 13:02:08 -0700 (PDT) Received: from mail171-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.22; Fri, 12 Jul 2013 20:02:08 +0000 Received: from mail171-tx2 (localhost [127.0.0.1]) by mail171-tx2-R.bigfish.com (Postfix) with ESMTP id D0F9C4C0484 for ; Fri, 12 Jul 2013 20:02:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz9371I936eI542Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2fh2a8h683h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail171-tx2: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=zzhang@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail171-tx2 (localhost.localdomain [127.0.0.1]) by mail171-tx2 (MessageSwitch) id 1373659325929284_29500; Fri, 12 Jul 2013 20:02:05 +0000 (UTC) Received: from TX2EHSMHS007.bigfish.com (unknown [10.9.14.231]) by mail171-tx2.bigfish.com (Postfix) with ESMTP id D03D9240076 for ; Fri, 12 Jul 2013 20:02:05 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.52) by TX2EHSMHS007.bigfish.com (10.9.99.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 12 Jul 2013 20:02:05 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 12 Jul 2013 13:01:53 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 12 Jul 2013 13:01:52 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.182) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 12 Jul 2013 13:05:30 -0700 Received: from mail215-ch1-R.bigfish.com (10.43.68.233) by CH1EHSOBE019.bigfish.com (10.43.70.76) with Microsoft SMTP Server id 14.1.225.22; Fri, 12 Jul 2013 20:01:51 +0000 Received: from mail215-ch1 (localhost [127.0.0.1]) by mail215-ch1-R.bigfish.com (Postfix) with ESMTP id AEC1C38076B for ; Fri, 12 Jul 2013 20:01:51 +0000 (UTC) Received: from mail215-ch1 (localhost.localdomain [127.0.0.1]) by mail215-ch1 (MessageSwitch) id 1373659309847230_18930; Fri, 12 Jul 2013 20:01:49 +0000 (UTC) Received: from CH1EHSMHS039.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.248]) by mail215-ch1.bigfish.com (Postfix) with ESMTP id C149D360202; Fri, 12 Jul 2013 20:01:49 +0000 (UTC) Received: from BY2PRD0510HT003.namprd05.prod.outlook.com (157.56.236.101) by CH1EHSMHS039.bigfish.com (10.43.69.248) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 12 Jul 2013 20:01:49 +0000 Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.99]) by BY2PRD0510HT003.namprd05.prod.outlook.com ([10.255.84.38]) with mapi id 14.16.0324.000; Fri, 12 Jul 2013 20:01:48 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "l3vpn@ietf.org" , "erosen@cisco.com" Subject: FW: New Version Notification for draft-zzhang-l3vpn-mvpn-global-table-mcast-00.txt Thread-Topic: New Version Notification for draft-zzhang-l3vpn-mvpn-global-table-mcast-00.txt Thread-Index: AQHOfznAHxXnU/m4SEqZ7Ac3A2viv5lhdd+A Date: Fri, 12 Jul 2013 20:01:48 +0000 Message-ID: <0BF0FCC78340F147BE76A6F5762318A83B7B6EB4@BY2PRD0510MB389.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "draft-zzhang-l3vpn-mvpn-global-table-mcast@tools.ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 20:02:14 -0000 SGksDQoNClRoaXMgaXMgYW4gdXBkYXRlIHRvIGRyYWZ0LXp6aGFuZy1tYm9uZWQtbXZwbi1nbG9i YWwtdGFibGUtbWNhc3QtMDAuDQoNCldlIGhhdmUgcmUtaG9tZWQgaXQgdG8gbDN2cG4sIGFuZCBo b3BlZnVsbHkgYWRkcmVzc2VkIG1vc3QgY29tbWVudHMgdGhhdCBFcmljIGhhZC4NCg0KWW91ciBy ZXZpZXcgYW5kIGNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC4NCg0KVGhhbmtzLg0KSmVmZnJleQ0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IEZyaWRheSwgSnVs eSAxMiwgMjAxMyAzOjU1IFBNDQpUbzogRGFudGUgSi5QYWNlbGxhOyBMZW5ueSBHaXVsaWFubzsg SmFzb24gU2NoaWxsZXI7IExlbm55IEdpdWxpYW5vOyBKZWZmcmV5IChaaGFvaHVpKSBaaGFuZw0K U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16emhhbmctbDN2cG4t bXZwbi1nbG9iYWwtdGFibGUtbWNhc3QtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LXp6aGFuZy1sM3Zwbi1tdnBuLWdsb2JhbC10YWJsZS1tY2FzdC0wMC50eHQNCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSmVmZnJleSBaaGFuZyBhbmQgcG9zdGVkIHRv IHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXp6aGFuZy1sM3Zwbi1t dnBuLWdsb2JhbC10YWJsZS1tY2FzdA0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgR2xvYmFsIFRh YmxlIE11bHRpY2FzdCB3aXRoIEJHUC1NVlBOIFByb2NlZHVyZXMNCkNyZWF0aW9uIGRhdGU6CSAy MDEzLTA3LTEyDQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdl czogMTQNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtenpoYW5nLWwzdnBuLW12cG4tZ2xvYmFsLXRhYmxlLW1jYXN0LTAwLnR4dA0KU3Rh dHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXp6aGFu Zy1sM3Zwbi1tdnBuLWdsb2JhbC10YWJsZS1tY2FzdA0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16emhhbmctbDN2cG4tbXZwbi1nbG9iYWwtdGFibGUt bWNhc3QtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgd2F5 IHRvIGltcGxlbWVudCBHbG9iYWwgVGFibGUgTXVsdGljYXN0LA0KICAgYWthIEludGVybmV0IE11 bHRpY2FzdCwgdXNpbmcgQkdQIGVuY29kaW5ncyBhbmQgcHJvY2VkdXJlcyBmb3IgTVZQTg0KICAg YXMgc3BlY2lmaWVkIGluIFtSRkM2NTE0XS4NCg0KICAgTm8gcHJvdG9jb2wgbW9kaWZpY2F0aW9u L2V4dGVuc2lvbiBpcyByZXF1aXJlZC4gIFRoaXMgaXMgcHVyZWx5IGZvcg0KICAgaW5mb3JtYXRp b25hbCBhbmQgY2xhcmlmeWluZyBwdXJwb3NlcyBvbmx5Lg0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQoNCg== From xuxiaohu@huawei.com Mon Jul 15 01:55:03 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1216121F9A18 for ; Mon, 15 Jul 2013 01:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 MoxH101OfLM2 for ; Mon, 15 Jul 2013 01:54:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E42AD21F9EF2 for ; Mon, 15 Jul 2013 01:51:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATL26200; Mon, 15 Jul 2013 08:44:49 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Jul 2013 09:43:56 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Jul 2013 09:44:42 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.175]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Mon, 15 Jul 2013 16:44:36 +0800 From: Xuxiaohu To: Martin Vigoureux , "l3vpn@ietf.org" , "thomas.morin@orange.com" , "daniel@olddog.co.uk" Subject: re: Slots requests for L3VPN Session - IETF 87 - Berlin Thread-Topic: Slots requests for L3VPN Session - IETF 87 - Berlin Thread-Index: AQHOdkIiWLgIoz+NB0OG1j0feiaudJllgO/A Date: Mon, 15 Jul 2013 08:44:36 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D551F@NKGEML512-MBS.china.huawei.com> References: <51D15386.4090303@alcatel-lucent.com> In-Reply-To: <51D15386.4090303@alcatel-lucent.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 08:55:03 -0000 SGkgY28tY2hhaXJzLA0KDQpJIHdvdWxkIGxpa2UgdG8gcmVxdWVzdCBhIDUtbWluIHNsb3QgZm9y IHByZXNlbnRpbmcgZHJhZnQteHUtbDN2cG4tdmlydHVhbC1zdWJuZXQtMDAudHh0IChodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1sM3Zwbi12aXJ0dWFsLXN1Ym5ldC0wMCkuDQoN CkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6 IGwzdnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsM3Zwbi1ib3VuY2VzQGlldGYub3JnXSC0 +rHtDQo+IE1hcnRpbiBWaWdvdXJldXgNCj4gt6LLzcqxvOQ6IDIwMTPE6jfUwjHI1SAxODowMg0K PiDK1bz+yMs6IGwzdnBuQGlldGYub3JnDQo+INb3zOI6IFNsb3RzIHJlcXVlc3RzIGZvciBMM1ZQ TiBTZXNzaW9uIC0gSUVURiA4NyAtIEJlcmxpbg0KPiANCj4gRGVhciBhbGwsDQo+IA0KPiB0aGUg TDNWUE4gV0cgd2lsbCBtZWV0IGluIEJlcmxpbi4gVGhlIHNlc3Npb24gKHN0aWxsIHN1YmplY3Qg dG8NCj4gY2hhbmdlKSBpcyBzY2hlZHVsZWQgb24gVHVlc2RheSAoMzB0aCksIE1vcm5pbmcgU2Vz c2lvbiBJLCAwOTowMC0xMTozMC4NCj4gDQo+IFRoaXMgaXMgdGh1cyBhIGNhbGwgZm9yIHByZXNl bnRhdGlvbiBzbG90cy4NCj4gDQo+IENvdWxkIHlvdSBwbGVhc2Ugc2VuZCB0byBUaG9tYXMgYW5k IEksIGNvcHlpbmcgRGFuLCB5b3VyIHJlcXVlc3RzLA0KPiBiZWZvcmUgdGhlIDE2dGggb2YgSnVs eSwgaW5kaWNhdGluZzoNCj4gZHJhZnQgbmFtZSwgc3BlYWtlciBhbmQgZGVzaXJlZCBkdXJhdGlv biAocHJlc2VudGF0aW9uICsgUSZBcykuDQo+IA0KPiBUaGFuayB5b3UuDQo+IA0KPiBNYXJ0aW4N Cj4gZm9yIHRoZSBMM1ZQTiBjby1jaGFpcnMNCg== From xuxiaohu@huawei.com Mon Jul 15 02:15:45 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B39821F864D; Mon, 15 Jul 2013 02:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.965 X-Spam-Level: X-Spam-Status: No, score=-3.965 tagged_above=-999 required=5 tests=[AWL=2.034, 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 VvL2zr43Hn6Z; Mon, 15 Jul 2013 02:15:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F24EE21F8FE5; Mon, 15 Jul 2013 02:15:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATL29658; Mon, 15 Jul 2013 09:15:27 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Jul 2013 10:14:37 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Jul 2013 10:15:23 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.175]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.01.0323.007; Mon, 15 Jul 2013 17:15:16 +0800 From: Xuxiaohu To: "Eric Osborne (eosborne)" , L3VPN Subject: re: [nvo3] Why not use L3VPN for data center interconnect?//re: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Topic: [nvo3] Why not use L3VPN for data center interconnect?//re: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Index: Ac5thMS2t8EppEHAQo6a5WxySmdDhQIdhP9gABRMqAAAIYUh4AAR3xWAABrQKhACbNST4A== Date: Mon, 15 Jul 2013 09:15:16 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D5553@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CAD74@NKGEML512-MBS.china.huawei.com> <6463_1372684423_51D18087_6463_1266_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D074D1A7D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CB31D@NKGEML512-MBS.china.huawei.com> <20ECF67871905846A80F77F8F4A2757210276FCC@xmb-rcd-x09.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CB5BF@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CB5BF@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 09:15:45 -0000 SGkgYWxsLA0KDQpGb3IgdGhlIGNvbnZlbmllbmNlIG9mIGZpbmRpbmcgdGhpcyBkcmFmdCwgSSBo YXZlIHN1Ym1pdHRlZCB0aGlzIGRyYWZ0IHRvIHRoZSBMM1ZQTiBXRyAoc2VlIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LWwzdnBuLXZpcnR1YWwtc3VibmV0LTAwKS4gTW9yZSBj b21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUuDQoNCkJ5IHRoZSB3YXksIGl0IHNl ZW1zIHRoYXQgdGhlcmUgaGFzIGJlZW4gYSBpbXBsZW1lbnRhdGlvbiBvZiB1c2luZyBCR1AvTDNW UE4gaG9zdCByb3V0ZXMgZm9yIHN1Ym5ldCBleHRlbnNpb24gYXMgcHJvcG9zZWQgaW4gdGhlIGFi b3ZlIGRyYWZ0IChzZWUNCmh0dHA6Ly93d3cubmV0d29ya2NvbXB1dGluZy5jb20vbmV4dC1nZW5l cmF0aW9uLWRhdGEtY2VudGVyL2NvbW1lbnRhcnkvY2lzY28tYWNjZWxlcmF0ZXMtc2RuLXN0cmF0 ZWd5LXdpdGgtZHluYS8yNDAxNTc3MDkjZGlzcXVzX3RocmVhZCkuDQoNCkJlc3QgcmVnYXJkcywN ClhpYW9odQ0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBudm8zLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqA0KPiBY dXhpYW9odQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTPlubQ35pyIM+aXpSA5OjExDQo+IOaUtuS7tuS6 ujogRXJpYyBPc2Jvcm5lIChlb3Nib3JuZSk7IEwzVlBODQo+IOaKhOmAgTogbnZvM0BpZXRmLm9y Zw0KPiDkuLvpopg6IFJlOiBbbnZvM10gV2h5IG5vdCB1c2UgTDNWUE4gZm9yIGRhdGEgY2VudGVy IGludGVyY29ubmVjdD8vL3JlOg0KPiBSZXF1ZXN0IGEgV0cgYWRvcHRpb24gcG9sbCBmb3IgZHJh ZnQteHUtdmlydHVhbC1zdWJuZXQtMTANCj4gDQo+IEhpIEVyaWMsDQo+IA0KPiBUaGFua3MgZm9y IHlvdXIgY29tbWVudHMuIFBsZWFzZSBzZWUgbXkgcmVwbHkgaW5saW5lLg0KPiANCj4gPiAtLS0t LemCruS7tuWOn+S7ti0tLS0tDQo+ID4g5Y+R5Lu25Lq6OiBudm8zLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBFcmljDQo+ID4gT3Nib3JuZSAo ZW9zYm9ybmUpDQo+ID4g5Y+R6YCB5pe26Ze0OiAyMDEz5bm0N+aciDLml6UgMjA6MDcNCj4gPiDm lLbku7bkuro6IFh1eGlhb2h1OyBMM1ZQTg0KPiA+IOaKhOmAgTogbnZvM0BpZXRmLm9yZw0KPiA+ IOS4u+mimDogUmU6IFtudm8zXSBXaHkgbm90IHVzZSBMM1ZQTiBmb3IgZGF0YSBjZW50ZXIgaW50 ZXJjb25uZWN0Py8vcmU6DQo+ID4gUmVxdWVzdCBhIFdHIGFkb3B0aW9uIHBvbGwgZm9yIGRyYWZ0 LXh1LXZpcnR1YWwtc3VibmV0LTEwDQo+ID4NCj4gPiBIaSBYaWFvaHUtDQo+ID4NCj4gPiAgIExl dCBtZSBmaXJzdCBzYXkgdGhhdCBJIGFncmVlIHRoYXQgTDMgaXMgdGhlIHdheSB0aGluZ3Mgc2hv dWxkIGJlIGJ1aWx0LiAgQnV0DQo+IA0KPiBUaGF0J3MgZ3JlYXQuDQo+IA0KPiA+IEknbSBub3Qg c3VyZSB0aGF0IHlvdXIgZHJhZnQgYWRkcyBtdWNoIHRvIGV4aXN0aW5nIG1ldGhvZHMsIGFuZCBp dCBzZWVtcyB0bw0KPiA+IG1ha2UgYSBudW1iZXIgb2YgYXNzdW1wdGlvbnMuDQo+ID4NCj4gPiAg ICAiUEUgcm91dGVycyAoaS5lLiwNCj4gPiAgICBQRS0xIGFuZCBQRS0yKSB3aGljaCBhcmUgdXNl ZCBmb3IgaW50ZXJjb25uZWN0aW5nIHRoZXNlIHR3byBkYXRhDQo+ID4gICAgY2VudGVycyBjcmVh dGUgaG9zdCByb3V0ZXMgZm9yIHRoZWlyIGxvY2FsIENFIGhvc3RzIHJlc3BlY3RpdmVseSBhbmQN Cj4gPiAgICB0aGVuIGFkdmVydGlzZSB0aGVtIHZpYSBMM1ZQTiBzaWduYWxpbmcuLi4uIEluIGZh Y3QsIHN1Y2ggc3VibmV0IGlzIGENCj4gdmlydHVhbA0KPiA+ICAgIHN1Ym5ldCB3aGljaCBpcyBl bXVsYXRlZCBieSB1c2luZyBob3N0IHJvdXRlcy4iDQo+ID4NCj4gPg0KPiA+IFNvIGlmIEkgaGF2 ZSBhIC8yNCBJIHdpbGwgZW5kIHVwIHdpdGggKHVwIHRvKSAyNTMgaG9zdCBhZGRyZXNzZXMgaW4g dGhlIG5ldHdvcms/DQo+IA0KPiBZZXMuDQo+IA0KPiA+IEhvdyBkb2VzIGEgUEUga25vdyB3aGlj aCBob3N0cyBleGlzdD8gIERvZXMgaXQgd2FpdCB1bnRpbCBpdCBzZWVzIGxvY2FsIEFSUA0KPiBp bg0KPiA+IG9yZGVyIHRvIGRldGVybWluZSB0aGF0IHRoZXJlIGlzIGEgdmFsaWQgLzMyPw0KPiAN Cj4gQVJQIGlzIGp1c3Qgb25lIHBvc3NpYmxlIGFwcHJvYWNoIGZvciBDRSBob3N0IGRpc2NvdmVy eS4gWW91IGNhbiBhbHNvIHVzZSBvdGhlcg0KPiBhcHByb2FjaGVzIChlLmcuLCBhbiBvcmNoZXN0 cmF0aW9uIHN5c3RlbSkgdG8gZmlsbCB0aGlzIGdvYWwuDQo+IA0KPiA+IFdoYXQgaGFwcGVucyBp ZiBIb3N0IEEgd2FudHMgdG8gcmVhY2ggSG9zdCBDLCBob21lZCBvZmYgb2YgUEUtMywgYnV0IFBF LTMNCj4gPiBkb2VzIG5vdCBrbm93IGFib3V0IEhvc3QgQyBiZWNhdXNlIGl0J3MgbmV2ZXIgcGFy dGljaXBhdGVkIGluIEFSUD8gIERvIEkNCj4gPiBuZWVkIHRvIHJlbGF5IHRoZSBBUlAgZnJvbSBQ RS0zIHRvIHRoZSBvdGhlciBQRXMgZm9yIHRoZSBWUE4/DQo+IA0KPiBUaGUgYmFzaWMgYXNzdW1w dGlvbiBvZiB0aGlzIGRyYWZ0IGlzIHRoYXQgbG9jYWwgUEUgcm91dGVycyBjb3VsZCB0aW1lbHkg ZGlzY292ZXINCj4gdGhlaXIgb3duIGxvY2FsIENFIGhvc3RzIHRocm91Z2ggYSBnaXZlbiBhcHBy b2FjaC4gSG93ZXZlciwgdGhlIGFwcHJvYWNoIHlvdQ0KPiBwcm9wb3NlZCBtYXkgYmUgd29ydGh3 aGlsZSB0byBiZSBjb25zaWRlcmVkIGluIHRoaXMgZHJhZnQuDQo+IA0KPiA+IFdoYXQgc2NhbGUg YmVuZWZpdHMgYXJlIHRoZXJlIGlmIEkgaGF2ZSB0byBhZHZlcnRpc2UgYWxsIHRoZSBob3N0IHJv dXRlcyBvbiBteQ0KPiA+IGxvY2FsIHBvcnRpb24gb2YgdGhlIHN1Ym5ldD8gIFNwZWNpZmljYWxs eSwgY2FuIHlvdSBjb21wYXJlIHRoZSBzY2FsZSBiZW5lZml0cw0KPiBvZg0KPiA+IGFkdmVydGlz aW5nIGEgYnVuY2ggb2YgLzMycyB0bywgc2F5LCBFVlBOLCB3aGVyZSBNQUMgYWRkcmVzc2VzIGFy ZSBiYXNpY2FsbHkNCj4gPiAvNDggaG9zdCByb3V0ZXM/DQo+IA0KPiBBbG1vc3QgdGhlIHNhbWUg ZnJvbSB0aGUgZm9yd2FyZGluZyB0YWJsZSBzaXplIHBlcnNwZWN0aXZlLiBBbmQgYm90aCBjYW4N Cj4gc3VwcHJlc3MgdGhlIHVua25vd24gdW5jYXN0IGZsb29kaW5nLiBIb3dldmVyLCBmcm9tIHRo ZSBtYXR1cml0eSBkZWdyZWUgb2YNCj4gdGVjaG5vbG9neSBhbmQgcHJvZHVjdCBhbmQgdGhlIG9w ZXJhdGlvbiBleHBlcmllbmNlIHBlcnNwZWN0aXZlcywgTDNWUE4gaXMNCj4gYWJzb2x1dGVseSBh IGJldHRlciBjaG9pY2UsIElNSE8uDQo+IA0KPiA+IEluIHNlY3Rpb24gMy42LjE6DQo+ID4NCj4g PiAtLS0NCj4gPiB0aGUgaW5ncmVzcyBQRSByb3V0ZXIgd2lsbCBmb3J3YXJkIHRoZSBwYWNrZXQg dG8gdGhlDQo+ID4gICAgICAgUlIgYWNjb3JkaW5nIHRvIG9uZSBvZiB0aGUgVlAgcm91dGVzIGxl YXJudCBmcm9tIHRoZSBSUiwgd2hpY2ggaW4NCj4gPiAgICAgICB0dXJuIGZvcndhcmRzIHRoZSBw YWNrZXQgdG8gdGhlIHJlbGV2YW50IGVncmVzcyBQRSByb3V0ZXINCj4gPiAgICAgICBhY2NvcmRp bmcgdG8gdGhlIGhvc3Qgcm91dGUgbGVhcm50IGZyb20gdGhhdCBlZ3Jlc3MgUEUgcm91dGVyLg0K PiA+IC0tLQ0KPiA+DQo+ID4gVGhpcyBtYWtlcyBtZSBuZXJ2b3VzLCBhcyB5b3UndmUgbm93IG1h ZGUgYSBSb3V0ZSBSZWZsZWN0b3IgKG9mdGVuIGEgYm94DQo+ID4gd2l0aCBsb3RzIG9mIENQVSBh bmQgbWVtb3J5IGJ1dCBub3QgbmVjZXNzYXJpbHkgbXVjaCBmb3J3YXJkaW5nDQo+IHRocm91Z2hw dXQpDQo+ID4gaW50byBiYXNpY2FsbHkgYSBCcm9hZGNhc3QvVW5rbm93biBNdWx0aWNhc3Qgc2Vy dmVyLg0KPiANCj4gQXMgbWVudGlvbmVkIGp1c3QgYWZ0ZXIgdGhlIHRleHQgeW91IHF1b3RlZCwN Cj4gDQo+ICAgICAgIi4uLiBOb3RlIHRoYXQgaW4gdGhlIGNhc2Ugd2hlcmUgdGhlIFJSIGlzDQo+ ICAgICAgIG5vdCBhdmFpbGFibGUgZm9yIHRyYW5zZmVycmluZyBMM1ZQTiB0cmFmZmljIGJldHdl ZW4gUEUgcm91dGVycw0KPiAgICAgICBmb3Igc29tZSByZWFzb24gKGUuZy4sIHRoZSBSUiBpcyBp bXBsZW1lbnRlZCBvbiBhIHNlcnZlciwgcmF0aGVyDQo+ICAgICAgIHRoYW4gYSByb3V0ZXIpLCB0 aGUgQVBSIGZ1bmN0aW9uIGNvdWxkIGFjdHVhbGx5IGJlIHBlcmZvcm1lZCBieSBhDQo+ICAgICAg IGdpdmVuIFBFIHJvdXRlciBvdGhlciB0aGFuIHRoZSBSUiBhcyBsb25nIGFzIHRoYXQgUEUgcm91 dGVyIGhhcw0KPiAgICAgICBpbnN0YWxsZWQgYWxsIGhvc3Qgcm91dGVzIGJlbG9uZ2luZyB0byB0 aGUgdmlydHVhbCBzdWJuZXQgaW50byBpdHMNCj4gICAgICAgRklCLiINCj4gDQo+ID4gVGhlIHdo b2xlIG9mIFNlY3Rpb24gMy42IGZlZWxzIGEgbGl0dGxlIGxpa2UgTElTUCBvciBOSFJQIG9yIHNv bWV0aGluZy4gIElmIHRoaXMNCj4gaXMNCj4gPiByZWFsbHkgd2hhdCB5b3UncmUgYWZ0ZXIgeW91 IG1heSB3YW50IHRvIGxvb2sgYXQgaG93IHRoZXkgYXBwcm9hY2hlZCB0aGlzDQo+ID4gcHJvYmxl bSBhbmQgc2hvdyB3aGF0J3MgZGlmZmVyZW50IGFib3V0IHlvdXIgc29sdXRpb24uDQo+IA0KPiBZ b3VyIG9ic2VydmF0aW9uIGlzIGNvcnJlY3QuIFRvIHNvbWUgZXh0ZW50LCBMSVNQIGNhbiBiZSBs b29rZWQgYXMgYW5vdGhlciB0eXBlDQo+IG9mIEwzVlBOIGFwcHJvYWNoLiBGdXJ0aGVybW9yZSwg TElTUC1tb2JpbGl0eSBpcyBhbm90aGVyIHR5cGUgb2YgaG9zdCByb3V0ZQ0KPiBiYXNlZCBzdWJu ZXQgZXh0ZW5zaW9uIGFwcHJvYWNoIGp1c3QgbGlrZSB0aGUgb25lIGRlZmluZWQgaW4gdGhpcyBk cmFmdC4gSXQncyB1cA0KPiB0byB0aGUgY2xvdWQgcHJvdmlkZXJzIHRvIG1ha2UgYSBjaG9pY2Ug YmV0d2VlbiBMM1ZQTiBhbmQgTElTUC4gQlRXLCBpZiB5b3UNCj4gd2VyZSBhIGNsb3VkIHByb3Zp ZGVyLCB3aGljaCBvbmUgd291bGQgeW91IGNob29zZSBpbiBwcmFjdGljZT8NCj4gDQo+IEJlc3Qg cmVnYXJkcywNCj4gWGlhb2h1DQo+IA0KPiA+IGVyaWMNCj4gPg0KPiA+DQo+ID4gPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogbnZvMy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gPiA+IFh1eGlhb2h1 DQo+ID4gPiBTZW50OiBUdWVzZGF5LCBKdWx5IDAyLCAyMDEzIDI6NTIgQU0NCj4gPiA+IFRvOiBM M1ZQTg0KPiA+ID4gQ2M6IG52bzNAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFtudm8zXSBXaHkg bm90IHVzZSBMM1ZQTiBmb3IgZGF0YSBjZW50ZXIgaW50ZXJjb25uZWN0Py8vcmU6DQo+ID4gPiBS ZXF1ZXN0IGEgV0cgYWRvcHRpb24gcG9sbCBmb3IgZHJhZnQteHUtdmlydHVhbC1zdWJuZXQtMTAN Cj4gPiA+DQo+ID4gPiBIaSBhbGwsDQo+ID4gPg0KPiA+ID4gVGlsbCBub3csIGl0IHNlZW1zIHRo YXQgdG9vIG11Y2ggYXR0ZW50aW9uIGhhcyBiZWVuIHBhaWQgdG8gdGhlIHVzZSBvZg0KPiA+ID4g TDJWUE4gZm9yIGRhdGEgY2VudGVyIGludGVyY29ubmVjdC4gQWx0aG91Z2ggdGhlcmUgYXJlIHN0 aWxsIGEgZmV3DQo+ID4gPiBjbHVzdGVyaW5nIGFwcGxpY2F0aW9ucyB3aGljaCByZWx5IG9uIG5v bi1JUCBvciBub24tcm91dGFibGUgSVANCj4gPiA+IGNvbW11bmljYXRpb25zIChlLmcuLCBoZWFy dGJlYXQgbWVzc2FnZXMgYmV0d2VlbiBjbHVzdGVyIG5vZGVzKSwgbW9yZQ0KPiA+ID4gYW5kIG1v cmUgY2x1c3RlciB2ZW5kb3JzIGFyZSBvZmZlcmluZyBjbHVzdGVyaW5nIGFwcGxpY2F0aW9ucyBi YXNlZCBvbg0KPiA+ID4gTGF5ZXIgMyBpbnRlcmNvbm5lY3Rpb24uIEluIGFkZGl0aW9uLCBnZW9n cmFwaGljYWwgaGlnaC1hdmFpbGFiaWxpdHkNCj4gPiA+IGNsdXN0ZXJzIGlzIG5vdCBhIG11c3Qg aW4gbWFueSBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3QgY2FzZXMuDQo+ID4gPg0KPiA+ID4gQXMg TDNWUE4gaGFzIG1hbnkgZGlzdGluY3QgYWR2YW50YWdlcyBvdmVyIEwyVlBOIGZvciBkYXRhIGNl bnRlcg0KPiA+ID4gaW50ZXJjb25uZWN0IHN1Y2ggYXM6IHNjYWxpbmcgZm9yd2FyZGluZyB0YWJs ZXMgb2YgZGF0YSBjZW50ZXIgc3dpdGNoZXMsDQo+ID4gPiBwYXRoIG9wdGltaXphdGlvbiwgdW5r bm93biB1bmljYXN0IGFuZCBBUlAgc3VwcHJlc3Npb24uLi4gd2h5IG5vdCB0cnkgdG8NCj4gPiA+ IHVzZSB0aGUgcHJvdmVuIEwzVlBOIHRlY2hub2xvZ3kgZm9yIGRhdGEgY2VudGVyIGludGVyY29u bmVjdCBpbiB0aGUNCj4gPiA+IHNjZW5hcmlvIHdoZXJlIHRoZSBsaW1pdGF0aW9ucyBhcyBtZW50 aW9uZWQgYWJvdmUgZG9uJ3QgZXhpc3Q/DQo+ID4gPg0KPiA+ID4gQmVzdCByZWdhcmRzLA0KPiA+ ID4gWGlhb2h1DQo+ID4gPg0KPiA+ID4gPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ID4gPiA+ IOWPkeS7tuS6ujogdGhvbWFzLm1vcmluQG9yYW5nZS5jb20NCj4gW21haWx0bzp0aG9tYXMubW9y aW5Ab3JhbmdlLmNvbV0NCj4gPiA+ID4g5Y+R6YCB5pe26Ze0OiAyMDEz5bm0N+aciDHml6UgMjE6 MTQNCj4gPiA+ID4g5pS25Lu25Lq6OiBYdXhpYW9odQ0KPiA+ID4gPiDmioTpgIE6IGwzdnBuLWNo YWlyc0B0b29scy5pZXRmLm9yZzsgbWFydGluLnZpZ291cmV1eEBhbGNhdGVsLQ0KPiA+ID4gbHVj ZW50LmNvbTsNCj4gPiA+ID4gTDNWUE4NCj4gPiA+ID4g5Li76aKYOiBSZTogUmVxdWVzdCBhIFdH IGFkb3B0aW9uIHBvbGwgZm9yIGRyYWZ0LXh1LXZpcnR1YWwtc3VibmV0LTEwDQo+ID4gPiA+DQo+ ID4gPiA+IEhlbGxvIFh1eGlhb2h1LA0KPiA+ID4gPg0KPiA+ID4gPiBCZWZvcmUgZXZlbnR1YWxs eSBzdGFydGluZyBhIGRpc2N1c3Npb24gb24gdGhlIGFkb3B0aW9uIG9uIHRoaXMNCj4gPiA+ID4g ZG9jdW1lbnQsIHdlIGNoYWlycyB3b3VsZCBsaWtlIHRvIHNlZSBtb3JlIGRpc2N1c3Npb24gYW5k IGhhdmUgdGhlDQo+ID4gPiA+IGZlZWRiYWNrIGZyb20gbW9yZSByZWFkZXJzIChkdXJpbmcgdGhl IDIgcHJldmlvdXMgbWVldGluZ3MsIG9ubHkgNSB0bw0KPiA+ID4gMTANCj4gPiA+ID4gcGVvcGxl IHJhaXNlZCB0aGVpciBoYW5kIHdoZW4gdGhlIHJvb20gd2FzIHBvbGxlZCBvbiBoYXZpbmcgcmVh ZCB0aGUNCj4gPiA+ID4gZG9jdW1lbnQpLg0KPiA+ID4gPg0KPiA+ID4gPiBSZWdhcmRzLA0KPiA+ ID4gPg0KPiA+ID4gPiAtVGhvbWFzIGFuZCBNYXJ0aW4sDQo+ID4gPiA+IGwzdnBuIGNvLWNoYWly cw0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiAyMDEzLTA3LTAxLCBYdXhpYW9odToNCj4gPiA+ ID4gPiBIaSBUaG9tYXMgYW5kIE1hcnRpbiwNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEkgaGF2ZW4n dCByZWNlaXZlZCBhbnkgcmVzcG9uc2UgZnJvbSBhbnkgb2YgeW91LiBIZW5jZSBJIHJlc2VuZCBp dC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEJlc3QgcmVnYXJkcywNCj4gPiA+ID4gPiBYaWFvaHUN Cj4gPiA+ID4gPg0KPiA+ID4gPiA+PiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ID4gPiA+ID4+ IOWPkeS7tuS6ujogWHV4aWFvaHUNCj4gPiA+ID4gPj4g5Y+R6YCB5pe26Ze0OiAyMDEz5bm0Nuac iDIw5pelIDE1OjA3DQo+ID4gPiA+ID4+IOaUtuS7tuS6ujogJ2wzdnBuLWNoYWlyc0B0b29scy5p ZXRmLm9yZyc7ICd0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbSc7DQo+ID4gPiA+ID4+ICdtYXJ0aW4u dmlnb3VyZXV4QGFsY2F0ZWwtbHVjZW50LmNvbScNCj4gPiA+ID4gPj4g5oqE6YCBOiBMM1ZQTg0K PiA+ID4gPiA+PiDkuLvpopg6IFJlcXVlc3QgYSBXRyBhZG9wdGlvbiBwb2xsIGZvciBkcmFmdC14 dS12aXJ0dWFsLXN1Ym5ldC0xMA0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiBIaSBXRyBjby1jaGFp cnMsDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IEFzIG1lbnRpb25lZCBiZWZvcmUsIHRoaXMgZHJh ZnQNCj4gPiA+ID4gPj4gKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LXZpcnR1 YWwtc3VibmV0LTEwKSBkZXNjcmliZXMNCj4gPiA+IGhvdyB0bw0KPiA+ID4gPiByZXVzZQ0KPiA+ ID4gPiA+PiB0aGUgcHJvdmVuIEwzVlBOIHRlY2hub2xvZ3kgdG8gcmVhbGl6ZSBzdWJuZXQgZXh0 ZW5zaW9uIGZvciBkYXRhDQo+ID4gPiBjZW50ZXINCj4gPiA+ID4gPj4gaW50ZXJjb25uZWN0LCB3 aXRoIHRoZSBhaWQgb2YgbWFueSBjb25jcmV0ZSBleHBlcmltZW50cyBhbmQNCj4gPiA+IHZlcmlm aWNhdGlvbnMuDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IFdlIGNvLWF1dGhvcnMgYmVsaWV2ZSB0 aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZHJhZnQgd291bGQNCj4gPiA+IGJlDQo+ ID4gPiA+IHZhbHVhYmxlDQo+ID4gPiA+ID4+IGZvciBjbG91ZCBzZXJ2aWNlIHByb3ZpZGVycyB0 byBldmFsdWF0ZSB0aGUgZmVhc2liaWxpdHkgb2YgYWRvcHRpbmcNCj4gPiA+IHRoZSBwcm92ZW4N Cj4gPiA+ID4gPj4gTDNWUE4gdGVjaG5vbG9neSBmb3IgZGF0YSBjZW50ZXIgaW50ZXJjb25uZWN0 aW9uIChieSB0aGUgd2F5LCBzb21lDQo+ID4gPiBwZW9wbGUNCj4gPiA+ID4gPj4gaGFkIHNob3du IHRoZWlyIGludGVyZXN0cyBvbiB0aGUgc2NoZW1lIGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0DQo+ ID4gPiB3aGVuDQo+ID4gPiA+IHZpc2l0aW5nDQo+ID4gPiA+ID4+IG91ciBpbXBsZW1lbnRhdGlv biBkZW1vIG9mIHRoaXMgc2NoZW1lIGF0IHRoZSBCaXRzLU4tQml0ZXMgZXZlbnQgb2YNCj4gPiA+ ID4gSUVURjg2KS4NCj4gPiA+ID4gPj4gSGVuY2Ugd2Ugd291bGQgbGlrZSBjby1jaGFpcnMgdG8g c3RhcnQgYSBXRyBhZG9wdGlvbiBwb2xsIGZvciB0aGlzDQo+ID4gPiBkcmFmdC4NCj4gPiA+ID4g Pj4NCj4gPiA+ID4gPj4gQmVzdCByZWdhcmRzLA0KPiA+ID4gPiA+PiBYaWFvaHUgKG9uIGJlaGFs ZiBvZiBhbGwgY28tYXV0aG9ycykNCj4gPiA+ID4NCj4gPiA+ID4NCj4gPg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+ID4gPg0KPiA+ID4gPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRl cyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCj4gPiA+ID4gY29uZmlkZW50aWVs bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCj4gPiA+ID4gcGFzIGV0cmUg ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg YXZleg0KPiA+ID4gcmVjdSBjZQ0KPiA+ID4gPiBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6 IGxlIHNpZ25hbGVyDQo+ID4gPiA+IGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNp IHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcw0KPiA+ID4gbWVzc2FnZXMNCj4gPiA+ID4gZWxl Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KPiA+ID4gPiBPcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVy ZSwNCj4gPiA+IGRlZm9ybWUgb3UNCj4gPiA+ID4gZmFsc2lmaWUuIE1lcmNpLg0KPiA+ID4gPg0K PiA+ID4gPiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25m aWRlbnRpYWwgb3INCj4gPiA+IHByaXZpbGVnZWQNCj4gPiA+ID4gaW5mb3JtYXRpb24gdGhhdCBt YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCj4gPiA+ID4gdGhleSBzaG91bGQgbm90IGJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+ID4gPiA+IElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBhbmQNCj4gPiA+IGRlbGV0ZSB0aGlzDQo+ID4gPiA+IG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy4NCj4gPiA+ID4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMg bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlDQo+ID4gPiBiZWVuDQo+ID4gPiA+IG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gPiA+ID4gVGhhbmsgeW91Lg0KPiA+ID4N Cj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gPiBudm8zIG1haWxpbmcgbGlzdA0KPiA+ID4gbnZvM0BpZXRmLm9yZw0KPiA+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zDQo+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBudm8zIG1haWxpbmcgbGlzdA0K PiA+IG52bzNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL252bzMNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gbnZvMyBtYWlsaW5nIGxpc3QNCj4gbnZvM0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMNCg== From martin.vigoureux@alcatel-lucent.com Tue Jul 16 07:49:03 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13D111E80D7 for ; Tue, 16 Jul 2013 07:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, 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 unPil8SwTJcp for ; Tue, 16 Jul 2013 07:48:58 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBFB21E8087 for ; Tue, 16 Jul 2013 07:48:56 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6GEmrEE014552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Jul 2013 09:48:55 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6GEmqnn014462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 16:48:53 +0200 Received: from [172.27.205.220] (135.239.27.40) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 16 Jul 2013 16:48:52 +0200 Message-ID: <51E55D53.9030307@alcatel-lucent.com> Date: Tue, 16 Jul 2013 16:48:51 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Subject: IETF 87 - L3VPN - Agenda Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.40] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: thomas.morin@orange.com X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 14:49:04 -0000 All, the draft agenda is online: http://www.ietf.org/proceedings/87/agenda/agenda-87-l3vpn Please be ready to send your slides. -m From zzhang@juniper.net Tue Jul 16 13:13:19 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD4B21F9DFB for ; Tue, 16 Jul 2013 13:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.149 X-Spam-Level: X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_00=-2.599, FS_REPLICA=0.994, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] 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 OzMZ91jfdNam for ; Tue, 16 Jul 2013 13:13:12 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 00ABC21F9C38 for ; Tue, 16 Jul 2013 13:13:11 -0700 (PDT) Received: from mail52-am1-R.bigfish.com (10.3.201.241) by AM1EHSOBE017.bigfish.com (10.3.207.139) with Microsoft SMTP Server id 14.1.225.22; Tue, 16 Jul 2013 20:13:04 +0000 Received: from mail52-am1 (localhost [127.0.0.1]) by mail52-am1-R.bigfish.com (Postfix) with ESMTP id E2AF5C0050 for ; Tue, 16 Jul 2013 20:13:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz9371I542I1432Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail52-am1: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=zzhang@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail52-am1 (localhost.localdomain [127.0.0.1]) by mail52-am1 (MessageSwitch) id 1374005581699027_1301; Tue, 16 Jul 2013 20:13:01 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.248]) by mail52-am1.bigfish.com (Postfix) with ESMTP id A6D87400046 for ; Tue, 16 Jul 2013 20:13:01 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.54) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 16 Jul 2013 20:13:00 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 16 Jul 2013 13:12:58 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.3.146.0; Tue, 16 Jul 2013 13:12:58 -0700 Received: from db9outboundpool.messaging.microsoft.com (213.199.154.248) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 16 Jul 2013 13:17:38 -0700 Received: from mail120-db9-R.bigfish.com (10.174.16.246) by DB9EHSOBE035.bigfish.com (10.174.14.98) with Microsoft SMTP Server id 14.1.225.22; Tue, 16 Jul 2013 20:12:55 +0000 Received: from mail120-db9 (localhost [127.0.0.1]) by mail120-db9-R.bigfish.com (Postfix) with ESMTP id BC57F4000B8 for ; Tue, 16 Jul 2013 20:12:55 +0000 (UTC) Received: from mail120-db9 (localhost.localdomain [127.0.0.1]) by mail120-db9 (MessageSwitch) id 137400557363737_30816; Tue, 16 Jul 2013 20:12:53 +0000 (UTC) Received: from DB9EHSMHS009.bigfish.com (unknown [10.174.16.227]) by mail120-db9.bigfish.com (Postfix) with ESMTP id 0A5A818004B; Tue, 16 Jul 2013 20:12:53 +0000 (UTC) Received: from SN2PRD0510HT002.namprd05.prod.outlook.com (157.56.234.117) by DB9EHSMHS009.bigfish.com (10.174.14.19) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 16 Jul 2013 20:12:52 +0000 Received: from SN2PRD0510MB394.namprd05.prod.outlook.com ([169.254.9.46]) by SN2PRD0510HT002.namprd05.prod.outlook.com ([10.255.116.37]) with mapi id 14.16.0329.000; Tue, 16 Jul 2013 20:12:50 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "erosen@cisco.com" Subject: RE: Comments on draft-zzhang-l3vpn-mvpn-bidir-ingress-replication-00.txt Thread-Topic: Comments on draft-zzhang-l3vpn-mvpn-bidir-ingress-replication-00.txt Thread-Index: AQHOZ6GvPo3pZ+o0CUymVYeDYKIT+ZlefN4g Date: Tue, 16 Jul 2013 20:12:49 +0000 Message-ID: <0BF0FCC78340F147BE76A6F5762318A83B7CCD51@SN2PRD0510MB394.namprd05.prod.outlook.com> References: <2449.1371064670@erosen-linux> In-Reply-To: <2449.1371064670@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 20:13:19 -0000 Eric, > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Wednesday, June 12, 2013 3:18 PM > To: Jeffrey (Zhaohui) Zhang > Cc: l3vpn@ietf.org > Subject: Comments on draft-zzhang-l3vpn-mvpn-bidir-ingress-replication- > 00.txt >=20 > This is an interesting and potentially useful draft. >=20 > The major issue I see is that while the draft does not say that it is > applicable only to non-segmented IR P-tunnels, I don't see how it will > work if IR P-tunnels are segmented at ASBRs or ABRs. The draft seems to = use > the term "Upstream Multicast Hop" (UMH) to mean "Upstream PE", which woul= d > be okay only if non-segmented IR P-tunnels are out of scope. I assume you meant "if segmented IR P-tunnels are out of scope". Indeed segmented P-tunnel case needs further study. >=20 > Comments in-line, look for ****. >=20 >=20 > Abstract >=20 > RFC 6513 described a method to support bidirectional C-flow using > "Partial Mesh of MP2MP P-Tunnels". This document describes how > partial mesh of MP2MP P-Tunnels can be simulated with Ingress > Replication, instead of a real MP2MP tunnel. >=20 > **** I'd add to the abstract that this enables a Service Provider to use > **** Ingress Replication to offer transparent BIDIR-PIM service to its VP= N > **** customers. Sure. > [draft-ietf-l3vpn-mvpn-bidir-05] assumes that an MP2MP P-tunnel is > realized either via PIM-Bidir, or via MP2MP mLDP. Each of them would > require signaling and state not just on PEs, but on the P routers as > well. This document describes how the MP2MP tunnel can be simulated > with a mesh of P2P or MP2P LSPs, i.e. Ingress Replication. >=20 > **** What is really being proposed is to simulate a MP2MP P-tunnel with a > **** set of P2MP P-tunnels, and then to use Ingress Replication to > **** instantiate each such P-tunnel. The trick is how to get all the PEs= to > **** join all the necessary P2MP P-tunnels without requiring each PE to s= end > **** a Leaf A-D route for each MP2MP P-tunnel to each other PE. Correct. >=20 > The > advantage is that existing P2P/MP2P LSPs created for unicast can be > used for multicast as well w/o introducing additional signaling or > state in the core. While there may be concerns with traffic > replication in the core, in many situations the traffic could be low- > rate and/or sporadic and the advantage of signaling and state savings > will outweight the concerns with traffic replication, making Ingress > Replication an applicable and attractive alternative. >=20 > **** It might be better simply to say that this scheme has both the > **** advantages and the disadvantages of Ingress Replication in general. I can do that. > 3.1. Control State >=20 > If a PE, say PEx, is connected to a site of a given VPN, and that > site hosts the C-RPA for some Bidir-PIM groups, i.e., the route to > the C-RPA is through a local PE-CE interface, >=20 > **** I think the actual condition is that PEx's next hop interface to som= e > **** C-RPA is a VRF interface. This is not exactly the same thing as bei= ng > **** connected to a site that "hosts a C-RPA". OK. >=20 > then PEx MUST > advertises a (C-*,C-BIDIR) S-PMSI A-D route, regardless of whether it > has any local Bidir-PIM join states corresponding to the C-RPA > learned from its CEs. It MAY also advertise a (C-*,C-G-BIDIR) S-PMSI >=20 > **** "advertise a" --> "advertise one or more" OK. >=20 > A-D route, just like how any other S-PMSI A-D routes are triggered > (e.g, when the (C-*,C-G-BIDIR) traffic rate goes above a threshold). >=20 > **** It's worth pointing out that applying a traffic rate threshold to a > **** (C-*,C-G-BIDIR) state would require measuring the traffic in both > **** directions, as the sources are not necessarily local. For IR > **** P-tunnels, it might also be necessary to take the fanout into accoun= t. I'll do that. >=20 > Here the C-G-BIDIR refers to a C-G where G is a Bidir-PIM group, and > the corresponding C-RPA is in the site that the PEx connects to. >=20 > The S-PMSI A-D routes include a Provider Tunnel Attribute (PTA) with >=20 > **** "PMSI Tunnel attribute" I'll fix that. >=20 > tunnel type set to Ingress Replication, with Leaf Information > Required flag set, and with a downstream allocated MPLS label that > other PEs in the same partition MUST use when sending relevant > C-bidir flows to this PE. >=20 > **** and with the Tunnel Identifier field in the PTA set to a routable > **** address of the originator? Yes. >=20 > **** Can the MPLS label be shared with any other P-tunnels? Perhaps all > **** the (C-*,C-BIDIR) and (C-*,C-G-BIDIR) S-PMSI A-D routes originated b= y a > **** given PE can (optionally) share a label? Subject to the anti-ambiguity rules for extranet. >=20 > If some other PE, PEy, receives and imports into one of its VRFs such > a (C-*,C-BIDIR) S-PMSI A-D route, >=20 > **** I'm not sure just what is mean by "such a (C-*,C-BIDIR) S-PMSI A-D > **** route". Does this mean "any (C-*,C-BIDIR) S-PMSI A-D route whose PT= A > **** specifies an IR P-tunnel"? The wording "such a" means the S-PMSI A-D route mentioned in earlier text (= originated by PEx). Yes, we can use the text you suggested. >=20 > and the VRF has any local Bidir-PIM > join state that PEy has received from its CEs, and if PEy chooses PEx > as its UMH wrt the C-RPA for those states, PEy MUST advertise a Leaf > A-D route in response. Or, if PEy has received and imported into one > of its VRFs a (C-*,C-BIDIR) S-PMSI A-D route from PEx before, then > upon receiving in the VRF any local Bidir-PIM join state from its CEs > with PEx being the UMH for those states' C-RPA, PEy MUST advertise a > Leaf A-D route. >=20 > The encoding of the Leaf A-D route is as specified in RFC 6514, > except that the Route Targets are set to the same value as in the > corresponding S-PMSI A-D route so that the Leaf A-D route will be > imported by all VRFs that import the corresponding S-PMSI A-D route. >=20 > **** I take the "except" clause to mean that RFC 6514's rules for setting > **** the Leaf A-D route's RTs are not followed, and that the RTs are inst= ead > **** just copied from the S-PMSI A-D route. Is that the intention? Yes. >=20 > **** This means that the Leaf A-D route will not have an RT that is creat= ed > **** from the Next Hop or P2MP Segmented Next Hop EC, which essentially > **** means that all the P-tunnels will be non-segmented. Is that the > **** intention? Segmented P-tunnel needs further study. >=20 > **** RFC 6514 says that a PE/ASBR should take no action with regard to a > **** Leaf A-D route unless that Leaf A-D route carries an IP Address > **** Specific RT identifying the PE/ASBR. This draft should make it very > **** clear that it is changing the RFC6514 procedures for the case where = the > **** route key of a Leaf A-D route identifies a (C-*,C-BIDIR) or a > **** (C-*,C-G-BIDIR) S-PMSI. Good catch. I'll make it clear. >=20 > **** It's not clear to me how these procedures would coexist with the > **** segmentation procedures that ordinarily occur at ABRs or ASBRs. Are > **** ABRs/ASBRs supposed to modify the next hop and/or segmented next hop > **** extended communities of the S-PMSI A-D routes that are about BIDIR > **** groups? If not, but if segmentation is to be applied to S-PMSI A-D > **** routes that are not about BIDIR groups, how will the ABRs/ASBRS know > **** which are which? I.e., how exactly do the procedures of this draft > **** coexist with the ABR/ASBR segmentation procedures that apply to > **** non-BIDIR S-PMSIs? Unfortunately, segmented P-tunnel case needs further study. >=20 > **** Note that there is up to now no requirement that an S-PMSI A-D route > **** originated from a particular VRF carry any of that VRF's import RTs.= I > **** think that requirement needs to be added to this draft; otherwise th= e > **** Leaf A-D routes originated in response to an S-PMSI A-D route won't > **** necessarily be imported into the originating VRF of the S-PMSI A-D > **** route. Alternatively, one could require that the Leaf A-D route car= ry > **** an IP Address Specific RT identifying the S-PMSI route's originator = (as > **** learned from the NLRI) in its Global Administrator field. I don't follow the alternative - all other PEs in the same partition need t= o import the Leaf A-D routes, so carrying the RT identifying the S-PMSI rou= te's originator would not help. Perhaps I need to explicitly point it out, but the RTs carried by the S-PMS= I A-D routes are just as specified at the end of section 12.1, RFC 6513. Th= e S-PMSI A-D routes will be imported by all PEs into the right VRFs, and by= copying the RTs to the Leaf-AD routes, the Leaf-AD routes will be imported= into the same set of VRFs? >=20 > This is irrespective of whether from a receiving PE, PEz's > perspective PEx (oiginator of the S-PMSI A-D route) is the UMH PE or >=20 > **** Is "PEz" supposed to be "PEy"? It is really PEz: PEx originates S-PMSI A-D route; PEy responds with a Leaf A-D route; PEz re= ceives it. >=20 > **** It would be better to say "Upstream PE" than "UMH" or "UMH PE", as t= he > **** UMH could presumably be an ABR or ASBR. Yes. >=20 > not. The label in the PTA of the Leaf A-D route originated by PEy > MUST be allocated specifically for PEx, so that when traffic arrives > with that label, the traffic can associated with the partition > (represented by the PEx). >=20 > **** This doesn't make it clear whether the label can be shared with othe= r > **** S-PMSIs (e.g., P2MP S-PMSIs) that originate from PEx. I think the > **** answer is yes, at least in non-extranet cases. Correct. I left it unspecified, because it would be covered by the extranet= spec. >=20 > **** I think the draft should specify that the originator (the upstream P= E) > **** is identified from the "originating router's IP address" field of th= e > **** NLRI of the S-PMSI A-D route. OK. >=20 > With PEy advertising Leaf A-D route only if it chooses the originator > of the S-PMSI A-D route as its UMH, it won't receive traffic from PEs >=20 > **** "UMH" vs. "Upstream PE" again. Yup :-) >=20 > in other partitions, so the label is actually useful only when PEy > switches to a different UMH - it will stop accepting traffic before > sending PEs stop sending it traffic (upon the receipt of its Leaf A-D > route withdrawl). >=20 > **** I don't see why it is said that "PEy ... won't receive traffic from = PEs > **** in other partitions". PE1, for example, may choose PE2 as the Upstr= eam > **** PE for (C-*,C-G1-BIDIR) while choosing PE3 as the Upstream PE for > **** (C-*,C-G2-BIDIR). PE4 may make the opposite choices. In that case = PE1 > **** and PE4 may both originate Leaf A-D routes with NLRI > **** and . As a result, PE2 and PE3 would get the > **** (C-*,C-G1-BIDIR) and (C-*,C-G2-BIDIR) flows from both partitions, an= d > **** they would need to use the label to determine which copy of each C-f= low > **** to drop. You are right. I'll fix it. >=20 >=20 > To speed up convergency (so that PEy starts > receiving traffic from its new UMH immediately instead of waiting > until the new Leaf A-D route corresponding to the new UMH is received > by sending PEs), PEy MAY advertise a Leaf A-D route even if does not > choose PEx as its UMH wrt the C-RPA. With that, it will receive > traffic from all PEs, but some will arrive with the label > corresponding to its choice of UMH while some will arrive with a > different label, and the traffic in the latter case will be > discarded. >=20 > **** This might be useful as a form of live-live redundancy, but I don't > **** think it is a very efficient way to speed up convergence when a > **** receiving PE decides to switch the partition over which it receives = a > **** particular C-flow. When the receiving PE originates the Leaf A-D ro= ute > **** for the new partition, it just has to keep forwarding the C-flow > **** received from the old partition for a certain period of time, while > **** discarding that C-flow when received from the new partition; when th= at > **** period of time is up, can start discarding the C-flow when received > **** from the old partition and start forwarding it when received from th= e > **** new. (A larger delay should be imposed on transmitters, so they > **** continue transmitting to a particular receiver for a period of time > **** after that receiver withdraws its Leaf A-D route.) This would provi= de > **** a more efficient "make before break" type of procedure. I suppose the transmitter would have to send on both the original tunnel (c= orresponding to the old UMH) and new tunnel (corresponding to the new UMH) = and then stop after a timeout? On the other hand, when UMH changes, keep sending/receiving on the old tunn= el may not be a good idea for PIM-bidir from loop-avoidance point of view. = I don't have a concrete example, though. I can reword the above paragraph to live-live redundancy case. > Whenever the (C-*,C-BIDIR) or (C-*,C-G-BIDIR) S-PMSI A-D route is > withdrawn, or if PEy no longer chooses the originator PEx as its UMH > wrt C-RPA and PEy only advertises Leaf A-D routes in response to its > UMH's S-PMSI A-D route, or if relevant local join state is pruned, > PEy MUST withdraw the corresponding Leaf A-D route. >=20 > **** I think this "MUST" is too strong, and in fact it contradicts what i= s > **** said above "PEy MAY advertise a Leaf A-D route even if does not > **** choose PEx as its UMH wrt the C-RPA". >=20 The above text does have an additional condition (see below), so it does no= t conflict? ... and PEy only advertises Leaf A-D routes in response to its UMH's S-PMSI A-D route, ... Thanks. Jeffrey From xuxiaohu@huawei.com Thu Jul 18 02:55:21 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428B711E8111; Thu, 18 Jul 2013 02:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.253 X-Spam-Level: X-Spam-Status: No, score=-4.253 tagged_above=-999 required=5 tests=[AWL=2.346, BAYES_00=-2.599, 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 tJytRLm7-3Ek; Thu, 18 Jul 2013 02:55:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E9FF021E80B3; Thu, 18 Jul 2013 02:55:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVD97060; Thu, 18 Jul 2013 09:55:09 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 10:53:53 +0100 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 10:54:48 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.175]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Thu, 18 Jul 2013 17:54:44 +0800 From: Xuxiaohu To: "nvo3@ietf.org" , L3VPN , "l2vpn@ietf.org" , "mpls@ietf.org" Subject: The possibility of using global MPLS labels as VNIs Thread-Topic: The possibility of using global MPLS labels as VNIs Thread-Index: Ac6DnNMgHvnlcn9VTo6g3UrBJiTzlQ== Date: Thu, 18 Jul 2013 09:54:43 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D6B60@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 09:55:21 -0000 Hi all, Till now, it seem that the only remaining technical reason for some people = to prefer VXLAN/NVGRE encapsulation format to MAC-in-MPLS-in-IP encapsulati= on format for network virtualization overlay is the former has global VNIs = while the latter doesn't have. If this reason is true, why can't we conside= r the possibility of using global MPLS labels to achieve the same goal? In fact, there are multiple possible ways to achieve global MPLS labels: 1) the first way is to allocate a label block from the existing label space= and use it as a global label space from which VPN labels are assigned. In = this way, the VPN label of a given VN is set to the corresponding VNI. This= approach doesn't require any change to the data plane. 2) the second way is to allocate a separate protocol type code for the glob= al MPLS label so as to distinguish global labels from downstream-assigned a= nd upstream-assigned labels. This approach requires some change to the data= plane of PE routers. 3) the third way is to reserve a special purpose label to indicate that the= label below such special purpose label is a global label. This approach re= quires some change to the data plane of PE routers as well. In case 2) and 3), the global label space mentioned above could be a label = space dedicated for VNI or a label space which is shared with other applica= tions (e.g., segment routing).=20 Any comments? Best regards, Xiaohu From xuxiaohu@huawei.com Thu Jul 18 20:43:05 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FAE21F9C32; Thu, 18 Jul 2013 20:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 87sV4Oje7Es0; Thu, 18 Jul 2013 20:43:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AF2E411E8176; Thu, 18 Jul 2013 20:43:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVF06182; Fri, 19 Jul 2013 03:42:59 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 04:42:15 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 04:42:56 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.175]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Fri, 19 Jul 2013 11:42:50 +0800 From: Xuxiaohu To: "nvo3@ietf.org" , L3VPN , "l2vpn@ietf.org" , "mpls@ietf.org" Subject: re: The possibility of using global MPLS labels as VNIs Thread-Topic: The possibility of using global MPLS labels as VNIs Thread-Index: Ac6DnNMgHvnlcn9VTo6g3UrBJiTzlQAkGO8Q Date: Fri, 19 Jul 2013 03:42:50 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D6F4B@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D6B60@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D6B60@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 03:43:05 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbnZvMy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnXSC0+rHtDQo+IFh1eGlhb2h1DQo+ILeiy83K sbzkOiAyMDEzxOo31MIxOMjVIDE3OjU1DQo+IMrVvP7IyzogbnZvM0BpZXRmLm9yZzsgTDNWUE47 IGwydnBuQGlldGYub3JnOyBtcGxzQGlldGYub3JnDQo+INb3zOI6IFtudm8zXSBUaGUgcG9zc2li aWxpdHkgb2YgdXNpbmcgZ2xvYmFsIE1QTFMgbGFiZWxzIGFzIFZOSXMNCj4gDQo+IEhpIGFsbCwN Cj4gDQo+IFRpbGwgbm93LCBpdCBzZWVtIHRoYXQgdGhlIG9ubHkgcmVtYWluaW5nIHRlY2huaWNh bCByZWFzb24gZm9yIHNvbWUgcGVvcGxlIHRvDQo+IHByZWZlciBWWExBTi9OVkdSRSBlbmNhcHN1 bGF0aW9uIGZvcm1hdCB0byBNQUMtaW4tTVBMUy1pbi1JUA0KPiBlbmNhcHN1bGF0aW9uIGZvcm1h dCBmb3IgbmV0d29yayB2aXJ0dWFsaXphdGlvbiBvdmVybGF5IGlzIHRoZSBmb3JtZXIgaGFzIGds b2JhbA0KPiBWTklzIHdoaWxlIHRoZSBsYXR0ZXIgZG9lc24ndCBoYXZlLiBJZiB0aGlzIHJlYXNv biBpcyB0cnVlLCB3aHkgY2FuJ3Qgd2UgY29uc2lkZXINCg0KT3IgdGhlIHJlYXNvbiBmb3IgcmVx dWlyaW5nIGdsb2JhbCBWTkkgaW4gdGhlIGRhdGEgcGFja2V0IGl0c2VsZiBpcyBmYWtlIG9yIGlu c2lnbmlmaWNhbnQ/IEkganVzdCBub3RpY2VkIHRoYXQgdGhlIE5WbzMgZGF0YSBwbGFuZSByZXF1 aXJlbWVudCBkb2MganVzdCBtZW50aW9uZWQgIi4uLlRoaXMgZmllbGQgTUFZIGJlIGFuIGV4cGxp Y2l0LCB1bmlxdWUgKHRvIHRoZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4pIHZpcnR1YWwgbmV0d29y ayBpZGVudGlmaWVyIChWTklEKSBvciBNQVkgZXhwcmVzcyB0aGUgbmVjZXNzYXJ5IGNvbnRleHQg aW5mb3JtYXRpb24gaW4gb3RoZXIgd2F5cyAoZS5nLiBhIGxvY2FsbHkgc2lnbmlmaWNhbnQgaWRl bnRpZmllcikuLi4iIEkgaGF2ZW4ndCBmb3VuZCBhbnkgZGVzY3JpcHRpb24gYWJvdXQgdGhlIHJl YXNvbiBmb3IgcmVxdWlyaW5nIGdsb2JhbCBWTkkgaW4gdGhlIGRhdGEgY2VudGVyIHBhY2tldCBp biB0aGUgTlZPMyByZWxhdGVkIGRvY3MuIFNob3VsZG4ndCB0aGUgcmVhc29uIGZvciByZXF1aXJp bmcgZ2xvYmFsIFZOSSBpbiB0aGUgZGF0YSBwYWNrZXQgYmUgaW52ZXN0aWdhdGVkIGJ5IE5WbzMg V0c/IFNpbmNlIGl0IHdvdWxkIGJlIGJlbmVmaWNpYWwgdG8gdGhlIGdhcCBhbmFseXNpcyB3b3Jr IHdoaWNoIHdvdWxkIGJlIHBlcmZvcm1lZCBvbiB0aGUgZXhpc3RpbmcgU1RBTkRBUkRJWkVEIGNh bmRpZGF0ZSBtZWNoYW5pc21zLCBJTUhPLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiB0 aGUgcG9zc2liaWxpdHkgb2YgdXNpbmcgZ2xvYmFsIE1QTFMgbGFiZWxzIHRvIGFjaGlldmUgdGhl IHNhbWUgZ29hbD8NCg0KPiBJbiBmYWN0LCB0aGVyZSBhcmUgbXVsdGlwbGUgcG9zc2libGUgd2F5 cyB0byBhY2hpZXZlIGdsb2JhbCBNUExTIGxhYmVsczoNCj4gDQo+IDEpIHRoZSBmaXJzdCB3YXkg aXMgdG8gYWxsb2NhdGUgYSBsYWJlbCBibG9jayBmcm9tIHRoZSBleGlzdGluZyBsYWJlbCBzcGFj ZSBhbmQgdXNlDQo+IGl0IGFzIGEgZ2xvYmFsIGxhYmVsIHNwYWNlIGZyb20gd2hpY2ggVlBOIGxh YmVscyBhcmUgYXNzaWduZWQuIEluIHRoaXMgd2F5LCB0aGUNCj4gVlBOIGxhYmVsIG9mIGEgZ2l2 ZW4gVk4gaXMgc2V0IHRvIHRoZSBjb3JyZXNwb25kaW5nIFZOSS4gVGhpcyBhcHByb2FjaCBkb2Vz bid0DQo+IHJlcXVpcmUgYW55IGNoYW5nZSB0byB0aGUgZGF0YSBwbGFuZS4NCj4gMikgdGhlIHNl Y29uZCB3YXkgaXMgdG8gYWxsb2NhdGUgYSBzZXBhcmF0ZSBwcm90b2NvbCB0eXBlIGNvZGUgZm9y IHRoZSBnbG9iYWwNCj4gTVBMUyBsYWJlbCBzbyBhcyB0byBkaXN0aW5ndWlzaCBnbG9iYWwgbGFi ZWxzIGZyb20gZG93bnN0cmVhbS1hc3NpZ25lZCBhbmQNCj4gdXBzdHJlYW0tYXNzaWduZWQgbGFi ZWxzLiBUaGlzIGFwcHJvYWNoIHJlcXVpcmVzIHNvbWUgY2hhbmdlIHRvIHRoZSBkYXRhDQo+IHBs YW5lIG9mIFBFIHJvdXRlcnMuDQo+IDMpIHRoZSB0aGlyZCB3YXkgaXMgdG8gcmVzZXJ2ZSBhIHNw ZWNpYWwgcHVycG9zZSBsYWJlbCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBsYWJlbA0KPiBiZWxvdyBz dWNoIHNwZWNpYWwgcHVycG9zZSBsYWJlbCBpcyBhIGdsb2JhbCBsYWJlbC4gVGhpcyBhcHByb2Fj aCByZXF1aXJlcyBzb21lDQo+IGNoYW5nZSB0byB0aGUgZGF0YSBwbGFuZSBvZiBQRSByb3V0ZXJz IGFzIHdlbGwuDQo+IA0KPiBJbiBjYXNlIDIpIGFuZCAzKSwgdGhlIGdsb2JhbCBsYWJlbCBzcGFj ZSBtZW50aW9uZWQgYWJvdmUgY291bGQgYmUgYSBsYWJlbCBzcGFjZQ0KPiBkZWRpY2F0ZWQgZm9y IFZOSSBvciBhIGxhYmVsIHNwYWNlIHdoaWNoIGlzIHNoYXJlZCB3aXRoIG90aGVyIGFwcGxpY2F0 aW9ucyAoZS5nLiwNCj4gc2VnbWVudCByb3V0aW5nKS4NCj4gDQo+IEFueSBjb21tZW50cz8NCj4g DQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IG52bzMgbWFpbGluZyBsaXN0DQo+IG52bzNAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zDQo= From zhangmingui@huawei.com Fri Jul 19 00:47:10 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCA411E81E6 for ; Fri, 19 Jul 2013 00:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.747 X-Spam-Level: X-Spam-Status: No, score=-7.747 tagged_above=-999 required=5 tests=[AWL=-1.148, BAYES_00=-2.599, 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 ystSDyTED8+L for ; Fri, 19 Jul 2013 00:47:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D7D8D11E81BD for ; Fri, 19 Jul 2013 00:47:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATO95227; Fri, 19 Jul 2013 07:47:03 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 08:45:45 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 08:46:43 +0100 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.110]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.01.0323.007; Fri, 19 Jul 2013 15:46:23 +0800 From: Mingui Zhang To: "l3vpn@ietf.org" Subject: FW: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt Thread-Topic: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt Thread-Index: AQHOgS6cBWFI1KLT1U2mnmg/9jFYHplrojgA Date: Fri, 19 Jul 2013 07:46:23 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7335C721B@nkgeml508-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 07:47:10 -0000 RGVhciBhbGwsDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0OiBMYWJlbCBTaGFyaW5n IGZvciBGYXN0IFBFIFByb3RlY3Rpb24uDQoNCiAgIFRoaXMgZHJhZnQgZGVzaWducyBhIHNpbXBs ZSBtZXRob2QgdG8gYmUgdXNlZCBieSBTUHMgdG8gYWNoaWV2ZSBmYXN0IFBFIHByb3RlY3Rpb24s IHV0aWxpemluZyB0aGUgZGVwbG95bWVudCBvZiByZWR1bmRhbnQgZWdyZXNzIFBFcy4NCg0KQ29t bWVudHMgYXJlIHdlbGNvbWUuDQoNClJlZ2FyZHMsDQpNaW5ndWkNCg0KPi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16aGFuZy1sM3Zwbi1s YWJlbC1zaGFyaW5nLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBN aW5ndWkgWmhhbmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFt ZToJIGRyYWZ0LXpoYW5nLWwzdnBuLWxhYmVsLXNoYXJpbmcNClJldmlzaW9uOgkgMDANClRpdGxl OgkJIExhYmVsIFNoYXJpbmcgZm9yIEZhc3QgUEUgUHJvdGVjdGlvbg0KQ3JlYXRpb24gZGF0ZToJ IDIwMTMtMDctMTINCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBh Z2VzOiAxMg0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC16aGFuZy1sM3Zwbi1sYWJlbC1zaGFyaW5nLTAwLnR4dA0KU3RhdHVzOiAgICAg ICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpoYW5nLWwzdnBuLWxh YmVsLXNoYXJpbmcNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtemhhbmctbDN2cG4tbGFiZWwtc2hhcmluZy0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhp cyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZXRob2QgdG8gYmUgdXNlZCBieSBTZXJ2aWNlIFByb3Zp ZGVycyB0bw0KICAgcHJvdmlkZSBmYXN0IHByb3RlY3Rpb24gb2YgVlBOIGNvbm5lY3Rpb25zIGZv ciBhIENFLiBFZ3Jlc3MgUEVzIGluIGENCiAgIHJlZHVuZGFudCBncm91cCBhbHdheXMgYXNzaWdu IHRoZSBzYW1lIGxhYmVsIGZvciBWUE4gcm91dGVzIGZyb20gYQ0KICAgVlJGLiBUaGVzZSBlZ3Jl c3MgUEVzIGNyZWF0ZSBhIEJHUCB2aXJ0dWFsIE5leHQgSG9wICh2TkgpIGluIHRoZQ0KICAgZG9t YWluIG9mIHRoZSBJUC9NUExTIGJhY2tib25lIG5ldHdvcmsgYXMgYW4gYWdlbnQgb2YgdGhlIENF IHJvdXRlci4NCiAgIFByaW1hcnkgYW5kIGJhY2t1cCB0dW5uZWxzIHRlcm1pbmF0ZWQgYXQgdGhl IHZOSCBhcmUgc2V0IHVwIGJ5IHRoZQ0KICAgQkdQL01QTFMgSVAgVlBOIGJhc2VkIG9uIElHUCBG UlIuIElmIHRoZSBwcmltYXJ5IGVncmVzcyBQRSBmYWlscywgdGhlDQogICBiYWNrdXAgZWdyZXNz IFBFcyBjYW4gcmVjb2duaXplIHRoZSAic2hhcmVkIiBWUE4gcm91dGUgbGFiZWwgYW5kDQogICBk ZWxpdmVyIHRoZSBmYWlsdXJlIGFmZmVjdGVkIHBhY2tldHMgYWNjb3JkaW5nbHkuDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From naikumar@cisco.com Fri Jul 19 01:15:25 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8776611E81FF for ; Fri, 19 Jul 2013 01:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 iwOqZjR+E71u for ; Fri, 19 Jul 2013 01:15:20 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9D53C11E814F for ; Fri, 19 Jul 2013 01:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2920; q=dns/txt; s=iport; t=1374221718; x=1375431318; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RRVuRsDEH2/y/Dts8GEmJx4nFL5MnKP1BssnjsCM63E=; b=LLI+BoB3F67I83ah7qaNKQF9mGoTK55YSm60mP3E0GuMTVSCW+EIUqlo DHKNlOii2jRZDr5rMWihG/BvTA7YD6TE/9dfm9yPxflWtVoWeulDH+SAu p/Wf3okGmNHZ3nZRsfjA/W6wwwEAdsl1G7I4wgD34sd6BuVJPeEqBZ9or o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAGb06FGtJV2c/2dsb2JhbABagwY1UIMGvUEXdxZ0giQBAQEEIxFDDgQCAQgRBAEBAwIGHQMCAgIwFAEICAIEARIIAYgHDKRVkUaBKI0cgRo4BoJVM24DmQaQJIMSgio X-IronPort-AV: E=Sophos;i="4.89,700,1367971200"; d="scan'208";a="236845830" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 19 Jul 2013 08:15:18 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6J8FHDn031809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Jul 2013 08:15:17 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.100]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 03:15:17 -0500 From: "Nagendra Kumar (naikumar)" To: Mingui Zhang , "l3vpn@ietf.org" Subject: RE: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt Thread-Topic: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt Thread-Index: AQHOgS6cBWFI1KLT1U2mnmg/9jFYHplrojgAgAALBLA= Date: Fri, 19 Jul 2013 08:15:16 +0000 Message-ID: <47E76F08F1BCF5458111C1939C7B9C4610268B3F@xmb-rcd-x03.cisco.com> References: <4552F0907735844E9204A62BBDD325E7335C721B@nkgeml508-mbx.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E7335C721B@nkgeml508-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.103.238.67] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 08:15:26 -0000 SGkgTWluZ3VpLA0KDQpJIGNvdWxkbuKAmXQgc2VlIGFueSBwb2ludCBtZW50aW9uZWQgaW4gdGhp cyBkcmFmdCBvbiBob3cgZWdyZXNzIFBFcyB3aWxsIGFzc2lnbiBzYW1lIFZQTiBsYWJlbCBmb3Ig dGhlIHByZWZpeC4gDQoNCkNhbiB5b3UgcGxlYXNlIHNoYXJlIHRoZSBzYW1lPy4gU29ycnksIGlm IEkgYW0gbWlzc2luZyBzb21ldGhpbmcgaW4gdGhlIGRvYy4NCg0KUmVnYXJkcywNCm5hZ2VuZHJh DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsM3Zwbi1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86bDN2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pbmd1aSBa aGFuZw0KU2VudDogRnJpZGF5LCBKdWx5IDE5LCAyMDEzIDE6MTYgUE0NClRvOiBsM3ZwbkBpZXRm Lm9yZw0KU3ViamVjdDogRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtemhh bmctbDN2cG4tbGFiZWwtc2hhcmluZy0wMC50eHQNCg0KRGVhciBhbGwsDQoNCldlIGhhdmUgc3Vi bWl0dGVkIGEgbmV3IGRyYWZ0OiBMYWJlbCBTaGFyaW5nIGZvciBGYXN0IFBFIFByb3RlY3Rpb24u DQoNCiAgIFRoaXMgZHJhZnQgZGVzaWducyBhIHNpbXBsZSBtZXRob2QgdG8gYmUgdXNlZCBieSBT UHMgdG8gYWNoaWV2ZSBmYXN0IFBFIHByb3RlY3Rpb24sIHV0aWxpemluZyB0aGUgZGVwbG95bWVu dCBvZiByZWR1bmRhbnQgZWdyZXNzIFBFcy4NCg0KQ29tbWVudHMgYXJlIHdlbGNvbWUuDQoNClJl Z2FyZHMsDQpNaW5ndWkNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC16aGFuZy1sM3Zwbi1sYWJlbC1zaGFyaW5nLTAwLnR4dA0KaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNaW5ndWkgWmhhbmcgYW5kIHBvc3RlZCB0 byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXpoYW5nLWwzdnBuLWxh YmVsLXNoYXJpbmcNClJldmlzaW9uOgkgMDANClRpdGxlOgkJIExhYmVsIFNoYXJpbmcgZm9yIEZh c3QgUEUgUHJvdGVjdGlvbg0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDctMTINCkdyb3VwOgkJIElu ZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxMg0KVVJMOiAgICAgICAgICAg ICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16aGFuZy1sM3Zwbi1s YWJlbC1zaGFyaW5nLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXpoYW5nLWwzdnBuLWxhYmVsLXNoYXJpbmcNCkh0bWxpemVkOiAg ICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctbDN2cG4tbGFiZWwt c2hhcmluZy0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBt ZXRob2QgdG8gYmUgdXNlZCBieSBTZXJ2aWNlIFByb3ZpZGVycyB0bw0KICAgcHJvdmlkZSBmYXN0 IHByb3RlY3Rpb24gb2YgVlBOIGNvbm5lY3Rpb25zIGZvciBhIENFLiBFZ3Jlc3MgUEVzIGluIGEN CiAgIHJlZHVuZGFudCBncm91cCBhbHdheXMgYXNzaWduIHRoZSBzYW1lIGxhYmVsIGZvciBWUE4g cm91dGVzIGZyb20gYQ0KICAgVlJGLiBUaGVzZSBlZ3Jlc3MgUEVzIGNyZWF0ZSBhIEJHUCB2aXJ0 dWFsIE5leHQgSG9wICh2TkgpIGluIHRoZQ0KICAgZG9tYWluIG9mIHRoZSBJUC9NUExTIGJhY2ti b25lIG5ldHdvcmsgYXMgYW4gYWdlbnQgb2YgdGhlIENFIHJvdXRlci4NCiAgIFByaW1hcnkgYW5k IGJhY2t1cCB0dW5uZWxzIHRlcm1pbmF0ZWQgYXQgdGhlIHZOSCBhcmUgc2V0IHVwIGJ5IHRoZQ0K ICAgQkdQL01QTFMgSVAgVlBOIGJhc2VkIG9uIElHUCBGUlIuIElmIHRoZSBwcmltYXJ5IGVncmVz cyBQRSBmYWlscywgdGhlDQogICBiYWNrdXAgZWdyZXNzIFBFcyBjYW4gcmVjb2duaXplIHRoZSAi c2hhcmVkIiBWUE4gcm91dGUgbGFiZWwgYW5kDQogICBkZWxpdmVyIHRoZSBmYWlsdXJlIGFmZmVj dGVkIHBhY2tldHMgYWNjb3JkaW5nbHkuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From zhangmingui@huawei.com Fri Jul 19 01:50:56 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3B821E80F2 for ; Fri, 19 Jul 2013 01:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.62 X-Spam-Level: X-Spam-Status: No, score=-7.62 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_00=-2.599, 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 rrbdz8Igjmqw for ; Fri, 19 Jul 2013 01:50:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE4F21E80CA for ; Fri, 19 Jul 2013 01:50:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATP01293; Fri, 19 Jul 2013 08:50:50 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 09:49:50 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 09:50:49 +0100 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.110]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Fri, 19 Jul 2013 16:50:42 +0800 From: Mingui Zhang To: "Nagendra Kumar (naikumar)" , "l3vpn@ietf.org" Subject: RE: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt Thread-Topic: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt Thread-Index: AQHOhFgrKKi7/uR8Ek+T5dv9lOYSXplrqOlw Date: Fri, 19 Jul 2013 08:50:42 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7335C727B@nkgeml508-mbx.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E7335C721B@nkgeml508-mbx.china.huawei.com> <47E76F08F1BCF5458111C1939C7B9C4610268B3F@xmb-rcd-x03.cisco.com> In-Reply-To: <47E76F08F1BCF5458111C1939C7B9C4610268B3F@xmb-rcd-x03.cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 08:50:56 -0000 SGkgTmFnZW5kcmEsDQoNCkluIHRoZSBtZXRob2QsIHRoZSBlZ3Jlc3MgUEVzIGluIHRoZSBSRyBo YXZlIHRvIHVzZSB0aGUgc2FtZSBWUE4gcm91dGUgbGFiZWwgZm9yIG9uZSBWUE4gc2l0ZSAoZS5n LiwgMTEwMCBmb3IgVlBOMSkuIA0KQXMgZm9yIHRoZSBwcmVmaXgsIGFsbCBwcmVmaXhlcyAoZS5n LiwgMTAuMS4xLjAvMjQpIGxlYXJudCBmcm9tIHRoaXMgVlBOIHNpdGUgd2lsbCBiZSBzdG9yZWQg aW4gdGhlIGNvcnJlc3BvbmRpbmcgVlJGIChlLmcuLCBWUE4xJyBWUE4gaW5zdGFuY2UpIGlkZW50 aWZpZWQgYnkgdGhlIFZQTiByb3V0ZSBsYWJlbC4NCg0KSSBndWVzcyB5b3UgcHJvcG9zZSB0byBz aGFyZSB0aGUgbGFiZWwgInBlci1wcmVmaXgiLiBJdCdzIHBvc3NpYmxlIHRvIGRvIHNvIGJ1dCBu b3QgYXMgY29tbW9uIGFzIHRoZSAicGVyLVZSRiIgYXNzaWdubWVudCBpbiBjdXJyZW50IHByYWN0 aWNlLiANCg0KVGhhbmtzLA0KTWluZ3VpDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PkZyb206IE5hZ2VuZHJhIEt1bWFyIChuYWlrdW1hcikgW21haWx0bzpuYWlrdW1hckBjaXNjby5j b21dDQo+U2VudDogRnJpZGF5LCBKdWx5IDE5LCAyMDEzIDQ6MTUgUE0NCj5UbzogTWluZ3VpIFpo YW5nOyBsM3ZwbkBpZXRmLm9yZw0KPlN1YmplY3Q6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXpoYW5nLWwzdnBuLWxhYmVsLXNoYXJpbmctMDAudHh0DQo+DQo+SGkgTWlu Z3VpLA0KPg0KPkkgY291bGRu4oCZdCBzZWUgYW55IHBvaW50IG1lbnRpb25lZCBpbiB0aGlzIGRy YWZ0IG9uIGhvdyBlZ3Jlc3MgUEVzIHdpbGwgYXNzaWduDQo+c2FtZSBWUE4gbGFiZWwgZm9yIHRo ZSBwcmVmaXguDQo+DQo+Q2FuIHlvdSBwbGVhc2Ugc2hhcmUgdGhlIHNhbWU/LiBTb3JyeSwgaWYg SSBhbSBtaXNzaW5nIHNvbWV0aGluZyBpbiB0aGUgZG9jLg0KPg0KPlJlZ2FyZHMsDQo+bmFnZW5k cmENCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IGwzdnBuLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpsM3Zwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj5N aW5ndWkgWmhhbmcNCj5TZW50OiBGcmlkYXksIEp1bHkgMTksIDIwMTMgMToxNiBQTQ0KPlRvOiBs M3ZwbkBpZXRmLm9yZw0KPlN1YmplY3Q6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LXpoYW5nLWwzdnBuLWxhYmVsLXNoYXJpbmctMDAudHh0DQo+DQo+RGVhciBhbGwsDQo+ DQo+V2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQ6IExhYmVsIFNoYXJpbmcgZm9yIEZhc3Qg UEUgUHJvdGVjdGlvbi4NCj4NCj4gICBUaGlzIGRyYWZ0IGRlc2lnbnMgYSBzaW1wbGUgbWV0aG9k IHRvIGJlIHVzZWQgYnkgU1BzIHRvIGFjaGlldmUgZmFzdCBQRQ0KPnByb3RlY3Rpb24sIHV0aWxp emluZyB0aGUgZGVwbG95bWVudCBvZiByZWR1bmRhbnQgZWdyZXNzIFBFcy4NCj4NCj5Db21tZW50 cyBhcmUgd2VsY29tZS4NCj4NCj5SZWdhcmRzLA0KPk1pbmd1aQ0KPg0KPj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPg0KPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16aGFuZy1sM3Zw bi1sYWJlbC1zaGFyaW5nLTAwLnR4dA0KPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgTWluZ3VpIFpoYW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCj5yZXBvc2l0b3J5Lg0KPg0K PkZpbGVuYW1lOgkgZHJhZnQtemhhbmctbDN2cG4tbGFiZWwtc2hhcmluZw0KPlJldmlzaW9uOgkg MDANCj5UaXRsZToJCSBMYWJlbCBTaGFyaW5nIGZvciBGYXN0IFBFIFByb3RlY3Rpb24NCj5DcmVh dGlvbiBkYXRlOgkgMjAxMy0wNy0xMg0KPkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K Pk51bWJlciBvZiBwYWdlczogMTINCj5VUkw6DQo+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtemhhbmctbDN2cG4tbGFiZWwtc2hhcmluZy0wMC50eHQNCj5TdGF0dXM6 DQo+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFuZy1sM3Zwbi1sYWJl bC1zaGFyaW5nDQo+SHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC16aGFuZy1sM3Zwbi1sYWJlbC1zaGFyaW5nLTAwDQo+DQo+DQo+QWJzdHJhY3Q6DQo+ICAg VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZXRob2QgdG8gYmUgdXNlZCBieSBTZXJ2aWNlIFBy b3ZpZGVycyB0bw0KPiAgIHByb3ZpZGUgZmFzdCBwcm90ZWN0aW9uIG9mIFZQTiBjb25uZWN0aW9u cyBmb3IgYSBDRS4gRWdyZXNzIFBFcyBpbiBhDQo+ICAgcmVkdW5kYW50IGdyb3VwIGFsd2F5cyBh c3NpZ24gdGhlIHNhbWUgbGFiZWwgZm9yIFZQTiByb3V0ZXMgZnJvbSBhDQo+ICAgVlJGLiBUaGVz ZSBlZ3Jlc3MgUEVzIGNyZWF0ZSBhIEJHUCB2aXJ0dWFsIE5leHQgSG9wICh2TkgpIGluIHRoZQ0K PiAgIGRvbWFpbiBvZiB0aGUgSVAvTVBMUyBiYWNrYm9uZSBuZXR3b3JrIGFzIGFuIGFnZW50IG9m IHRoZSBDRSByb3V0ZXIuDQo+ICAgUHJpbWFyeSBhbmQgYmFja3VwIHR1bm5lbHMgdGVybWluYXRl ZCBhdCB0aGUgdk5IIGFyZSBzZXQgdXAgYnkgdGhlDQo+ICAgQkdQL01QTFMgSVAgVlBOIGJhc2Vk IG9uIElHUCBGUlIuIElmIHRoZSBwcmltYXJ5IGVncmVzcyBQRSBmYWlscywgdGhlDQo+ICAgYmFj a3VwIGVncmVzcyBQRXMgY2FuIHJlY29nbml6ZSB0aGUgInNoYXJlZCIgVlBOIHJvdXRlIGxhYmVs IGFuZA0KPiAgIGRlbGl2ZXIgdGhlIGZhaWx1cmUgYWZmZWN0ZWQgcGFja2V0cyBhY2NvcmRpbmds eS4NCj4NCj4NCj4NCj4NCj5UaGUgSUVURiBTZWNyZXRhcmlhdA0K From naikumar@cisco.com Fri Jul 19 01:55:33 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F71421E811D for ; Fri, 19 Jul 2013 01:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 q59LZeaWfvVo for ; Fri, 19 Jul 2013 01:55:27 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D242C11E80EC for ; Fri, 19 Jul 2013 01:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4360; q=dns/txt; s=iport; t=1374224127; x=1375433727; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=1/i48WiNz6UPu64wU6mXJDYUGu2ApwFJeQem8PSIcDw=; b=iEO8w8UDl7XQLQ6rs2tnfQKU6UGVWCxyxschb3oqb7ateGq/MnGacoRH D3sCFR/uPRLGkodZP2OcM8CLIT+gpSDpJDrWNLBBtz+bUQzMy2WjzoOcs BEL6FzZOwpna5bOYrA+y7O3fVIJQMrwYGXWsAYLHhSgkdfMkCqN7vFWGt s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAMT96FGtJV2a/2dsb2JhbABagwY1UIMGvT8XeBZ0giQBAQEEIxFDDgQCAQgRBAEBAwIGHQMCAgIwFAEICAIEARIIAYgHDKRjkUyBKI0cgRo4BoJVM24DmQaQJIMSgio X-IronPort-AV: E=Sophos;i="4.89,700,1367971200"; d="scan'208";a="236856937" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 19 Jul 2013 08:55:26 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6J8tQMo016771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Jul 2013 08:55:26 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.100]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 03:55:26 -0500 From: "Nagendra Kumar (naikumar)" To: Mingui Zhang , "l3vpn@ietf.org" Subject: RE: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt Thread-Topic: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt Thread-Index: AQHOgS6cBWFI1KLT1U2mnmg/9jFYHplrojgAgAALBLCAAF5RAP//rTjg Date: Fri, 19 Jul 2013 08:55:25 +0000 Message-ID: <47E76F08F1BCF5458111C1939C7B9C4610268C58@xmb-rcd-x03.cisco.com> References: <4552F0907735844E9204A62BBDD325E7335C721B@nkgeml508-mbx.china.huawei.com> <47E76F08F1BCF5458111C1939C7B9C4610268B3F@xmb-rcd-x03.cisco.com> <4552F0907735844E9204A62BBDD325E7335C727B@nkgeml508-mbx.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E7335C727B@nkgeml508-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.103.238.67] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 08:55:33 -0000 SGksDQoNClRoYW5rcy4gSXMgdGhlIHByb3Bvc2FsIGlzIHRvIG1hbnVhbGx5IGFzc2lnbi9jb25m aWd1cmUgaW4gZWFjaCBQRT8uDQoNCi1OYWdlbmRyYQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogTWluZ3VpIFpoYW5nIFttYWlsdG86emhhbmdtaW5ndWlAaHVhd2VpLmNvbV0g DQpTZW50OiBGcmlkYXksIEp1bHkgMTksIDIwMTMgMjoyMSBQTQ0KVG86IE5hZ2VuZHJhIEt1bWFy IChuYWlrdW1hcik7IGwzdnBuQGlldGYub3JnDQpTdWJqZWN0OiBSRTogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC16aGFuZy1sM3Zwbi1sYWJlbC1zaGFyaW5nLTAwLnR4dA0KDQpI aSBOYWdlbmRyYSwNCg0KSW4gdGhlIG1ldGhvZCwgdGhlIGVncmVzcyBQRXMgaW4gdGhlIFJHIGhh dmUgdG8gdXNlIHRoZSBzYW1lIFZQTiByb3V0ZSBsYWJlbCBmb3Igb25lIFZQTiBzaXRlIChlLmcu LCAxMTAwIGZvciBWUE4xKS4gDQpBcyBmb3IgdGhlIHByZWZpeCwgYWxsIHByZWZpeGVzIChlLmcu LCAxMC4xLjEuMC8yNCkgbGVhcm50IGZyb20gdGhpcyBWUE4gc2l0ZSB3aWxsIGJlIHN0b3JlZCBp biB0aGUgY29ycmVzcG9uZGluZyBWUkYgKGUuZy4sIFZQTjEnIFZQTiBpbnN0YW5jZSkgaWRlbnRp ZmllZCBieSB0aGUgVlBOIHJvdXRlIGxhYmVsLg0KDQpJIGd1ZXNzIHlvdSBwcm9wb3NlIHRvIHNo YXJlIHRoZSBsYWJlbCAicGVyLXByZWZpeCIuIEl0J3MgcG9zc2libGUgdG8gZG8gc28gYnV0IG5v dCBhcyBjb21tb24gYXMgdGhlICJwZXItVlJGIiBhc3NpZ25tZW50IGluIGN1cnJlbnQgcHJhY3Rp Y2UuIA0KDQpUaGFua3MsDQpNaW5ndWkNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ RnJvbTogTmFnZW5kcmEgS3VtYXIgKG5haWt1bWFyKSBbbWFpbHRvOm5haWt1bWFyQGNpc2NvLmNv bV0NCj5TZW50OiBGcmlkYXksIEp1bHkgMTksIDIwMTMgNDoxNSBQTQ0KPlRvOiBNaW5ndWkgWmhh bmc7IGwzdnBuQGlldGYub3JnDQo+U3ViamVjdDogUkU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgDQo+ZHJhZnQtemhhbmctbDN2cG4tbGFiZWwtc2hhcmluZy0wMC50eHQNCj4NCj5IaSBN aW5ndWksDQo+DQo+SSBjb3VsZG7igJl0IHNlZSBhbnkgcG9pbnQgbWVudGlvbmVkIGluIHRoaXMg ZHJhZnQgb24gaG93IGVncmVzcyBQRXMgd2lsbCANCj5hc3NpZ24gc2FtZSBWUE4gbGFiZWwgZm9y IHRoZSBwcmVmaXguDQo+DQo+Q2FuIHlvdSBwbGVhc2Ugc2hhcmUgdGhlIHNhbWU/LiBTb3JyeSwg aWYgSSBhbSBtaXNzaW5nIHNvbWV0aGluZyBpbiB0aGUgZG9jLg0KPg0KPlJlZ2FyZHMsDQo+bmFn ZW5kcmENCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IGwzdnBuLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpsM3Zwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgDQo+ T2YgTWluZ3VpIFpoYW5nDQo+U2VudDogRnJpZGF5LCBKdWx5IDE5LCAyMDEzIDE6MTYgUE0NCj5U bzogbDN2cG5AaWV0Zi5vcmcNCj5TdWJqZWN0OiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciANCj5kcmFmdC16aGFuZy1sM3Zwbi1sYWJlbC1zaGFyaW5nLTAwLnR4dA0KPg0KPkRlYXIg YWxsLA0KPg0KPldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0OiBMYWJlbCBTaGFyaW5nIGZv ciBGYXN0IFBFIFByb3RlY3Rpb24uDQo+DQo+ICAgVGhpcyBkcmFmdCBkZXNpZ25zIGEgc2ltcGxl IG1ldGhvZCB0byBiZSB1c2VkIGJ5IFNQcyB0byBhY2hpZXZlIGZhc3QgDQo+UEUgcHJvdGVjdGlv biwgdXRpbGl6aW5nIHRoZSBkZXBsb3ltZW50IG9mIHJlZHVuZGFudCBlZ3Jlc3MgUEVzLg0KPg0K PkNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KPg0KPlJlZ2FyZHMsDQo+TWluZ3VpDQo+DQo+Pi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+DQo+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXpo YW5nLWwzdnBuLWxhYmVsLXNoYXJpbmctMDAudHh0DQo+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBNaW5ndWkgWmhhbmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURiANCj5yZXBvc2l0 b3J5Lg0KPg0KPkZpbGVuYW1lOgkgZHJhZnQtemhhbmctbDN2cG4tbGFiZWwtc2hhcmluZw0KPlJl dmlzaW9uOgkgMDANCj5UaXRsZToJCSBMYWJlbCBTaGFyaW5nIGZvciBGYXN0IFBFIFByb3RlY3Rp b24NCj5DcmVhdGlvbiBkYXRlOgkgMjAxMy0wNy0xMg0KPkdyb3VwOgkJIEluZGl2aWR1YWwgU3Vi bWlzc2lvbg0KPk51bWJlciBvZiBwYWdlczogMTINCj5VUkw6DQo+aHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtemhhbmctbDN2cG4tbGFiZWwtc2hhcmluZy0wMC4NCj50 eHQNCj5TdGF0dXM6DQo+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFu Zy1sM3Zwbi1sYWJlbC1zaGFyaW5nDQo+SHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1sM3Zwbi1sYWJlbC1zaGFyaW5nLTAwDQo+DQo+DQo+QWJz dHJhY3Q6DQo+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZXRob2QgdG8gYmUgdXNlZCBi eSBTZXJ2aWNlIFByb3ZpZGVycyB0bw0KPiAgIHByb3ZpZGUgZmFzdCBwcm90ZWN0aW9uIG9mIFZQ TiBjb25uZWN0aW9ucyBmb3IgYSBDRS4gRWdyZXNzIFBFcyBpbiBhDQo+ICAgcmVkdW5kYW50IGdy b3VwIGFsd2F5cyBhc3NpZ24gdGhlIHNhbWUgbGFiZWwgZm9yIFZQTiByb3V0ZXMgZnJvbSBhDQo+ ICAgVlJGLiBUaGVzZSBlZ3Jlc3MgUEVzIGNyZWF0ZSBhIEJHUCB2aXJ0dWFsIE5leHQgSG9wICh2 TkgpIGluIHRoZQ0KPiAgIGRvbWFpbiBvZiB0aGUgSVAvTVBMUyBiYWNrYm9uZSBuZXR3b3JrIGFz IGFuIGFnZW50IG9mIHRoZSBDRSByb3V0ZXIuDQo+ICAgUHJpbWFyeSBhbmQgYmFja3VwIHR1bm5l bHMgdGVybWluYXRlZCBhdCB0aGUgdk5IIGFyZSBzZXQgdXAgYnkgdGhlDQo+ICAgQkdQL01QTFMg SVAgVlBOIGJhc2VkIG9uIElHUCBGUlIuIElmIHRoZSBwcmltYXJ5IGVncmVzcyBQRSBmYWlscywg dGhlDQo+ICAgYmFja3VwIGVncmVzcyBQRXMgY2FuIHJlY29nbml6ZSB0aGUgInNoYXJlZCIgVlBO IHJvdXRlIGxhYmVsIGFuZA0KPiAgIGRlbGl2ZXIgdGhlIGZhaWx1cmUgYWZmZWN0ZWQgcGFja2V0 cyBhY2NvcmRpbmdseS4NCj4NCj4NCj4NCj4NCj5UaGUgSUVURiBTZWNyZXRhcmlhdA0K From zhangmingui@huawei.com Fri Jul 19 02:01:51 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A55A11E80EC for ; Fri, 19 Jul 2013 02:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.518 X-Spam-Level: X-Spam-Status: No, score=-7.518 tagged_above=-999 required=5 tests=[AWL=-0.918, BAYES_00=-2.599, 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 jC38Ya3v+2dQ for ; Fri, 19 Jul 2013 02:01:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F14D211E8205 for ; Fri, 19 Jul 2013 02:01:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVF28810; Fri, 19 Jul 2013 09:01:42 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 10:00:43 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 10:01:41 +0100 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.110]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.01.0323.007; Fri, 19 Jul 2013 17:01:37 +0800 From: Mingui Zhang To: "Nagendra Kumar (naikumar)" , "l3vpn@ietf.org" Subject: RE: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt Thread-Topic: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt Thread-Index: AQHOhFgrKKi7/uR8Ek+T5dv9lOYSXplrqOlw//+DtYCAAIaDQA== Date: Fri, 19 Jul 2013 09:01:36 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7335C72AB@nkgeml508-mbx.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E7335C721B@nkgeml508-mbx.china.huawei.com> <47E76F08F1BCF5458111C1939C7B9C4610268B3F@xmb-rcd-x03.cisco.com> <4552F0907735844E9204A62BBDD325E7335C727B@nkgeml508-mbx.china.huawei.com> <47E76F08F1BCF5458111C1939C7B9C4610268C58@xmb-rcd-x03.cisco.com> In-Reply-To: <47E76F08F1BCF5458111C1939C7B9C4610268C58@xmb-rcd-x03.cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 09:01:51 -0000 SGkgTmFnZW5kcmEsDQoNCkl0IGNhbiBhbHNvIGJlIGF1dG9tYXRpY2FsbHkgbmVnb3RpYXRlZCB0 aHJvdWdoIHNpZ25hbGluZyBhbW9uZyB0aG9zZSBlZ3Jlc3MgUEVzLiBJIGhhdmUgY29tcG9zZWQg dGhlIGZvbGxvd2luZyBkcmFmdCBmb3IgdGhpcyBwb2ludC4NCklDQ1AgQXBwbGljYXRpb24gVExW cyBmb3IgVlBOIFJvdXRlIExhYmVsIFNoYXJpbmcgLSBNaW5ndWkgWkhBTkcNCmh0dHA6Ly93d3cu aWV0Zi5vcmcvaWQvZHJhZnQtemhhbmctcHdlMy1pY2NwLWxhYmVsLXNoYXJpbmctMDAudHh0DQoN ClRoYW5rcywNCk1pbmd1aQ0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBO YWdlbmRyYSBLdW1hciAobmFpa3VtYXIpIFttYWlsdG86bmFpa3VtYXJAY2lzY28uY29tXQ0KPlNl bnQ6IEZyaWRheSwgSnVseSAxOSwgMjAxMyA0OjU1IFBNDQo+VG86IE1pbmd1aSBaaGFuZzsgbDN2 cG5AaWV0Zi5vcmcNCj5TdWJqZWN0OiBSRTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC16aGFuZy1sM3Zwbi1sYWJlbC1zaGFyaW5nLTAwLnR4dA0KPg0KPkhpLA0KPg0KPlRoYW5r cy4gSXMgdGhlIHByb3Bvc2FsIGlzIHRvIG1hbnVhbGx5IGFzc2lnbi9jb25maWd1cmUgaW4gZWFj aCBQRT8uDQo+DQo+LU5hZ2VuZHJhDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5G cm9tOiBNaW5ndWkgWmhhbmcgW21haWx0bzp6aGFuZ21pbmd1aUBodWF3ZWkuY29tXQ0KPlNlbnQ6 IEZyaWRheSwgSnVseSAxOSwgMjAxMyAyOjIxIFBNDQo+VG86IE5hZ2VuZHJhIEt1bWFyIChuYWlr dW1hcik7IGwzdnBuQGlldGYub3JnDQo+U3ViamVjdDogUkU6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtemhhbmctbDN2cG4tbGFiZWwtc2hhcmluZy0wMC50eHQNCj4NCj5IaSBO YWdlbmRyYSwNCj4NCj5JbiB0aGUgbWV0aG9kLCB0aGUgZWdyZXNzIFBFcyBpbiB0aGUgUkcgaGF2 ZSB0byB1c2UgdGhlIHNhbWUgVlBOIHJvdXRlIGxhYmVsDQo+Zm9yIG9uZSBWUE4gc2l0ZSAoZS5n LiwgMTEwMCBmb3IgVlBOMSkuDQo+QXMgZm9yIHRoZSBwcmVmaXgsIGFsbCBwcmVmaXhlcyAoZS5n LiwgMTAuMS4xLjAvMjQpIGxlYXJudCBmcm9tIHRoaXMgVlBOIHNpdGUgd2lsbCBiZQ0KPnN0b3Jl ZCBpbiB0aGUgY29ycmVzcG9uZGluZyBWUkYgKGUuZy4sIFZQTjEnIFZQTiBpbnN0YW5jZSkgaWRl bnRpZmllZCBieSB0aGUgVlBODQo+cm91dGUgbGFiZWwuDQo+DQo+SSBndWVzcyB5b3UgcHJvcG9z ZSB0byBzaGFyZSB0aGUgbGFiZWwgInBlci1wcmVmaXgiLiBJdCdzIHBvc3NpYmxlIHRvIGRvIHNv IGJ1dCBub3QNCj5hcyBjb21tb24gYXMgdGhlICJwZXItVlJGIiBhc3NpZ25tZW50IGluIGN1cnJl bnQgcHJhY3RpY2UuDQo+DQo+VGhhbmtzLA0KPk1pbmd1aQ0KPg0KPj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj5Gcm9tOiBOYWdlbmRyYSBLdW1hciAobmFpa3VtYXIpIFttYWlsdG86bmFp a3VtYXJAY2lzY28uY29tXQ0KPj5TZW50OiBGcmlkYXksIEp1bHkgMTksIDIwMTMgNDoxNSBQTQ0K Pj5UbzogTWluZ3VpIFpoYW5nOyBsM3ZwbkBpZXRmLm9yZw0KPj5TdWJqZWN0OiBSRTogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPj5kcmFmdC16aGFuZy1sM3Zwbi1sYWJlbC1zaGFyaW5n LTAwLnR4dA0KPj4NCj4+SGkgTWluZ3VpLA0KPj4NCj4+SSBjb3VsZG7igJl0IHNlZSBhbnkgcG9p bnQgbWVudGlvbmVkIGluIHRoaXMgZHJhZnQgb24gaG93IGVncmVzcyBQRXMgd2lsbA0KPj5hc3Np Z24gc2FtZSBWUE4gbGFiZWwgZm9yIHRoZSBwcmVmaXguDQo+Pg0KPj5DYW4geW91IHBsZWFzZSBz aGFyZSB0aGUgc2FtZT8uIFNvcnJ5LCBpZiBJIGFtIG1pc3Npbmcgc29tZXRoaW5nIGluIHRoZSBk b2MuDQo+Pg0KPj5SZWdhcmRzLA0KPj5uYWdlbmRyYQ0KPj4NCj4+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+RnJvbTogbDN2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwzdnBuLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPj5PZiBNaW5ndWkgWmhhbmcNCj4+U2VudDogRnJp ZGF5LCBKdWx5IDE5LCAyMDEzIDE6MTYgUE0NCj4+VG86IGwzdnBuQGlldGYub3JnDQo+PlN1Ympl Y3Q6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+PmRyYWZ0LXpoYW5nLWwzdnBu LWxhYmVsLXNoYXJpbmctMDAudHh0DQo+Pg0KPj5EZWFyIGFsbCwNCj4+DQo+PldlIGhhdmUgc3Vi bWl0dGVkIGEgbmV3IGRyYWZ0OiBMYWJlbCBTaGFyaW5nIGZvciBGYXN0IFBFIFByb3RlY3Rpb24u DQo+Pg0KPj4gICBUaGlzIGRyYWZ0IGRlc2lnbnMgYSBzaW1wbGUgbWV0aG9kIHRvIGJlIHVzZWQg YnkgU1BzIHRvIGFjaGlldmUgZmFzdA0KPj5QRSBwcm90ZWN0aW9uLCB1dGlsaXppbmcgdGhlIGRl cGxveW1lbnQgb2YgcmVkdW5kYW50IGVncmVzcyBQRXMuDQo+Pg0KPj5Db21tZW50cyBhcmUgd2Vs Y29tZS4NCj4+DQo+PlJlZ2FyZHMsDQo+Pk1pbmd1aQ0KPj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+Pg0KPj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtemhhbmctbDN2cG4t bGFiZWwtc2hhcmluZy0wMC50eHQNCj4+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBNaW5ndWkgWmhhbmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURg0KPj5yZXBvc2l0b3J5Lg0KPj4N Cj4+RmlsZW5hbWU6CSBkcmFmdC16aGFuZy1sM3Zwbi1sYWJlbC1zaGFyaW5nDQo+PlJldmlzaW9u OgkgMDANCj4+VGl0bGU6CQkgTGFiZWwgU2hhcmluZyBmb3IgRmFzdCBQRSBQcm90ZWN0aW9uDQo+ PkNyZWF0aW9uIGRhdGU6CSAyMDEzLTA3LTEyDQo+Pkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlz c2lvbg0KPj5OdW1iZXIgb2YgcGFnZXM6IDEyDQo+PlVSTDoNCj4+aHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtemhhbmctbDN2cG4tbGFiZWwtc2hhcmluZy0wMC4NCj4+ dHh0DQo+PlN0YXR1czoNCj4+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16 aGFuZy1sM3Zwbi1sYWJlbC1zaGFyaW5nDQo+Pkh0bWxpemVkOg0KPmh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXpoYW5nLWwzdnBuLWxhYmVsLXNoYXJpbmctMDANCj4+DQo+Pg0KPj5B YnN0cmFjdDoNCj4+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZXRob2QgdG8gYmUgdXNl ZCBieSBTZXJ2aWNlIFByb3ZpZGVycyB0bw0KPj4gICBwcm92aWRlIGZhc3QgcHJvdGVjdGlvbiBv ZiBWUE4gY29ubmVjdGlvbnMgZm9yIGEgQ0UuIEVncmVzcyBQRXMgaW4gYQ0KPj4gICByZWR1bmRh bnQgZ3JvdXAgYWx3YXlzIGFzc2lnbiB0aGUgc2FtZSBsYWJlbCBmb3IgVlBOIHJvdXRlcyBmcm9t IGENCj4+ICAgVlJGLiBUaGVzZSBlZ3Jlc3MgUEVzIGNyZWF0ZSBhIEJHUCB2aXJ0dWFsIE5leHQg SG9wICh2TkgpIGluIHRoZQ0KPj4gICBkb21haW4gb2YgdGhlIElQL01QTFMgYmFja2JvbmUgbmV0 d29yayBhcyBhbiBhZ2VudCBvZiB0aGUgQ0Ugcm91dGVyLg0KPj4gICBQcmltYXJ5IGFuZCBiYWNr dXAgdHVubmVscyB0ZXJtaW5hdGVkIGF0IHRoZSB2TkggYXJlIHNldCB1cCBieSB0aGUNCj4+ICAg QkdQL01QTFMgSVAgVlBOIGJhc2VkIG9uIElHUCBGUlIuIElmIHRoZSBwcmltYXJ5IGVncmVzcyBQ RSBmYWlscywgdGhlDQo+PiAgIGJhY2t1cCBlZ3Jlc3MgUEVzIGNhbiByZWNvZ25pemUgdGhlICJz aGFyZWQiIFZQTiByb3V0ZSBsYWJlbCBhbmQNCj4+ICAgZGVsaXZlciB0aGUgZmFpbHVyZSBhZmZl Y3RlZCBwYWNrZXRzIGFjY29yZGluZ2x5Lg0KPj4NCj4+DQo+Pg0KPj4NCj4+VGhlIElFVEYgU2Vj cmV0YXJpYXQNCg== From wim.henderickx@alcatel-lucent.com Fri Jul 19 04:32:35 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB2911E80F8 for ; Fri, 19 Jul 2013 04:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 zEp-n0a284ON for ; Fri, 19 Jul 2013 04:32:29 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id B8DFA11E8105 for ; Fri, 19 Jul 2013 04:32:28 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r6JBWJnj012004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 19 Jul 2013 06:32:20 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6JBWITe003702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Jul 2013 13:32:18 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.63]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 19 Jul 2013 13:32:19 +0200 From: "Henderickx, Wim (Wim)" To: Mingui Zhang , "Nagendra Kumar (naikumar)" , "l3vpn@ietf.org" Subject: Re: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt Thread-Topic: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt Thread-Index: AQHOhHOgZwV64qzptka+krxgl0LZJQ== Date: Fri, 19 Jul 2013 11:32:18 +0000 Message-ID: In-Reply-To: <4552F0907735844E9204A62BBDD325E7335C72AB@nkgeml508-mbx.china.huawei.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7A70360DA711C545B0DFCF1824A2E8F8@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 11:32:35 -0000 What you are trying to achieve can be done with Ctxt labels using locally assigned labels. So no need for global labels. On 19/07/13 11:01, "Mingui Zhang" wrote: >Hi Nagendra, > >It can also be automatically negotiated through signaling among those >egress PEs. I have composed the following draft for this point. >ICCP Application TLVs for VPN Route Label Sharing - Mingui ZHANG >http://www.ietf.org/id/draft-zhang-pwe3-iccp-label-sharing-00.txt > >Thanks, >Mingui > >>-----Original Message----- >>From: Nagendra Kumar (naikumar) [mailto:naikumar@cisco.com] >>Sent: Friday, July 19, 2013 4:55 PM >>To: Mingui Zhang; l3vpn@ietf.org >>Subject: RE: New Version Notification for >>draft-zhang-l3vpn-label-sharing-00.txt >> >>Hi, >> >>Thanks. Is the proposal is to manually assign/configure in each PE?. >> >>-Nagendra >> >>-----Original Message----- >>From: Mingui Zhang [mailto:zhangmingui@huawei.com] >>Sent: Friday, July 19, 2013 2:21 PM >>To: Nagendra Kumar (naikumar); l3vpn@ietf.org >>Subject: RE: New Version Notification for >>draft-zhang-l3vpn-label-sharing-00.txt >> >>Hi Nagendra, >> >>In the method, the egress PEs in the RG have to use the same VPN route >>label >>for one VPN site (e.g., 1100 for VPN1). >>As for the prefix, all prefixes (e.g., 10.1.1.0/24) learnt from this VPN >>site will be >>stored in the corresponding VRF (e.g., VPN1' VPN instance) identified by >>the VPN >>route label. >> >>I guess you propose to share the label "per-prefix". It's possible to do >>so but not >>as common as the "per-VRF" assignment in current practice. >> >>Thanks, >>Mingui >> >>>-----Original Message----- >>>From: Nagendra Kumar (naikumar) [mailto:naikumar@cisco.com] >>>Sent: Friday, July 19, 2013 4:15 PM >>>To: Mingui Zhang; l3vpn@ietf.org >>>Subject: RE: New Version Notification for >>>draft-zhang-l3vpn-label-sharing-00.txt >>> >>>Hi Mingui, >>> >>>I couldn=B9t see any point mentioned in this draft on how egress PEs wil= l >>>assign same VPN label for the prefix. >>> >>>Can you please share the same?. Sorry, if I am missing something in the >>>doc. >>> >>>Regards, >>>nagendra >>> >>>-----Original Message----- >>>From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf >>>Of Mingui Zhang >>>Sent: Friday, July 19, 2013 1:16 PM >>>To: l3vpn@ietf.org >>>Subject: FW: New Version Notification for >>>draft-zhang-l3vpn-label-sharing-00.txt >>> >>>Dear all, >>> >>>We have submitted a new draft: Label Sharing for Fast PE Protection. >>> >>> This draft designs a simple method to be used by SPs to achieve fast >>>PE protection, utilizing the deployment of redundant egress PEs. >>> >>>Comments are welcome. >>> >>>Regards, >>>Mingui >>> >>>>-----Original Message----- >>> >>>A new version of I-D, draft-zhang-l3vpn-label-sharing-00.txt >>>has been successfully submitted by Mingui Zhang and posted to the IETF >>>repository. >>> >>>Filename: draft-zhang-l3vpn-label-sharing >>>Revision: 00 >>>Title: Label Sharing for Fast PE Protection >>>Creation date: 2013-07-12 >>>Group: Individual Submission >>>Number of pages: 12 >>>URL: >>>http://www.ietf.org/internet-drafts/draft-zhang-l3vpn-label-sharing-00. >>>txt >>>Status: >>>http://datatracker.ietf.org/doc/draft-zhang-l3vpn-label-sharing >>>Htmlized: >>http://tools.ietf.org/html/draft-zhang-l3vpn-label-sharing-00 >>> >>> >>>Abstract: >>> This document describes a method to be used by Service Providers to >>> provide fast protection of VPN connections for a CE. Egress PEs in a >>> redundant group always assign the same label for VPN routes from a >>> VRF. These egress PEs create a BGP virtual Next Hop (vNH) in the >>> domain of the IP/MPLS backbone network as an agent of the CE router. >>> Primary and backup tunnels terminated at the vNH are set up by the >>> BGP/MPLS IP VPN based on IGP FRR. If the primary egress PE fails, the >>> backup egress PEs can recognize the "shared" VPN route label and >>> deliver the failure affected packets accordingly. >>> >>> >>> >>> >>>The IETF Secretariat From thomas.morin@orange.com Fri Jul 19 06:18:28 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE30121F99DA for ; Fri, 19 Jul 2013 06:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] 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 bnf1rkv7o2JM for ; Fri, 19 Jul 2013 06:18:23 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6F24221F99A8 for ; Fri, 19 Jul 2013 06:18:23 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 48DE33B4FD8; Fri, 19 Jul 2013 15:18:20 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 285DD4C015; Fri, 19 Jul 2013 15:18:20 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Fri, 19 Jul 2013 15:18:19 +0200 From: To: Xuxiaohu , L3VPN Subject: Re: The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOhIJvNVczrDWN+0+O/Ezo7cRjpg== Date: Fri, 19 Jul 2013 13:18:19 +0000 Message-ID: <9252_1374239900_51E93C9C_9252_4871_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D0751AC91@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D6B60@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D6B60@NKGEML512-MBS.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="utf-8" Content-ID: <115C348CF9BA0B40A6D9A0DFFC0AC9E8@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.19.91235 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 13:18:28 -0000 SGkgWHV4aWFvaHUsDQoNCjIwMTMtMDctMTgsIFh1eGlhb2h1Og0KPg0KPiBUaWxsIG5vdywgaXQg c2VlbSB0aGF0IHRoZSBvbmx5IHJlbWFpbmluZyB0ZWNobmljYWwgcmVhc29uIGZvciBzb21lDQo+ IHBlb3BsZSB0byBwcmVmZXIgVlhMQU4vTlZHUkUgZW5jYXBzdWxhdGlvbiBmb3JtYXQgdG8NCj4g TUFDLWluLU1QTFMtaW4tSVAgZW5jYXBzdWxhdGlvbiBmb3JtYXQgZm9yIG5ldHdvcmsgdmlydHVh bGl6YXRpb24NCj4gb3ZlcmxheSBpcyB0aGUgZm9ybWVyIGhhcyBnbG9iYWwgVk5JcyB3aGlsZSB0 aGUgbGF0dGVyIGRvZXNuJ3QgaGF2ZS4NCj4gSWYgdGhpcyByZWFzb24gaXMgdHJ1ZSwgd2h5IGNh bid0IHdlIGNvbnNpZGVyIHRoZSBwb3NzaWJpbGl0eSBvZg0KPiB1c2luZyBnbG9iYWwgTVBMUyBs YWJlbHMgdG8gYWNoaWV2ZSB0aGUgc2FtZSBnb2FsPw0KDQpJTUhPLCBleGFtaW5pbmcgKndoeSog c29tZW9uZSB3b3VsZCB3YW50IGEgImdsb2JhbCBWTkkiIHNob3VsZCBiZSB0aGUgDQpzdGFydCBv ZiB0aGUgZGlzY3Vzc2lvbiwgcmF0aGVyIHRoYW4gcG9zc2libGUgc29sdXRpb25zLg0KDQpJIGNv dWxkIHBvc3NpYmx5IHNlZSBhdCBsZWFzdCBvbmUgcmVhc29uICpub3QqIHRvIHRyeSB0byBoYXZl IGEgDQpkZWRpY2F0ZWQgaWRlbnRpZmllciBpbiB0aGUgZGF0YXBsYW5lIGNvbW1vbiBmb3IgYWxs IGZsb3dzIG9mICJhIFZQTiIuIA0KSXQgaXMgbm90IHJlbGF0ZWQgdG8gdGhlIGVuY2Fwc3VsYXRp b24sIGJ1dCB0byB0aGUgZmFjdCB0aGF0IFJGQzQzNjQgDQpoYXMsIGluIGZhY3QsIG5vIHN0cmlj dCBub3Rpb24gb2YgImEgVlBOIiwgYnV0IG9ubHkgb2YgaG93IGNvbm5lY3Rpdml0eSANCmlzIGVz dGFibGlzaGVkIGJldHdlZW5zIHNldCBvZiBWUkZzLg0KDQotVGhvbWFzDQoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2Ug bWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3Jt YXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25j CnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9u LiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNp Z25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2Vz IGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBk J2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1l c3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2 aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hv dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0 aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVz c2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFu ayB5b3UuCgo= From yakov@juniper.net Fri Jul 19 06:23:28 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDB411E8117 for ; Fri, 19 Jul 2013 06:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 ULfOwWiRqEad for ; Fri, 19 Jul 2013 06:23:22 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0248.outbound.messaging.microsoft.com [213.199.154.248]) by ietfa.amsl.com (Postfix) with ESMTP id 49B8011E8128 for ; Fri, 19 Jul 2013 06:23:21 -0700 (PDT) Received: from mail78-db9-R.bigfish.com (10.174.16.247) by DB9EHSOBE024.bigfish.com (10.174.14.87) with Microsoft SMTP Server id 14.1.225.22; Fri, 19 Jul 2013 13:23:20 +0000 Received: from mail78-db9 (localhost [127.0.0.1]) by mail78-db9-R.bigfish.com (Postfix) with ESMTP id 2EFA71E0065; Fri, 19 Jul 2013 13:23:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VPS1(zcb8kz936eI1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h668h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1155h) Received-SPF: pass (mail78-db9: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=yakov@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail78-db9 (localhost.localdomain [127.0.0.1]) by mail78-db9 (MessageSwitch) id 1374240199245598_16077; Fri, 19 Jul 2013 13:23:19 +0000 (UTC) Received: from DB9EHSMHS026.bigfish.com (unknown [10.174.16.235]) by mail78-db9.bigfish.com (Postfix) with ESMTP id 2974522007C; Fri, 19 Jul 2013 13:23:19 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.53) by DB9EHSMHS026.bigfish.com (10.174.14.36) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 19 Jul 2013 13:23:16 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 19 Jul 2013 06:23:14 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r6JDNBL44457; Fri, 19 Jul 2013 06:23:12 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201307191323.r6JDNBL44457@magenta.juniper.net> To: Subject: Re: The possibility of using global MPLS labels as VNIs ... for l3vpn In-Reply-To: <9252_1374239900_51E93C9C_9252_4871_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D0751AC91@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D6B60@NKGEML512-MBS.china.huawei.com> <9252_1374239900_51E93C9C_9252_4871_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D0751AC91@PEXCVZYM13.corporate.adroot.infra.ftgroup> X-MH-In-Reply-To: message dated "Fri, 19 Jul 2013 13:18:19 -0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <518.1374240191.1@juniper.net> Date: Fri, 19 Jul 2013 06:23:11 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 13:23:28 -0000 Thomas, > 2013-07-18, Xuxiaohu: > > > > Till now, it seem that the only remaining technical reason for some > > people to prefer VXLAN/NVGRE encapsulation format to > > MAC-in-MPLS-in-IP encapsulation format for network virtualization > > overlay is the former has global VNIs while the latter doesn't have. > > If this reason is true, why can't we consider the possibility of > > using global MPLS labels to achieve the same goal? > > IMHO, examining *why* someone would want a "global VNI" should be the > start of the discussion, rather than possible solutions. > > I could possibly see at least one reason *not* to try to have a > dedicated identifier in the dataplane common for all flows of "a VPN". > It is not related to the encapsulation, but to the fact that RFC4364 > has, in fact, no strict notion of "a VPN", but only of how connectivity > is established betweens set of VRFs. Moreover, connectivity between set of VRFs is not "cast in concrete". To the contrary it could change, as extranets are formed/dissolved, and the process of forming/dissolving extranets could be fairly dynamic. Yakov. > > -Thomas > > ______________________________________________________________________________ ___________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentie lles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages elect roniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou fal sifie. Merci. > > This message and its attachments may contain confidential or privileged inform ation that may be protected by law; > they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete th is message and its attachments. > As emails may be altered, Orange is not liable for messages that have been mod ified, changed or falsified. > Thank you. > > From rajiva@cisco.com Fri Jul 19 06:34:13 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C285721F99CF for ; Fri, 19 Jul 2013 06:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] 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 ALuGsfBrPgmK for ; Fri, 19 Jul 2013 06:34:09 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E6F8321F8B04 for ; Fri, 19 Jul 2013 06:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3089; q=dns/txt; s=iport; t=1374240849; x=1375450449; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=b4Fm9OTOPjxL7BMENwiWQEKNECHAQl5c5XzZUoJDV3c=; b=jSYPFYTPI1sXUF/45HyMLlhE8BYPXwkZGSWwe9LRmZufwv/QN3Xe550f 45TPM2SiJtcHd7Zn8vTgvgECOLKKCZ/j6JWAFTzi6qQLNlPiCgSHm4Z2h 9DurAVImRtesXKXO0z/Nc3PsrkEsWvhna2lLPiM/ZVZvDosRdYmB0wK2w E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAK0/6VGtJV2b/2dsb2JhbABagwY1UMBGgRAWdIIkAQEBAwE6PwUHBgEIEQMBAgsUQh0IAgQBDQUIE4dvBgy2eo5NgRExBwaDCm4DmQaQJIMSgXE5 X-IronPort-AV: E=Sophos;i="4.89,701,1367971200"; d="scan'208";a="236907000" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 19 Jul 2013 13:34:08 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6JDY8im004623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Jul 2013 13:34:08 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.251]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 08:34:07 -0500 From: "Rajiv Asati (rajiva)" To: Yakov Rekhter , "thomas.morin@orange.com" Subject: Re: The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOhIJ8gDu41UJ+8E+6OfnaOq4tRZlsUQeA//+/9oA= Date: Fri, 19 Jul 2013 13:34:06 +0000 Message-ID: In-Reply-To: <201307191323.r6JDNBL44457@magenta.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.82.251.115] Content-Type: text/plain; charset="us-ascii" Content-ID: <3E56FF543FFF9540933A072B2B149828@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 13:34:13 -0000 > IMHO, examining *why* someone would want a "global VNI" should be the > start of the discussion, rather than possible solutions. +1. > It is not related to the encapsulation, but to the fact that RFC4364 > has, in fact, no strict notion of "a VPN", but only of how connectivity > is established betweens set of VRFs. I find http://tools.ietf.org/html/rfc4364#section-1.1 sufficiently describing the notion of VPN (which could be intranet or extranet). Cheers Rajiv -----Original Message----- From: Yakov Rekhter Date: Friday, July 19, 2013 9:23 AM To: "thomas.morin@orange.com" Cc: "l3vpn@ietf.org" Subject: Re: The possibility of using global MPLS labels as VNIs ... for l3vpn >Thomas, > >> 2013-07-18, Xuxiaohu: >> > >> > Till now, it seem that the only remaining technical reason for some >> > people to prefer VXLAN/NVGRE encapsulation format to >> > MAC-in-MPLS-in-IP encapsulation format for network virtualization >> > overlay is the former has global VNIs while the latter doesn't have. >> > If this reason is true, why can't we consider the possibility of >> > using global MPLS labels to achieve the same goal? >>=20 >> IMHO, examining *why* someone would want a "global VNI" should be the >> start of the discussion, rather than possible solutions. >>=20 >> I could possibly see at least one reason *not* to try to have a >> dedicated identifier in the dataplane common for all flows of "a VPN". >> It is not related to the encapsulation, but to the fact that RFC4364 >> has, in fact, no strict notion of "a VPN", but only of how connectivity >> is established betweens set of VRFs. > >Moreover, connectivity between set of VRFs is not "cast in concrete". >To the contrary it could change, as extranets are formed/dissolved, >and the process of forming/dissolving extranets could be fairly >dynamic. > >Yakov. > >>=20 >> -Thomas >>=20 >>=20 >>_________________________________________________________________________ >>_____ >___________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations >>confidentie >lles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>recu ce > message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les >>messages elect >roniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme >>ou fal >sifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileged >>inform >ation that may be protected by law; >> they should not be distributed, used or copied without authorisation. >If you have received this email in error, please notify the sender and >delete th >is message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >>been mod >ified, changed or falsified. >> Thank you. >>=20 >>=20 > From thomas.morin@orange.com Fri Jul 19 08:09:28 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DF621E80C8 for ; Fri, 19 Jul 2013 08:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] 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 Q6yH0dIklQvx for ; Fri, 19 Jul 2013 08:09:24 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1D311E8251 for ; Fri, 19 Jul 2013 08:09:20 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 65F9618C346; Fri, 19 Jul 2013 17:09:19 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 45C0627C067; Fri, 19 Jul 2013 17:09:19 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Fri, 19 Jul 2013 17:09:18 +0200 From: To: "l3vpn@ietf.org" Subject: Re: IETF 87 - L3VPN - Agenda Thread-Topic: IETF 87 - L3VPN - Agenda Thread-Index: AQHOgjObn7wemWnpH02/QffD1i5WXplr/fIA Date: Fri, 19 Jul 2013 15:09:18 +0000 Message-ID: <2955_1374246559_51E9569F_2955_4121_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D0751BEAF@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <51E55D53.9030307@alcatel-lucent.com> In-Reply-To: <51E55D53.9030307@alcatel-lucent.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.19.91235 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 15:09:29 -0000 SGVsbG8gV0csDQoNClBsZWFzZSBiZSBhd2FyZSB0aGF0IHdlLCBsM3ZwbiBjby1jaGFpcnMsIGFy ZSBjdXJyZW50bHkgd29ya2luZyBvbiANCmFkYXB0aW5nIHRoZSBpbml0aWFsIGFnZW5kYSBwb3N0 ZWQgMyBkYXlzIGFnbyB0byBhZGRyZXNzIHNsb3QgcmVxdWVzdHMgDQpmb3IgYWxsIGRyYWZ0cyBv biB0b3BpY3MgcmVsYXRlZCB0byB0aGUgZGF0YWNlbnRlciBhbmQgdGhlaXIgDQppbnRlcmNvbm5l Y3Rpb25zIChpbmNsdWRpbmcgDQpkcmFmdC1kcmFvLWJncC1sM3Zwbi12aXJ0dWFsLW5ldHdvcmst b3ZlcmxheXMgYW5kIA0KZHJhZnQtZHJhby1sM3Zwbi12aXJ0dWFsLW5ldHdvcmstb3ZlcmxheS1t dWx0aWNhc3QgdGhhdCBoYWQgbm90IGJlZW4gDQppbmNsdWRlZCBpbiBvdXIgaW5pdGlhbCBkcmFm dCBhZ2VuZGEpLCBrZWVwaW5nIGluIG1pbmQgdGhhdCBmaW5hbCANCmFnZW5kYXMgYXJlIGR1ZSBu ZXh0IE1vbmRheSBVVEMgMjQ6MDAuDQoNCldlIG1pZ2h0IGhhdmUgdG8gYWxsb2NhdGUgbGVzcyB0 aW1lIG9yIG5vIHRpbWUgdG8gc29tZSBkcmFmdHMgdGhhdCB3ZXJlIA0KaW4gb3VyIGluaXRpYWwg ZHJhZnQgYWdlbmRhLg0KDQpUaGFua3MgZm9yIHlvdXIgdW5kZXJzdGFuZGluZywNCg0KLVRob21h cyBhbmQgTWFydGluDQoNCg0KDQoyMDEzLTA3LTE2LCBNYXJ0aW4gVmlnb3VyZXV4Og0KPiBBbGws DQo+DQo+IHRoZSBkcmFmdCBhZ2VuZGEgaXMgb25saW5lOg0KPiBodHRwOi8vd3d3LmlldGYub3Jn L3Byb2NlZWRpbmdzLzg3L2FnZW5kYS9hZ2VuZGEtODctbDN2cG4NCj4NCj4gUGxlYXNlIGJlIHJl YWR5IHRvIHNlbmQgeW91ciBzbGlkZXMuDQo+DQo+IC1tDQoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNv bmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJl IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEg bCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMu IExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRp b24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGlu Zm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBi ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1h aWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhh dCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From agmalis@gmail.com Fri Jul 19 08:20:24 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6506D21F9EA3; Fri, 19 Jul 2013 08:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] 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 4ap-Yv49K2Ei; Fri, 19 Jul 2013 08:20:23 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A26CD11E82B3; Fri, 19 Jul 2013 08:20:20 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z11so661707wgg.5 for ; Fri, 19 Jul 2013 08:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sjmvat08ZafOSqzBFamY3CqLovCR5XyMIXAz3RDiHMk=; b=si/crtw6NZrrt18fMHFCVKiIGSa8IQeFYtOKtkM3FnArdtgN1QDuY/u0OfgHMZ0rB7 ZybiVflCh0nbZZmHqvhfrRpy/6DQwkHJqSReShsZAM524oQlGi2Yrx4DMto8BB8qvSIK RxXBdWJ0Q3Sj3fjdXnWjFCYJRGd3YVnpppfCpSBEfHcNr+XJPZzre+sBGzwE+UqHslet rTbuZW8CPZYN5n0B7zcMpFUhVWrebdqkHwvb5tgclII8H5pg40bAvotiwfdKl+EiFABZ B5Tf9PZs+2aLMHXV0i3AlyQRrvgjxAEIj+nNd8J5oipar/1rv6N0rXJ7up1LKBHPlHXF BTlA== X-Received: by 10.180.20.228 with SMTP id q4mr23143446wie.60.1374247217705; Fri, 19 Jul 2013 08:20:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.234.3 with HTTP; Fri, 19 Jul 2013 08:19:57 -0700 (PDT) In-Reply-To: <4552F0907735844E9204A62BBDD325E7335C720D@nkgeml508-mbx.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E7335C720D@nkgeml508-mbx.china.huawei.com> From: "Andrew G. Malis" Date: Fri, 19 Jul 2013 11:19:57 -0400 Message-ID: Subject: Re: [PWE3] FW: New Version Notification for draft-zhang-pwe3-iccp-label-sharing-00.txt To: Mingui Zhang Content-Type: multipart/alternative; boundary=f46d042184853eba4a04e1dedd29 Cc: "pwe3@ietf.org" , L3VPN list X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 15:20:24 -0000 --f46d042184853eba4a04e1dedd29 Content-Type: text/plain; charset=ISO-8859-1 All, Just to elaborate, there are two related drafts on this topic, http://www.ietf.org/id/draft-zhang-l3vpn-label-sharing-00.txt and http://www.ietf.org/internet-drafts/draft-zhang-pwe3-iccp-label-sharing-00.txt. Comments should probably go to both the l3vpn and pwe3 lists for now. Mingui will have a presentation on these drafts in both the l3vpn and pwe3 sessions in Berlin. Thanks, Andy On Fri, Jul 19, 2013 at 3:46 AM, Mingui Zhang wrote: > Dear all, > > We have submitted a draft about ICCP Application TLVs for VPN Route Label > Sharing. > > The application is elaborated in another draft: Label Sharing for Fast PE > Protection > http://www.ietf.org/id/draft-zhang-l3vpn-label-sharing-00.txt > Egress PEs in a redundant group always assign the same label for VPN > routes from a > VRF. These egress PEs create a BGP virtual Next Hop (vNH) in the > domain of the IP/MPLS backbone network as an agent of the CE router. > Primary and backup tunnels terminated at the vNH are set up by the > BGP/MPLS IP VPN based on IGP FRR. If the primary egress PE fails, the > backup egress PE can recognize the "shared" VPN route label and > deliver the failure affected packets accordingly. > > Egress PEs in the same Redundant Group utilize the ICCP > connection to negotiate the "VPN route label" and the "BGP next hop" > for each VPN. > > Comments are welcome. > > Regards, > Mingui > > >-----Original Message----- > > A new version of I-D, draft-zhang-pwe3-iccp-label-sharing-00.txt > has been successfully submitted by Mingui Zhang and posted to the IETF > repository. > > Filename: draft-zhang-pwe3-iccp-label-sharing > Revision: 00 > Title: ICCP Application TLVs for VPN Route Label Sharing > Creation date: 2013-07-12 > Group: Individual Submission > Number of pages: 11 > URL: > http://www.ietf.org/internet-drafts/draft-zhang-pwe3-iccp-label-sharing-00.txt > Status: > http://datatracker.ietf.org/doc/draft-zhang-pwe3-iccp-label-sharing > Htmlized: > http://tools.ietf.org/html/draft-zhang-pwe3-iccp-label-sharing-00 > > > Abstract: > This document defines TLVs under Inter-Chassis Communication Protocol > (ICCP) to include a new application: Label Sharing for Fast PE > Protection. Egress PEs in the same Redundant Group utilize the ICCP > connection to negotiate the "VPN route label" and the "BGP next hop" > for each VPN. > > > > > The IETF Secretariat > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --f46d042184853eba4a04e1dedd29 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

Just to elaborate, there are two related = drafts on this topic, http://www.ietf.org/id/draft-zhang-l= 3vpn-label-sharing-00.txt and http://= www.ietf.org/internet-drafts/draft-zhang-pwe3-iccp-label-sharing-00.txt= . Comments should probably go to both the l3vpn and pwe3 lists for now.
Mingui will have a presentation on these drafts in both the = l3vpn and pwe3 sessions in Berlin.

Thanks,
Andy<= /div>


On Fri, = Jul 19, 2013 at 3:46 AM, Mingui Zhang <zhangmingui@huawei.com>= wrote:
Dear all,

We have submitted a draft about ICCP Application TLVs for VPN Route Label S= haring.

The application is elaborated in another draft: Label Sharing for Fast PE P= rotection
http://www.ietf.org/id/draft-zhang-l3vpn-label-sharing-00.= txt
=A0 =A0Egress PEs in a redundant group always assign the same label for VPN= routes from a
=A0 =A0VRF. These egress PEs create a BGP virtual Next Hop (vNH) in the
=A0 =A0domain of the IP/MPLS backbone network as an agent of the CE router.=
=A0 =A0Primary and backup tunnels terminated at the vNH are set up by the =A0 =A0BGP/MPLS IP VPN based on IGP FRR. If the primary egress PE fails, th= e
=A0 =A0backup egress PE can recognize the "shared" VPN route labe= l and
=A0 =A0deliver the failure affected packets accordingly.

=A0 =A0Egress PEs in the same Redundant Group utilize the ICCP
=A0 =A0connection to negotiate the "VPN route label" and the &quo= t;BGP next hop"
=A0 =A0for each VPN.

Comments are welcome.

Regards,
Mingui

>-----Original Message-----

A new version of I-D, draft-zhang-pwe3-iccp-label-sharing-00.txt
has been successfully submitted by Mingui Zhang and posted to the IETF repo= sitory.

Filename: =A0 =A0 =A0 =A0draft-zhang-pwe3-iccp-label-sharing
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 ICCP Application TLVs for VPN Route Label Sharin= g
Creation date: =A0 2013-07-12
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 11
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.i= etf.org/internet-drafts/draft-zhang-pwe3-iccp-label-sharing-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.o= rg/doc/draft-zhang-pwe3-iccp-label-sharing
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/dr= aft-zhang-pwe3-iccp-label-sharing-00


Abstract:
=A0 =A0This document defines TLVs under Inter-Chassis Communication Protoco= l
=A0 =A0(ICCP) to include a new application: Label Sharing for Fast PE
=A0 =A0Protection. Egress PEs in the same Redundant Group utilize the ICCP<= br> =A0 =A0connection to negotiate the "VPN route label" and the &quo= t;BGP next hop"
=A0 =A0for each VPN.




The IETF Secretariat
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pwe3

--f46d042184853eba4a04e1dedd29-- From ju1738@att.com Fri Jul 19 09:49:54 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F00A21E80BB for ; Fri, 19 Jul 2013 09:49:54 -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=[AWL=-0.300, 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 Kb9ys+IQPGxB for ; Fri, 19 Jul 2013 09:49:42 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id EBB7211E80E1 for ; Fri, 19 Jul 2013 09:49:41 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 52e69e15.0.7115302.00-337.19784753.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 19 Jul 2013 16:49:41 +0000 (UTC) X-MXL-Hash: 51e96e2568c82809-d155fa02f2e6a393a6caff34ba42e845c81d9177 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6JGnfil017892; Fri, 19 Jul 2013 12:49:41 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6JGnT2U017781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 12:49:35 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 19 Jul 2013 16:49:11 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0342.003; Fri, 19 Jul 2013 12:49:11 -0400 From: "UTTARO, JAMES" To: Yakov Rekhter , "thomas.morin@orange.com" Subject: RE: The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOhIMtIH0GRmHfo0yiZNTVHzxBvJlsNqAw Date: Fri, 19 Jul 2013 16:49:09 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D6B60@NKGEML512-MBS.china.huawei.com> <9252_1374239900_51E93C9C_9252_4871_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D0751AC91@PEXCVZYM13.corporate.adroot.infra.ftgroup> <201307191323.r6JDNBL44457@magenta.juniper.net> In-Reply-To: <201307191323.r6JDNBL44457@magenta.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.100.111] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=R5y076tX c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=kbQaRRVrGUQA:10 a=FsBSW_QmHFQA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=F-Rx8qf4j4kA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8] X-AnalysisOut: [ a=_RrEqOZQ0KSZXKO7pWQA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=oAXR_kdF8uMA:10 a=dk3XmDSNZ62gXGqO:21 a=tPxTj1JyKvZD] X-AnalysisOut: [ocjO:21] X-Mailman-Approved-At: Fri, 19 Jul 2013 23:55:34 -0700 Cc: L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 16:49:54 -0000 Comments In-Line.. Jim Uttaro -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Y= akov Rekhter Sent: Friday, July 19, 2013 9:23 AM To: thomas.morin@orange.com Cc: L3VPN Subject: Re: The possibility of using global MPLS labels as VNIs ... for l3= vpn Thomas, > 2013-07-18, Xuxiaohu: > > > > Till now, it seem that the only remaining technical reason for some > > people to prefer VXLAN/NVGRE encapsulation format to > > MAC-in-MPLS-in-IP encapsulation format for network virtualization > > overlay is the former has global VNIs while the latter doesn't have. > > If this reason is true, why can't we consider the possibility of > > using global MPLS labels to achieve the same goal? >=20 > IMHO, examining *why* someone would want a "global VNI" should be the=20 > start of the discussion, rather than possible solutions. >=20 > I could possibly see at least one reason *not* to try to have a=20 > dedicated identifier in the dataplane common for all flows of "a VPN".=20 > It is not related to the encapsulation, but to the fact that RFC4364=20 > has, in fact, no strict notion of "a VPN", but only of how connectivity=20 > is established betweens set of VRFs. Moreover, connectivity between set of VRFs is not "cast in concrete". To the contrary it could change, as extranets are formed/dissolved, and the process of forming/dissolving extranets could be fairly dynamic. [Jim U>] This happens today.. Yakov. >=20 > -Thomas >=20 > _________________________________________________________________________= _____ ___________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entie lles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = elect roniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u fal sifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nform ation that may be protected by law; > they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te th is message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n mod ified, changed or falsified. > Thank you. >=20 >=20 From xuxiaohu@huawei.com Sun Jul 21 18:53:07 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F09921F9D6B; Sun, 21 Jul 2013 18:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 sP1QvkAsAVWc; Sun, 21 Jul 2013 18:53:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 24D4121F9C7B; Sun, 21 Jul 2013 18:53:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVG93426; Mon, 22 Jul 2013 01:52:59 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 02:52:09 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 02:52:58 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.175]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Mon, 22 Jul 2013 09:52:52 +0800 From: Xuxiaohu To: Yakov Rekhter , "thomas.morin@orange.com" Subject: re: The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOhIJ1yIlB/WUnJ0iGPHkvmxyIC5lrdxmAgAR1qvA= Date: Mon, 22 Jul 2013 01:52:52 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D7364@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D6B60@NKGEML512-MBS.china.huawei.com> <9252_1374239900_51E93C9C_9252_4871_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D0751AC91@PEXCVZYM13.corporate.adroot.infra.ftgroup> <201307191323.r6JDNBL44457@magenta.juniper.net> In-Reply-To: <201307191323.r6JDNBL44457@magenta.juniper.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" , L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 01:53:07 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbDN2cG4tYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmwzdnBuLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gWWFrb3YNCj4gUmVraHRlcg0K PiC3osvNyrG85DogMjAxM8TqN9TCMTnI1SAyMToyMw0KPiDK1bz+yMs6IHRob21hcy5tb3JpbkBv cmFuZ2UuY29tDQo+ILOty806IEwzVlBODQo+INb3zOI6IFJlOiBUaGUgcG9zc2liaWxpdHkgb2Yg dXNpbmcgZ2xvYmFsIE1QTFMgbGFiZWxzIGFzIFZOSXMgLi4uIGZvciBsM3Zwbg0KPiANCj4gVGhv bWFzLA0KPiANCj4gPiAyMDEzLTA3LTE4LCBYdXhpYW9odToNCj4gPiA+DQo+ID4gPiBUaWxsIG5v dywgaXQgc2VlbSB0aGF0IHRoZSBvbmx5IHJlbWFpbmluZyB0ZWNobmljYWwgcmVhc29uIGZvciBz b21lDQo+ID4gPiBwZW9wbGUgdG8gcHJlZmVyIFZYTEFOL05WR1JFIGVuY2Fwc3VsYXRpb24gZm9y bWF0IHRvDQo+ID4gPiBNQUMtaW4tTVBMUy1pbi1JUCBlbmNhcHN1bGF0aW9uIGZvcm1hdCBmb3Ig bmV0d29yayB2aXJ0dWFsaXphdGlvbg0KPiA+ID4gb3ZlcmxheSBpcyB0aGUgZm9ybWVyIGhhcyBn bG9iYWwgVk5JcyB3aGlsZSB0aGUgbGF0dGVyIGRvZXNuJ3QgaGF2ZS4NCj4gPiA+IElmIHRoaXMg cmVhc29uIGlzIHRydWUsIHdoeSBjYW4ndCB3ZSBjb25zaWRlciB0aGUgcG9zc2liaWxpdHkgb2YN Cj4gPiA+IHVzaW5nIGdsb2JhbCBNUExTIGxhYmVscyB0byBhY2hpZXZlIHRoZSBzYW1lIGdvYWw/ DQo+ID4NCj4gPiBJTUhPLCBleGFtaW5pbmcgKndoeSogc29tZW9uZSB3b3VsZCB3YW50IGEgImds b2JhbCBWTkkiIHNob3VsZCBiZSB0aGUNCj4gPiBzdGFydCBvZiB0aGUgZGlzY3Vzc2lvbiwgcmF0 aGVyIHRoYW4gcG9zc2libGUgc29sdXRpb25zLg0KPiA+DQo+ID4gSSBjb3VsZCBwb3NzaWJseSBz ZWUgYXQgbGVhc3Qgb25lIHJlYXNvbiAqbm90KiB0byB0cnkgdG8gaGF2ZSBhDQo+ID4gZGVkaWNh dGVkIGlkZW50aWZpZXIgaW4gdGhlIGRhdGFwbGFuZSBjb21tb24gZm9yIGFsbCBmbG93cyBvZiAi YSBWUE4iLg0KPiA+IEl0IGlzIG5vdCByZWxhdGVkIHRvIHRoZSBlbmNhcHN1bGF0aW9uLCBidXQg dG8gdGhlIGZhY3QgdGhhdCBSRkM0MzY0DQo+ID4gaGFzLCBpbiBmYWN0LCBubyBzdHJpY3Qgbm90 aW9uIG9mICJhIFZQTiIsIGJ1dCBvbmx5IG9mIGhvdyBjb25uZWN0aXZpdHkNCj4gPiBpcyBlc3Rh Ymxpc2hlZCBiZXR3ZWVucyBzZXQgb2YgVlJGcy4NCj4gDQo+IE1vcmVvdmVyLCBjb25uZWN0aXZp dHkgYmV0d2VlbiBzZXQgb2YgVlJGcyBpcyBub3QgImNhc3QgaW4gY29uY3JldGUiLg0KPiBUbyB0 aGUgY29udHJhcnkgaXQgY291bGQgY2hhbmdlLCBhcyBleHRyYW5ldHMgYXJlIGZvcm1lZC9kaXNz b2x2ZWQsDQo+IGFuZCB0aGUgcHJvY2VzcyBvZiBmb3JtaW5nL2Rpc3NvbHZpbmcgZXh0cmFuZXRz IGNvdWxkIGJlIGZhaXJseQ0KPiBkeW5hbWljLg0KDQpJcyBleHRyYW5ldCBpcyBhIG5vcm1hbCBy ZXF1aXJlbWVudCBmb3IgTGF5ZXIzIERDIG5ldHdvcmsgdmlydHVhbGl6YXRpb24gb3ZlcmxheT8g SSBoYXZlbid0IHNlZW4gYW55IGRlc2NyaXB0aW9uIG9mIHRoaXMgaW4gdGhlIE5WbzMgcmVxdWly ZW1lbnQgYW5kIGZyYW1ld29yayBkcmFmdHMgeWV0Lg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUN Cg0KPiBZYWtvdi4NCj4gDQo+ID4NCj4gPiAtVGhvbWFzDQo+ID4NCj4gPg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IF9fX19fX19fX19fX19fDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPg0KPiA+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0KPiBjb25maWRlbnRpZQ0KPiBsbGVzIG91IHByaXZp bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCj4gPiBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UNCj4g IG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCj4gPiBhIGwnZXhwZWRp dGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVz c2FnZXMgZWxlY3QNCj4gcm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwN Cj4gPiBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEg ZXRlIGFsdGVyZSwgZGVmb3JtZSBvdQ0KPiBmYWwNCj4gc2lmaWUuIE1lcmNpLg0KPiA+DQo+ID4g VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IG9yIHByaXZpbGVnZWQNCj4gaW5mb3JtDQo+IGF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBi eSBsYXc7DQo+ID4gdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGll ZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoDQo+IGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4gPiBBcyBlbWFpbHMgbWF5IGJlIGFsdGVy ZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbg0KPiBt b2QNCj4gaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiA+IFRoYW5rIHlvdS4NCj4gPg0K PiA+DQoNCg== From zhangmingui@huawei.com Sun Jul 21 22:58:37 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8D221F9C3A for ; Sun, 21 Jul 2013 22:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.434 X-Spam-Level: X-Spam-Status: No, score=-7.434 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_00=-2.599, 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 uyugBVRfrIMD for ; Sun, 21 Jul 2013 22:58:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EE02A21F99DA for ; Sun, 21 Jul 2013 22:58:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVH08041; Mon, 22 Jul 2013 05:58:27 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 06:57:34 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 06:58:24 +0100 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.110]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Mon, 22 Jul 2013 13:58:20 +0800 From: Mingui Zhang To: "Henderickx, Wim (Wim)" , "Nagendra Kumar (naikumar)" , "l3vpn@ietf.org" Subject: RE: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt Thread-Topic: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt Thread-Index: AQHOhHOpfQte+N5R0U+LUwKBoxU1zJlwBeKA Date: Mon, 22 Jul 2013 05:58:19 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7335C77FA@nkgeml508-mbx.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E7335C72AB@nkgeml508-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 05:58:37 -0000 Hi Wim, There should be alternative methods. But this document tries to provide a s= imple one. For example,=20 a. It does not require multiple label spaces.=20 b. It need not store context label tables repeatedly on each RG member. c. It does not changes the forwarding process.=20 d. It does not bear the restriction of no penultimate-hop-popping. Thanks, Mingui >-----Original Message----- >From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] >Sent: Friday, July 19, 2013 7:32 PM >To: Mingui Zhang; Nagendra Kumar (naikumar); l3vpn@ietf.org >Subject: Re: New Version Notification for draft-zhang-l3vpn-label-sharing-= 00.txt > >What you are trying to achieve can be done with Ctxt labels using locally >assigned labels. So no need for global labels. > >On 19/07/13 11:01, "Mingui Zhang" wrote: > >>Hi Nagendra, >> >>It can also be automatically negotiated through signaling among those >>egress PEs. I have composed the following draft for this point. >>ICCP Application TLVs for VPN Route Label Sharing - Mingui ZHANG >>http://www.ietf.org/id/draft-zhang-pwe3-iccp-label-sharing-00.txt >> >>Thanks, >>Mingui >> >>>-----Original Message----- >>>From: Nagendra Kumar (naikumar) [mailto:naikumar@cisco.com] >>>Sent: Friday, July 19, 2013 4:55 PM >>>To: Mingui Zhang; l3vpn@ietf.org >>>Subject: RE: New Version Notification for >>>draft-zhang-l3vpn-label-sharing-00.txt >>> >>>Hi, >>> >>>Thanks. Is the proposal is to manually assign/configure in each PE?. >>> >>>-Nagendra >>> >>>-----Original Message----- >>>From: Mingui Zhang [mailto:zhangmingui@huawei.com] >>>Sent: Friday, July 19, 2013 2:21 PM >>>To: Nagendra Kumar (naikumar); l3vpn@ietf.org >>>Subject: RE: New Version Notification for >>>draft-zhang-l3vpn-label-sharing-00.txt >>> >>>Hi Nagendra, >>> >>>In the method, the egress PEs in the RG have to use the same VPN route >>>label >>>for one VPN site (e.g., 1100 for VPN1). >>>As for the prefix, all prefixes (e.g., 10.1.1.0/24) learnt from this VPN >>>site will be >>>stored in the corresponding VRF (e.g., VPN1' VPN instance) identified by >>>the VPN >>>route label. >>> >>>I guess you propose to share the label "per-prefix". It's possible to do >>>so but not >>>as common as the "per-VRF" assignment in current practice. >>> >>>Thanks, >>>Mingui >>> >>>>-----Original Message----- >>>>From: Nagendra Kumar (naikumar) [mailto:naikumar@cisco.com] >>>>Sent: Friday, July 19, 2013 4:15 PM >>>>To: Mingui Zhang; l3vpn@ietf.org >>>>Subject: RE: New Version Notification for >>>>draft-zhang-l3vpn-label-sharing-00.txt >>>> >>>>Hi Mingui, >>>> >>>>I couldn=B9t see any point mentioned in this draft on how egress PEs wi= ll >>>>assign same VPN label for the prefix. >>>> >>>>Can you please share the same?. Sorry, if I am missing something in the >>>>doc. >>>> >>>>Regards, >>>>nagendra >>>> >>>>-----Original Message----- >>>>From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf >>>>Of Mingui Zhang >>>>Sent: Friday, July 19, 2013 1:16 PM >>>>To: l3vpn@ietf.org >>>>Subject: FW: New Version Notification for >>>>draft-zhang-l3vpn-label-sharing-00.txt >>>> >>>>Dear all, >>>> >>>>We have submitted a new draft: Label Sharing for Fast PE Protection. >>>> >>>> This draft designs a simple method to be used by SPs to achieve fast >>>>PE protection, utilizing the deployment of redundant egress PEs. >>>> >>>>Comments are welcome. >>>> >>>>Regards, >>>>Mingui >>>> >>>>>-----Original Message----- >>>> >>>>A new version of I-D, draft-zhang-l3vpn-label-sharing-00.txt >>>>has been successfully submitted by Mingui Zhang and posted to the IETF >>>>repository. >>>> >>>>Filename: draft-zhang-l3vpn-label-sharing >>>>Revision: 00 >>>>Title: Label Sharing for Fast PE Protection >>>>Creation date: 2013-07-12 >>>>Group: Individual Submission >>>>Number of pages: 12 >>>>URL: >>>>http://www.ietf.org/internet-drafts/draft-zhang-l3vpn-label-sharing-00. >>>>txt >>>>Status: >>>>http://datatracker.ietf.org/doc/draft-zhang-l3vpn-label-sharing >>>>Htmlized: >>>http://tools.ietf.org/html/draft-zhang-l3vpn-label-sharing-00 >>>> >>>> >>>>Abstract: >>>> This document describes a method to be used by Service Providers to >>>> provide fast protection of VPN connections for a CE. Egress PEs in a >>>> redundant group always assign the same label for VPN routes from a >>>> VRF. These egress PEs create a BGP virtual Next Hop (vNH) in the >>>> domain of the IP/MPLS backbone network as an agent of the CE router. >>>> Primary and backup tunnels terminated at the vNH are set up by the >>>> BGP/MPLS IP VPN based on IGP FRR. If the primary egress PE fails, th= e >>>> backup egress PEs can recognize the "shared" VPN route label and >>>> deliver the failure affected packets accordingly. >>>> >>>> >>>> >>>> >>>>The IETF Secretariat From ju1738@att.com Mon Jul 22 05:17:20 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1051921E8091; Mon, 22 Jul 2013 05:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 WiD4dKB3a-cx; Mon, 22 Jul 2013 05:17:12 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 869F521E8051; Mon, 22 Jul 2013 05:17:12 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 8c22de15.2aaad9214940.846311.00-555.2249410.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 22 Jul 2013 12:17:12 +0000 (UTC) X-MXL-Hash: 51ed22c864401540-7cdfe4f31acf22b2aa28931a0bb1f43a9af71592 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id ca22de15.0.846276.00-457.2248947.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 22 Jul 2013 12:16:46 +0000 (UTC) X-MXL-Hash: 51ed22ae7ae67626-199d113bcc29335f7444b77ece67e43d3a4fd463 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6MCGhqP006277; Mon, 22 Jul 2013 08:16:44 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6MCGYke006181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 08:16:42 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 22 Jul 2013 12:16:23 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0342.003; Mon, 22 Jul 2013 08:16:23 -0400 From: "UTTARO, JAMES" To: Xuxiaohu , Yakov Rekhter , "thomas.morin@orange.com" Subject: RE: The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOhIJ1IH0GRmHfo0yiZNTVHzxBvJlrdxmAgAR1qvCAALQvwA== Date: Mon, 22 Jul 2013 12:16:22 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D6B60@NKGEML512-MBS.china.huawei.com> <9252_1374239900_51E93C9C_9252_4871_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D0751AC91@PEXCVZYM13.corporate.adroot.infra.ftgroup> <201307191323.r6JDNBL44457@magenta.juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D7364@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D7364@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.242] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=WbS7nTdX c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=xGb8pAI6nX4A:10 a=FsBSW_QmHFQA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=_l4uJm6h9gAA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=F-Rx8qf4j4kA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8] X-AnalysisOut: [ a=O-AF0fo0kB1Y3TCw3vkA:9 a=mFyHDrcPJccA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=oAXR_kdF8uMA:10 a=SonRBh7NqNrKfTKu:21 a=bkgsa3iwKlRH] X-AnalysisOut: [6Y-z:21] X-Mailman-Approved-At: Mon, 22 Jul 2013 06:26:45 -0700 Cc: "nvo3@ietf.org" , L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 12:17:20 -0000 WWVzIGNyZWF0aW5nIGV4dHJhbmV0cyBpcyBjdXJyZW50bHkgZG9uZSBpbiBMM1ZQTi4gSSB3b3Vs ZCBhc3N1bWUgdGhhdCB0aGlzIGlzIGFsc28gY3JlYXRpbmcgd2hlbiBleHRlbmRpbmcgYSBjdXN0 b21lcnMgVlBOIGludG8gYSBWUEMgKCBWaXJ0dWFsIFByaXZhdGUgQ2xvdWQgKS4uIElNTyBOVk8z IGlzIGZvY3VzZWQgb24gb25seSB0aGUgb3ZlcmxheSB0ZWNobm9sb2d5IGFuZCBub3Qgb24gdGhl IHNlcnZpY2UgcmVhbGl6YXRpb24uDQoNCkppbSBVdHRhcm8NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IGwzdnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsM3Zwbi1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWHV4aWFvaHUNClNlbnQ6IFN1bmRheSwgSnVseSAy MSwgMjAxMyA5OjUzIFBNDQpUbzogWWFrb3YgUmVraHRlcjsgdGhvbWFzLm1vcmluQG9yYW5nZS5j b20NCkNjOiBudm8zQGlldGYub3JnOyBMM1ZQTg0KU3ViamVjdDogcmU6IFRoZSBwb3NzaWJpbGl0 eSBvZiB1c2luZyBnbG9iYWwgTVBMUyBsYWJlbHMgYXMgVk5JcyAuLi4gZm9yIGwzdnBuDQoNCg0K DQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IGwzdnBuLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpsM3Zwbi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFlha292DQo+IFJla2h0ZXINCj4g t6LLzcqxvOQ6IDIwMTPE6jfUwjE5yNUgMjE6MjMNCj4gytW8/sjLOiB0aG9tYXMubW9yaW5Ab3Jh bmdlLmNvbQ0KPiCzrcvNOiBMM1ZQTg0KPiDW98ziOiBSZTogVGhlIHBvc3NpYmlsaXR5IG9mIHVz aW5nIGdsb2JhbCBNUExTIGxhYmVscyBhcyBWTklzIC4uLiBmb3IgbDN2cG4NCj4gDQo+IFRob21h cywNCj4gDQo+ID4gMjAxMy0wNy0xOCwgWHV4aWFvaHU6DQo+ID4gPg0KPiA+ID4gVGlsbCBub3cs IGl0IHNlZW0gdGhhdCB0aGUgb25seSByZW1haW5pbmcgdGVjaG5pY2FsIHJlYXNvbiBmb3Igc29t ZQ0KPiA+ID4gcGVvcGxlIHRvIHByZWZlciBWWExBTi9OVkdSRSBlbmNhcHN1bGF0aW9uIGZvcm1h dCB0bw0KPiA+ID4gTUFDLWluLU1QTFMtaW4tSVAgZW5jYXBzdWxhdGlvbiBmb3JtYXQgZm9yIG5l dHdvcmsgdmlydHVhbGl6YXRpb24NCj4gPiA+IG92ZXJsYXkgaXMgdGhlIGZvcm1lciBoYXMgZ2xv YmFsIFZOSXMgd2hpbGUgdGhlIGxhdHRlciBkb2Vzbid0IGhhdmUuDQo+ID4gPiBJZiB0aGlzIHJl YXNvbiBpcyB0cnVlLCB3aHkgY2FuJ3Qgd2UgY29uc2lkZXIgdGhlIHBvc3NpYmlsaXR5IG9mDQo+ ID4gPiB1c2luZyBnbG9iYWwgTVBMUyBsYWJlbHMgdG8gYWNoaWV2ZSB0aGUgc2FtZSBnb2FsPw0K PiA+DQo+ID4gSU1ITywgZXhhbWluaW5nICp3aHkqIHNvbWVvbmUgd291bGQgd2FudCBhICJnbG9i YWwgVk5JIiBzaG91bGQgYmUgdGhlDQo+ID4gc3RhcnQgb2YgdGhlIGRpc2N1c3Npb24sIHJhdGhl ciB0aGFuIHBvc3NpYmxlIHNvbHV0aW9ucy4NCj4gPg0KPiA+IEkgY291bGQgcG9zc2libHkgc2Vl IGF0IGxlYXN0IG9uZSByZWFzb24gKm5vdCogdG8gdHJ5IHRvIGhhdmUgYQ0KPiA+IGRlZGljYXRl ZCBpZGVudGlmaWVyIGluIHRoZSBkYXRhcGxhbmUgY29tbW9uIGZvciBhbGwgZmxvd3Mgb2YgImEg VlBOIi4NCj4gPiBJdCBpcyBub3QgcmVsYXRlZCB0byB0aGUgZW5jYXBzdWxhdGlvbiwgYnV0IHRv IHRoZSBmYWN0IHRoYXQgUkZDNDM2NA0KPiA+IGhhcywgaW4gZmFjdCwgbm8gc3RyaWN0IG5vdGlv biBvZiAiYSBWUE4iLCBidXQgb25seSBvZiBob3cgY29ubmVjdGl2aXR5DQo+ID4gaXMgZXN0YWJs aXNoZWQgYmV0d2VlbnMgc2V0IG9mIFZSRnMuDQo+IA0KPiBNb3Jlb3ZlciwgY29ubmVjdGl2aXR5 IGJldHdlZW4gc2V0IG9mIFZSRnMgaXMgbm90ICJjYXN0IGluIGNvbmNyZXRlIi4NCj4gVG8gdGhl IGNvbnRyYXJ5IGl0IGNvdWxkIGNoYW5nZSwgYXMgZXh0cmFuZXRzIGFyZSBmb3JtZWQvZGlzc29s dmVkLA0KPiBhbmQgdGhlIHByb2Nlc3Mgb2YgZm9ybWluZy9kaXNzb2x2aW5nIGV4dHJhbmV0cyBj b3VsZCBiZSBmYWlybHkNCj4gZHluYW1pYy4NCg0KSXMgZXh0cmFuZXQgaXMgYSBub3JtYWwgcmVx dWlyZW1lbnQgZm9yIExheWVyMyBEQyBuZXR3b3JrIHZpcnR1YWxpemF0aW9uIG92ZXJsYXk/IEkg aGF2ZW4ndCBzZWVuIGFueSBkZXNjcmlwdGlvbiBvZiB0aGlzIGluIHRoZSBOVm8zIHJlcXVpcmVt ZW50IGFuZCBmcmFtZXdvcmsgZHJhZnRzIHlldC4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoN Cj4gWWFrb3YuDQo+IA0KPiA+DQo+ID4gLVRob21hcw0KPiA+DQo+ID4NCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBf X19fX19fX19fX19fXw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4NCj4gPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCj4gY29uZmlkZW50aWUNCj4gbGxlcyBvdSBwcml2aWxl Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQo+ID4gcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRl cyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlDQo+ICBt ZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQo+ID4gYSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0DQo+IHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQo+ ID4gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0 ZSBhbHRlcmUsIGRlZm9ybWUgb3UNCj4gZmFsDQo+IHNpZmllLiBNZXJjaS4NCj4gPg0KPiA+IFRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBv ciBwcml2aWxlZ2VkDQo+IGluZm9ybQ0KPiBhdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg bGF3Ow0KPiA+IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQg d2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aA0KPiBpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+ID4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVk LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4NCj4gbW9k DQo+IGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gPiBUaGFuayB5b3UuDQo+ID4NCj4g Pg0KDQo= From erosen@cisco.com Mon Jul 22 08:09:52 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595F921E80B0 for ; Mon, 22 Jul 2013 08:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.976 X-Spam-Level: X-Spam-Status: No, score=-9.976 tagged_above=-999 required=5 tests=[AWL=0.623, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 q06acJwveOUn for ; Mon, 22 Jul 2013 08:09:46 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7D79011E8111 for ; Mon, 22 Jul 2013 08:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=696; q=dns/txt; s=iport; t=1374505780; x=1375715380; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=sS9H7hR8M9+49XMKCDx/FFdE3PFClwDY5bX3tIKsyl4=; b=NFjy1UvW4XrXeO7kroGIe/SZTIOo+3gIcvXrrQWL0hH07oxh7Vh2KJP9 pplqUYPPhuY193YzqHCxQp7vi82azm4w8GwO6hBpJQfT4xxYgRVr4FsBQ JZqnyj1rymeNpBeuFqAIeAvFnCeQXkkNi+5xpEaicjVA2jTgTFMrKzREq w=; X-IronPort-AV: E=Sophos;i="4.89,719,1367971200"; d="scan'208";a="237861263" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 22 Jul 2013 15:09:40 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6MF9dCN007705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 15:09:39 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id r6MF9a8j027327; Mon, 22 Jul 2013 11:09:36 -0400 From: Eric Rosen To: Mingui Zhang Subject: Re: FW: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt In-reply-to: Your message of Fri, 19 Jul 2013 07:46:23 -0000. <4552F0907735844E9204A62BBDD325E7335C721B@nkgeml508-mbx.china.huawei.com> Date: Mon, 22 Jul 2013 11:09:36 -0400 Message-ID: <27326.1374505776@erosen-linux> Cc: erosen@cisco.com, "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 15:09:52 -0000 As far as I can tell, your scheme only handles the case where the two egress PEs connect to the exact same set of CEs. If so, this applicability restriction should be clearly stated. In Figure 2.1, you show CE2 connected to PE3 and PE4. Now suppose we also have CE4 connected to PE3 and PE5. If PE3 fails, one might want use PE4 as a backup for CE2, while using PE5 as a backup for CE4. Your scheme doesn't seem to handle this. Also, even in the case of Figure 2.1, it seems entirely possibly that one might want PE3's primary route to CE2 to be via the directly attached interface, while wanting PE4's primary route to CE2 to be via PE3. Does your scheme handle this case? From lufang@cisco.com Mon Jul 22 09:19:30 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8A611E811D for ; Mon, 22 Jul 2013 09:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8] 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 Mg6QUSCZJOtE for ; Mon, 22 Jul 2013 09:19:22 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id ACBDD11E80E7 for ; Mon, 22 Jul 2013 09:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3466; q=dns/txt; s=iport; t=1374509960; x=1375719560; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7GVNqRvc/KteDnd52561djBB1bicFsmGfVk9MnXjjlk=; b=GeTR/vODYb3wzSOu3R1KWl2JIzB1Y+KtLhGlEre4ZSqIW0+8aLpx5xpR tf1AvUvxTiMIJpqRiASZxdxG5VZUg+w2AeEdbKzkwrB1Cv0KdJKn/rb1F uM992BNY7+ruSPOXDKs4vQfbko6m9hW67PHJCkCDj+gr42LUZQ7THeOIY Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFAEhb7VGtJXHA/2dsb2JhbABbgwaBBcAxgRYWdIIkAQEBBDo/DAYBCBEDAQEBCxQJORQJCAIEAQ0FCBOHdbdsjlSBEQYrBwaDCm4DqSqDEoFxOQ X-IronPort-AV: E=Sophos;i="4.89,720,1367971200"; d="scan'208";a="237851861" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 22 Jul 2013 16:19:20 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6MGJJqH010187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Jul 2013 16:19:19 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.100]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Mon, 22 Jul 2013 11:19:19 -0500 From: "Luyuan Fang (lufang)" To: "UTTARO, JAMES" , Yakov Rekhter , "thomas.morin@orange.com" Subject: Re: The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOhIJ87Rz8qHbLQUeZKpoWu4I/m5lsUQeAgAA5jICABGuWgA== Date: Mon, 22 Jul 2013 16:19:19 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD931044FBDC@xmb-rcd-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.21.103.12] Content-Type: text/plain; charset="us-ascii" Content-ID: <1940593CD3DABF4B8B1EE538E4D613D0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 16:19:30 -0000 As I remember, the global VPN-ID was discussed/debated in L3VPN WG around 2003-2006, the global VPN-ID was proposed in the vr draft. The general consensus of the WG was that the L3VPN solution would be more flexible and scalable without the global VPN-ID, as the way RFC4364/2547 handling it. I don't believe this has changed since then. In fact, the extensive large scale global deployments of 4364 L3VPNs over the past 15 years provide good living testimony of it. Luyuan -----Original Message----- From: , JAMES Date: Friday, July 19, 2013 12:49 PM To: Yakov Rekhter , "thomas.morin@orange.com" Cc: L3VPN Subject: RE: The possibility of using global MPLS labels as VNIs ... for l3vpn >Comments In-Line.. > >Jim Uttaro > >-----Original Message----- >From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of >Yakov Rekhter >Sent: Friday, July 19, 2013 9:23 AM >To: thomas.morin@orange.com >Cc: L3VPN >Subject: Re: The possibility of using global MPLS labels as VNIs ... for >l3vpn > >Thomas, > >> 2013-07-18, Xuxiaohu: >> > >> > Till now, it seem that the only remaining technical reason for some >> > people to prefer VXLAN/NVGRE encapsulation format to >> > MAC-in-MPLS-in-IP encapsulation format for network virtualization >> > overlay is the former has global VNIs while the latter doesn't have. >> > If this reason is true, why can't we consider the possibility of >> > using global MPLS labels to achieve the same goal? >>=20 >> IMHO, examining *why* someone would want a "global VNI" should be the >> start of the discussion, rather than possible solutions. >>=20 >> I could possibly see at least one reason *not* to try to have a >> dedicated identifier in the dataplane common for all flows of "a VPN". >> It is not related to the encapsulation, but to the fact that RFC4364 >> has, in fact, no strict notion of "a VPN", but only of how connectivity >> is established betweens set of VRFs. > >Moreover, connectivity between set of VRFs is not "cast in concrete". >To the contrary it could change, as extranets are formed/dissolved, >and the process of forming/dissolving extranets could be fairly >dynamic. >[Jim U>] This happens today.. > >Yakov. > >>=20 >> -Thomas >>=20 >>=20 >>_________________________________________________________________________ >>_____ >___________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations >>confidentie >lles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>recu ce > message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les >>messages elect >roniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme >>ou fal >sifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileged >>inform >ation that may be protected by law; >> they should not be distributed, used or copied without authorisation. >If you have received this email in error, please notify the sender and >delete th >is message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >>been mod >ified, changed or falsified. >> Thank you. >>=20 >>=20 > From wim.henderickx@alcatel-lucent.com Mon Jul 22 11:54:05 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E78611E80F5 for ; Mon, 22 Jul 2013 11:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.246 X-Spam-Level: X-Spam-Status: No, score=-8.246 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8] 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 EiiXriu67LgS for ; Mon, 22 Jul 2013 11:53:57 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3E11F11E80E2 for ; Mon, 22 Jul 2013 11:53:57 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6MIriQO025466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Jul 2013 13:53:46 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6MIriHI013858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Jul 2013 20:53:44 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.63]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 22 Jul 2013 20:53:44 +0200 From: "Henderickx, Wim (Wim)" To: Mingui Zhang , "Nagendra Kumar (naikumar)" , "l3vpn@ietf.org" Subject: Re: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt Thread-Topic: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt Thread-Index: AQHOhHOgZwV64qzptka+krxgl0LZJZlwFn+AgAD6JgA= Date: Mon, 22 Jul 2013 18:53:44 +0000 Message-ID: In-Reply-To: <4552F0907735844E9204A62BBDD325E7335C77FA@nkgeml508-mbx.china.huawei.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="euc-kr" Content-ID: <6A7FA7F77253AF47A643B6C27E39702C@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 18:54:05 -0000 VGhlcmUgaXMgYWx3YXlzIHByb3MvY29ucyBvZiBlYWNoIHNvbHV0aW9uIGJ1dCB3aGVuIHRoZSBn bG9iYWwgbGFiZWwgd2FzDQpkaXNjdXNzZWQgaW4gdGhlIHBhc3QgaW4gTDNWUE4gYmVjYXVzZSBp dCB3YXMgbGVzcyBmbGV4aWJsZSBjb21wYXJlZCB0bw0KY3VycmVudCBhdmFpbGFibGUgYXBwcm9h Y2hlcyB3aGljaCBoYXZlIGJlZW4gYWRvcHRlZCBzdWNjZXNzZnVsbHkuDQoNCk9uIDIyLzA3LzEz IDA3OjU4LCAiTWluZ3VpIFpoYW5nIiA8emhhbmdtaW5ndWlAaHVhd2VpLmNvbT4gd3JvdGU6DQoN Cj5IaSBXaW0sDQo+DQo+VGhlcmUgc2hvdWxkIGJlIGFsdGVybmF0aXZlIG1ldGhvZHMuIEJ1dCB0 aGlzIGRvY3VtZW50IHRyaWVzIHRvIHByb3ZpZGUgYQ0KPnNpbXBsZSBvbmUuDQo+DQo+Rm9yIGV4 YW1wbGUsIA0KPmEuIEl0IGRvZXMgbm90IHJlcXVpcmUgbXVsdGlwbGUgbGFiZWwgc3BhY2VzLg0K PmIuIEl0IG5lZWQgbm90IHN0b3JlIGNvbnRleHQgbGFiZWwgdGFibGVzIHJlcGVhdGVkbHkgb24g ZWFjaCBSRyBtZW1iZXIuDQo+Yy4gSXQgZG9lcyBub3QgY2hhbmdlcyB0aGUgZm9yd2FyZGluZyBw cm9jZXNzLg0KPmQuIEl0IGRvZXMgbm90IGJlYXIgdGhlIHJlc3RyaWN0aW9uIG9mIG5vIHBlbnVs dGltYXRlLWhvcC1wb3BwaW5nLg0KPg0KPlRoYW5rcywNCj5NaW5ndWkNCj4NCj4+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogSGVuZGVyaWNreCwgV2ltIChXaW0pIFttYWlsdG86 d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29tXQ0KPj5TZW50OiBGcmlkYXksIEp1bHkg MTksIDIwMTMgNzozMiBQTQ0KPj5UbzogTWluZ3VpIFpoYW5nOyBOYWdlbmRyYSBLdW1hciAobmFp a3VtYXIpOyBsM3ZwbkBpZXRmLm9yZw0KPj5TdWJqZWN0OiBSZTogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvcg0KPj5kcmFmdC16aGFuZy1sM3Zwbi1sYWJlbC1zaGFyaW5nLTAwLnR4dA0KPj4N Cj4+V2hhdCB5b3UgYXJlIHRyeWluZyB0byBhY2hpZXZlIGNhbiBiZSBkb25lIHdpdGggQ3R4dCBs YWJlbHMgdXNpbmcgbG9jYWxseQ0KPj5hc3NpZ25lZCBsYWJlbHMuIFNvIG5vIG5lZWQgZm9yIGds b2JhbCBsYWJlbHMuDQo+Pg0KPj5PbiAxOS8wNy8xMyAxMTowMSwgIk1pbmd1aSBaaGFuZyIgPHpo YW5nbWluZ3VpQGh1YXdlaS5jb20+IHdyb3RlOg0KPj4NCj4+PkhpIE5hZ2VuZHJhLA0KPj4+DQo+ Pj5JdCBjYW4gYWxzbyBiZSBhdXRvbWF0aWNhbGx5IG5lZ290aWF0ZWQgdGhyb3VnaCBzaWduYWxp bmcgYW1vbmcgdGhvc2UNCj4+PmVncmVzcyBQRXMuIEkgaGF2ZSBjb21wb3NlZCB0aGUgZm9sbG93 aW5nIGRyYWZ0IGZvciB0aGlzIHBvaW50Lg0KPj4+SUNDUCBBcHBsaWNhdGlvbiBUTFZzIGZvciBW UE4gUm91dGUgTGFiZWwgU2hhcmluZyAtIE1pbmd1aSBaSEFORw0KPj4+aHR0cDovL3d3dy5pZXRm Lm9yZy9pZC9kcmFmdC16aGFuZy1wd2UzLWljY3AtbGFiZWwtc2hhcmluZy0wMC50eHQNCj4+Pg0K Pj4+VGhhbmtzLA0KPj4+TWluZ3VpDQo+Pj4NCj4+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4+PkZyb206IE5hZ2VuZHJhIEt1bWFyIChuYWlrdW1hcikgW21haWx0bzpuYWlrdW1hckBj aXNjby5jb21dDQo+Pj4+U2VudDogRnJpZGF5LCBKdWx5IDE5LCAyMDEzIDQ6NTUgUE0NCj4+Pj5U bzogTWluZ3VpIFpoYW5nOyBsM3ZwbkBpZXRmLm9yZw0KPj4+PlN1YmplY3Q6IFJFOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yDQo+Pj4+ZHJhZnQtemhhbmctbDN2cG4tbGFiZWwtc2hhcmlu Zy0wMC50eHQNCj4+Pj4NCj4+Pj5IaSwNCj4+Pj4NCj4+Pj5UaGFua3MuIElzIHRoZSBwcm9wb3Nh bCBpcyB0byBtYW51YWxseSBhc3NpZ24vY29uZmlndXJlIGluIGVhY2ggUEU/Lg0KPj4+Pg0KPj4+ Pi1OYWdlbmRyYQ0KPj4+Pg0KPj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+RnJv bTogTWluZ3VpIFpoYW5nIFttYWlsdG86emhhbmdtaW5ndWlAaHVhd2VpLmNvbV0NCj4+Pj5TZW50 OiBGcmlkYXksIEp1bHkgMTksIDIwMTMgMjoyMSBQTQ0KPj4+PlRvOiBOYWdlbmRyYSBLdW1hciAo bmFpa3VtYXIpOyBsM3ZwbkBpZXRmLm9yZw0KPj4+PlN1YmplY3Q6IFJFOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yDQo+Pj4+ZHJhZnQtemhhbmctbDN2cG4tbGFiZWwtc2hhcmluZy0wMC50 eHQNCj4+Pj4NCj4+Pj5IaSBOYWdlbmRyYSwNCj4+Pj4NCj4+Pj5JbiB0aGUgbWV0aG9kLCB0aGUg ZWdyZXNzIFBFcyBpbiB0aGUgUkcgaGF2ZSB0byB1c2UgdGhlIHNhbWUgVlBOIHJvdXRlDQo+Pj4+ bGFiZWwNCj4+Pj5mb3Igb25lIFZQTiBzaXRlIChlLmcuLCAxMTAwIGZvciBWUE4xKS4NCj4+Pj5B cyBmb3IgdGhlIHByZWZpeCwgYWxsIHByZWZpeGVzIChlLmcuLCAxMC4xLjEuMC8yNCkgbGVhcm50 IGZyb20gdGhpcw0KPj4+PlZQTg0KPj4+PnNpdGUgd2lsbCBiZQ0KPj4+PnN0b3JlZCBpbiB0aGUg Y29ycmVzcG9uZGluZyBWUkYgKGUuZy4sIFZQTjEnIFZQTiBpbnN0YW5jZSkgaWRlbnRpZmllZA0K Pj4+PmJ5DQo+Pj4+dGhlIFZQTg0KPj4+PnJvdXRlIGxhYmVsLg0KPj4+Pg0KPj4+PkkgZ3Vlc3Mg eW91IHByb3Bvc2UgdG8gc2hhcmUgdGhlIGxhYmVsICJwZXItcHJlZml4Ii4gSXQncyBwb3NzaWJs ZSB0bw0KPj4+PmRvDQo+Pj4+c28gYnV0IG5vdA0KPj4+PmFzIGNvbW1vbiBhcyB0aGUgInBlci1W UkYiIGFzc2lnbm1lbnQgaW4gY3VycmVudCBwcmFjdGljZS4NCj4+Pj4NCj4+Pj5UaGFua3MsDQo+ Pj4+TWluZ3VpDQo+Pj4+DQo+Pj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+PkZy b206IE5hZ2VuZHJhIEt1bWFyIChuYWlrdW1hcikgW21haWx0bzpuYWlrdW1hckBjaXNjby5jb21d DQo+Pj4+PlNlbnQ6IEZyaWRheSwgSnVseSAxOSwgMjAxMyA0OjE1IFBNDQo+Pj4+PlRvOiBNaW5n dWkgWmhhbmc7IGwzdnBuQGlldGYub3JnDQo+Pj4+PlN1YmplY3Q6IFJFOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yDQo+Pj4+PmRyYWZ0LXpoYW5nLWwzdnBuLWxhYmVsLXNoYXJpbmctMDAu dHh0DQo+Pj4+Pg0KPj4+Pj5IaSBNaW5ndWksDQo+Pj4+Pg0KPj4+Pj5JIGNvdWxkbqn2dCBzZWUg YW55IHBvaW50IG1lbnRpb25lZCBpbiB0aGlzIGRyYWZ0IG9uIGhvdyBlZ3Jlc3MgUEVzDQo+Pj4+ PndpbGwNCj4+Pj4+YXNzaWduIHNhbWUgVlBOIGxhYmVsIGZvciB0aGUgcHJlZml4Lg0KPj4+Pj4N Cj4+Pj4+Q2FuIHlvdSBwbGVhc2Ugc2hhcmUgdGhlIHNhbWU/LiBTb3JyeSwgaWYgSSBhbSBtaXNz aW5nIHNvbWV0aGluZyBpbg0KPj4+Pj50aGUNCj4+Pj4+ZG9jLg0KPj4+Pj4NCj4+Pj4+UmVnYXJk cywNCj4+Pj4+bmFnZW5kcmENCj4+Pj4+DQo+Pj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+Pj4+PkZyb206IGwzdnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsM3Zwbi1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYNCj4+Pj4+T2YgTWluZ3VpIFpoYW5nDQo+Pj4+PlNlbnQ6IEZy aWRheSwgSnVseSAxOSwgMjAxMyAxOjE2IFBNDQo+Pj4+PlRvOiBsM3ZwbkBpZXRmLm9yZw0KPj4+ Pj5TdWJqZWN0OiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPj4+Pj5kcmFmdC16 aGFuZy1sM3Zwbi1sYWJlbC1zaGFyaW5nLTAwLnR4dA0KPj4+Pj4NCj4+Pj4+RGVhciBhbGwsDQo+ Pj4+Pg0KPj4+Pj5XZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdDogTGFiZWwgU2hhcmluZyBm b3IgRmFzdCBQRSBQcm90ZWN0aW9uLg0KPj4+Pj4NCj4+Pj4+ICAgVGhpcyBkcmFmdCBkZXNpZ25z IGEgc2ltcGxlIG1ldGhvZCB0byBiZSB1c2VkIGJ5IFNQcyB0byBhY2hpZXZlDQo+Pj4+PmZhc3QN Cj4+Pj4+UEUgcHJvdGVjdGlvbiwgdXRpbGl6aW5nIHRoZSBkZXBsb3ltZW50IG9mIHJlZHVuZGFu dCBlZ3Jlc3MgUEVzLg0KPj4+Pj4NCj4+Pj4+Q29tbWVudHMgYXJlIHdlbGNvbWUuDQo+Pj4+Pg0K Pj4+Pj5SZWdhcmRzLA0KPj4+Pj5NaW5ndWkNCj4+Pj4+DQo+Pj4+Pj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4+Pj4NCj4+Pj4+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXpoYW5n LWwzdnBuLWxhYmVsLXNoYXJpbmctMDAudHh0DQo+Pj4+PmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgTWluZ3VpIFpoYW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCj4+Pj4+cmVw b3NpdG9yeS4NCj4+Pj4+DQo+Pj4+PkZpbGVuYW1lOgkgZHJhZnQtemhhbmctbDN2cG4tbGFiZWwt c2hhcmluZw0KPj4+Pj5SZXZpc2lvbjoJIDAwDQo+Pj4+PlRpdGxlOgkJIExhYmVsIFNoYXJpbmcg Zm9yIEZhc3QgUEUgUHJvdGVjdGlvbg0KPj4+Pj5DcmVhdGlvbiBkYXRlOgkgMjAxMy0wNy0xMg0K Pj4+Pj5Hcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4+Pj4+TnVtYmVyIG9mIHBhZ2Vz OiAxMg0KPj4+Pj5VUkw6DQo+Pj4+Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LXpoYW5nLWwzdnBuLWxhYmVsLXNoYXJpbmctMDANCj4+Pj4+Lg0KPj4+Pj50eHQNCj4+ Pj4+U3RhdHVzOg0KPj4+Pj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpo YW5nLWwzdnBuLWxhYmVsLXNoYXJpbmcNCj4+Pj4+SHRtbGl6ZWQ6DQo+Pj4+aHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctbDN2cG4tbGFiZWwtc2hhcmluZy0wMA0KPj4+Pj4N Cj4+Pj4+DQo+Pj4+PkFic3RyYWN0Og0KPj4+Pj4gICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBh IG1ldGhvZCB0byBiZSB1c2VkIGJ5IFNlcnZpY2UgUHJvdmlkZXJzIHRvDQo+Pj4+PiAgIHByb3Zp ZGUgZmFzdCBwcm90ZWN0aW9uIG9mIFZQTiBjb25uZWN0aW9ucyBmb3IgYSBDRS4gRWdyZXNzIFBF cyBpbg0KPj4+Pj5hDQo+Pj4+PiAgIHJlZHVuZGFudCBncm91cCBhbHdheXMgYXNzaWduIHRoZSBz YW1lIGxhYmVsIGZvciBWUE4gcm91dGVzIGZyb20gYQ0KPj4+Pj4gICBWUkYuIFRoZXNlIGVncmVz cyBQRXMgY3JlYXRlIGEgQkdQIHZpcnR1YWwgTmV4dCBIb3AgKHZOSCkgaW4gdGhlDQo+Pj4+PiAg IGRvbWFpbiBvZiB0aGUgSVAvTVBMUyBiYWNrYm9uZSBuZXR3b3JrIGFzIGFuIGFnZW50IG9mIHRo ZSBDRQ0KPj4+Pj5yb3V0ZXIuDQo+Pj4+PiAgIFByaW1hcnkgYW5kIGJhY2t1cCB0dW5uZWxzIHRl cm1pbmF0ZWQgYXQgdGhlIHZOSCBhcmUgc2V0IHVwIGJ5IHRoZQ0KPj4+Pj4gICBCR1AvTVBMUyBJ UCBWUE4gYmFzZWQgb24gSUdQIEZSUi4gSWYgdGhlIHByaW1hcnkgZWdyZXNzIFBFIGZhaWxzLA0K Pj4+Pj50aGUNCj4+Pj4+ICAgYmFja3VwIGVncmVzcyBQRXMgY2FuIHJlY29nbml6ZSB0aGUgInNo YXJlZCIgVlBOIHJvdXRlIGxhYmVsIGFuZA0KPj4+Pj4gICBkZWxpdmVyIHRoZSBmYWlsdXJlIGFm ZmVjdGVkIHBhY2tldHMgYWNjb3JkaW5nbHkuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0K Pj4+Pj5UaGUgSUVURiBTZWNyZXRhcmlhdA0KPg0KDQo= From xuxiaohu@huawei.com Mon Jul 22 18:51:45 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEA921F9C82; Mon, 22 Jul 2013 18:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.502 X-Spam-Level: X-Spam-Status: No, score=-3.502 tagged_above=-999 required=5 tests=[AWL=-2.645, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 qy8CkkjUVjRL; Mon, 22 Jul 2013 18:51:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7C421F9CAD; Mon, 22 Jul 2013 18:51:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATR60126; Tue, 23 Jul 2013 01:51:33 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 02:50:36 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 02:51:12 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.175]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Tue, 23 Jul 2013 09:51:07 +0800 From: Xuxiaohu To: "Luyuan Fang (lufang)" , "UTTARO, JAMES" , Yakov Rekhter , "thomas.morin@orange.com" Subject: re: The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOhIJ1yIlB/WUnJ0iGPHkvmxyIC5lrdxmAgAA5jICABK6pgIABGz7g Date: Tue, 23 Jul 2013 01:51:06 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D80F2@NKGEML512-MBS.china.huawei.com> References: <0DB8F45437AB844CBB5102F807A0AD931044FBDC@xmb-rcd-x03.cisco.com> In-Reply-To: <0DB8F45437AB844CBB5102F807A0AD931044FBDC@xmb-rcd-x03.cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" , L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 01:51:45 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbDN2cG4tYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmwzdnBuLWJvdW5jZXNAaWV0Zi5vcmddILT6se0NCj4gTHV5dWFuIEZhbmcgKGx1 ZmFuZykNCj4gt6LLzcqxvOQ6IDIwMTPE6jfUwjIzyNUgMDoxOQ0KPiDK1bz+yMs6IFVUVEFSTywg SkFNRVM7IFlha292IFJla2h0ZXI7IHRob21hcy5tb3JpbkBvcmFuZ2UuY29tDQo+ILOty806IEwz VlBODQo+INb3zOI6IFJlOiBUaGUgcG9zc2liaWxpdHkgb2YgdXNpbmcgZ2xvYmFsIE1QTFMgbGFi ZWxzIGFzIFZOSXMgLi4uIGZvciBsM3Zwbg0KPiANCj4gQXMgSSByZW1lbWJlciwgdGhlIGdsb2Jh bCBWUE4tSUQgd2FzIGRpc2N1c3NlZC9kZWJhdGVkIGluIEwzVlBOIFdHIGFyb3VuZA0KPiAyMDAz LTIwMDYsIHRoZSBnbG9iYWwgVlBOLUlEIHdhcyBwcm9wb3NlZCBpbiB0aGUgdnIgZHJhZnQuIFRo ZSBnZW5lcmFsDQo+IGNvbnNlbnN1cyBvZiB0aGUgV0cgd2FzIHRoYXQgdGhlIEwzVlBOIHNvbHV0 aW9uIHdvdWxkIGJlIG1vcmUgZmxleGlibGUgYW5kDQo+IHNjYWxhYmxlIHdpdGhvdXQgdGhlIGds b2JhbCBWUE4tSUQsIGFzIHRoZSB3YXkgUkZDNDM2NC8yNTQ3IGhhbmRsaW5nIGl0Lg0KPiANCj4g SSBkb24ndCBiZWxpZXZlIHRoaXMgaGFzIGNoYW5nZWQgc2luY2UgdGhlbi4gSW4gZmFjdCwgdGhl IGV4dGVuc2l2ZSBsYXJnZQ0KPiBzY2FsZSBnbG9iYWwgZGVwbG95bWVudHMgb2YgNDM2NCBMM1ZQ TnMgb3ZlciB0aGUgcGFzdCAxNSB5ZWFycyBwcm92aWRlDQo+IGdvb2QgbGl2aW5nIHRlc3RpbW9u eSBvZiBpdC4NCg0KSSBmdWxseSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBtYWtlIHRoZSBtb3N0IG9m IHRoZSBleGlzdGluZyBhbmQgcHJvdmVuIHRlY2hub2xvZ2llcyBpZiBwb3NzaWJsZS4gVGhlIHJl YXNvbiB0aGF0IEkgc3RhcnRlZCB0aGlzIGRpc2N1c3Npb24gaXMgdG8gbWFrZSBzdXJlIHdoZXRo ZXIgdGhlIFZpcnR1YWwgTmV0d29yayBDb250ZXh0IElkZW50aWZpY2F0aW9uIGNvbnRhaW5lZCBp biB0aGUgZGF0YSBwYWNrZXQgaXMgUkVBTExZIHJlcXVpcmVkIHRvIGJlIGdsb2JhbGx5IHVuaXF1 ZSBpbiBzb21lIGNhc2VzLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUgDQoNCj4gTHV5dWFuDQo+ IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiA8VVRUQVJPPiwgSkFNRVMg PGp1MTczOEBhdHQuY29tPg0KPiBEYXRlOiBGcmlkYXksIEp1bHkgMTksIDIwMTMgMTI6NDkgUE0N Cj4gVG86IFlha292IFJla2h0ZXIgPHlha292QGp1bmlwZXIubmV0PiwgInRob21hcy5tb3JpbkBv cmFuZ2UuY29tIg0KPiA8dGhvbWFzLm1vcmluQG9yYW5nZS5jb20+DQo+IENjOiBMM1ZQTiA8bDN2 cG5AaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJFOiBUaGUgcG9zc2liaWxpdHkgb2YgdXNpbmcgZ2xv YmFsIE1QTFMgbGFiZWxzIGFzIFZOSXMgLi4uIGZvcg0KPiBsM3Zwbg0KPiANCj4gPkNvbW1lbnRz IEluLUxpbmUuLg0KPiA+DQo+ID5KaW0gVXR0YXJvDQo+ID4NCj4gPi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID5Gcm9tOiBsM3Zwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDN2cG4t Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ID5ZYWtvdiBSZWtodGVyDQo+ID5TZW50 OiBGcmlkYXksIEp1bHkgMTksIDIwMTMgOToyMyBBTQ0KPiA+VG86IHRob21hcy5tb3JpbkBvcmFu Z2UuY29tDQo+ID5DYzogTDNWUE4NCj4gPlN1YmplY3Q6IFJlOiBUaGUgcG9zc2liaWxpdHkgb2Yg dXNpbmcgZ2xvYmFsIE1QTFMgbGFiZWxzIGFzIFZOSXMgLi4uIGZvcg0KPiA+bDN2cG4NCj4gPg0K PiA+VGhvbWFzLA0KPiA+DQo+ID4+IDIwMTMtMDctMTgsIFh1eGlhb2h1Og0KPiA+PiA+DQo+ID4+ ID4gVGlsbCBub3csIGl0IHNlZW0gdGhhdCB0aGUgb25seSByZW1haW5pbmcgdGVjaG5pY2FsIHJl YXNvbiBmb3Igc29tZQ0KPiA+PiA+IHBlb3BsZSB0byBwcmVmZXIgVlhMQU4vTlZHUkUgZW5jYXBz dWxhdGlvbiBmb3JtYXQgdG8NCj4gPj4gPiBNQUMtaW4tTVBMUy1pbi1JUCBlbmNhcHN1bGF0aW9u IGZvcm1hdCBmb3IgbmV0d29yayB2aXJ0dWFsaXphdGlvbg0KPiA+PiA+IG92ZXJsYXkgaXMgdGhl IGZvcm1lciBoYXMgZ2xvYmFsIFZOSXMgd2hpbGUgdGhlIGxhdHRlciBkb2Vzbid0IGhhdmUuDQo+ ID4+ID4gSWYgdGhpcyByZWFzb24gaXMgdHJ1ZSwgd2h5IGNhbid0IHdlIGNvbnNpZGVyIHRoZSBw b3NzaWJpbGl0eSBvZg0KPiA+PiA+IHVzaW5nIGdsb2JhbCBNUExTIGxhYmVscyB0byBhY2hpZXZl IHRoZSBzYW1lIGdvYWw/DQo+ID4+DQo+ID4+IElNSE8sIGV4YW1pbmluZyAqd2h5KiBzb21lb25l IHdvdWxkIHdhbnQgYSAiZ2xvYmFsIFZOSSIgc2hvdWxkIGJlIHRoZQ0KPiA+PiBzdGFydCBvZiB0 aGUgZGlzY3Vzc2lvbiwgcmF0aGVyIHRoYW4gcG9zc2libGUgc29sdXRpb25zLg0KPiA+Pg0KPiA+ PiBJIGNvdWxkIHBvc3NpYmx5IHNlZSBhdCBsZWFzdCBvbmUgcmVhc29uICpub3QqIHRvIHRyeSB0 byBoYXZlIGENCj4gPj4gZGVkaWNhdGVkIGlkZW50aWZpZXIgaW4gdGhlIGRhdGFwbGFuZSBjb21t b24gZm9yIGFsbCBmbG93cyBvZiAiYSBWUE4iLg0KPiA+PiBJdCBpcyBub3QgcmVsYXRlZCB0byB0 aGUgZW5jYXBzdWxhdGlvbiwgYnV0IHRvIHRoZSBmYWN0IHRoYXQgUkZDNDM2NA0KPiA+PiBoYXMs IGluIGZhY3QsIG5vIHN0cmljdCBub3Rpb24gb2YgImEgVlBOIiwgYnV0IG9ubHkgb2YgaG93IGNv bm5lY3Rpdml0eQ0KPiA+PiBpcyBlc3RhYmxpc2hlZCBiZXR3ZWVucyBzZXQgb2YgVlJGcy4NCj4g Pg0KPiA+TW9yZW92ZXIsIGNvbm5lY3Rpdml0eSBiZXR3ZWVuIHNldCBvZiBWUkZzIGlzIG5vdCAi Y2FzdCBpbiBjb25jcmV0ZSIuDQo+ID5UbyB0aGUgY29udHJhcnkgaXQgY291bGQgY2hhbmdlLCBh cyBleHRyYW5ldHMgYXJlIGZvcm1lZC9kaXNzb2x2ZWQsDQo+ID5hbmQgdGhlIHByb2Nlc3Mgb2Yg Zm9ybWluZy9kaXNzb2x2aW5nIGV4dHJhbmV0cyBjb3VsZCBiZSBmYWlybHkNCj4gPmR5bmFtaWMu DQo+ID5bSmltIFU+XSBUaGlzIGhhcHBlbnMgdG9kYXkuLg0KPiA+DQo+ID5ZYWtvdi4NCj4gPg0K PiA+Pg0KPiA+PiAtVGhvbWFzDQo+ID4+DQo+ID4+DQo+ID4+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gX19fX19fX19fX18N Cj4gPj5fX19fXw0KPiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+Pg0KPiA+PiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCj4gPj5jb25maWRlbnRpZQ0KPiA+bGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQo+ID4+IHBhcyBldHJlIGRpZmZ1c2VzLCBleHBs b2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXoNCj4gPj5yZWN1 IGNlDQo+ID4gbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KPiA+PiBh IGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVz LiBMZXMNCj4gPj5tZXNzYWdlcyBlbGVjdA0KPiA+cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVz IGQnYWx0ZXJhdGlvbiwNCj4gPj4gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUNCj4gPj5vdSBmYWwNCj4gPnNpZmll LiBNZXJjaS4NCj4gPj4NCj4gPj4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5 IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQNCj4gPj5pbmZvcm0NCj4gPmF0aW9u IHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQo+ID4+IHRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPiA+SWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGFuZA0KPiA+ZGVsZXRlIHRoDQo+ID5pcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMuDQo+ID4+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUg Zm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZQ0KPiA+PmJlZW4gbW9kDQo+ID5pZmllZCwgY2hhbmdlZCBv ciBmYWxzaWZpZWQuDQo+ID4+IFRoYW5rIHlvdS4NCj4gPj4NCj4gPj4NCj4gPg0KDQo= From kireeti.kompella@gmail.com Mon Jul 22 23:39:54 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382DB21F9477; Mon, 22 Jul 2013 23:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] 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 XO32TjxrTeSf; Mon, 22 Jul 2013 23:39:53 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id AE71F21F8F78; Mon, 22 Jul 2013 23:39:53 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id b20so2792392yha.32 for ; Mon, 22 Jul 2013 23:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=XL4Q4Fmm2jOQttyQPB5TF/sNJE6vy3Afzmj+NCZ86N4=; b=elvTkTRaFEZBo6FxWwBuH7V9bnqZOLQmAncS31DyGTUTgJbAPdj0LdoAz8JOgrPTBW cGkVpC8SIBvBZoLxRdxOj0QZcSHBKIh3Ygzf++N6eOBccrjRShdqYr9S7Q6lOqV5h5JB llSYwL90aIN7lBIfXcwG92i6GXvIVqvfj9HE1BOVMXe9o8Ut9WR8E6b32pQi6y3lHG4Y 3M8zVVh3f6NzSC+9WzACcuvxbbHNXUjPSAMiJcn1/YAAGB6KmsRidpGlYJpIuxbg5mgi R3ItVvWLTiiI6xe7UXlxxM0FBslsonWN29YjWlUggm+DgFkERMKDuxc1klJkKMobEMGZ VMlw== X-Received: by 10.236.4.234 with SMTP id 70mr14598826yhj.182.1374561593145; Mon, 22 Jul 2013 23:39:53 -0700 (PDT) Received: from [10.111.95.242] (mobile-166-147-111-195.mycingular.net. [166.147.111.195]) by mx.google.com with ESMTPSA id o1sm43952359yho.2.2013.07.22.23.39.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 23:39:52 -0700 (PDT) References: <0DB8F45437AB844CBB5102F807A0AD931044FBDC@xmb-rcd-x03.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D80F2@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D80F2@NKGEML512-MBS.china.huawei.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <37C3D7DF-1B3E-401F-8A1E-A849835F0AE6@gmail.com> X-Mailer: iPhone Mail (10B329) From: Kireeti Kompella Subject: Re: The possibility of using global MPLS labels as VNIs ... for l3vpn Date: Tue, 23 Jul 2013 09:39:42 +0300 To: Xuxiaohu Cc: "thomas.morin@orange.com" , L3VPN , Yakov Rekhter , "nvo3@ietf.org" , "UTTARO, JAMES" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 06:39:54 -0000 Kireeti On Jul 23, 2013, at 4:51, Xuxiaohu wrote: > The reason that I started this discussion is to make sure whether the Virt= ual Network Context Identification contained in the data packet is REALLY re= quired to be globally unique in some cases. From kireeti.kompella@gmail.com Mon Jul 22 23:46:33 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A8911E8103; Mon, 22 Jul 2013 23:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] 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 DPf54BGQg0TB; Mon, 22 Jul 2013 23:46:32 -0700 (PDT) Received: from mail-ye0-x235.google.com (mail-ye0-x235.google.com [IPv6:2607:f8b0:4002:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id A468A11E80D1; Mon, 22 Jul 2013 23:46:32 -0700 (PDT) Received: by mail-ye0-f181.google.com with SMTP id g12so2392634yee.40 for ; Mon, 22 Jul 2013 23:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=eyyMnl8jfY0sLfPwzxibljNEKzaEhJXtmFu+zadZnoU=; b=MOqhmxE2rP6d8srlskotpCV6XGogXH0jgC1sPosTC4C4OqYivDhoeJIdV2yMnpVLKv Xvppt/ai/s9FApFeC9hQaO1jy5yN+m0NcTdwB+PnUIhlEsG8kIK0kgP+27wXxVQfhosN +RMIpU520KwvGXwFHl65M/oGeqmXgRpef0ge+qZiEiid6Jkl/NAtxjhCd8hsESOKM59A QwWtf+K7dZxBGcB9a3G+za8IGvEpsK1l/wLMvpdI9WQJfoWEr0hBX8llVhVgIzyG9aIR M1JuhXyRwjlHlGabXSpGPtgTNQMbaqOTrxPg+MUiUNgCq9e2HBenxGJJr9L4M/Ve9499 sKxQ== X-Received: by 10.236.120.230 with SMTP id p66mr14744116yhh.111.1374561991899; Mon, 22 Jul 2013 23:46:31 -0700 (PDT) Received: from [10.111.95.242] (mobile-166-147-111-195.mycingular.net. [166.147.111.195]) by mx.google.com with ESMTPSA id s47sm43950782yhl.19.2013.07.22.23.46.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 23:46:31 -0700 (PDT) References: <0DB8F45437AB844CBB5102F807A0AD931044FBDC@xmb-rcd-x03.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D80F2@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D80F2@NKGEML512-MBS.china.huawei.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <9921DABA-3484-4D52-813A-77119BEBAA58@gmail.com> X-Mailer: iPhone Mail (10B329) From: Kireeti Kompella Subject: Re: The possibility of using global MPLS labels as VNIs ... for l3vpn Date: Tue, 23 Jul 2013 09:46:19 +0300 To: Xuxiaohu Cc: "thomas.morin@orange.com" , L3VPN , Yakov Rekhter , "nvo3@ietf.org" , "UTTARO, JAMES" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 06:46:33 -0000 Hi Xuxiaohu, Sorry for the previous empty email.=20 On Jul 23, 2013, at 4:51, Xuxiaohu wrote: > The reason that I started this discussion is to make sure whether the Virt= ual Network Context Identification contained in the data packet is REALLY re= quired to be globally unique in some cases. No. There's nothing useful that I know that one can do with global IDs in th= e data plane that one cannot do with local IDs, and local IDs are easier to a= llocate and manage. So, I'd be going the other way and advocate locally sign= ificant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do) Kireeti= From xuxiaohu@huawei.com Tue Jul 23 00:05:56 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820C111E8103; Tue, 23 Jul 2013 00:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=-1.022, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 S-en+zLUNJLw; Tue, 23 Jul 2013 00:05:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1C43C11E80D1; Tue, 23 Jul 2013 00:05:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATR81943; Tue, 23 Jul 2013 07:05:48 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 08:04:48 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 08:05:41 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.175]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.01.0323.007; Tue, 23 Jul 2013 15:05:36 +0800 From: Xuxiaohu To: Kireeti Kompella Subject: re: The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOhIJ1yIlB/WUnJ0iGPHkvmxyIC5lrdxmAgAA5jICABK6pgIABGz7g///W/oCAAIa2YA== Date: Tue, 23 Jul 2013 07:05:35 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D820F@NKGEML512-MBS.china.huawei.com> References: <0DB8F45437AB844CBB5102F807A0AD931044FBDC@xmb-rcd-x03.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D80F2@NKGEML512-MBS.china.huawei.com> <9921DABA-3484-4D52-813A-77119BEBAA58@gmail.com> In-Reply-To: <9921DABA-3484-4D52-813A-77119BEBAA58@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Yakov Rekhter , "thomas.morin@orange.com" , "UTTARO, JAMES" , L3VPN , "nvo3@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 07:05:56 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbDN2cG4tYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmwzdnBuLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gS2lyZWV0aQ0KPiBLb21wZWxs YQ0KPiC3osvNyrG85DogMjAxM8TqN9TCMjPI1SAxNDo0Ng0KPiDK1bz+yMs6IFh1eGlhb2h1DQo+ ILOty806IHRob21hcy5tb3JpbkBvcmFuZ2UuY29tOyBMM1ZQTjsgWWFrb3YgUmVraHRlcjsgbnZv M0BpZXRmLm9yZzsNCj4gVVRUQVJPLCBKQU1FUw0KPiDW98ziOiBSZTogVGhlIHBvc3NpYmlsaXR5 IG9mIHVzaW5nIGdsb2JhbCBNUExTIGxhYmVscyBhcyBWTklzIC4uLiBmb3IgbDN2cG4NCj4gDQo+ IEhpIFh1eGlhb2h1LA0KPiANCj4gU29ycnkgZm9yIHRoZSBwcmV2aW91cyBlbXB0eSBlbWFpbC4N Cj4gDQo+IE9uIEp1bCAyMywgMjAxMywgYXQgNDo1MSwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdl aS5jb20+IHdyb3RlOg0KPiANCj4gPiBUaGUgcmVhc29uIHRoYXQgSSBzdGFydGVkIHRoaXMgZGlz Y3Vzc2lvbiBpcyB0byBtYWtlIHN1cmUgd2hldGhlciB0aGUgVmlydHVhbA0KPiBOZXR3b3JrIENv bnRleHQgSWRlbnRpZmljYXRpb24gY29udGFpbmVkIGluIHRoZSBkYXRhIHBhY2tldCBpcyBSRUFM TFkgcmVxdWlyZWQNCj4gdG8gYmUgZ2xvYmFsbHkgdW5pcXVlIGluIHNvbWUgY2FzZXMuDQo+IA0K PiBOby4gVGhlcmUncyBub3RoaW5nIHVzZWZ1bCB0aGF0IEkga25vdyB0aGF0IG9uZSBjYW4gZG8g d2l0aCBnbG9iYWwgSURzIGluIHRoZQ0KPiBkYXRhIHBsYW5lIHRoYXQgb25lIGNhbm5vdCBkbyB3 aXRoIGxvY2FsIElEcywgYW5kIGxvY2FsIElEcyBhcmUgZWFzaWVyIHRvDQo+IGFsbG9jYXRlIGFu ZCBtYW5hZ2UuIFNvLCBJJ2QgYmUgZ29pbmcgdGhlIG90aGVyIHdheSBhbmQgYWR2b2NhdGUgbG9j YWxseQ0KPiBzaWduaWZpY2FudCBWTklEcyBmb3IgVlhMQU4gYW5kIE5WR1JFLCBub3QgZ2xvYmFs IElEcyBmb3IgVlBOcy4gKEFuZCBJIGRvKQ0KDQpIaSBLaXJlZXRpLA0KDQpJJ3ZlIGV2ZXIgaGVh cmQgdGhhdCB0aGUgbWFqb3IgdGVjaG5pY2FsIHJlYXNvbiBmb3Igc29tZSBvcGVyYXRvcnMgdG8g cHJlZmVyIFZYTEFOIG9yIE5WR1JFIHRvIE1BQy1pbi1NUExTLWluLUlQIGFzIHRoZSBlbmNhcHN1 bGF0aW9uIHNjaGVtZSBpcyB0aGF0IHRoZSBmb3JtZXIgcHJvdmlkZXMgZ2xvYmFsIFZOSURzIGlu IHRoZSBkYXRhIHBhY2tldHMuIFRoZXJlZm9yZSwgSSB3YW50IHRvIGtub3cgdGhlIGNvbmNyZXRl IHVzZSBjYXNlcyB3aGVyZSB0aGUgZ2xvYmFsIFZOSUQgaXMgcmVxdWlyZWQuIE5vdyBzaW5jZSB5 b3UgYWR2b2NhdGUgbG9jYWxseSBzaWduaWZpY2FudCBWTklEcyBmb3IgVlhMQU4gYW5kIE5WR1JF LCB3b3VsZCB5b3UgcGxlYXNlIHNoYXJlIHlvdXIgcmVhc29uIHdoeSBub3QgZGlyZWN0bHkgdXNl IHRoZSBNQUMtaW4tTVBMUy1pbi1JUCBmb3JtYXQgd2hlcmUgdGhlIFZOSUQgKGkuZS4sIFZQTiBs YWJlbCkgaXMgYWxyZWFkeSBsb2NhbGx5IHNpZ25pZmljYW50Pw0KDQpCZXN0IHJlZ2FyZHMsDQpY aWFvaHUNCg0KPiBLaXJlZXRpDQo= From zhangmingui@huawei.com Tue Jul 23 01:21:40 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFC521E804D; Tue, 23 Jul 2013 01:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 TAMgBcdD9IVz; Tue, 23 Jul 2013 01:21:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CC72921F9FDE; Tue, 23 Jul 2013 01:21:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVI33132; Tue, 23 Jul 2013 08:21:25 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 09:20:27 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 09:21:20 +0100 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.110]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Tue, 23 Jul 2013 16:21:15 +0800 From: Mingui Zhang To: "erosen@cisco.com" Subject: RE: FW: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt Thread-Topic: FW: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt Thread-Index: AQHOhu2m99aNIcBiiE+hzMF4FJ/BvJlx4VuQ Date: Tue, 23 Jul 2013 08:21:14 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7335C7B0C@nkgeml508-mbx.china.huawei.com> References: Your message of Fri, 19 Jul 2013 07:46:23 -0000. <4552F0907735844E9204A62BBDD325E7335C721B@nkgeml508-mbx.china.huawei.com> <27326.1374505776@erosen-linux> In-Reply-To: <27326.1374505776@erosen-linux> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pwe3@ietf.org" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 08:21:40 -0000 Hi Eric, Please see my response in-line below. I add the pwe3 mailing list since this document is related to the following= draft submitted for pwe3. ICCP Application TLVs for VPN Route Label Sharing http://www.ietf.org/internet-drafts/draft-zhang-pwe3-iccp-label-sharing-00.= txt Thanks, Mingui >-----Original Message----- >From: Eric Rosen [mailto:erosen@cisco.com] >Sent: Monday, July 22, 2013 11:10 PM >To: Mingui Zhang >Cc: l3vpn@ietf.org; erosen@cisco.com >Subject: Re: FW: New Version Notification for >draft-zhang-l3vpn-label-sharing-00.txt > > >As far as I can tell, your scheme only handles the case where the two egre= ss >PEs connect to the exact same set of CEs. If so, this applicability >restriction should be clearly stated. > >In Figure 2.1, you show CE2 connected to PE3 and PE4. Now suppose we also >have CE4 connected to PE3 and PE5. If PE3 fails, one might want use PE4 a= s >a backup for CE2, while using PE5 as a backup for CE4. Your scheme doesn'= t >seem to handle this. Not exactly. If PE3 and PE4 allocate (1100, vNH1) for CE2 while PE3 and PE5 allocate (11= 01, vNH2) for CE4. The scheme works well. This also answers your first ques= tion. > >Also, even in the case of Figure 2.1, it seems entirely possibly that one >might want PE3's primary route to CE2 to be via the directly attached >interface, while wanting PE4's primary route to CE2 to be via PE3. Does >your scheme handle this case? Interesting point.=20 Yes, it handles. Please see the right part of eq1: Sxy3+M. If the backup tu= nnel goes through Pxy->PE4->PE3->vNH, then Sxy3+M < =3D Sxy4+S. That means = eq1 does not hold. From zhangmingui@huawei.com Tue Jul 23 01:38:51 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3221111E813D; Tue, 23 Jul 2013 01:38:51 -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=[AWL=-0.300, 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 Mmdgz5CPntY7; Tue, 23 Jul 2013 01:38:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 114D611E8103; Tue, 23 Jul 2013 01:38:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVI35046; Tue, 23 Jul 2013 08:38:42 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 09:38:11 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 09:38:20 +0100 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.110]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Tue, 23 Jul 2013 16:38:13 +0800 From: Mingui Zhang To: "Henderickx, Wim (Wim)" , "Nagendra Kumar (naikumar)" , "l3vpn@ietf.org" Subject: RE: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt Thread-Topic: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt Thread-Index: AQHOhHOpfQte+N5R0U+LUwKBoxU1zJlwBeKAgACErgCAAO67EA== Date: Tue, 23 Jul 2013 08:38:12 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7335C7B38@nkgeml508-mbx.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E7335C77FA@nkgeml508-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pwe3@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 08:38:51 -0000 The "shared label" does not equal to "global label". It is still a local la= bel allocated by each PE. Yes, the context label has been adopted. But it does not mean protection ap= proaches based on it have been adopted.=20 I agree with your point that there is always pros/cons of each solution. Co= existence may be not unacceptable. I add the pwe3 mailing list since this document is related to the following= draft submitted for pwe3. ICCP Application TLVs for VPN Route Label Sharing http://www.ietf.org/internet-drafts/draft-zhang-pwe3-iccp-label-sharing-00.= txt Thanks, Mingui >-----Original Message----- >From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] >Sent: Tuesday, July 23, 2013 2:54 AM >To: Mingui Zhang; Nagendra Kumar (naikumar); l3vpn@ietf.org >Subject: Re: New Version Notification for draft-zhang-l3vpn-label-sharing-= 00.txt > >There is always pros/cons of each solution but when the global label was >discussed in the past in L3VPN because it was less flexible compared to >current available approaches which have been adopted successfully. > >On 22/07/13 07:58, "Mingui Zhang" wrote: > >>Hi Wim, >> >>There should be alternative methods. But this document tries to provide a >>simple one. >> >>For example, >>a. It does not require multiple label spaces. >>b. It need not store context label tables repeatedly on each RG member. >>c. It does not changes the forwarding process. >>d. It does not bear the restriction of no penultimate-hop-popping. >> >>Thanks, >>Mingui >> >>>-----Original Message----- >>>From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] >>>Sent: Friday, July 19, 2013 7:32 PM >>>To: Mingui Zhang; Nagendra Kumar (naikumar); l3vpn@ietf.org >>>Subject: Re: New Version Notification for >>>draft-zhang-l3vpn-label-sharing-00.txt >>> >>>What you are trying to achieve can be done with Ctxt labels using locall= y >>>assigned labels. So no need for global labels. >>> >>>On 19/07/13 11:01, "Mingui Zhang" wrote: >>> >>>>Hi Nagendra, >>>> >>>>It can also be automatically negotiated through signaling among those >>>>egress PEs. I have composed the following draft for this point. >>>>ICCP Application TLVs for VPN Route Label Sharing - Mingui ZHANG >>>>http://www.ietf.org/id/draft-zhang-pwe3-iccp-label-sharing-00.txt >>>> >>>>Thanks, >>>>Mingui >>>> >>>>>-----Original Message----- >>>>>From: Nagendra Kumar (naikumar) [mailto:naikumar@cisco.com] >>>>>Sent: Friday, July 19, 2013 4:55 PM >>>>>To: Mingui Zhang; l3vpn@ietf.org >>>>>Subject: RE: New Version Notification for >>>>>draft-zhang-l3vpn-label-sharing-00.txt >>>>> >>>>>Hi, >>>>> >>>>>Thanks. Is the proposal is to manually assign/configure in each PE?. >>>>> >>>>>-Nagendra >>>>> >>>>>-----Original Message----- >>>>>From: Mingui Zhang [mailto:zhangmingui@huawei.com] >>>>>Sent: Friday, July 19, 2013 2:21 PM >>>>>To: Nagendra Kumar (naikumar); l3vpn@ietf.org >>>>>Subject: RE: New Version Notification for >>>>>draft-zhang-l3vpn-label-sharing-00.txt >>>>> >>>>>Hi Nagendra, >>>>> >>>>>In the method, the egress PEs in the RG have to use the same VPN route >>>>>label >>>>>for one VPN site (e.g., 1100 for VPN1). >>>>>As for the prefix, all prefixes (e.g., 10.1.1.0/24) learnt from this >>>>>VPN >>>>>site will be >>>>>stored in the corresponding VRF (e.g., VPN1' VPN instance) identified >>>>>by >>>>>the VPN >>>>>route label. >>>>> >>>>>I guess you propose to share the label "per-prefix". It's possible to >>>>>do >>>>>so but not >>>>>as common as the "per-VRF" assignment in current practice. >>>>> >>>>>Thanks, >>>>>Mingui >>>>> >>>>>>-----Original Message----- >>>>>>From: Nagendra Kumar (naikumar) [mailto:naikumar@cisco.com] >>>>>>Sent: Friday, July 19, 2013 4:15 PM >>>>>>To: Mingui Zhang; l3vpn@ietf.org >>>>>>Subject: RE: New Version Notification for >>>>>>draft-zhang-l3vpn-label-sharing-00.txt >>>>>> >>>>>>Hi Mingui, >>>>>> >>>>>>I couldn=B9t see any point mentioned in this draft on how egress PEs >>>>>>will >>>>>>assign same VPN label for the prefix. >>>>>> >>>>>>Can you please share the same?. Sorry, if I am missing something in >>>>>>the >>>>>>doc. >>>>>> >>>>>>Regards, >>>>>>nagendra >>>>>> >>>>>>-----Original Message----- >>>>>>From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behal= f >>>>>>Of Mingui Zhang >>>>>>Sent: Friday, July 19, 2013 1:16 PM >>>>>>To: l3vpn@ietf.org >>>>>>Subject: FW: New Version Notification for >>>>>>draft-zhang-l3vpn-label-sharing-00.txt >>>>>> >>>>>>Dear all, >>>>>> >>>>>>We have submitted a new draft: Label Sharing for Fast PE Protection. >>>>>> >>>>>> This draft designs a simple method to be used by SPs to achieve >>>>>>fast >>>>>>PE protection, utilizing the deployment of redundant egress PEs. >>>>>> >>>>>>Comments are welcome. >>>>>> >>>>>>Regards, >>>>>>Mingui >>>>>> >>>>>>>-----Original Message----- >>>>>> >>>>>>A new version of I-D, draft-zhang-l3vpn-label-sharing-00.txt >>>>>>has been successfully submitted by Mingui Zhang and posted to the IET= F >>>>>>repository. >>>>>> >>>>>>Filename: draft-zhang-l3vpn-label-sharing >>>>>>Revision: 00 >>>>>>Title: Label Sharing for Fast PE Protection >>>>>>Creation date: 2013-07-12 >>>>>>Group: Individual Submission >>>>>>Number of pages: 12 >>>>>>URL: >>>>>>http://www.ietf.org/internet-drafts/draft-zhang-l3vpn-label-sharing-0= 0 >>>>>>. >>>>>>txt >>>>>>Status: >>>>>>http://datatracker.ietf.org/doc/draft-zhang-l3vpn-label-sharing >>>>>>Htmlized: >>>>>http://tools.ietf.org/html/draft-zhang-l3vpn-label-sharing-00 >>>>>> >>>>>> >>>>>>Abstract: >>>>>> This document describes a method to be used by Service Providers t= o >>>>>> provide fast protection of VPN connections for a CE. Egress PEs in >>>>>>a >>>>>> redundant group always assign the same label for VPN routes from a >>>>>> VRF. These egress PEs create a BGP virtual Next Hop (vNH) in the >>>>>> domain of the IP/MPLS backbone network as an agent of the CE >>>>>>router. >>>>>> Primary and backup tunnels terminated at the vNH are set up by the >>>>>> BGP/MPLS IP VPN based on IGP FRR. If the primary egress PE fails, >>>>>>the >>>>>> backup egress PEs can recognize the "shared" VPN route label and >>>>>> deliver the failure affected packets accordingly. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>The IETF Secretariat >> From jeff.tantsura@ericsson.com Tue Jul 23 04:21:07 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3225211E8214; Tue, 23 Jul 2013 04:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 uIXxAGamDJWe; Tue, 23 Jul 2013 04:20:59 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id DA04911E8202; Tue, 23 Jul 2013 04:20:53 -0700 (PDT) X-AuditID: c618062d-b7fc36d0000032ea-0d-51ee6714f27d Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 92.EB.13034.4176EE15; Tue, 23 Jul 2013 13:20:53 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Tue, 23 Jul 2013 07:20:52 -0400 From: Jeff Tantsura To: Kireeti Kompella Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOh3BhC5P+t2mj8kOX9jZZgIECpZlyHoCf Date: Tue, 23 Jul 2013 11:20:51 +0000 Message-ID: <5BA81E7D-63FE-43EF-8039-8BEB38A46EBD@ericsson.com> References: <0DB8F45437AB844CBB5102F807A0AD931044FBDC@xmb-rcd-x03.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D80F2@NKGEML512-MBS.china.huawei.com>, <9921DABA-3484-4D52-813A-77119BEBAA58@gmail.com> In-Reply-To: <9921DABA-3484-4D52-813A-77119BEBAA58@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXRPlK5o+rtAgz1P+C2ezzrAarFm/yRG i7Pz/S0ePl/JaPF0vqTFhn1H2Sy2nl/FaHH8xzd2Bw6Pl/1zGD2m/N7I6rFz1l12j5Yjb1k9 liz5yeRxvekqkPvsJFsAexSXTUpqTmZZapG+XQJXxp09f9kKlrFXTJx7jLWB8QNrFyMnh4SA icTUu1PZIWwxiQv31rN1MXJxCAkcZZTYPv0OE0hCSGA5o8TCxkwQm03AQOL/t+MsILaIgKHE y/13GUEamAXamCR29FwGmyQsEC5x99Q+qKIIia4nWxghbCOJi3tawGwWAVWJdQ2TwOp5Bewl WtqmMEFsnskk8XvCZ6AEBwengK3EhgYzkBpGoOu+n1oDdhCzgLjErSfzmSCuFpBYsuc8M4Qt KvHy8T9WiBodiQW7P7FB2NoSyxa+ZobYJShxcuYTlgmMorOQjJqFpGUWkpZZSFoWMLKsYuQo LU4ty003MtjECIy8YxJsujsY97y0PMQozcGiJM67Su9MoJBAemJJanZqakFqUXxRaU5q8SFG Jg5OqQbGrv0XT7dPmP5P/HTY0neqRQET4m9WJTGy/XhZUqNuy7yxptHe5Gng7G83/k+dGDDJ wZP/QsQiWSdZ75m/trkbPV3muG2K0bSyO/df6qeHzFkWduLwEe3Sixfb78z+tnG2w8J5r393 BvhJxb5ddr/ovGX44u4rDDorbTfLPTZNmGkjcGt1365v/5VYijMSDbWYi4oTAZs+yXSKAgAA Cc: L3VPN , Yakov Rekhter , "nvo3@ietf.org" , "thomas.morin@orange.com" , "UTTARO, JAMES" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 11:21:07 -0000 +1 Regards, Jeff On Jul 23, 2013, at 7:46 AM, "Kireeti Kompella" wrote: > Hi Xuxiaohu, >=20 > Sorry for the previous empty email.=20 >=20 > On Jul 23, 2013, at 4:51, Xuxiaohu wrote: >=20 >> The reason that I started this discussion is to make sure whether the Vi= rtual Network Context Identification contained in the data packet is REALLY= required to be globally unique in some cases. >=20 > No. There's nothing useful that I know that one can do with global IDs in= the data plane that one cannot do with local IDs, and local IDs are easier= to allocate and manage. So, I'd be going the other way and advocate locall= y significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do= ) >=20 > Kireeti > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From martin.vigoureux@alcatel-lucent.com Tue Jul 23 05:06:03 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56A311E80EC for ; Tue, 23 Jul 2013 05:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, 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 AbbEp6Y8SC1v for ; Tue, 23 Jul 2013 05:05:58 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 6B82E11E80CC for ; Tue, 23 Jul 2013 05:05:58 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6NC5rH4024820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 23 Jul 2013 07:05:55 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6NC5fqr006960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 23 Jul 2013 14:05:53 +0200 Received: from [172.27.205.220] (135.239.27.38) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 23 Jul 2013 14:05:22 +0200 Message-ID: <51EE7181.1060704@alcatel-lucent.com> Date: Tue, 23 Jul 2013 14:05:21 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Subject: IETF87 L3VPN revised agenda - heads-up Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.38] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 12:06:04 -0000 All, as indicated by Thomas few days ago, we have reworked the agenda for our session in Berlin: http://www.ietf.org/proceedings/87/agenda/agenda-87-l3vpn Please note that a specific slot has been allocated to enable for a discussion on the potential activities of the L3VPN Working Group in the scope of data-centres and their interconnection. Some drafts are listed as reading material. An introduction will be given by the chairs, followed by an "open microphone" slot to which we invite interested people to express their views on the subject. Speakers, please start sending us (Dan, Thomas, and I) your slides. Thank you Martin From aldrin.isaac@gmail.com Tue Jul 23 05:59:59 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963A611E80FD; Tue, 23 Jul 2013 05:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] 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 oP+-tCKeDFjC; Tue, 23 Jul 2013 05:59:59 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2AB11E80F7; Tue, 23 Jul 2013 05:59:58 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id w20so6197707lbh.38 for ; Tue, 23 Jul 2013 05:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aY1zOqS7V1/1ugAErCH1XEaLsBwHif5nlLl6q3jnbbk=; b=WjWlEJzGJ1khTbzUgTR1Jj33CT7dOv1pXi3xx+oibl16LXqiff0Rjl1WvY8hYHulq1 ELgGVLq0VLVnaAmbGua0kikfyL7+UNytHFsBicGni391axh3bSTFIPwU6mc8y3CvS+I0 CAIH8Zj+x+6l8Ayutl+p0JuzvPOk3L/IaRal4X+dfNf+WneedcYTJctZkdkPOJ7ceq7I jiDIjof4n6jG5v/9knR9YH6PsL1EjsW3HlCgq3xWC9A155yYWKGIkSOz64erbNfODKuZ gtx4THTRjpQNByqB4h4gitF+TYdPamvH3VSncsq0ZYN6M/JGkNTwOWVZEZA9N6F87FX3 bWoA== MIME-Version: 1.0 X-Received: by 10.152.6.169 with SMTP id c9mr14947065laa.47.1374584397411; Tue, 23 Jul 2013 05:59:57 -0700 (PDT) Received: by 10.152.134.106 with HTTP; Tue, 23 Jul 2013 05:59:57 -0700 (PDT) In-Reply-To: <9921DABA-3484-4D52-813A-77119BEBAA58@gmail.com> References: <0DB8F45437AB844CBB5102F807A0AD931044FBDC@xmb-rcd-x03.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D80F2@NKGEML512-MBS.china.huawei.com> <9921DABA-3484-4D52-813A-77119BEBAA58@gmail.com> Date: Tue, 23 Jul 2013 08:59:57 -0400 Message-ID: Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn From: Aldrin Isaac To: Kireeti Kompella Content-Type: multipart/alternative; boundary=089e01493c06b8bc4d04e22d5edb X-Mailman-Approved-At: Tue, 23 Jul 2013 06:22:30 -0700 Cc: L3VPN , Yakov Rekhter , "nvo3@ietf.org" , "thomas.morin@orange.com" , "UTTARO, JAMES" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 12:59:59 -0000 --089e01493c06b8bc4d04e22d5edb Content-Type: text/plain; charset=ISO-8859-1 +1. Network operators lose flexibility with Global VNIDs. Virtual topology will be fine tuned on top of VNIDs by squeezing a square peg (ACLs) into a round hole (where it's otherwise not needed). I think local context IDs will make a come back once we regain our sanity. :). On Tuesday, July 23, 2013, Kireeti Kompella wrote: > Hi Xuxiaohu, > > Sorry for the previous empty email. > > On Jul 23, 2013, at 4:51, Xuxiaohu > > wrote: > > > The reason that I started this discussion is to make sure whether the > Virtual Network Context Identification contained in the data packet is > REALLY required to be globally unique in some cases. > > No. There's nothing useful that I know that one can do with global IDs in > the data plane that one cannot do with local IDs, and local IDs are easier > to allocate and manage. So, I'd be going the other way and advocate locally > significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do) > > Kireeti > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > --089e01493c06b8bc4d04e22d5edb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1.

Network operators lose flexibility=A0with Global VNI= Ds.=A0Virtual=A0topology will be fine tuned=A0on top of VNIDs by=A0squeezin= g a square peg (ACLs) into a round hole (where it's otherwise not neede= d). =A0I think=A0local context IDs will make= a come back once we regain our=A0sanity. =A0:).<= /div>

On Tuesday= , July 23, 2013, Kireeti Kompella wrote:
Hi Xuxiaohu,

Sorry for the previous empty email.

On Jul 23, 2013, at 4:51, Xuxiaohu <xuxiaohu@huawei.c= om> wrote:

> The reason that I started this discussion is to make sure whether the = Virtual Network Context Identification contained in the data packet is REAL= LY required to be globally unique in some cases.

No. There's nothing useful that I know that one can do with global IDs = in the data plane that one cannot do with local IDs, and local IDs are easi= er to allocate and manage. So, I'd be going the other way and advocate = locally significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (An= d I do)

Kireeti
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3
--089e01493c06b8bc4d04e22d5edb-- From tnadeau@lucidvision.com Tue Jul 23 07:01:48 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBA521E8055 for ; Tue, 23 Jul 2013 07:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6] 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 XipcoqjVsD8b for ; Tue, 23 Jul 2013 07:01:42 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id B79BB21E8092 for ; Tue, 23 Jul 2013 07:01:37 -0700 (PDT) Received: from [172.28.130.112] (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id 3FE97250B101; Tue, 23 Jul 2013 10:01:36 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: The possibility of using global MPLS labels as VNIs ... for l3vpn From: Thomas Nadeau In-Reply-To: <0DB8F45437AB844CBB5102F807A0AD931044FBDC@xmb-rcd-x03.cisco.com> Date: Tue, 23 Jul 2013 10:01:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <324CF8AA-05AB-4C7F-AF76-1A87FE7D3BD4@lucidvision.com> References: <0DB8F45437AB844CBB5102F807A0AD931044FBDC@xmb-rcd-x03.cisco.com> To: "Luyuan Fang (lufang)" X-Mailer: Apple Mail (2.1508) Cc: Yakov Rekhter , "thomas.morin@orange.com" , "UTTARO, JAMES" , L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 14:01:48 -0000 Another issue as I recall, was around the management and = administration of the ID space to avoid conflicts, etc... --Tom > As I remember, the global VPN-ID was discussed/debated in L3VPN WG = around > 2003-2006, the global VPN-ID was proposed in the vr draft. The general > consensus of the WG was that the L3VPN solution would be more flexible = and > scalable without the global VPN-ID, as the way RFC4364/2547 handling = it. >=20 > I don't believe this has changed since then. In fact, the extensive = large > scale global deployments of 4364 L3VPNs over the past 15 years provide > good living testimony of it. >=20 >=20 > Luyuan >=20 > -----Original Message----- > From: , JAMES > Date: Friday, July 19, 2013 12:49 PM > To: Yakov Rekhter , "thomas.morin@orange.com" > > Cc: L3VPN > Subject: RE: The possibility of using global MPLS labels as VNIs ... = for > l3vpn >=20 >> Comments In-Line.. >>=20 >> Jim Uttaro >>=20 >> -----Original Message----- >> From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On = Behalf Of >> Yakov Rekhter >> Sent: Friday, July 19, 2013 9:23 AM >> To: thomas.morin@orange.com >> Cc: L3VPN >> Subject: Re: The possibility of using global MPLS labels as VNIs ... = for >> l3vpn >>=20 >> Thomas, >>=20 >>> 2013-07-18, Xuxiaohu: >>>>=20 >>>> Till now, it seem that the only remaining technical reason for some >>>> people to prefer VXLAN/NVGRE encapsulation format to >>>> MAC-in-MPLS-in-IP encapsulation format for network virtualization >>>> overlay is the former has global VNIs while the latter doesn't = have. >>>> If this reason is true, why can't we consider the possibility of >>>> using global MPLS labels to achieve the same goal? >>>=20 >>> IMHO, examining *why* someone would want a "global VNI" should be = the >>> start of the discussion, rather than possible solutions. >>>=20 >>> I could possibly see at least one reason *not* to try to have a >>> dedicated identifier in the dataplane common for all flows of "a = VPN". >>> It is not related to the encapsulation, but to the fact that RFC4364 >>> has, in fact, no strict notion of "a VPN", but only of how = connectivity >>> is established betweens set of VRFs. >>=20 >> Moreover, connectivity between set of VRFs is not "cast in concrete". >> To the contrary it could change, as extranets are formed/dissolved, >> and the process of forming/dissolving extranets could be fairly >> dynamic. >> [Jim U>] This happens today.. >>=20 >> Yakov. >>=20 >>>=20 >>> -Thomas >>>=20 >>>=20 >>> = _________________________________________________________________________ >>> _____ >> ___________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentie >> lles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez >>> recu ce >> message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les >>> messages elect >> roniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, = deforme >>> ou fal >> sifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or = privileged >>> inform >> ation that may be protected by law; >>> they should not be distributed, used or copied without = authorisation. >> If you have received this email in error, please notify the sender = and >> delete th >> is message and its attachments. >>> As emails may be altered, Orange is not liable for messages that = have >>> been mod >> ified, changed or falsified. >>> Thank you. >>>=20 >>>=20 >>=20 >=20 >=20 From mn1921@att.com Tue Jul 23 07:06:23 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68D711E8222; Tue, 23 Jul 2013 07:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[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 W3F6zEFsGTn4; Tue, 23 Jul 2013 07:06:18 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id DDA3E11E814B; Tue, 23 Jul 2013 07:06:17 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 9dd8ee15.489f9940.1521061.00-543.4175467.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 23 Jul 2013 14:06:17 +0000 (UTC) X-MXL-Hash: 51ee8dd974a031d3-c5a8fb874515635ebe27f827fd0097a32964cdb7 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id cbd8ee15.0.1520668.00-170.4174370.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 23 Jul 2013 14:06:15 +0000 (UTC) X-MXL-Hash: 51ee8dd728f31dc7-bc07fe14a6c4ca342e726d01520ef563e2c89f11 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6NE5mgN004496; Tue, 23 Jul 2013 10:05:48 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6NE5fSp004286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jul 2013 10:05:44 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Tue, 23 Jul 2013 14:05:18 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0342.003; Tue, 23 Jul 2013 10:05:18 -0400 From: "NAPIERALA, MARIA H" To: Xuxiaohu , Yakov Rekhter , "thomas.morin@orange.com" Subject: RE: The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOhIJvNVczrDWN+0+O/Ezo7cRjpplsQESAgAP2HwCAAhmwoA== Date: Tue, 23 Jul 2013 14:05:18 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01206A30@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D6B60@NKGEML512-MBS.china.huawei.com> <9252_1374239900_51E93C9C_9252_4871_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D0751AC91@PEXCVZYM13.corporate.adroot.infra.ftgroup> <201307191323.r6JDNBL44457@magenta.juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D7364@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D7364@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.104.246] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=Sa5AgItu c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=ePGvkPwV-BMA:10 a=FsBSW_QmHFQA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=F-Rx8qf4j4kA:10 a=48vgC7mUAAAA:8 a=wFSdBG3fPE5c1O] X-AnalysisOut: [DV4eYA:9 a=CjuIK1q_8ugA:10] Cc: "nvo3@ietf.org" , L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 14:06:24 -0000 Xuxiaohu, > Is extranet is a normal requirement for Layer3 DC network > virtualization overlay? I haven't seen any description of this in the > NVo3 requirement and framework drafts yet. Since we have not been able to fully pursue it as a requirement in nvo3, we= have created a separate requirement document (http://tools.ietf.org/html/d= raft-fang-l3vpn-end-system-requirements-00) in l3vpn WG where it is stated = as a requirement: "A network virtualization solution should allow a VM or application end-p= oint to directly access multiple VPNs without a need to traverse a gateway.= It is often the case that SP infrastructure services are provided to multi= ple tenants, for example voice-over-IP gateway services or video-conferenci= ng services for branch offices. A network virtualization solution should su= pport both, isolated VPNs and overlapping VPNs (often referred to as "extra= nets"), as well as both, any-to-any and hub-and-spoke topologies." Maria From lufang@cisco.com Tue Jul 23 07:12:38 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2FD11E8218 for ; Tue, 23 Jul 2013 07:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8] 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 tPAEkOA75I1f for ; Tue, 23 Jul 2013 07:12:33 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7174411E8222 for ; Tue, 23 Jul 2013 07:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4511; q=dns/txt; s=iport; t=1374588746; x=1375798346; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=AgFkO03loR8um0F1zf71z1wsFxmE5syUH+/lAnEo7gQ=; b=EbqouWiPk6uTSR4EpQHvsSE2fw8kDXhTC4jidPevChNt1HMHoWLTefiJ hXALZkjviBpB0cmrRc/tdRsFY51ONOU9UDpBrO8QT9ykFl2VY166F4bXU QItkWljzneGLMcGyaLc3BNJvxAEF2bIJE7qaAM8oOX1MMI6653afNOO0d U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAEyO7lGtJV2Z/2dsb2JhbABagwaBBcA6gRMWdIIkAQEBAwE6PwwGAQgOAwMBAQELFAk5FAkIAgQOBQgTh28GuEyOUYERBisHBoMKbgOpKoMSgXE5 X-IronPort-AV: E=Sophos;i="4.89,728,1367971200"; d="scan'208";a="238269827" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 23 Jul 2013 14:12:26 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6NECPjZ028584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Jul 2013 14:12:25 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.202]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Tue, 23 Jul 2013 09:12:25 -0500 From: "Luyuan Fang (lufang)" To: Thomas Nadeau Subject: Re: The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOhIJ87Rz8qHbLQUeZKpoWu4I/m5lsUQeAgAA5jICABGuWgIABru6A//+/9IA= Date: Tue, 23 Jul 2013 14:12:25 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD93104699D8@xmb-rcd-x03.cisco.com> In-Reply-To: <324CF8AA-05AB-4C7F-AF76-1A87FE7D3BD4@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.21.103.12] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Yakov Rekhter , "thomas.morin@orange.com" , "UTTARO, JAMES" , L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 14:12:38 -0000 Yep. Thanks, Tom! Certainly another very important reason to avoid global ID, especially considering operational impact which protocol designers sometimes forget. Luyuan -----Original Message----- From: Thomas Nadeau Date: Tuesday, July 23, 2013 10:01 AM To: Luyuan Fang Cc: "UTTARO, JAMES" , Yakov Rekhter , "thomas.morin@orange.com" , L3VPN Subject: Re: The possibility of using global MPLS labels as VNIs ... for l3vpn > > Another issue as I recall, was around the management and administration >of the ID space to avoid conflicts, etc... > > --Tom > > >> As I remember, the global VPN-ID was discussed/debated in L3VPN WG >>around >> 2003-2006, the global VPN-ID was proposed in the vr draft. The general >> consensus of the WG was that the L3VPN solution would be more flexible >>and >> scalable without the global VPN-ID, as the way RFC4364/2547 handling it. >>=20 >> I don't believe this has changed since then. In fact, the extensive >>large >> scale global deployments of 4364 L3VPNs over the past 15 years provide >> good living testimony of it. >>=20 >>=20 >> Luyuan >>=20 >> -----Original Message----- >> From: , JAMES >> Date: Friday, July 19, 2013 12:49 PM >> To: Yakov Rekhter , "thomas.morin@orange.com" >> >> Cc: L3VPN >> Subject: RE: The possibility of using global MPLS labels as VNIs ... for >> l3vpn >>=20 >>> Comments In-Line.. >>>=20 >>> Jim Uttaro >>>=20 >>> -----Original Message----- >>> From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf >>>Of >>> Yakov Rekhter >>> Sent: Friday, July 19, 2013 9:23 AM >>> To: thomas.morin@orange.com >>> Cc: L3VPN >>> Subject: Re: The possibility of using global MPLS labels as VNIs ... >>>for >>> l3vpn >>>=20 >>> Thomas, >>>=20 >>>> 2013-07-18, Xuxiaohu: >>>>>=20 >>>>> Till now, it seem that the only remaining technical reason for some >>>>> people to prefer VXLAN/NVGRE encapsulation format to >>>>> MAC-in-MPLS-in-IP encapsulation format for network virtualization >>>>> overlay is the former has global VNIs while the latter doesn't have. >>>>> If this reason is true, why can't we consider the possibility of >>>>> using global MPLS labels to achieve the same goal? >>>>=20 >>>> IMHO, examining *why* someone would want a "global VNI" should be the >>>> start of the discussion, rather than possible solutions. >>>>=20 >>>> I could possibly see at least one reason *not* to try to have a >>>> dedicated identifier in the dataplane common for all flows of "a VPN". >>>> It is not related to the encapsulation, but to the fact that RFC4364 >>>> has, in fact, no strict notion of "a VPN", but only of how >>>>connectivity >>>> is established betweens set of VRFs. >>>=20 >>> Moreover, connectivity between set of VRFs is not "cast in concrete". >>> To the contrary it could change, as extranets are formed/dissolved, >>> and the process of forming/dissolving extranets could be fairly >>> dynamic. >>> [Jim U>] This happens today.. >>>=20 >>> Yakov. >>>=20 >>>>=20 >>>> -Thomas >>>>=20 >>>>=20 >>>>=20 >>>>_______________________________________________________________________ >>>>__ >>>> _____ >>> ___________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentie >>> lles ou privilegiees et ne doivent donc >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>>> recu ce >>> message par erreur, veuillez le signaler >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les >>>> messages elect >>> roniques etant susceptibles d'alteration, >>>> Orange decline toute responsabilite si ce message a ete altere, >>>>deforme >>>> ou fal >>> sifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or >>>>privileged >>>> inform >>> ation that may be protected by law; >>>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and >>> delete th >>> is message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that have >>>> been mod >>> ified, changed or falsified. >>>> Thank you. >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 > From lufang@cisco.com Tue Jul 23 07:32:05 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C61911E823B; Tue, 23 Jul 2013 07:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.128 X-Spam-Level: X-Spam-Status: No, score=-7.128 tagged_above=-999 required=5 tests=[AWL=-2.271, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] 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 Z1N3-qTW+KNm; Tue, 23 Jul 2013 07:31:59 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 528BA11E8232; Tue, 23 Jul 2013 07:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7112; q=dns/txt; s=iport; t=1374589919; x=1375799519; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7NvBWOtEhATT3spBSaIOJhkdo2V1ens2Fs9RuzS5O2Y=; b=ZodYII7mw7naRue9Owt8PXhuURR9hNVcuGcBgkSVlmdNNpKlROsmhJXO kMkVBJOYIjvv4lo4RfhYrwdMZhTubJynLYzbuv2/LvI6M0PCAqP46hywk UZ7Ru/Kq+AaI6Rvor3iVftDueoD/DcoOVB2eM+VVk6v7qtjc0Aua0HHl1 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAHOT7lGtJV2b/2dsb2JhbABagwaBBYMJvTEXexZ0giQBAQEENEUMBgEGAhEDAQEBBQYdBQQwFAkIAgQBDQUIE4d1iyWbOwiRZ4EkjS2BDwIGEBsHBAKCUzduA6kqgxKBcTk X-IronPort-AV: E=Sophos;i="4.89,728,1367971200"; d="scan'208";a="238110254" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 23 Jul 2013 14:31:58 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6NEVwPN011876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Jul 2013 14:31:58 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.202]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Tue, 23 Jul 2013 09:31:57 -0500 From: "Luyuan Fang (lufang)" To: Xuxiaohu , "UTTARO, JAMES" , "Yakov Rekhter" , "thomas.morin@orange.com" Subject: Re: The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOhIJ87Rz8qHbLQUeZKpoWu4I/m5lsUQeAgAA5jICABGuWgIAA4tQAgACRg4A= Date: Tue, 23 Jul 2013 14:31:57 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD9310469A42@xmb-rcd-x03.cisco.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D80F2@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.21.103.12] Content-Type: text/plain; charset="gb2312" Content-ID: <52687E9197DDDF4FBF81726D8C8B2513@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "nvo3@ietf.org" , L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 14:32:05 -0000 WGlhb2h1LA0KDQpUaGFua3MuIEkgdGhpbmsgd2UgYXJlIGluIGFncmVlbWVudC4NCk9uZSBzbWFs bCBzdWJ0bGV0eSB0byBwb2ludCBvdXQsICJleGlzdGluZyIgaXMgbm90IHRoZSByZWFzb24sICJw cm92ZW4iDQoodG8gc2NhbGUpLCB5ZXMuIEl0IGlzICJyaWdodCI6LSksIG5vdCBiZWNhdXNlIGl0 IGlzIHRoZXJlLg0KDQo+d2hldGhlciB0aGUgVmlydHVhbCBOZXR3b3JrIENvbnRleHQgSWRlbnRp ZmljYXRpb24gY29udGFpbmVkIGluIHRoZSBkYXRhDQo+cGFja2V0IGlzIFJFQUxMWSByZXF1aXJl ZCB0byBiZSBnbG9iYWxseSB1bmlxdWUgaW4gc29tZSBjYXNlcy4NCk5vdCBJIGtub3cgb2YuIA0K DQpUaGFua3MsDQpMdXl1YW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFh1 eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPg0KRGF0ZTogTW9uZGF5LCBKdWx5IDIyLCAyMDEz IDk6NTEgUE0NClRvOiBMdXl1YW4gRmFuZyA8bHVmYW5nQGNpc2NvLmNvbT4sICJVVFRBUk8sIEpB TUVTIiA8anUxNzM4QGF0dC5jb20+LA0KWWFrb3YgUmVraHRlciA8eWFrb3ZAanVuaXBlci5uZXQ+ LCAidGhvbWFzLm1vcmluQG9yYW5nZS5jb20iDQo8dGhvbWFzLm1vcmluQG9yYW5nZS5jb20+DQpD YzogTDNWUE4gPGwzdnBuQGlldGYub3JnPiwgIm52bzNAaWV0Zi5vcmciIDxudm8zQGlldGYub3Jn Pg0KU3ViamVjdDogcmU6IFRoZSBwb3NzaWJpbGl0eSBvZiB1c2luZyBnbG9iYWwgTVBMUyBsYWJl bHMgYXMgVk5JcyAuLi4gZm9yDQpsM3Zwbg0KDQo+DQo+DQo+PiAtLS0tLdPKvP7Urbz+LS0tLS0N Cj4+ILeivP7IyzogbDN2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwzdnBuLWJvdW5jZXNA aWV0Zi5vcmddILT6se0NCj4+IEx1eXVhbiBGYW5nIChsdWZhbmcpDQo+PiC3osvNyrG85DogMjAx M8TqN9TCMjPI1SAwOjE5DQo+PiDK1bz+yMs6IFVUVEFSTywgSkFNRVM7IFlha292IFJla2h0ZXI7 IHRob21hcy5tb3JpbkBvcmFuZ2UuY29tDQo+PiCzrcvNOiBMM1ZQTg0KPj4g1vfM4jogUmU6IFRo ZSBwb3NzaWJpbGl0eSBvZiB1c2luZyBnbG9iYWwgTVBMUyBsYWJlbHMgYXMgVk5JcyAuLi4gZm9y DQo+PmwzdnBuDQo+PiANCj4+IEFzIEkgcmVtZW1iZXIsIHRoZSBnbG9iYWwgVlBOLUlEIHdhcyBk aXNjdXNzZWQvZGViYXRlZCBpbiBMM1ZQTiBXRw0KPj5hcm91bmQNCj4+IDIwMDMtMjAwNiwgdGhl IGdsb2JhbCBWUE4tSUQgd2FzIHByb3Bvc2VkIGluIHRoZSB2ciBkcmFmdC4gVGhlIGdlbmVyYWwN Cj4+IGNvbnNlbnN1cyBvZiB0aGUgV0cgd2FzIHRoYXQgdGhlIEwzVlBOIHNvbHV0aW9uIHdvdWxk IGJlIG1vcmUgZmxleGlibGUNCj4+YW5kDQo+PiBzY2FsYWJsZSB3aXRob3V0IHRoZSBnbG9iYWwg VlBOLUlELCBhcyB0aGUgd2F5IFJGQzQzNjQvMjU0NyBoYW5kbGluZyBpdC4NCj4+IA0KPj4gSSBk b24ndCBiZWxpZXZlIHRoaXMgaGFzIGNoYW5nZWQgc2luY2UgdGhlbi4gSW4gZmFjdCwgdGhlIGV4 dGVuc2l2ZQ0KPj5sYXJnZQ0KPj4gc2NhbGUgZ2xvYmFsIGRlcGxveW1lbnRzIG9mIDQzNjQgTDNW UE5zIG92ZXIgdGhlIHBhc3QgMTUgeWVhcnMgcHJvdmlkZQ0KPj4gZ29vZCBsaXZpbmcgdGVzdGlt b255IG9mIGl0Lg0KPg0KPkkgZnVsbHkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgbWFrZSB0aGUgbW9z dCBvZiB0aGUgZXhpc3RpbmcgYW5kIHByb3Zlbg0KPnRlY2hub2xvZ2llcyBpZiBwb3NzaWJsZS4g VGhlIHJlYXNvbiB0aGF0IEkgc3RhcnRlZCB0aGlzIGRpc2N1c3Npb24gaXMgdG8NCj5tYWtlIHN1 cmUgd2hldGhlciB0aGUgVmlydHVhbCBOZXR3b3JrIENvbnRleHQgSWRlbnRpZmljYXRpb24gY29u dGFpbmVkIGluDQo+dGhlIGRhdGEgcGFja2V0IGlzIFJFQUxMWSByZXF1aXJlZCB0byBiZSBnbG9i YWxseSB1bmlxdWUgaW4gc29tZSBjYXNlcy4NCj4NCj5CZXN0IHJlZ2FyZHMsDQo+WGlhb2h1IA0K Pg0KPj4gTHV5dWFuDQo+PiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9t OiA8VVRUQVJPPiwgSkFNRVMgPGp1MTczOEBhdHQuY29tPg0KPj4gRGF0ZTogRnJpZGF5LCBKdWx5 IDE5LCAyMDEzIDEyOjQ5IFBNDQo+PiBUbzogWWFrb3YgUmVraHRlciA8eWFrb3ZAanVuaXBlci5u ZXQ+LCAidGhvbWFzLm1vcmluQG9yYW5nZS5jb20iDQo+PiA8dGhvbWFzLm1vcmluQG9yYW5nZS5j b20+DQo+PiBDYzogTDNWUE4gPGwzdnBuQGlldGYub3JnPg0KPj4gU3ViamVjdDogUkU6IFRoZSBw b3NzaWJpbGl0eSBvZiB1c2luZyBnbG9iYWwgTVBMUyBsYWJlbHMgYXMgVk5JcyAuLi4gZm9yDQo+ PiBsM3Zwbg0KPj4gDQo+PiA+Q29tbWVudHMgSW4tTGluZS4uDQo+PiA+DQo+PiA+SmltIFV0dGFy bw0KPj4gPg0KPj4gPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+RnJvbTogbDN2cG4t Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwzdnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs Zg0KPj5PZg0KPj4gPllha292IFJla2h0ZXINCj4+ID5TZW50OiBGcmlkYXksIEp1bHkgMTksIDIw MTMgOToyMyBBTQ0KPj4gPlRvOiB0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbQ0KPj4gPkNjOiBMM1ZQ Tg0KPj4gPlN1YmplY3Q6IFJlOiBUaGUgcG9zc2liaWxpdHkgb2YgdXNpbmcgZ2xvYmFsIE1QTFMg bGFiZWxzIGFzIFZOSXMgLi4uDQo+PmZvcg0KPj4gPmwzdnBuDQo+PiA+DQo+PiA+VGhvbWFzLA0K Pj4gPg0KPj4gPj4gMjAxMy0wNy0xOCwgWHV4aWFvaHU6DQo+PiA+PiA+DQo+PiA+PiA+IFRpbGwg bm93LCBpdCBzZWVtIHRoYXQgdGhlIG9ubHkgcmVtYWluaW5nIHRlY2huaWNhbCByZWFzb24gZm9y IHNvbWUNCj4+ID4+ID4gcGVvcGxlIHRvIHByZWZlciBWWExBTi9OVkdSRSBlbmNhcHN1bGF0aW9u IGZvcm1hdCB0bw0KPj4gPj4gPiBNQUMtaW4tTVBMUy1pbi1JUCBlbmNhcHN1bGF0aW9uIGZvcm1h dCBmb3IgbmV0d29yayB2aXJ0dWFsaXphdGlvbg0KPj4gPj4gPiBvdmVybGF5IGlzIHRoZSBmb3Jt ZXIgaGFzIGdsb2JhbCBWTklzIHdoaWxlIHRoZSBsYXR0ZXIgZG9lc24ndA0KPj5oYXZlLg0KPj4g Pj4gPiBJZiB0aGlzIHJlYXNvbiBpcyB0cnVlLCB3aHkgY2FuJ3Qgd2UgY29uc2lkZXIgdGhlIHBv c3NpYmlsaXR5IG9mDQo+PiA+PiA+IHVzaW5nIGdsb2JhbCBNUExTIGxhYmVscyB0byBhY2hpZXZl IHRoZSBzYW1lIGdvYWw/DQo+PiA+Pg0KPj4gPj4gSU1ITywgZXhhbWluaW5nICp3aHkqIHNvbWVv bmUgd291bGQgd2FudCBhICJnbG9iYWwgVk5JIiBzaG91bGQgYmUgdGhlDQo+PiA+PiBzdGFydCBv ZiB0aGUgZGlzY3Vzc2lvbiwgcmF0aGVyIHRoYW4gcG9zc2libGUgc29sdXRpb25zLg0KPj4gPj4N Cj4+ID4+IEkgY291bGQgcG9zc2libHkgc2VlIGF0IGxlYXN0IG9uZSByZWFzb24gKm5vdCogdG8g dHJ5IHRvIGhhdmUgYQ0KPj4gPj4gZGVkaWNhdGVkIGlkZW50aWZpZXIgaW4gdGhlIGRhdGFwbGFu ZSBjb21tb24gZm9yIGFsbCBmbG93cyBvZiAiYQ0KPj5WUE4iLg0KPj4gPj4gSXQgaXMgbm90IHJl bGF0ZWQgdG8gdGhlIGVuY2Fwc3VsYXRpb24sIGJ1dCB0byB0aGUgZmFjdCB0aGF0IFJGQzQzNjQN Cj4+ID4+IGhhcywgaW4gZmFjdCwgbm8gc3RyaWN0IG5vdGlvbiBvZiAiYSBWUE4iLCBidXQgb25s eSBvZiBob3cNCj4+Y29ubmVjdGl2aXR5DQo+PiA+PiBpcyBlc3RhYmxpc2hlZCBiZXR3ZWVucyBz ZXQgb2YgVlJGcy4NCj4+ID4NCj4+ID5Nb3Jlb3ZlciwgY29ubmVjdGl2aXR5IGJldHdlZW4gc2V0 IG9mIFZSRnMgaXMgbm90ICJjYXN0IGluIGNvbmNyZXRlIi4NCj4+ID5UbyB0aGUgY29udHJhcnkg aXQgY291bGQgY2hhbmdlLCBhcyBleHRyYW5ldHMgYXJlIGZvcm1lZC9kaXNzb2x2ZWQsDQo+PiA+ YW5kIHRoZSBwcm9jZXNzIG9mIGZvcm1pbmcvZGlzc29sdmluZyBleHRyYW5ldHMgY291bGQgYmUg ZmFpcmx5DQo+PiA+ZHluYW1pYy4NCj4+ID5bSmltIFU+XSBUaGlzIGhhcHBlbnMgdG9kYXkuLg0K Pj4gPg0KPj4gPllha292Lg0KPj4gPg0KPj4gPj4NCj4+ID4+IC1UaG9tYXMNCj4+ID4+DQo+PiA+ Pg0KPj4gPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gX19fX19fX19fX18NCj4+ID4+X19fX18NCj4+ID5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+Pg0KPj4gPj4gQ2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z DQo+PiA+PmNvbmZpZGVudGllDQo+PiA+bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu dCBkb25jDQo+PiA+PiBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z IGF1dG9yaXNhdGlvbi4gU2kgdm91cw0KPj5hdmV6DQo+PiA+PnJlY3UgY2UNCj4+ID4gbWVzc2Fn ZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KPj4gPj4gYSBsJ2V4cGVkaXRldXIg ZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzDQo+PiA+Pm1l c3NhZ2VzIGVsZWN0DQo+PiA+cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlv biwNCj4+ID4+IE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh Z2UgYSBldGUgYWx0ZXJlLA0KPj5kZWZvcm1lDQo+PiA+Pm91IGZhbA0KPj4gPnNpZmllLiBNZXJj aS4NCj4+ID4+DQo+PiA+PiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3INCj4+cHJpdmlsZWdlZA0KPj4gPj5pbmZvcm0NCj4+ID5hdGlv biB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KPj4gPj4gdGhleSBzaG91bGQgbm90IGJl IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+PiA+ SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGFuZA0KPj4gPmRlbGV0ZSB0aA0KPj4gPmlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cy4NCj4+ID4+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBs aWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZQ0KPj4gPj5iZWVuIG1vZA0KPj4gPmlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4+ID4+IFRoYW5rIHlvdS4NCj4+ID4+DQo+PiA+Pg0KPj4g Pg0KPg0KDQo= From erosen@cisco.com Tue Jul 23 07:42:34 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C121411E824E; Tue, 23 Jul 2013 07:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 wNpInx1GxhwV; Tue, 23 Jul 2013 07:42:29 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 210EF11E8254; Tue, 23 Jul 2013 07:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1545; q=dns/txt; s=iport; t=1374590546; x=1375800146; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=MWsxQX7dKKRU+O8n32ACbLTjC5MqGq0VkdxdNl9E1/w=; b=YrsZ9yYvLSteN8YMHOC7LZb3UYP7v8Bm5dtPel4rafIWXmFek1GoqU7k UsKQzFzRDSSoujwddaEDp6ewV4MvJ7yFMiT78Reey2UGFjKe/dKBecp9w lRgriV/YM5EKhPL40P1vHTAUN84+EGb9enVFlAD2CGMAeIJCmORi73eRr k=; X-IronPort-AV: E=Sophos;i="4.89,728,1367971200"; d="scan'208";a="238330755" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 23 Jul 2013 14:42:24 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6NEgMON008544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jul 2013 14:42:23 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id r6NEgLHl003087; Tue, 23 Jul 2013 10:42:21 -0400 From: Eric Rosen To: Mingui Zhang Subject: Re: FW: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt In-reply-to: Your message of Tue, 23 Jul 2013 08:21:14 -0000. <4552F0907735844E9204A62BBDD325E7335C7B0C@nkgeml508-mbx.china.huawei.com> Date: Tue, 23 Jul 2013 10:42:21 -0400 Message-ID: <3086.1374590541@erosen-linux> Cc: erosen@cisco.com, "pwe3@ietf.org" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 14:42:34 -0000 Eric> In Figure 2.1, you show CE2 connected to PE3 and PE4. Now suppose we also Eric> have CE4 connected to PE3 and PE5. If PE3 fails, one might want use PE4 as Eric> a backup for CE2, while using PE5 as a backup for CE4. Your scheme doesn't Eric> seem to handle this. Mingui> If PE3 and PE4 allocate (1100, vNH1) for CE2 while PE3 and PE5 Mingui> allocate (1101, vNH2) for CE4. The scheme works well. Are you now suggesting to allocate a vNH address and shared label for every CE? Since there are many more CEs than PEs, that would make the scaling properties of the scheme a lot less favorable. Eric> Also, even in the case of Figure 2.1, it seems entirely possibly that Eric> one might want PE3's primary route to CE2 to be via the directly Eric> attached interface, while wanting PE4's primary route to CE2 to be via Eric> PE3. Does your scheme handle this case? Mingui> Yes, it handles. Please see the right part of eq1: Sxy3+M. If the Mingui> backup tunnel goes through Pxy->PE4->PE3->vNH, then Sxy3+M < = Mingui> Sxy4+S. That means eq1 does not hold. I think that equation is based only on the IGP link costs. A service provider might use BGP LOCAL_PREF to give the PE3-->CE2 route a higher degree of preference than the PE4-->CE2 route, in which case PE4's normal route to CE2 could be via PE3, independent of the IGP link costs. Of course, PE4 will switch to the directly attached route when it learns, through IGP, that PE3 is not reachable. But in that case you might not meet the FRR goal. From lucy.yong@huawei.com Tue Jul 23 08:15:21 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF7C21F85C3; Tue, 23 Jul 2013 08:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 o5JlHXrnffHc; Tue, 23 Jul 2013 08:15:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C6F8D21F9E6E; Tue, 23 Jul 2013 08:15:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVI70563; Tue, 23 Jul 2013 15:15:13 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 16:13:46 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 16:14:40 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Tue, 23 Jul 2013 08:14:31 -0700 From: Lucy yong To: Aldrin Isaac , Kireeti Kompella Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOh6SdfX2poll6ik2P4GZLQHBAlJlyVhnA Date: Tue, 23 Jul 2013 15:14:31 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4527E258@dfweml509-mbx.china.huawei.com> References: <0DB8F45437AB844CBB5102F807A0AD931044FBDC@xmb-rcd-x03.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D80F2@NKGEML512-MBS.china.huawei.com> <9921DABA-3484-4D52-813A-77119BEBAA58@gmail.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.140.118] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D4527E258dfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "thomas.morin@orange.com" , L3VPN , Yakov Rekhter , "nvo3@ietf.org" , "UTTARO, JAMES" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 15:15:21 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D4527E258dfweml509mbxchi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable For distributed based architecture, the local context ID has a lot of benef= its. For centralized (or SDN) architecture, will the global context ID have= advance? Another way to ask this is: is distributed architecture better t= han centralized architecture for VPN or virtual network overlay? Lucy From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Ald= rin Isaac Sent: Tuesday, July 23, 2013 8:00 AM To: Kireeti Kompella Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; th= omas.morin@orange.com; UTTARO, JAMES Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn +1. Network operators lose flexibility with Global VNIDs. Virtual topology will= be fine tuned on top of VNIDs by squeezing a square peg (ACLs) into a roun= d hole (where it's otherwise not needed). I think local context IDs will m= ake a come back once we regain our sanity. :). On Tuesday, July 23, 2013, Kireeti Kompella wrote: Hi Xuxiaohu, Sorry for the previous empty email. On Jul 23, 2013, at 4:51, Xuxiaohu > wrot= e: > The reason that I started this discussion is to make sure whether the Vir= tual Network Context Identification contained in the data packet is REALLY = required to be globally unique in some cases. No. There's nothing useful that I know that one can do with global IDs in t= he data plane that one cannot do with local IDs, and local IDs are easier t= o allocate and manage. So, I'd be going the other way and advocate locally = significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do) Kireeti _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --_000_2691CE0099834E4A9C5044EEC662BB9D4527E258dfweml509mbxchi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

For distributed based arc= hitecture, the local context ID has a lot of benefits. For centralized (or = SDN) architecture, will the global context ID have advance?  Another way to ask this is: is distributed architecture better than = centralized architecture for VPN or virtual network overlay?

 <= /p>

Lucy

 <= /p>

From: nvo3-bou= nces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Aldrin Isaac
Sent: Tuesday, July 23, 2013 8:00 AM
To: Kireeti Kompella
Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxia= ohu; thomas.morin@orange.com; UTTARO, JAMES
Subject: Re: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 

+1.

 

Network operators lose flexibility with Global = VNIDs. Virtual topology will be fine tuned on top of VNIDs b= y squeezing a square peg (ACLs) into a round hole (where it's otherwis= e not needed).  I think local context IDs will make a come back once we regain our sanity.  :).

 

On Tuesday, July 23, 2013, Kireeti Kompella wrote:

Hi Xuxiaohu,

Sorry for the previous empty email.

On Jul 23, 2013, at 4:51, Xuxiaohu <xuxiaohu@hu= awei.com> wrote:

> The reason that I started this discussion is to make sure whether the = Virtual Network Context Identification contained in the data packet is REAL= LY required to be globally unique in some cases.

No. There's nothing useful that I know that one can do with global IDs in t= he data plane that one cannot do with local IDs, and local IDs are easier t= o allocate and manage. So, I'd be going the other way and advocate locally = significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do)

Kireeti
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

--_000_2691CE0099834E4A9C5044EEC662BB9D4527E258dfweml509mbxchi_-- From lufang@cisco.com Tue Jul 23 08:21:52 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A4021E8064; Tue, 23 Jul 2013 08:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] 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 eJpTqD4tB1X4; Tue, 23 Jul 2013 08:21:47 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 38A1011E822F; Tue, 23 Jul 2013 08:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11308; q=dns/txt; s=iport; t=1374592907; x=1375802507; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=l1tiuCWmpO1JFV/BgQ5wSVKpeMERMSQAy5zN7nwnxe4=; b=cnIXPGxZxuDnOr0kSXNOD7gWT6hHM0C7R49+4pvsuQ9GllnPsU3wQZaI altssA1gqP4TzL8dCld/yVFBDXdefSr8jgd9BuaW+N++mRrrbSyucidD8 JusbVwjThVpS1re1ap1CKc/rkIsQrFYaEBO+tsZXIsbwXMgOVoy+FMbLl U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFACqf7lGtJV2Y/2dsb2JhbABagkJENVDAOIESFnSCJAEBAQMBAQEBKkELBQ0BCBEBAgEBAQsdKAYLFAMGCAIEAQ0FCId2AwkGDK9qDYhaAQMGjQyBKYERIA0EBgGDEm4DlXaOEIUmgxSBcTk X-IronPort-AV: E=Sophos;i="4.89,728,1367971200"; d="scan'208,217";a="238314759" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 23 Jul 2013 15:21:35 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6NFLZjK020217 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Jul 2013 15:21:35 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.202]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 23 Jul 2013 10:21:35 -0500 From: "Luyuan Fang (lufang)" To: Lucy yong , Aldrin Isaac , Kireeti Kompella Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOh6SRkp4YTM7gKEqj/QEiI7HXu5lyszGA//++6AA= Date: Tue, 23 Jul 2013 15:21:34 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD9310469D39@xmb-rcd-x03.cisco.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4527E258@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.21.103.12] Content-Type: multipart/alternative; boundary="_000_0DB8F45437AB844CBB5102F807A0AD9310469D39xmbrcdx03ciscoc_" MIME-Version: 1.0 Cc: L3VPN , Yakov Rekhter , "nvo3@ietf.org" , "thomas.morin@orange.com" , "UTTARO, JAMES" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 15:21:52 -0000 --_000_0DB8F45437AB844CBB5102F807A0AD9310469D39xmbrcdx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lucy, As I see, using SDN approach or distributed control plane, and using global= or local ID are two orthogonal questions. > is distributed architecture better than centralized architecture for VPN = or virtual network overlay? No necessarily. Luyuan From: Lucy yong > Date: Tuesday, July 23, 2013 11:14 AM To: Aldrin Isaac >, K= ireeti Kompella > Cc: Luyuan Fang >, L3VPN >, Yakov Rekhter >, "nvo3@ietf.org" >, Xuxiaohu >, "thomas.morin@orange.com" >, "UTTARO, JAMES" > Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn For distributed based architecture, the local context ID has a lot of benef= its. For centralized (or SDN) architecture, will the global context ID have= advance? Another way to ask this is: is distributed architecture better t= han centralized architecture for VPN or virtual network overlay? Lucy From: nvo3-bounces@ietf.org [mailto:nvo3-boun= ces@ietf.org] On Behalf Of Aldrin Isaac Sent: Tuesday, July 23, 2013 8:00 AM To: Kireeti Kompella Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; thomas.morin@orange.com= ; UTTARO, JAMES Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn +1. Network operators lose flexibility with Global VNIDs. Virtual topology will= be fine tuned on top of VNIDs by squeezing a square peg (ACLs) into a roun= d hole (where it's otherwise not needed). I think local context IDs will m= ake a come back once we regain our sanity. :). On Tuesday, July 23, 2013, Kireeti Kompella wrote: Hi Xuxiaohu, Sorry for the previous empty email. On Jul 23, 2013, at 4:51, Xuxiaohu > wrot= e: > The reason that I started this discussion is to make sure whether the Vir= tual Network Context Identification contained in the data packet is REALLY = required to be globally unique in some cases. No. There's nothing useful that I know that one can do with global IDs in t= he data plane that one cannot do with local IDs, and local IDs are easier t= o allocate and manage. So, I'd be going the other way and advocate locally = significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do) Kireeti _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --_000_0DB8F45437AB844CBB5102F807A0AD9310469D39xmbrcdx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <848804664AB9BE40B12EB095DD585A80@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Lucy,

As I see, using SDN approach or distributed control plane, and using g= lobal or local ID are two orthogonal questions.

> i= s distributed architecture better than centralized architecture for VPN or = virtual network overlay?
No necessarily.

Luyuan
From: Lucy yong <lucy.yong@huawei.com>
Date: Tuesday, July 23, 2013 11:14 = AM
To: Aldrin Isaac <aldrin.isaac@gmail.com>, Kireeti Kompell= a <kireeti.kompella@gmail.= com>
Cc: Luyuan Fang <lufang@cisco.com>, L3VPN <l3vpn@ietf.org>, Yakov Rekhter <yakov@juniper.net>, "nvo3@ietf.org" <nvo3@ietf.org>, Xuxiaohu <<= a href=3D"mailto:xuxiaohu@huawei.com">xuxiaohu@huawei.com>, "thomas.morin@orange.com" = <thomas.morin@orange.com&= gt;, "UTTARO, JAMES" <ju1738@att= .com>
Subject: RE: [nvo3] The possibility= of using global MPLS labels as VNIs ... for l3vpn

For distributed based architecture= , the local context ID has a lot of benefits. For centralized (or SDN) arch= itecture, will the global context ID have advance?  Another way to ask this is: is distributed architectur= e better than centralized architecture for VPN or virtual network overlay?<= o:p>

 

Lucy

 

From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Aldrin Isaac
Sent: Tuesday, July 23, 2013 8:00 AM
To: Kireeti Kompella
Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; tho= mas.morin@orange.com; UTTARO, JAMES
Subject: Re: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 

+1.

 

Network operators lose flexibility with Global = VNIDs. Virtual topology will be fine tuned on top of VNIDs b= y squeezing a square peg (ACLs) into a round hole (where it's otherwis= e not needed).  I think local context IDs will make a come back once we regain our sanity.  :).

 

On Tuesday, July 23, 2013, Kireeti Kompella wrote:

Hi Xuxiaohu,

Sorry for the previous empty email.

On Jul 23, 2013, at 4:51, Xuxiaohu <xuxiaohu@hu= awei.com> wrote:

> The reason that I started this discussion is to make sure whether the = Virtual Network Context Identification contained in the data packet is REAL= LY required to be globally unique in some cases.

No. There's nothing useful that I know that one can do with global IDs in t= he data plane that one cannot do with local IDs, and local IDs are easier t= o allocate and manage. So, I'd be going the other way and advocate locally = significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do)

Kireeti
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

 --_000_0DB8F45437AB844CBB5102F807A0AD9310469D39xmbrcdx03ciscoc_-- From lucy.yong@huawei.com Tue Jul 23 08:59:12 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C534C11E82A3; Tue, 23 Jul 2013 08:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 d3g27JqS6+Ez; Tue, 23 Jul 2013 08:59:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA6111E82A1; Tue, 23 Jul 2013 08:59:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATS29913; Tue, 23 Jul 2013 15:59:04 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 16:58:02 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 16:58:55 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Tue, 23 Jul 2013 08:58:46 -0700 From: Lucy yong To: "Luyuan Fang (lufang)" , Aldrin Isaac , Kireeti Kompella Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOh6SdfX2poll6ik2P4GZLQHBAlJlyVhnAgACAmAD//5MeAA== Date: Tue, 23 Jul 2013 15:58:45 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4527E2C4@dfweml509-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D4527E258@dfweml509-mbx.china.huawei.com> <0DB8F45437AB844CBB5102F807A0AD9310469D39@xmb-rcd-x03.cisco.com> In-Reply-To: <0DB8F45437AB844CBB5102F807A0AD9310469D39@xmb-rcd-x03.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.140.118] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D4527E2C4dfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: L3VPN , Yakov Rekhter , "nvo3@ietf.org" , "thomas.morin@orange.com" , "UTTARO, JAMES" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 15:59:13 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D4527E2C4dfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As I see, using SDN approach or distributed control plane, and using global= or local ID are two orthogonal questions. [Lucy] then, the question to be asked is which usage makes sense in the SDN= approach, global ID or local ID? IMHO: they are related. Lucy > is distributed architecture better than centralized architecture for VPN = or virtual network overlay? No necessarily. Luyuan From: Lucy yong > Date: Tuesday, July 23, 2013 11:14 AM To: Aldrin Isaac >, K= ireeti Kompella > Cc: Luyuan Fang >, L3VPN >, Yakov Rekhter >, "nvo3@ietf.org" >, Xuxiaohu >, "thomas.morin@orange.com" >, "UTTARO, JAMES" > Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn For distributed based architecture, the local context ID has a lot of benef= its. For centralized (or SDN) architecture, will the global context ID have= advance? Another way to ask this is: is distributed architecture better t= han centralized architecture for VPN or virtual network overlay? Lucy From: nvo3-bounces@ietf.org [mailto:nvo3-boun= ces@ietf.org] On Behalf Of Aldrin Isaac Sent: Tuesday, July 23, 2013 8:00 AM To: Kireeti Kompella Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; thomas.morin@orange.com= ; UTTARO, JAMES Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn +1. Network operators lose flexibility with Global VNIDs. Virtual topology will= be fine tuned on top of VNIDs by squeezing a square peg (ACLs) into a roun= d hole (where it's otherwise not needed). I think local context IDs will m= ake a come back once we regain our sanity. :). On Tuesday, July 23, 2013, Kireeti Kompella wrote: Hi Xuxiaohu, Sorry for the previous empty email. On Jul 23, 2013, at 4:51, Xuxiaohu > wrot= e: > The reason that I started this discussion is to make sure whether the Vir= tual Network Context Identification contained in the data packet is REALLY = required to be globally unique in some cases. No. There's nothing useful that I know that one can do with global IDs in t= he data plane that one cannot do with local IDs, and local IDs are easier t= o allocate and manage. So, I'd be going the other way and advocate locally = significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do) Kireeti _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --_000_2691CE0099834E4A9C5044EEC662BB9D4527E2C4dfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 <= /p>

 

As I see, using SDN approac= h or distributed control plane, and using global or local ID are two orthog= onal questions.

[Lucy] then, the qu= estion to be asked is which usage makes sense in the SDN approach,  gl= obal ID or local ID? IMHO: they are related.

 

Lucy

 

> is distributed architecture better than centralized archit= ecture for VPN or virtual network overlay?=

No necessarily.<= /span>

 

Luyuan

From: Lucy yong <lucy.yong@huawei.com>
Date: Tuesday, July 23, 2013 11:14 AM
To: Aldrin Isaac <aldri= n.isaac@gmail.com>, Kireeti Kompella <kireeti.kompella@gmail.com>
Cc: Luyuan Fang <lufang@cisco= .com>, L3VPN <l3vpn@ietf.org>, Yakov Rekhter <yakov@juniper= .net>, "nvo3@ietf.org"= ; <nvo3@ietf.org>, Xuxiaohu <<= a href=3D"mailto:xuxiaohu@huawei.com">xuxiaohu@huawei.com>, "thomas.morin@orange.com" = <thomas.morin@orange.com&= gt;, "UTTARO, JAMES" <ju1738@att= .com>
Subject: RE: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 

For distributed based arc= hitecture, the local context ID has a lot of benefits. For centralized (or = SDN) architecture, will the global context ID have advance?  Another way to ask this is: is distributed architecture better than = centralized architecture for VPN or virtual network overlay?

 

Lucy

 

From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Aldrin Isaac
Sent: Tuesday, July 23, 2013 8:00 AM
To: Kireeti Kompella
Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; tho= mas.morin@orange.com; UTTARO, JAMES
Subject: Re: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 =

+1.

 =

Network operators lose f= lexibility with Global VNIDs. Virtual topology will be fine = tuned on top of VNIDs by squeezing a square peg (ACLs) into a rou= nd hole (where it's otherwise not needed).  I think local context IDs will make a come back once we regain our sanity.  :).

 =

On Tuesday, July 23, 201= 3, Kireeti Kompella wrote:

Hi Xuxiaohu,

Sorry for the previous empty email.

On Jul 23, 2013, at 4:51, Xuxiaohu <xuxiaohu@hu= awei.com> wrote:

> The reason that I started this discussion is to make sure whether the = Virtual Network Context Identification contained in the data packet is REAL= LY required to be globally unique in some cases.

No. There's nothing useful that I know that one can do with global IDs in t= he data plane that one cannot do with local IDs, and local IDs are easier t= o allocate and manage. So, I'd be going the other way and advocate locally = significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do)

Kireeti
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

--_000_2691CE0099834E4A9C5044EEC662BB9D4527E2C4dfweml509mbxchi_-- From lufang@cisco.com Tue Jul 23 09:06:12 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A84411E80F9; Tue, 23 Jul 2013 09:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.198 X-Spam-Level: X-Spam-Status: No, score=-10.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] 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 0ju41SxB3u2f; Tue, 23 Jul 2013 09:06:07 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 35C4611E80E9; Tue, 23 Jul 2013 09:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17298; q=dns/txt; s=iport; t=1374595567; x=1375805167; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=hDl1O9jEyhWKbiu7x11ZmmqYsz6XhD/ya0niY2X7U9k=; b=FdhNHgJ5Hw5yGM+ArQG9lkwbrHZiPbyLQslyGiPvBNqfhbEYJ5tUwVEo z5Wupw+WCF7UyUHD6dvxlFn5l0Dslj5nM1PVJzXewGEmVZxwFh2NmbFE8 uGOpt7Vj2k0ARrOvoQLBla40IFJBGMXLiejRdcxle4JzKNmlexNeL05Zo 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAACp7lGtJV2c/2dsb2JhbABagkJENVDAO4ETFnSCJAEBAQMBAQEBKkELBQ0BCBEBAgEBAQsdKAYLFAMGCAIEAQ0FCId2AwkGDK99DYhaAQMGjQyBKYERIA0EBgGDEm4DlXaOEIUmgxSBcTk X-IronPort-AV: E=Sophos;i="4.89,728,1367971200"; d="scan'208,217";a="238324752" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 23 Jul 2013 16:06:06 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6NG66FV010956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Jul 2013 16:06:06 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.202]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 23 Jul 2013 11:06:06 -0500 From: "Luyuan Fang (lufang)" To: Lucy yong , Aldrin Isaac , Kireeti Kompella Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOh6SRkp4YTM7gKEqj/QEiI7HXu5lyszGA//++6ACAAE10gP//vvqA Date: Tue, 23 Jul 2013 16:06:05 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD9310469E53@xmb-rcd-x03.cisco.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4527E2C4@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.21.103.12] Content-Type: multipart/alternative; boundary="_000_0DB8F45437AB844CBB5102F807A0AD9310469E53xmbrcdx03ciscoc_" MIME-Version: 1.0 Cc: L3VPN , Yakov Rekhter , "nvo3@ietf.org" , "thomas.morin@orange.com" , "UTTARO, JAMES" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 16:06:12 -0000 --_000_0DB8F45437AB844CBB5102F807A0AD9310469E53xmbrcdx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You choose the ID type: global or local. You choose the control paradigm, SDN, dynamic control plane, or hybrid. The two decisions are independent. My personal preferences: SDN with local ID. Luyuan From: Lucy yong > Date: Tuesday, July 23, 2013 11:58 AM To: Luyuan Fang >, Aldrin Isaac <= aldrin.isaac@gmail.com>, Kireeti Kompella > Cc: L3VPN >, Yakov Rekhter >, "nvo3@ietf.org" = >, Xuxiaohu >, "thomas.morin@orange.com" >, "UTTARO, = JAMES" > Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn As I see, using SDN approach or distributed control plane, and using global= or local ID are two orthogonal questions. [Lucy] then, the question to be asked is which usage makes sense in the SDN= approach, global ID or local ID? IMHO: they are related. Lucy > is distributed architecture better than centralized architecture for VPN = or virtual network overlay? No necessarily. Luyuan From: Lucy yong > Date: Tuesday, July 23, 2013 11:14 AM To: Aldrin Isaac >, K= ireeti Kompella > Cc: Luyuan Fang >, L3VPN >, Yakov Rekhter >, "nvo3@ietf.org" >, Xuxiaohu >, "thomas.morin@orange.com" >, "UTTARO, JAMES" > Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn For distributed based architecture, the local context ID has a lot of benef= its. For centralized (or SDN) architecture, will the global context ID have= advance? Another way to ask this is: is distributed architecture better t= han centralized architecture for VPN or virtual network overlay? Lucy From:nvo3-bounces@ietf.org [mailto:nvo3-bounc= es@ietf.org] On Behalf Of Aldrin Isaac Sent: Tuesday, July 23, 2013 8:00 AM To: Kireeti Kompella Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; thomas.morin@orange.com= ; UTTARO, JAMES Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn +1. Network operators lose flexibility with Global VNIDs. Virtual topology will= be fine tuned on top of VNIDs by squeezing a square peg (ACLs) into a roun= d hole (where it's otherwise not needed). I think local context IDs will m= ake a come back once we regain our sanity. :). On Tuesday, July 23, 2013, Kireeti Kompella wrote: Hi Xuxiaohu, Sorry for the previous empty email. On Jul 23, 2013, at 4:51, Xuxiaohu > wrot= e: > The reason that I started this discussion is to make sure whether the Vir= tual Network Context Identification contained in the data packet is REALLY = required to be globally unique in some cases. No. There's nothing useful that I know that one can do with global IDs in t= he data plane that one cannot do with local IDs, and local IDs are easier t= o allocate and manage. So, I'd be going the other way and advocate locally = significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do) Kireeti _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --_000_0DB8F45437AB844CBB5102F807A0AD9310469E53xmbrcdx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
You choose the ID type: global or local.
You choose the control paradigm, SDN, dynamic control plane, or hybrid= .

The two decisions are independent.

My personal preferences: SDN with local ID.

Luyuan

From: Lucy yong <lucy.yong@huawei.com>
Date: Tuesday, July 23, 2013 11:58 = AM
To: Luyuan Fang <lufang@cisco.com>, Aldrin Isaac <aldrin.isaac@gmail.com>, Kireeti Komp= ella <kireeti.kompella@gma= il.com>
Cc: L3VPN <l3vpn@ietf.org>, Yakov Rekhter <yakov@juniper.net>, "nvo3@ietf.org" <nvo3@i= etf.org>, Xuxiaohu <xuxiaohu@huawei.com>, "thomas.morin@orange= .com" <thomas.morin@= orange.com>, "UTTARO, JAMES" <ju1738@att.com>
Subject: RE: [nvo3] The possibility= of using global MPLS labels as VNIs ... for l3vpn

 

 

As I see, using SDN approach or distributed= control plane, and using global or local ID are two orthogonal questions.<= o:p>

[Lucy] then, the question to= be asked is which usage makes sense in the SDN approach,  global ID o= r local ID? IMHO: they are related.

 =

Lucy

 

> is dis= tributed architecture better than centralized architecture for VPN or virtual network overlay?

No necessarily.

 

Luyuan

From: Lucy yong <luc= y.yong@huawei.com>
Date: Tuesday, July 23, 2013 11:14 AM
To: Aldrin Isaac <aldri= n.isaac@gmail.com>, Kireeti Kompella <kireeti.kompella@gmail.com>
Cc: Luyuan Fang <lufang@cisco= .com>, L3VPN <l3vpn@ietf.org>, Yakov Rekhter <yakov@juniper= .net>, "nvo3@ietf.org"= ; <nvo3@ietf.org>, Xuxiaohu <<= a href=3D"mailto:xuxiaohu@huawei.com">xuxiaohu@huawei.com>, "thomas.morin@orange.com" = <thomas.morin@orange.com&= gt;, "UTTARO, JAMES" <ju1738@att= .com>
Subject: RE: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 

For distributed based architecture= , the local context ID has a lot of benefits. For centralized (or SDN) arch= itecture, will the global context ID have advance?  Another way to ask this is: is distributed architectur= e better than centralized architecture for VPN or virtual network overlay?<= /span>

 

Lucy

 

From:nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org= ] On Behalf Of Aldrin Isaac
Sent: Tuesday, July 23, 2013 8:00 AM
To: Kireeti Kompella
Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; tho= mas.morin@orange.com; UTTARO, JAMES
Subject: Re: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 =

+1.

 =

Network operators lose f= lexibility with Global VNIDs. Virtual topology will be fine = tuned on top of VNIDs by squeezing a square peg (ACLs) into a rou= nd hole (where it's otherwise not needed).  I think local context IDs will make a come back once we regain our sanity.  :).

 =

On Tuesday, July 23, 201= 3, Kireeti Kompella wrote:

Hi Xuxiaohu,

Sorry for the previous empty email.

On Jul 23, 2013, at 4:51, Xuxiaohu <xuxiaohu@hu= awei.com> wrote:

> The reason that I started this discussion is to make sure whether the = Virtual Network Context Identification contained in the data packet is REAL= LY required to be globally unique in some cases.

No. There's nothing useful that I know that one can do with global IDs in t= he data plane that one cannot do with local IDs, and local IDs are easier t= o allocate and manage. So, I'd be going the other way and advocate locally = significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do)

Kireeti
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

 --_000_0DB8F45437AB844CBB5102F807A0AD9310469E53xmbrcdx03ciscoc_-- From lucy.yong@huawei.com Tue Jul 23 09:28:39 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD72B11E82E7; Tue, 23 Jul 2013 09:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 xMBJYqVy2RXS; Tue, 23 Jul 2013 09:28:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7788611E8269; Tue, 23 Jul 2013 09:28:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATS31574; Tue, 23 Jul 2013 16:28:30 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 17:27:34 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 17:28:28 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.007; Tue, 23 Jul 2013 09:28:20 -0700 From: Lucy yong To: "Luyuan Fang (lufang)" , Aldrin Isaac , Kireeti Kompella Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOh6SdfX2poll6ik2P4GZLQHBAlJlyVhnAgACAmAD//5MeAIAAeVKA//+ORnA= Date: Tue, 23 Jul 2013 16:28:19 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4527E309@dfweml509-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D4527E2C4@dfweml509-mbx.china.huawei.com> <0DB8F45437AB844CBB5102F807A0AD9310469E53@xmb-rcd-x03.cisco.com> In-Reply-To: <0DB8F45437AB844CBB5102F807A0AD9310469E53@xmb-rcd-x03.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.140.118] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D4527E309dfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: L3VPN , Yakov Rekhter , "nvo3@ietf.org" , "thomas.morin@orange.com" , "UTTARO, JAMES" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 16:28:39 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D4527E309dfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In distributed control plane approach, we have strong consensus that local = ID is the way to go. Like to hear more the people opinions about: in SDN approach, will global I= D and local ID are equally good (just mater choice) or one is better than o= ther? Lucy From: Luyuan Fang (lufang) [mailto:lufang@cisco.com] Sent: Tuesday, July 23, 2013 11:06 AM To: Lucy yong; Aldrin Isaac; Kireeti Kompella Cc: L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; thomas.morin@orange.com;= UTTARO, JAMES Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn You choose the ID type: global or local. You choose the control paradigm, SDN, dynamic control plane, or hybrid. The two decisions are independent. My personal preferences: SDN with local ID. Luyuan From: Lucy yong > Date: Tuesday, July 23, 2013 11:58 AM To: Luyuan Fang >, Aldrin Isaac <= aldrin.isaac@gmail.com>, Kireeti Kompella > Cc: L3VPN >, Yakov Rekhter >, "nvo3@ietf.org" = >, Xuxiaohu >, "thomas.morin@orange.com" >, "UTTARO, = JAMES" > Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn As I see, using SDN approach or distributed control plane, and using global= or local ID are two orthogonal questions. [Lucy] then, the question to be asked is which usage makes sense in the SDN= approach, global ID or local ID? IMHO: they are related. Lucy > is distributed architecture better than centralized architecture for VPN = or virtual network overlay? No necessarily. Luyuan From: Lucy yong > Date: Tuesday, July 23, 2013 11:14 AM To: Aldrin Isaac >, K= ireeti Kompella > Cc: Luyuan Fang >, L3VPN >, Yakov Rekhter >, "nvo3@ietf.org" >, Xuxiaohu >, "thomas.morin@orange.com" >, "UTTARO, JAMES" > Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn For distributed based architecture, the local context ID has a lot of benef= its. For centralized (or SDN) architecture, will the global context ID have= advance? Another way to ask this is: is distributed architecture better t= han centralized architecture for VPN or virtual network overlay? Lucy From:nvo3-bounces@ietf.org [mailto:nvo3-bounc= es@ietf.org] On Behalf Of Aldrin Isaac Sent: Tuesday, July 23, 2013 8:00 AM To: Kireeti Kompella Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; thomas.morin@orange.com= ; UTTARO, JAMES Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn +1. Network operators lose flexibility with Global VNIDs. Virtual topology will= be fine tuned on top of VNIDs by squeezing a square peg (ACLs) into a roun= d hole (where it's otherwise not needed). I think local context IDs will m= ake a come back once we regain our sanity. :). On Tuesday, July 23, 2013, Kireeti Kompella wrote: Hi Xuxiaohu, Sorry for the previous empty email. On Jul 23, 2013, at 4:51, Xuxiaohu > wrot= e: > The reason that I started this discussion is to make sure whether the Vir= tual Network Context Identification contained in the data packet is REALLY = required to be globally unique in some cases. No. There's nothing useful that I know that one can do with global IDs in t= he data plane that one cannot do with local IDs, and local IDs are easier t= o allocate and manage. So, I'd be going the other way and advocate locally = significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do) Kireeti _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --_000_2691CE0099834E4A9C5044EEC662BB9D4527E309dfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In distributed control pl= ane approach, we have strong consensus that local ID is the way to go.=

 <= /p>

Like to hear more the peo= ple opinions about: in SDN approach, will global ID and local ID are equall= y good (just mater choice) or one is better than other?

 <= /p>

Lucy

 <= /p>

From: Luyuan F= ang (lufang) [mailto:lufang@cisco.com]
Sent: Tuesday, July 23, 2013 11:06 AM
To: Lucy yong; Aldrin Isaac; Kireeti Kompella
Cc: L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; thomas.morin@oran= ge.com; UTTARO, JAMES
Subject: Re: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 

You choose the ID type: glo= bal or local.

You choose the control para= digm, SDN, dynamic control plane, or hybrid.

 

The two decisions are indep= endent.

 

My personal preferences: SD= N with local ID.

 

Luyuan

 

From: Lucy yong <lucy.yong@huawei.com>
Date: Tuesday, July 23, 2013 11:58 AM
To: Luyuan Fang <lufang@cisco= .com>, Aldrin Isaac <al= drin.isaac@gmail.com>, Kireeti Kompella <kireeti.kompella@gmail.com>
Cc: L3VPN <l3vpn@ietf.org&g= t;, Yakov Rekhter <yakov@juniper.ne= t>, "nvo3@ietf.org" &= lt;nvo3@ietf.org>, Xuxiaohu <xuxiaohu@huawei.com>, &q= uot;thomas.morin@orange.com&= quot; <thomas.morin@orange.co= m>, "UTTARO, JAMES" <= ju1738@att.com>
Subject: RE: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 

 

 

As I see, using SDN approac= h or distributed control plane, and using global or local ID are two orthog= onal questions.

[Lucy] then, the qu= estion to be asked is which usage makes sense in the SDN approach,  gl= obal ID or local ID? IMHO: they are related.

 

Lucy

 

> is distributed architecture better than centralized archit= ecture for VPN or virtual network overlay?

No necessarily.

 

Luyuan

From: Lucy yong <lucy.yong@huawei.com>
Date: Tuesday, July 23, 2013 11:14 AM
To: Aldrin Isaac <aldri= n.isaac@gmail.com>, Kireeti Kompella <kireeti.kompella@gmail.com>
Cc: Luyuan Fang <lufang@cisco= .com>, L3VPN <l3vpn@ietf.org>, Yakov Rekhter <yakov@juniper= .net>, "nvo3@ietf.org"= ; <nvo3@ietf.org>, Xuxiaohu <<= a href=3D"mailto:xuxiaohu@huawei.com">xuxiaohu@huawei.com>, "thomas.morin@orange.com" = <thomas.morin@orange.com&= gt;, "UTTARO, JAMES" <ju1738@att= .com>
Subject: RE: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 

For distributed based arc= hitecture, the local context ID has a lot of benefits. For centralized (or = SDN) architecture, will the global context ID have advance?  Another way to ask this is: is distributed architecture better than = centralized architecture for VPN or virtual network overlay?

 

Lucy

 

From:nvo3-bounces@ietf.o= rg [mailto:nvo3-bounces@ietf.org= ] On Behalf Of Aldrin Isaac
Sent: Tuesday, July 23, 2013 8:00 AM
To: Kireeti Kompella
Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; tho= mas.morin@orange.com; UTTARO, JAMES
Subject: Re: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 =

+1.

 =

Network operators lose f= lexibility with Global VNIDs. Virtual topology will be fine = tuned on top of VNIDs by squeezing a square peg (ACLs) into a rou= nd hole (where it's otherwise not needed).  I think local context IDs will make a come back once we regain our sanity.  :).

 =

On Tuesday, July 23, 201= 3, Kireeti Kompella wrote:

Hi Xuxiaohu,

Sorry for the previous empty email.

On Jul 23, 2013, at 4:51, Xuxiaohu <xuxiaohu@hu= awei.com> wrote:

> The reason that I started this discussion is to make sure whether the = Virtual Network Context Identification contained in the data packet is REAL= LY required to be globally unique in some cases.

No. There's nothing useful that I know that one can do with global IDs in t= he data plane that one cannot do with local IDs, and local IDs are easier t= o allocate and manage. So, I'd be going the other way and advocate locally = significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do)

Kireeti
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

--_000_2691CE0099834E4A9C5044EEC662BB9D4527E309dfweml509mbxchi_-- From kireeti.kompella@gmail.com Tue Jul 23 09:46:17 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2584411E82CF; Tue, 23 Jul 2013 09:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] 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 GT4shIWFV8xs; Tue, 23 Jul 2013 09:46:16 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBC611E8213; Tue, 23 Jul 2013 09:46:09 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id ia10so3771316vcb.36 for ; Tue, 23 Jul 2013 09:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=/sTTePR2nrYVqEjQ3G4xWYtp3Mmbk9zwJPxKfm8h1js=; b=MvUmClKCHBcSjcvc7epclNTWEbWSIm3f35v02qhGgzrrXPapoTtDpLsYfEYBBlPRkc It9Zxl2Lp7El3fDK58chKVcnJzDwP58InaAQsCwVpb3rLw1A/0eLm2RhhxuEzG3x8kPR WwJONMZEp9eX+HH6p3vhpcXEeFO6XTSpY14xUTDWOGkSZDK2ESHPkXWbjbAk9khAfxeH bqvM/EFn5V/b1idGZeqi/UtvtNabS61dx2kehJDEDl1m1psARo9uMX5nZ0X+nwQS2p7U E2hbbz71o9gO7+gzagjVL0Tv3VAkmTsgxiMkYy218emG0QNEP+rnNJ0lV1gVZl84kkPx SMmw== X-Received: by 10.52.92.114 with SMTP id cl18mr3167524vdb.67.1374597967606; Tue, 23 Jul 2013 09:46:07 -0700 (PDT) Received: from [10.73.39.229] (mobile-166-147-108-172.mycingular.net. [166.147.108.172]) by mx.google.com with ESMTPSA id q2sm11018865vef.3.2013.07.23.09.45.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 09:46:07 -0700 (PDT) References: <2691CE0099834E4A9C5044EEC662BB9D4527E2C4@dfweml509-mbx.china.huawei.com> <0DB8F45437AB844CBB5102F807A0AD9310469E53@xmb-rcd-x03.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D4527E309@dfweml509-mbx.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4527E309@dfweml509-mbx.china.huawei.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (10B329) From: Kireeti Kompella Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Date: Tue, 23 Jul 2013 19:45:53 +0300 To: Lucy yong Cc: "thomas.morin@orange.com" , L3VPN , Yakov Rekhter , "nvo3@ietf.org" , Aldrin Isaac , "UTTARO, JAMES" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 16:46:17 -0000 On Jul 23, 2013, at 19:28, Lucy yong wrote: > Like to hear more the people opinions about: in SDN approach, will global I= D and local ID are equally good (just mater choice) or one is better than ot= her? The SDN (centralized) approach makes allocation of global IDs easier. Howeve= r, Xiaohu asked a data plane question. Local IDs are much easier for the dat= a plane. BTW, I am not in favor of centralizing everything.=20 Kireeti= From jakob.heitz@ericsson.com Tue Jul 23 10:10:23 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF2011E82EE; Tue, 23 Jul 2013 10:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] 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 dc+9N81aj7vw; Tue, 23 Jul 2013 10:10:18 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 960A811E82EC; Tue, 23 Jul 2013 10:10:17 -0700 (PDT) X-AuditID: c6180641-b7f986d000007a82-f9-51eeb8f86838 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id C9.2D.31362.8F8BEE15; Tue, 23 Jul 2013 19:10:16 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Tue, 23 Jul 2013 13:10:13 -0400 From: Jakob Heitz To: Lucy yong , "Luyuan Fang (lufang)" , Aldrin Isaac , Kireeti Kompella Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOh8G0/j0z/ZBkpEyNkQMYVts9aJlyfhdQ Date: Tue, 23 Jul 2013 17:10:13 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02DC796A@eusaamb109.ericsson.se> References: <2691CE0099834E4A9C5044EEC662BB9D4527E2C4@dfweml509-mbx.china.huawei.com> <0DB8F45437AB844CBB5102F807A0AD9310469E53@xmb-rcd-x03.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D4527E309@dfweml509-mbx.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4527E309@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02DC796Aeusaamb109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyuXRPuO6PHe8CDT6ftbKYubuVxeL5rAOs Fmv2T2K0ODvf32Ljr0VsFg+fr2S0eDpf0mLDvqNsFsd/fGN34PR42T+H0WPK742sHjtn3WX3 aDnyltVjyZKfTB7Xm64Cuc9OsgWwR3HZpKTmZJalFunbJXBltE3+yFKwfB9jxbV5N5kaGOes Yuxi5OSQEDCRuN5xhgXCFpO4cG89WxcjF4eQwFFGifuzP7NDOMsZJfbv2c0GUsUmoCPx7XoX M0hCRGAlo8SE30/AqpgFdjJKfNl+FmyWsEC4xJmey2AdIgIREl1PtjBC2EYS53s/gNWwCKhK vDs9H6yGV8BX4uyLO6wQ654ADZq8ixkkwSkQJnFv5gUmEJsR6MDvp9aA2cwC4hK3nsxngjhc QGLJnvPMELaoxMvH/1ghbGWJ73MeAS3jAKrPl3j7qApil6DEyZlPWCYwis5CMmkWQtUsJFUQ JToSC3Z/YoOwtSWWLXzNDGOfOfCYCVl8ASP7KkaO0uLUstx0I8NNjMCIPibB5riDccEny0OM 0hwsSuK8G/TOBAoJpCeWpGanphakFsUXleakFh9iZOLglGpgjK6vUQpKerIvwlTZRehEd9Hb ysmCwVNTexSY15guWbH5UB3b5TWKTn+2bIpr3hw7M/aezu7uTX3Lv+ozFan/UbGK2SZzuNpx 4y1VBRXXrN3p2Z+P1C6UtgrY8b5mjrDOpsRjTdcjJW6/kM7ZadCQkX0hyGO7jQt72qRpus/M roY+s3/1fouCEktxRqKhFnNRcSIA5HhQx7YCAAA= Cc: Yakov Rekhter , "nvo3@ietf.org" , "UTTARO, JAMES" , L3VPN , "thomas.morin@orange.com" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 17:10:23 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02DC796Aeusaamb109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does a pure SDN network need MPLS labels? A control plane that contains MPLS protocols is distributed even if there are elements of SDN in it. From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of L= ucy yong Sent: Tuesday, July 23, 2013 9:28 AM To: Luyuan Fang (lufang); Aldrin Isaac; Kireeti Kompella Cc: L3VPN; Yakov Rekhter; nvo3@ietf.org; thomas.morin@orange.com; UTTARO, J= AMES Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn In distributed control plane approach, we have strong consensus that local = ID is the way to go. Like to hear more the people opinions about: in SDN approach, will global I= D and local ID are equally good (just mater choice) or one is better than o= ther? Lucy From: Luyuan Fang (lufang) [mailto:lufang@cisco.com] Sent: Tuesday, July 23, 2013 11:06 AM To: Lucy yong; Aldrin Isaac; Kireeti Kompella Cc: L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; th= omas.morin@orange.com; UTTARO, JAMES Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn You choose the ID type: global or local. You choose the control paradigm, SDN, dynamic control plane, or hybrid. The two decisions are independent. My personal preferences: SDN with local ID. Luyuan From: Lucy yong > Date: Tuesday, July 23, 2013 11:58 AM To: Luyuan Fang >, Aldrin Isaac <= aldrin.isaac@gmail.com>, Kireeti Kompella > Cc: L3VPN >, Yakov Rekhter >, "nvo3@ietf.org" = >, Xuxiaohu >, "thomas.morin@orange.com" >, "UTTARO, = JAMES" > Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn As I see, using SDN approach or distributed control plane, and using global= or local ID are two orthogonal questions. [Lucy] then, the question to be asked is which usage makes sense in the SDN= approach, global ID or local ID? IMHO: they are related. Lucy > is distributed architecture better than centralized architecture for VPN = or virtual network overlay? No necessarily. Luyuan From: Lucy yong > Date: Tuesday, July 23, 2013 11:14 AM To: Aldrin Isaac >, K= ireeti Kompella > Cc: Luyuan Fang >, L3VPN >, Yakov Rekhter >, "nvo3@ietf.org" >, Xuxiaohu >, "thomas.morin@orange.com" >, "UTTARO, JAMES" > Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn For distributed based architecture, the local context ID has a lot of benef= its. For centralized (or SDN) architecture, will the global context ID have= advance? Another way to ask this is: is distributed architecture better t= han centralized architecture for VPN or virtual network overlay? Lucy From:nvo3-bounces@ietf.org [mailto:nvo3-bounc= es@ietf.org] On Behalf Of Aldrin Isaac Sent: Tuesday, July 23, 2013 8:00 AM To: Kireeti Kompella Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; thomas.morin@orange.com= ; UTTARO, JAMES Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn +1. Network operators lose flexibility with Global VNIDs. Virtual topology will= be fine tuned on top of VNIDs by squeezing a square peg (ACLs) into a roun= d hole (where it's otherwise not needed). I think local context IDs will m= ake a come back once we regain our sanity. :). On Tuesday, July 23, 2013, Kireeti Kompella wrote: Hi Xuxiaohu, Sorry for the previous empty email. On Jul 23, 2013, at 4:51, Xuxiaohu > wrot= e: > The reason that I started this discussion is to make sure whether the Vir= tual Network Context Identification contained in the data packet is REALLY = required to be globally unique in some cases. No. There's nothing useful that I know that one can do with global IDs in t= he data plane that one cannot do with local IDs, and local IDs are easier t= o allocate and manage. So, I'd be going the other way and advocate locally = significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do) Kireeti _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02DC796Aeusaamb109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Does a pure SDN network need MPLS labels?=

A control plane that contains MPLS protoc= ols is distributed

even if there are elements of SDN in it.<= o:p>

 

From: l3vpn-bo= unces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Tuesday, July 23, 2013 9:28 AM
To: Luyuan Fang (lufang); Aldrin Isaac; Kireeti Kompella
Cc: L3VPN; Yakov Rekhter; nvo3@ietf.org; thomas.morin@orange.com; UT= TARO, JAMES
Subject: RE: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 

In distributed control pl= ane approach, we have strong consensus that local ID is the way to go.=

 <= /p>

Like to hear more the peo= ple opinions about: in SDN approach, will global ID and local ID are equall= y good (just mater choice) or one is better than other?

 <= /p>

Lucy

 <= /p>

From: Luyuan F= ang (lufang) [mailto:lufang@cisco.com] =
Sent: Tuesday, July 23, 2013 11:06 AM
To: Lucy yong; Aldrin Isaac; Kireeti Kompella
Cc: L3VPN; Yakov Rekhter; nvo3@ietf= .org; Xuxiaohu; thomas.morin@orange.com; UTT= ARO, JAMES
Subject: Re: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 

You choose the ID type: glo= bal or local.

You choose the control para= digm, SDN, dynamic control plane, or hybrid.

 

The two decisions are indep= endent.

 

My personal preferences: SD= N with local ID.

 

Luyuan

 

From: Lucy yong <lucy.yong@huawei.com>
Date: Tuesday, July 23, 2013 11:58 AM
To: Luyuan Fang <lufang@cisco= .com>, Aldrin Isaac <al= drin.isaac@gmail.com>, Kireeti Kompella <kireeti.kompella@gmail.com>
Cc: L3VPN <l3vpn@ietf.org&g= t;, Yakov Rekhter <yakov@juniper.ne= t>, "nvo3@ietf.org" &= lt;nvo3@ietf.org>, Xuxiaohu <xuxiaohu@huawei.com>, &q= uot;thomas.morin@orange.com&= quot; <thomas.morin@orange.co= m>, "UTTARO, JAMES" <= ju1738@att.com>
Subject: RE: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 

 

 

As I see, using SDN approac= h or distributed control plane, and using global or local ID are two orthog= onal questions.

[Lucy] then, the qu= estion to be asked is which usage makes sense in the SDN approach,  gl= obal ID or local ID? IMHO: they are related.

 

Lucy

 

> is distributed architecture better than centralized archit= ecture for VPN or virtual network overlay?

No necessarily.

 

Luyuan

From: Lucy yong <lucy.yong@huawei.com>
Date: Tuesday, July 23, 2013 11:14 AM
To: Aldrin Isaac <aldri= n.isaac@gmail.com>, Kireeti Kompella <kireeti.kompella@gmail.com>
Cc: Luyuan Fang <lufang@cisco= .com>, L3VPN <l3vpn@ietf.org>, Yakov Rekhter <yakov@juniper= .net>, "nvo3@ietf.org"= ; <nvo3@ietf.org>, Xuxiaohu <<= a href=3D"mailto:xuxiaohu@huawei.com">xuxiaohu@huawei.com>, "thomas.morin@orange.com" = <thomas.morin@orange.com&= gt;, "UTTARO, JAMES" <ju1738@att= .com>
Subject: RE: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 

For distributed based arc= hitecture, the local context ID has a lot of benefits. For centralized (or = SDN) architecture, will the global context ID have advance?  Another way to ask this is: is distributed architecture better than = centralized architecture for VPN or virtual network overlay?

 

Lucy

 

From:nvo3-bounces@ietf.o= rg [mailto:nvo3-bounces@ietf.org= ] On Behalf Of Aldrin Isaac
Sent: Tuesday, July 23, 2013 8:00 AM
To: Kireeti Kompella
Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; tho= mas.morin@orange.com; UTTARO, JAMES
Subject: Re: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 =

+1.

 =

Network operators lose f= lexibility with Global VNIDs. Virtual topology will be fine = tuned on top of VNIDs by squeezing a square peg (ACLs) into a rou= nd hole (where it's otherwise not needed).  I think local context IDs will make a come back once we regain our sanity.  :).

 =

On Tuesday, July 23, 201= 3, Kireeti Kompella wrote:

Hi Xuxiaohu,

Sorry for the previous empty email.

On Jul 23, 2013, at 4:51, Xuxiaohu <xuxiaohu@hu= awei.com> wrote:

> The reason that I started this discussion is to make sure whether the = Virtual Network Context Identification contained in the data packet is REAL= LY required to be globally unique in some cases.

No. There's nothing useful that I know that one can do with global IDs in t= he data plane that one cannot do with local IDs, and local IDs are easier t= o allocate and manage. So, I'd be going the other way and advocate locally = significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do)

Kireeti
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02DC796Aeusaamb109erics_-- From Weijing_Chen@labs.att.com Tue Jul 23 09:50:32 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8619111E82D9; Tue, 23 Jul 2013 09:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 dgNCdbafNQK4; Tue, 23 Jul 2013 09:50:24 -0700 (PDT) Received: from relay2.labs.att.com (postman.labs.att.com [205.173.58.32]) by ietfa.amsl.com (Postfix) with ESMTP id DD2A611E8213; Tue, 23 Jul 2013 09:50:23 -0700 (PDT) Received: from mailpolish.labs.att.com (mailpolish [144.60.65.114]) by relay2.labs.att.com (Postfix) with ESMTP id 9A1011F51E; Tue, 23 Jul 2013 11:50:22 -0500 (CDT) Received: from mailpolish.labs.att.com (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 7CE8F126E16_1EEB44EB; Tue, 23 Jul 2013 16:50:22 +0000 (GMT) Received: from irelay1.labs.att.com (irelay1.labs.att.com [144.60.17.146]) by mailpolish.labs.att.com (Sophos Email Appliance) with ESMTP id 2666012682D_1EEB448F; Tue, 23 Jul 2013 16:50:16 +0000 (GMT) Received: from SAUSMAILHUB.ad.tri.sbc.com (sausmailhub.ad.tri.sbc.com [144.60.55.228]) by irelay1.labs.att.com (Postfix) with ESMTP id 2070124001F; Tue, 23 Jul 2013 11:50:16 -0500 (CDT) Received: from SAUSMAILMBX2.ad.tri.sbc.com ([144.60.55.230]) by SAUSMAILHUB.ad.tri.sbc.com ([144.60.55.228]) with mapi id 14.03.0123.003; Tue, 23 Jul 2013 11:50:16 -0500 From: "Chen, Weijing" To: L3VPN , "nvo3@ietf.org" Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOh8G0k3ppQGQOREa4Zj8c92Dij5lyzH6A//+srlA= Date: Tue, 23 Jul 2013 16:50:15 +0000 Message-ID: <46BA31809AC84B4BA1D8139B683142610B9236C0@SAUSMAILMBX2.ad.tri.sbc.com> References: <2691CE0099834E4A9C5044EEC662BB9D4527E2C4@dfweml509-mbx.china.huawei.com> <0DB8F45437AB844CBB5102F807A0AD9310469E53@xmb-rcd-x03.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D4527E309@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.60.56.239] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-20032.007 x-tm-as-result: No--41.343500-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 23 Jul 2013 10:13:22 -0700 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 16:50:32 -0000 Centralized controller can allocate global IDs and build the mapping table = of global ID to associated local ID. Data plane and control protocol need = not to aware of global ID. -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of K= ireeti Kompella Sent: Tuesday, July 23, 2013 11:46 AM To: Lucy yong Cc: thomas.morin@orange.com; L3VPN; Yakov Rekhter; nvo3@ietf.org; Aldrin Is= aac; UTTARO, JAMES Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn On Jul 23, 2013, at 19:28, Lucy yong wrote: > Like to hear more the people opinions about: in SDN approach, will global= ID and local ID are equally good (just mater choice) or one is better than= other? The SDN (centralized) approach makes allocation of global IDs easier. Howev= er, Xiaohu asked a data plane question. Local IDs are much easier for the d= ata plane. BTW, I am not in favor of centralizing everything.=20 Kireeti From Peter.AshwoodSmith@huawei.com Tue Jul 23 10:03:45 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345CA11E8228; Tue, 23 Jul 2013 10:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[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 vHRPkie+X+Ym; Tue, 23 Jul 2013 10:03:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E192111E82E7; Tue, 23 Jul 2013 10:03:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVI77048; Tue, 23 Jul 2013 17:03:37 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 18:02:39 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 18:03:33 +0100 Received: from dfweml513-mbb.china.huawei.com ([169.254.15.169]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Tue, 23 Jul 2013 10:03:23 -0700 From: AshwoodsmithPeter To: Kireeti Kompella , Lucy yong Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOh8Qz+RSc2BnczUOelMQdtM6jFJlye8hw Date: Tue, 23 Jul 2013 17:03:22 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E20989315A@dfweml513-mbb.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D4527E2C4@dfweml509-mbx.china.huawei.com> <0DB8F45437AB844CBB5102F807A0AD9310469E53@xmb-rcd-x03.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D4527E309@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.60.127] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Tue, 23 Jul 2013 10:13:22 -0700 Cc: L3VPN , Yakov Rekhter , "nvo3@ietf.org" , Aldrin Isaac , "thomas.morin@orange.com" , "UTTARO, JAMES" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 17:03:45 -0000 One area where it would perhaps make a difference for SDN is in the case of= merging two SDN controlled regions. Global identifiers (for anything) that= overlap between the two SDN regions that must then be merged/deconflicted = would be tricky to deal with. Peter -----Original Message----- From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Kir= eeti Kompella Sent: Tuesday, July 23, 2013 12:46 PM To: Lucy yong Cc: thomas.morin@orange.com; L3VPN; Yakov Rekhter; nvo3@ietf.org; Aldrin Is= aac; Xuxiaohu; Luyuan Fang (lufang); UTTARO, JAMES Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn On Jul 23, 2013, at 19:28, Lucy yong wrote: > Like to hear more the people opinions about: in SDN approach, will global= ID and local ID are equally good (just mater choice) or one is better than= other? The SDN (centralized) approach makes allocation of global IDs easier. Howev= er, Xiaohu asked a data plane question. Local IDs are much easier for the d= ata plane. BTW, I am not in favor of centralizing everything.=20 Kireeti _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From mn1921@att.com Tue Jul 23 12:03:44 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F7D11E83A1; Tue, 23 Jul 2013 12:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 cJhfJKI2TuMm; Tue, 23 Jul 2013 12:03:38 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAEC11E83BD; Tue, 23 Jul 2013 12:02:51 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id b53dee15.2aaaf5e42940.415422.00-574.1145545.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 23 Jul 2013 19:02:51 +0000 (UTC) X-MXL-Hash: 51eed35b369752ca-a5440d161770a429cc2f425ac9d9fae16782c629 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 453dee15.0.415355.00-144.1145321.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 23 Jul 2013 19:02:48 +0000 (UTC) X-MXL-Hash: 51eed35843cd24a3-8f87ce6670994d7fff30c6af37c3878ec84195b7 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6NJ2iYN000486; Tue, 23 Jul 2013 15:02:44 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6NJ2bEf032739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jul 2013 15:02:42 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 23 Jul 2013 19:02:24 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0342.003; Tue, 23 Jul 2013 15:02:23 -0400 From: "NAPIERALA, MARIA H" To: Lucy yong Subject: FW: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOh8G3H3ayRcd0hku0ElT1yiZjvplym31QgAABXxA= Date: Tue, 23 Jul 2013 19:02:22 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01206D70@MISOUT7MSGUSR9I.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.193] Content-Type: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E01206D70MISOUT7MSGUSR9I_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=YP8oP26x c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=-s3I2kwCOWQA:10 a=-75S1CYa6MQA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=b8SDY8akl] X-AnalysisOut: [RgA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=AUd_NHdVAAAA:8 ] X-AnalysisOut: [a=i0EeH86SAAAA:8 a=pGLkceISAAAA:8 a=OUXY8nFuAAAA:8 a=kQ41l] X-AnalysisOut: [9oBcOV2y6zrG-0A:9 a=CjuIK1q_8ugA:10 a=qmVb32oy2m0A:10 a=lZ] X-AnalysisOut: [B815dzVvQA:10 a=oAXR_kdF8uMA:10 a=JfD0Fch1gWkA:10 a=hPjdaM] X-AnalysisOut: [EvmhQA:10 a=MSl-tDqOz04A:10 a=peF9eE_zjQwA:10 a=4uYAX-xd9O] X-AnalysisOut: [Q7D2fU:21 a=OGXIHX-V6siV2iY3:21 a=yMhMjlubAAAA:8 a=SSmOFEA] X-AnalysisOut: [CAAAA:8 a=Gcidq9P0k2mAMqw9UggA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7] X-AnalysisOut: [L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=tXsnliwV7] X-AnalysisOut: [b4A:10 a=eNEfg04RGdYZ7YNe:21 a=PSlUhe0fdvCmy9sx:21 a=MY3bW] X-AnalysisOut: [gGMDTfwfuAO:21] Cc: "nvo3@ietf.org" , L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 19:03:44 -0000 --_000_1D70D757A2C9D54D83B4CBD7625FA80E01206D70MISOUT7MSGUSR9I_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Like to hear more the people opinions about: in SDN approach, will global= ID and local ID are equally good (just mater choice) or one is better than= other? If one wants flexible network connectivity, using a global ID in a data pla= ne is not the way to go. If there is any need to transition traffic from on= e global ID to another, it basically means that those IDs should be local i= n the first place. This is independent of SDN. Maria From: l3vpn-bounces@ietf.org [mailto:l3vpn-b= ounces@ietf.org] On Behalf Of Lucy yong Sent: Tuesday, July 23, 2013 12:28 PM To: Luyuan Fang (lufang); Aldrin Isaac; Kireeti Kompella Cc: L3VPN; Yakov Rekhter; nvo3@ietf.org; thomas.morin= @orange.com; UTTARO, JAMES Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn In distributed control plane approach, we have strong consensus that local = ID is the way to go. Like to hear more the people opinions about: in SDN approach, will global I= D and local ID are equally good (just mater choice) or one is better than o= ther? Lucy From: Luyuan Fang (lufang) [mailto:lufang@cisco.com] Sent: Tuesday, July 23, 2013 11:06 AM To: Lucy yong; Aldrin Isaac; Kireeti Kompella Cc: L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; th= omas.morin@orange.com; UTTARO, JAMES Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn You choose the ID type: global or local. You choose the control paradigm, SDN, dynamic control plane, or hybrid. The two decisions are independent. My personal preferences: SDN with local ID. Luyuan From: Lucy yong > Date: Tuesday, July 23, 2013 11:58 AM To: Luyuan Fang >, Aldrin Isaac <= aldrin.isaac@gmail.com>, Kireeti Kompella > Cc: L3VPN >, Yakov Rekhter >, "nvo3@ietf.org" = >, Xuxiaohu >, "thomas.morin@orange.com" >, "UTTARO, = JAMES" > Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn As I see, using SDN approach or distributed control plane, and using global= or local ID are two orthogonal questions. [Lucy] then, the question to be asked is which usage makes sense in the SDN= approach, global ID or local ID? IMHO: they are related. Lucy > is distributed architecture better than centralized architecture for VPN = or virtual network overlay? No necessarily. Luyuan From: Lucy yong > Date: Tuesday, July 23, 2013 11:14 AM To: Aldrin Isaac >, K= ireeti Kompella > Cc: Luyuan Fang >, L3VPN >, Yakov Rekhter >, "nvo3@ietf.org" >, Xuxiaohu >, "thomas.morin@orange.com" >, "UTTARO, JAMES" > Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn For distributed based architecture, the local context ID has a lot of benef= its. For centralized (or SDN) architecture, will the global context ID have= advance? Another way to ask this is: is distributed architecture better t= han centralized architecture for VPN or virtual network overlay? Lucy From:nvo3-bounces@ietf.org [mailto:nvo3-bounc= es@ietf.org] On Behalf Of Aldrin Isaac Sent: Tuesday, July 23, 2013 8:00 AM To: Kireeti Kompella Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; thomas.morin@orange.com= ; UTTARO, JAMES Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn +1. Network operators lose flexibility with Global VNIDs. Virtual topology will= be fine tuned on top of VNIDs by squeezing a square peg (ACLs) into a roun= d hole (where it's otherwise not needed). I think local context IDs will m= ake a come back once we regain our sanity. :). On Tuesday, July 23, 2013, Kireeti Kompella wrote: Hi Xuxiaohu, Sorry for the previous empty email. On Jul 23, 2013, at 4:51, Xuxiaohu > wrot= e: > The reason that I started this discussion is to make sure whether the Vir= tual Network Context Identification contained in the data packet is REALLY = required to be globally unique in some cases. No. There's nothing useful that I know that one can do with global IDs in t= he data plane that one cannot do with local IDs, and local IDs are easier t= o allocate and manage. So, I'd be going the other way and advocate locally = significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do) Kireeti _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --_000_1D70D757A2C9D54D83B4CBD7625FA80E01206D70MISOUT7MSGUSR9I_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> Like to hear more th= e people opinions about: in SDN approach, will global ID and local ID are e= qually good (just mater choice) or one is better than other?

 <= /p>

If one wants flexible net= work connectivity, using a global ID in a data plane is not the way to go. = If there is any need to transition traffic from one global ID to another, it basically means that those IDs should be local in the fi= rst place.

This is independent of SD= N.

 <= /p>

Maria

 <= /p>

From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Tuesday, July 23, 2013 12:28 PM
To: Luyuan Fang (lufang); Aldrin Isaac; Kireeti Kompella
Cc: L3VPN; Yakov Rekhter; nvo3@ietf= .org; thomas.morin@orange.com; UTT= ARO, JAMES
Subject: RE: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 

In distributed control pl= ane approach, we have strong consensus that local ID is the way to go.=

 <= /p>

Like to hear more the peo= ple opinions about: in SDN approach, will global ID and local ID are equall= y good (just mater choice) or one is better than other?

 <= /p>

Lucy

 <= /p>

From: Luyuan F= ang (lufang) [mailto:lufang@cisco.com]
Sent: Tuesday, July 23, 2013 11:06 AM
To: Lucy yong; Aldrin Isaac; Kireeti Kompella
Cc: L3VPN; Yakov Rekhter; nvo3@ietf= .org; Xuxiaohu; thomas.morin@orange.com; UTT= ARO, JAMES
Subject: Re: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 

You choose the ID type: glo= bal or local.

You choose the control para= digm, SDN, dynamic control plane, or hybrid.

 

The two decisions are indep= endent.

 

My personal preferences: SD= N with local ID.

 

Luyuan

 

From: Lucy yong <lucy.yong@huawei.com>
Date: Tuesday, July 23, 2013 11:58 AM
To: Luyuan Fang <lufang@cisco= .com>, Aldrin Isaac <al= drin.isaac@gmail.com>, Kireeti Kompella <kireeti.kompella@gmail.com>
Cc: L3VPN <l3vpn@ietf.org&g= t;, Yakov Rekhter <yakov@juniper.ne= t>, "nvo3@ietf.org" &= lt;nvo3@ietf.org>, Xuxiaohu <xuxiaohu@huawei.com>, &q= uot;thomas.morin@orange.com&= quot; <thomas.morin@orange.co= m>, "UTTARO, JAMES" <= ju1738@att.com>
Subject: RE: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 

 

 

As I see, using SDN approac= h or distributed control plane, and using global or local ID are two orthog= onal questions.

[Lucy] then, the qu= estion to be asked is which usage makes sense in the SDN approach,  gl= obal ID or local ID? IMHO: they are related.

 

Lucy

 

> is distributed architecture better than centralized archit= ecture for VPN or virtual network overlay?

No necessarily.

 

Luyuan

From: Lucy yong <lucy.yong@huawei.com>
Date: Tuesday, July 23, 2013 11:14 AM
To: Aldrin Isaac <aldri= n.isaac@gmail.com>, Kireeti Kompella <kireeti.kompella@gmail.com>
Cc: Luyuan Fang <lufang@cisco= .com>, L3VPN <l3vpn@ietf.org>, Yakov Rekhter <yakov@juniper= .net>, "nvo3@ietf.org"= ; <nvo3@ietf.org>, Xuxiaohu <<= a href=3D"mailto:xuxiaohu@huawei.com">xuxiaohu@huawei.com>, "thomas.morin@orange.com" = <thomas.morin@orange.com&= gt;, "UTTARO, JAMES" <ju1738@att= .com>
Subject: RE: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 

For distributed based arc= hitecture, the local context ID has a lot of benefits. For centralized (or = SDN) architecture, will the global context ID have advance?  Another way to ask this is: is distributed architecture better than = centralized architecture for VPN or virtual network overlay?

 

Lucy

 

From:nvo3-bounces@ietf.o= rg [mailto:nvo3-bounces@ietf.org= ] On Behalf Of Aldrin Isaac
Sent: Tuesday, July 23, 2013 8:00 AM
To: Kireeti Kompella
Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; tho= mas.morin@orange.com; UTTARO, JAMES
Subject: Re: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 =

+1.

 =

Network operators lose f= lexibility with Global VNIDs. Virtual topology will be fine = tuned on top of VNIDs by squeezing a square peg (ACLs) into a rou= nd hole (where it's otherwise not needed).  I think local context IDs will make a come back once we regain our sanity.  :).

 =

On Tuesday, July 23, 201= 3, Kireeti Kompella wrote:

Hi Xuxiaohu,

Sorry for the previous empty email.

On Jul 23, 2013, at 4:51, Xuxiaohu <xuxiaohu@hu= awei.com> wrote:

> The reason that I started this discussion is to make sure whether the = Virtual Network Context Identification contained in the data packet is REAL= LY required to be globally unique in some cases.

No. There's nothing useful that I know that one can do with global IDs in t= he data plane that one cannot do with local IDs, and local IDs are easier t= o allocate and manage. So, I'd be going the other way and advocate locally = significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do)

Kireeti
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

--_000_1D70D757A2C9D54D83B4CBD7625FA80E01206D70MISOUT7MSGUSR9I_-- From someshg@Brocade.COM Tue Jul 23 12:36:41 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F1F11E8382; Tue, 23 Jul 2013 12:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.664 X-Spam-Level: X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, 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 GhHaH-0wL-Km; Tue, 23 Jul 2013 12:36:37 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id BB01511E8381; Tue, 23 Jul 2013 12:36:36 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r6NJBMg9021308; Tue, 23 Jul 2013 12:36:05 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1dsc4bgnep-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 23 Jul 2013 12:36:05 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 23 Jul 2013 12:36:04 -0700 Received: from HQ1-EXCH02.corp.brocade.com ([fe80::c92a:772e:befa:c34c]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Tue, 23 Jul 2013 12:36:04 -0700 From: Somesh Gupta To: Lucy yong , Aldrin Isaac , Kireeti Kompella Date: Tue, 23 Jul 2013 12:36:03 -0700 Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOh6SdfX2poll6ik2P4GZLQHBAlJlyVhnAgABQtGA= Message-ID: References: <0DB8F45437AB844CBB5102F807A0AD931044FBDC@xmb-rcd-x03.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D80F2@NKGEML512-MBS.china.huawei.com> <9921DABA-3484-4D52-813A-77119BEBAA58@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D4527E258@dfweml509-mbx.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4527E258@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BB8D8AEC7DBA1F41810DCB5D38AF56ABA3B78814C8HQ1EXCH02corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-23_05:2013-07-22, 2013-07-23, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1307230138 X-Mailman-Approved-At: Tue, 23 Jul 2013 12:46:29 -0700 Cc: L3VPN , Yakov Rekhter , "nvo3@ietf.org" , "thomas.morin@orange.com" , "UTTARO, JAMES" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 19:36:41 -0000 --_000_BB8D8AEC7DBA1F41810DCB5D38AF56ABA3B78814C8HQ1EXCH02corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A centralized architecture for a single domain is the way things will be in practice (already are). One way or the other, non-virtualized network devices (physical switches etc) will have to fit into that model. Now we can debate the definition of a domain is :) It may be defined by the scope of a centralized control plane? Somesh From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Luc= y yong Sent: Tuesday, July 23, 2013 8:15 AM To: Aldrin Isaac; Kireeti Kompella Cc: thomas.morin@orange.com; L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu;= Luyuan Fang (lufang); UTTARO, JAMES Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn For distributed based architecture, the local context ID has a lot of benef= its. For centralized (or SDN) architecture, will the global context ID have= advance? Another way to ask this is: is distributed architecture better t= han centralized architecture for VPN or virtual network overlay? Lucy From: nvo3-bounces@ietf.org [mailto:nvo3-boun= ces@ietf.org] On Behalf Of Aldrin Isaac Sent: Tuesday, July 23, 2013 8:00 AM To: Kireeti Kompella Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; thomas.morin@orange.com= ; UTTARO, JAMES Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn +1. Network operators lose flexibility with Global VNIDs. Virtual topology will= be fine tuned on top of VNIDs by squeezing a square peg (ACLs) into a roun= d hole (where it's otherwise not needed). I think local context IDs will m= ake a come back once we regain our sanity. :). On Tuesday, July 23, 2013, Kireeti Kompella wrote: Hi Xuxiaohu, Sorry for the previous empty email. On Jul 23, 2013, at 4:51, Xuxiaohu > wrot= e: > The reason that I started this discussion is to make sure whether the Vir= tual Network Context Identification contained in the data packet is REALLY = required to be globally unique in some cases. No. There's nothing useful that I know that one can do with global IDs in t= he data plane that one cannot do with local IDs, and local IDs are easier t= o allocate and manage. So, I'd be going the other way and advocate locally = significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do) Kireeti _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --_000_BB8D8AEC7DBA1F41810DCB5D38AF56ABA3B78814C8HQ1EXCH02corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A central= ized architecture for a single domain is the way things

will be in practice (already are). One way or= the other, non-virtualized

network devices (physical switches etc) will have to fit into that

model.

 

Now we can debate the definition of a domain is J It = may

be defined by the scop= e of a centralized control plane?

 

Somesh=

 

From: nvo3-bounces@ietf.org [mailto:n= vo3-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Tuesday= , July 23, 2013 8:15 AM
To: Aldrin Isaac; Kireeti Kompella
= Cc: thomas.morin@orange.com; L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxia= ohu; Luyuan Fang (lufang); UTTARO, JAMES
Subject: Re: [nvo3] The = possibility of using global MPLS labels as VNIs ... for l3vpn

 

For distributed based architecture, the local context ID has= a lot of benefits. For centralized (or SDN) architecture, will the global = context ID have advance?  Another way to ask this is: is distributed a= rchitecture better than centralized architecture for VPN or virtual network= overlay?

 

Lucy

 

From: nvo3-bounces@ie= tf.org [mailto:nvo3-bounces@ie= tf.org] On Behalf Of Aldrin Isaac
Sent: Tuesday, July = 23, 2013 8:00 AM
To: Kireeti Kompella
Cc: Luyuan Fang (= lufang); L3VPN; Yakov Rekhter; nvo3@ietf.o= rg; Xuxiaohu; thomas.morin@o= range.com; UTTARO, JAMES
Subject: Re: [nvo3] The possibility = of using global MPLS labels as VNIs ... for l3vpn

 

+1.<= o:p>

 

Network operators lose flexibility with Global VNIDs= . Virtual topology will be fine tuned on top of VNIDs by&nbs= p;squeezing a square peg (ACLs) into a round hole (where it's otherwise not= needed).  I think local context IDs will make a come back once w= e regain our sanity.  :).

 

On Tuesday, July 23, = 2013, Kireeti Kompella wrote:

Hi Xuxiaoh= u,

Sorry for the previous empty email.

On Jul 23, 2013, at 4:= 51, Xuxiaohu <xuxiaohu@huawei.com> wrote= :

> The reason that I started this discussion is to make sure whe= ther the Virtual Network Context Identification contained in the data packe= t is REALLY required to be globally unique in some cases.

No. There'= s nothing useful that I know that one can do with global IDs in the data pl= ane that one cannot do with local IDs, and local IDs are easier to allocate= and manage. So, I'd be going the other way and advocate locally significan= t VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do)

Kir= eeti
_______________________________________________
nvo3 mailing lis= t
nvo3@ietf.org
https://www.ietf.org/mailm= an/listinfo/nvo3

= --_000_BB8D8AEC7DBA1F41810DCB5D38AF56ABA3B78814C8HQ1EXCH02corp_-- From ju1738@att.com Tue Jul 23 13:45:44 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5BDF11E8136; Tue, 23 Jul 2013 13:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ftcy6cR4SElj; Tue, 23 Jul 2013 13:45:38 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id A220B11E8100; Tue, 23 Jul 2013 13:45:37 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 17beee15.2aaad2e0a940.1968104.00-525.5363600.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 23 Jul 2013 20:45:37 +0000 (UTC) X-MXL-Hash: 51eeeb713491905c-d1b1818fc83cc98d279592174af8ce8db9a11678 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id beaeee15.0.1966516.00-458.5359230.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 23 Jul 2013 20:43:25 +0000 (UTC) X-MXL-Hash: 51eeeaed26941106-b6c41bd20167ce9769c3efd9c3551574ed6d301a Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6NKhMtU022375; Tue, 23 Jul 2013 16:43:23 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6NKhBeG022226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jul 2013 16:43:14 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 23 Jul 2013 20:42:57 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0342.003; Tue, 23 Jul 2013 16:42:57 -0400 From: "UTTARO, JAMES" To: Somesh Gupta , Lucy yong , Aldrin Isaac , Kireeti Kompella Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOh6SdfX2poll6ik2P4GZLQHBAlJlyVhnAgABQtGCAABNrcA== Date: Tue, 23 Jul 2013 20:42:56 +0000 Message-ID: References: <0DB8F45437AB844CBB5102F807A0AD931044FBDC@xmb-rcd-x03.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D80F2@NKGEML512-MBS.china.huawei.com> <9921DABA-3484-4D52-813A-77119BEBAA58@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D4527E258@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.179.156] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F0623EE54MISOUT7MSGUSR9I_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=WbS7nTdX c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=WSbCeTKtZzAA:10 a=40jasayI6h8A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=rAke-XTGM] X-AnalysisOut: [yIA:10 a=p-L6lgetAAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 ] X-AnalysisOut: [a=i0EeH86SAAAA:8 a=2nl0Q-o6u9wJxwHnb2oA:9 a=CjuIK1q_8ugA:1] X-AnalysisOut: [0 a=qmVb32oy2m0A:10 a=8sUx55cWP4cA:10 a=oAXR_kdF8uMA:10 a=] X-AnalysisOut: [lZB815dzVvQA:10 a=hPjdaMEvmhQA:10 a=w1712orAKknMznaG:21 a=] X-AnalysisOut: [98fjqhyYIJmetoNb:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=Aa] X-AnalysisOut: [RMTvKX2lYaJ19NJM8A:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a] X-AnalysisOut: [=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10 a=NjM] X-AnalysisOut: [eifIm3-F3c9PL:21 a=bLPUKHnMUN7vqs57:21 a=6dL4dDmxeCYH4sqt:] X-AnalysisOut: [21] Cc: L3VPN , Yakov Rekhter , "nvo3@ietf.org" , "thomas.morin@orange.com" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 20:45:44 -0000 --_000_B17A6910EEDD1F45980687268941550F0623EE54MISOUT7MSGUSR9I_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Maybe the approach should be to gather reqs and then decide what will be or= not be in practice. Jim Uttaro From: Somesh Gupta [mailto:someshg@brocade.com] Sent: Tuesday, July 23, 2013 3:36 PM To: Lucy yong; Aldrin Isaac; Kireeti Kompella Cc: thomas.morin@orange.com; L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu;= Luyuan Fang (lufang); UTTARO, JAMES Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn A centralized architecture for a single domain is the way things will be in practice (already are). One way or the other, non-virtualized network devices (physical switches etc) will have to fit into that model. Now we can debate the definition of a domain is :) It may be defined by the scope of a centralized control plane? Somesh From: nvo3-bounces@ietf.org [mailto:nvo3-boun= ces@ietf.org] On Behalf Of Lucy yong Sent: Tuesday, July 23, 2013 8:15 AM To: Aldrin Isaac; Kireeti Kompella Cc: thomas.morin@orange.com; L3VPN; Yakov R= ekhter; nvo3@ietf.org; Xuxiaohu; Luyuan Fang (lufang)= ; UTTARO, JAMES Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn For distributed based architecture, the local context ID has a lot of benef= its. For centralized (or SDN) architecture, will the global context ID have= advance? Another way to ask this is: is distributed architecture better t= han centralized architecture for VPN or virtual network overlay? Lucy From: nvo3-bounces@ietf.org [mailto:nvo3-boun= ces@ietf.org] On Behalf Of Aldrin Isaac Sent: Tuesday, July 23, 2013 8:00 AM To: Kireeti Kompella Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; thomas.morin@orange.com= ; UTTARO, JAMES Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn +1. Network operators lose flexibility with Global VNIDs. Virtual topology will= be fine tuned on top of VNIDs by squeezing a square peg (ACLs) into a roun= d hole (where it's otherwise not needed). I think local context IDs will m= ake a come back once we regain our sanity. :). On Tuesday, July 23, 2013, Kireeti Kompella wrote: Hi Xuxiaohu, Sorry for the previous empty email. On Jul 23, 2013, at 4:51, Xuxiaohu > wrot= e: > The reason that I started this discussion is to make sure whether the Vir= tual Network Context Identification contained in the data packet is REALLY = required to be globally unique in some cases. No. There's nothing useful that I know that one can do with global IDs in t= he data plane that one cannot do with local IDs, and local IDs are easier t= o allocate and manage. So, I'd be going the other way and advocate locally = significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do) Kireeti _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --_000_B17A6910EEDD1F45980687268941550F0623EE54MISOUT7MSGUSR9I_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Maybe the approach should= be to gather reqs and then decide what will be or not be in practice.=

 <= /p>

Jim Uttaro

 <= /p>

From: Somesh G= upta [mailto:someshg@brocade.com]
Sent: Tuesday, July 23, 2013 3:36 PM
To: Lucy yong; Aldrin Isaac; Kireeti Kompella
Cc: thomas.morin@orange.com; L3VPN; Yakov Rekhter; nvo3@ietf.org; Xu= xiaohu; Luyuan Fang (lufang); UTTARO, JAMES
Subject: RE: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 

A centralized architectur= e for a single domain is the way things

will be in practice (alre= ady are). One way or the other, non-virtualized

network devices (physical= switches etc) will have to fit into that

model.<= /p>

 <= /p>

Now we can debate the def= inition of a domain is J It may

be defined by the scope o= f a centralized control plane?

 <= /p>

Somesh<= /p>

 <= /p>

From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Tuesday, July 23, 2013 8:15 AM
To: Aldrin Isaac; Kireeti Kompella
Cc: thomas.morin@orange.c= om; L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; Luyuan Fang (= lufang); UTTARO, JAMES
Subject: Re: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 

For distributed based arc= hitecture, the local context ID has a lot of benefits. For centralized (or = SDN) architecture, will the global context ID have advance?  Another way to ask this is: is distributed architecture better than = centralized architecture for VPN or virtual network overlay?

 <= /p>

Lucy

 <= /p>

From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Aldrin Isaac
Sent: Tuesday, July 23, 2013 8:00 AM
To: Kireeti Kompella
Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; tho= mas.morin@orange.com; UTTARO, JAMES
Subject: Re: [nvo3] The possibility of using global MPLS labels as V= NIs ... for l3vpn

 

+1.

 

Network operators lose flexibility with Global = VNIDs. Virtual topology will be fine tuned on top of VNIDs b= y squeezing a square peg (ACLs) into a round hole (where it's otherwis= e not needed).  I think local context IDs will make a come back once we regain our sanity.  :).

 

On Tuesday, July 23, 2013, Kireeti Kompella wrote:

Hi Xuxiaohu,

Sorry for the previous empty email.

On Jul 23, 2013, at 4:51, Xuxiaohu <xuxiaohu@hu= awei.com> wrote:

> The reason that I started this discussion is to make sure whether the = Virtual Network Context Identification contained in the data packet is REAL= LY required to be globally unique in some cases.

No. There's nothing useful that I know that one can do with global IDs in t= he data plane that one cannot do with local IDs, and local IDs are easier t= o allocate and manage. So, I'd be going the other way and advocate locally = significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do)

Kireeti
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

--_000_B17A6910EEDD1F45980687268941550F0623EE54MISOUT7MSGUSR9I_-- From yakov@juniper.net Tue Jul 23 15:29:27 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BDE11E8162; Tue, 23 Jul 2013 15:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.199 X-Spam-Level: X-Spam-Status: No, score=-97.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_19=0.6, MANGLED_LIST=2.3, MANGLED_MEDS=2.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 L2gacAAjjfNU; Tue, 23 Jul 2013 15:29:23 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 34B0621F8FF3; Tue, 23 Jul 2013 15:29:23 -0700 (PDT) Received: from mail137-ch1-R.bigfish.com (10.43.68.253) by CH1EHSOBE019.bigfish.com (10.43.70.76) with Microsoft SMTP Server id 14.1.225.22; Tue, 23 Jul 2013 22:29:22 +0000 Received: from mail137-ch1 (localhost [127.0.0.1]) by mail137-ch1-R.bigfish.com (Postfix) with ESMTP id 4E23FE00EA; Tue, 23 Jul 2013 22:29:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -17 X-BigFish: VPS-17(zcb8kz98dI9371Ic85fh1432Idbb0izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah8275dh1de097h1de096h8275bh74efjz2fh2a8h668h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1155h) Received-SPF: pass (mail137-ch1: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=yakov@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail137-ch1 (localhost.localdomain [127.0.0.1]) by mail137-ch1 (MessageSwitch) id 1374618559274963_555; Tue, 23 Jul 2013 22:29:19 +0000 (UTC) Received: from CH1EHSMHS041.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.226]) by mail137-ch1.bigfish.com (Postfix) with ESMTP id 3B75D340047; Tue, 23 Jul 2013 22:29:19 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.54) by CH1EHSMHS041.bigfish.com (10.43.69.250) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 23 Jul 2013 22:29:17 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 23 Jul 2013 15:28:48 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r6NMSlL52723; Tue, 23 Jul 2013 15:28:47 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201307232228.r6NMSlL52723@magenta.juniper.net> To: Somesh Gupta Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn In-Reply-To: References: <0DB8F45437AB844CBB5102F807A0AD931044FBDC@xmb-rcd-x03.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D80F2@NKGEML512-MBS.china.huawei.com> <9921DABA-3484-4D52-813A-77119BEBAA58@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D4527E258@dfweml509-mbx.china.huawei.com> X-MH-In-Reply-To: Somesh Gupta message dated "Tue, 23 Jul 2013 12:36:03 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23844.1374618527.1@juniper.net> Date: Tue, 23 Jul 2013 15:28:47 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "thomas.morin@orange.com" , L3VPN , Yakov Rekhter , "nvo3@ietf.org" , Aldrin Isaac , "UTTARO, JAMES" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 22:29:28 -0000 Somesh, > A centralized architecture for a single domain is the way things > will be in practice (already are). We can all speculate about how "the things will be in practice". However, in terms of how things "already are", 2547 VPNs, which are widely deployed today, are *not* based on "a centralized architecture". Yakov. > One way or the other, non-virtualized > network devices (physical switches etc) will have to fit into that > model. > > Now we can debate the definition of a domain is :) It may > be defined by the scope of a centralized control plane? > > Somesh > > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Luc= > y yong > Sent: Tuesday, July 23, 2013 8:15 AM > To: Aldrin Isaac; Kireeti Kompella > Cc: thomas.morin@orange.com; L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu;= > Luyuan Fang (lufang); UTTARO, JAMES > Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= > for l3vpn > > For distributed based architecture, the local context ID has a lot of benef= > its. For centralized (or SDN) architecture, will the global context ID have= > advance? Another way to ask this is: is distributed architecture better t= > han centralized architecture for VPN or virtual network overlay? > > Lucy > > From: nvo3-bounces@ietf.org [mailto:nvo3-boun= > ces@ietf.org] On Behalf Of Aldrin Isaac > Sent: Tuesday, July 23, 2013 8:00 AM > To: Kireeti Kompella > Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; nvo3@ietf.org etf.org>; Xuxiaohu; thomas.morin@orange.com= > ; UTTARO, JAMES > Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= > for l3vpn > > +1. > > Network operators lose flexibility with Global VNIDs. Virtual topology will= > be fine tuned on top of VNIDs by squeezing a square peg (ACLs) into a roun= > d hole (where it's otherwise not needed). I think local context IDs will m= > ake a come back once we regain our sanity. :). > > On Tuesday, July 23, 2013, Kireeti Kompella wrote: > Hi Xuxiaohu, > > Sorry for the previous empty email. > > On Jul 23, 2013, at 4:51, Xuxiaohu > wrot= > e: > > > The reason that I started this discussion is to make sure whether the Vir= > tual Network Context Identification contained in the data packet is REALLY = > required to be globally unique in some cases. > > No. There's nothing useful that I know that one can do with global IDs in t= > he data plane that one cannot do with local IDs, and local IDs are easier t= > o allocate and manage. So, I'd be going the other way and advocate locally = > significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do) > > Kireeti > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > --_000_BB8D8AEC7DBA1F41810DCB5D38AF56ABA3B78814C8HQ1EXCH02corp_ > Content-Type: text/html; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= > //www.w3.org/TR/REC-html40"> =3D"text/html; charset=3Dus-ascii"> oft Word 14 (filtered medium)"> nk=3Dpurple>

ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>A central= > ized architecture for a single domain is the way things p>

","sans-serif";color:#1F497D'>will be in practice (already are). One way or= > the other, non-virtualized

style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D= > '>network devices (physical switches etc) will have to fit into that o:p>

mily:"Calibri","sans-serif";color:#1F497D'>model.

lass=3DMsoNormal> s-serif";color:#1F497D'> 

pan style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F4= > 97D'>Now we can debate the definition of a domain is font-size:11.0pt;font-family:Wingdings;color:#1F497D'>J =3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> It = > may

pt;font-family:"Calibri","sans-serif";color:#1F497D'>be defined by the scop= > e of a centralized control plane?

> 1F497D'> 

t-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Somesh= >

family:"Calibri","sans-serif";color:#1F497D'> 

iv style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.= > 0pt'>
3.0pt 0in 0in 0in'>

font-family:"Tahoma","sans-serif"'>From: :10.0pt;font-family:"Tahoma","sans-serif"'> nvo3-bounces@ietf.org [mailto:n= > vo3-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Tuesday= > , July 23, 2013 8:15 AM
To: Aldrin Isaac; Kireeti Kompella
= > Cc: thomas.morin@orange.com; L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxia= > ohu; Luyuan Fang (lufang); UTTARO, JAMES
Subject: Re: [nvo3] The = > possibility of using global MPLS labels as VNIs ... for l3vpn pan>

 

oNormal> color:#1F497D'>For distributed based architecture, the local context ID has= > a lot of benefits. For centralized (or SDN) architecture, will the global = > context ID have advance?  Another way to ask this is: is distributed a= > rchitecture better than centralized architecture for VPN or virtual network= > overlay?

e:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>  >

y:"Calibri","sans-serif";color:#1F497D'>Lucy

=3DMsoNormal> rif";color:#1F497D'> 

order-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
order:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

ss=3DMsoNormal> s-serif"'>From: ma","sans-serif"'> nvo3-bounces@ie= > tf.org [mailto:nvo3-bounces@ie= > tf.org] On Behalf Of Aldrin Isaac
Sent: Tuesday, July = > 23, 2013 8:00 AM
To: Kireeti Kompella
Cc: Luyuan Fang (= > lufang); L3VPN; Yakov Rekhter; nvo3@ietf.o= > rg; Xuxiaohu; thomas.morin@o= > range.com; UTTARO, JAMES
Subject: Re: [nvo3] The possibility = > of using global MPLS labels as VNIs ... for l3vpn

v>

 

+1.<= > o:p>

 

class=3DMsoNormal>Network operators lose flexibility with Global VNIDs= > . Virtual topology will be fine tuned on top of VNIDs by&nbs= > p;squeezing a square peg (ACLs) into a round hole (where it's otherwise not= > needed).  I think local context IDs will make a come back once w= > e regain our sanity.  :).

Normal> 

On Tuesday, July 23, = > 2013, Kireeti Kompella wrote:

Hi Xuxiaoh= > u,

Sorry for the previous empty email.

On Jul 23, 2013, at 4:= > 51, Xuxiaohu <xuxiaohu@huawei.com> wrote= > :

> The reason that I started this discussion is to make sure whe= > ther the Virtual Network Context Identification contained in the data packe= > t is REALLY required to be globally unique in some cases.

No. There'= > s nothing useful that I know that one can do with global IDs in the data pl= > ane that one cannot do with local IDs, and local IDs are easier to allocate= > and manage. So, I'd be going the other way and advocate locally significan= > t VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do)

Kir= > eeti
_______________________________________________
nvo3 mailing lis= > t
nvo3@ietf.org
etf.org/mailman/listinfo/nvo3" target=3D"_blank">https://www.ietf.org/mailm= > an/listinfo/nvo3

tml>= > > --_000_BB8D8AEC7DBA1F41810DCB5D38AF56ABA3B78814C8HQ1EXCH02corp_-- > From ju1738@att.com Tue Jul 23 15:56:29 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94ED11E8169; Tue, 23 Jul 2013 15:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-2.900, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_19=0.6, MANGLED_BODY=2.3, MANGLED_MEDS=2.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 OW1y4OWRWN9V; Tue, 23 Jul 2013 15:56:24 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id D78DA11E816F; Tue, 23 Jul 2013 15:56:20 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 41a0fe15.7f050940.1948655.00-570.5333837.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 23 Jul 2013 22:56:20 +0000 (UTC) X-MXL-Hash: 51ef0a1479fc2c4d-6c60eb10ed3ec5990151a4ca2afb598928a6f445 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id f0a0fe15.0.1948647.00-326.5333749.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 23 Jul 2013 22:56:16 +0000 (UTC) X-MXL-Hash: 51ef0a10481709b6-5f62986b83ec33198502a1538b5a0c42764384fb Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6NMuFC4018777; Tue, 23 Jul 2013 18:56:15 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6NMu3Im018720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jul 2013 18:56:03 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Tue, 23 Jul 2013 22:55:53 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0342.003; Tue, 23 Jul 2013 18:55:52 -0400 From: "UTTARO, JAMES" To: Somesh Gupta , Yakov Rekhter Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOh/fHkMOsoXl31UGZ5HqEurAGdA== Date: Tue, 23 Jul 2013 22:55:52 +0000 Message-ID: References: <0DB8F45437AB844CBB5102F807A0AD931044FBDC@xmb-rcd-x03.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D80F2@NKGEML512-MBS.china.huawei.com> <9921DABA-3484-4D52-813A-77119BEBAA58@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D4527E258@dfweml509-mbx.china.huawei.com> <201307232228.r6NMSlL52723@magenta.juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.179.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=Sa5AgItu c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=WSbCeTKtZzAA:10 a=40jasayI6h8A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=rAke-XTGMyIA:10 a=p-L6lgetAAAA:8 a=z9tbli-vAAAA:8] X-AnalysisOut: [ a=48vgC7mUAAAA:8 a=OUXY8nFuAAAA:8 a=ilg0rRk5AAAA:8 a=i0Ee] X-AnalysisOut: [H86SAAAA:8 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=4vgIikcKAAA] X-AnalysisOut: [A:8 a=rRldHyOPAAAA:8 a=UfQLjSqmC_ID6ZKjW14A:9 a=CjuIK1q_8u] X-AnalysisOut: [gA:10 a=UiCQ7L4-1S4A:10 a=qmVb32oy2m0A:10 a=LNyxSjUz4xgA:1] X-AnalysisOut: [0 a=NWWHaA-u5HIA:10 a=Vvg477KoImsA:10 a=8sUx55cWP4cA:10 a=] X-AnalysisOut: [oAXR_kdF8uMA:10 a=lZB815dzVvQA:10 a=peF9eE_zjQwA:10 a=hPjd] X-AnalysisOut: [aMEvmhQA:10 a=ND1GOKE_S1i_MfRo:21 a=9XxDkyNNFRLZlA4k:21 a=] X-AnalysisOut: [y2GVygdwxqLDZ_Al:21] Cc: "thomas.morin@orange.com" , L3VPN , "nvo3@ietf.org" , Aldrin Isaac X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 22:56:29 -0000 Somesh, IMO one of the bigger use cases is "stitching" between data center and WAN= and data center 1 and data center 2 instances of a given VPN. These two CU= Gs are not orthogonal, this is where it is important to define the services= that will utilize the technology. Jim Uttaro -----Original Message----- From: Somesh Gupta [mailto:someshg@brocade.com]=20 Sent: Tuesday, July 23, 2013 6:38 PM To: Yakov Rekhter Cc: Lucy yong; Aldrin Isaac; Kireeti Kompella; thomas.morin@orange.com; L3V= PN; nvo3@ietf.org; Xuxiaohu; Luyuan Fang (lufang); UTTARO, JAMES Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn=20 Yaakov, I thought we were discussing virtual overlay networks (not VPNs) as related to virtualized data centers (maybe I assumed incorrectly). >From whatever I see from the vendors of these products, they seem to be shipping/moving towards centralized control plane. > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: Tuesday, July 23, 2013 3:29 PM > To: Somesh Gupta > Cc: Lucy yong; Aldrin Isaac; Kireeti Kompella; thomas.morin@orange.com; > L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; Luyuan Fang (lufang); > UTTARO, JAMES > Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs .= .. for > l3vpn >=20 > Somesh, >=20 > > A centralized architecture for a single domain is the way things > > will be in practice (already are). >=20 > We can all speculate about how "the things will be in practice". >=20 > However, in terms of how things "already are", 2547 VPNs, which are widel= y > deployed today, are *not* based on "a centralized architecture". >=20 > Yakov. >=20 > > One way or the other, non-virtualized > > network devices (physical switches etc) will have to fit into that > > model. > > > > Now we can debate the definition of a domain is :) It may > > be defined by the scope of a centralized control plane? > > > > Somesh > > > > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf > Of Luc=3D > > y yong > > Sent: Tuesday, July 23, 2013 8:15 AM > > To: Aldrin Isaac; Kireeti Kompella > > Cc: thomas.morin@orange.com; L3VPN; Yakov Rekhter; nvo3@ietf.org; > Xuxiaohu;=3D > > Luyuan Fang (lufang); UTTARO, JAMES > > Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs= ...=3D > > for l3vpn > > > > For distributed based architecture, the local context ID has a lot of b= enef=3D > > its. For centralized (or SDN) architecture, will the global context ID = have=3D > > advance? Another way to ask this is: is distributed architecture bett= er t=3D > > han centralized architecture for VPN or virtual network overlay? > > > > Lucy > > > > From: nvo3-bounces@ietf.org > [mailto:nvo3-boun=3D > > ces@ietf.org] On Behalf Of Aldrin Isaac > > Sent: Tuesday, July 23, 2013 8:00 AM > > To: Kireeti Kompella > > Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; > nvo3@ietf.org > etf.org>; Xuxiaohu; > thomas.morin@orange.com=3D > > ; UTTARO, JAMES > > Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs= ...=3D > > for l3vpn > > > > +1. > > > > Network operators lose flexibility with Global VNIDs. Virtual topology = will=3D > > be fine tuned on top of VNIDs by squeezing a square peg (ACLs) into a > roun=3D > > d hole (where it's otherwise not needed). I think local context IDs wi= ll m=3D > > ake a come back once we regain our sanity. :). > > > > On Tuesday, July 23, 2013, Kireeti Kompella wrote: > > Hi Xuxiaohu, > > > > Sorry for the previous empty email. > > > > On Jul 23, 2013, at 4:51, Xuxiaohu > > wrot=3D > > e: > > > > > The reason that I started this discussion is to make sure whether the= Vir=3D > > tual Network Context Identification contained in the data packet is REA= LLY > =3D > > required to be globally unique in some cases. > > > > No. There's nothing useful that I know that one can do with global IDs = in t=3D > > he data plane that one cannot do with local IDs, and local IDs are easi= er t=3D > > o allocate and manage. So, I'd be going the other way and advocate loca= lly > =3D > > significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I = do) > > > > Kireeti > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > -- > _000_BB8D8AEC7DBA1F41810DCB5D38AF56ABA3B78814C8HQ1EXCH02corp_ > > Content-Type: text/html; charset=3D"us-ascii" > > Content-Transfer-Encoding: quoted-printable > > > > xmlns:o=3D3D"urn:schemas-micr=3D > > osoft-com:office:office" xmlns:w=3D3D"urn:schemas-microsoft- > com:office:word" =3D > > xmlns:m=3D3D"http://schemas.microsoft.com/office/2004/12/omml" > xmlns=3D3D"http:=3D > > //www.w3.org/TR/REC-html40"> Type" CONTENT=3D > > =3D3D"text/html; charset=3D3Dus-ascii"> content=3D3D"Micros=3D > > oft Word 14 (filtered medium)"> link=3D3Dblue vli=3D > > nk=3D3Dpurple>

style=3D3D'f=3D > > ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>A cen= tral=3D > > ized architecture for a single domain is the way > things > p>

family:"Calibri=3D > > ","sans-serif";color:#1F497D'>will be in practice (already are). One wa= y or=3D > > the other, non-virtualized

class=3D3DMsoNormal> > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#= 1F497D=3D > > '>network devices (physical switches etc) will have to fit into that > o:p>

size:11.0pt;font-fa=3D > > mily:"Calibri","sans- > serif";color:#1F497D'>model.

> lass=3D3DMsoNormal> family:"Calibri","san=3D > > s-serif";color:#1F497D'> 

class=3D3DMsoNormal> > pan style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif";colo= r:#1F4=3D > > 97D'>Now we can debate the definition of a domain is style=3D3D'=3D > > font-size:11.0pt;font-family:Wingdings;color:#1F497D'>J style=3D > > =3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D= '> It =3D > > may

style=3D3D'font-size:11.0=3D > > pt;font-family:"Calibri","sans-serif";color:#1F497D'>be defined by the > scop=3D > > e of a centralized control plane?

class=3D3DMsoNormal=3D > > > > 1F497D'> 

style=3D3D'fon=3D > > t-size:11.0pt;font-family:"Calibri","sans- > serif";color:#1F497D'>Somesh=3D > >

size:11.0pt;font-=3D > > family:"Calibri","sans- > serif";color:#1F497D'> 

> iv style=3D3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in = 0in 4.=3D > > 0pt'>
1.0pt;padding:=3D > > 3.0pt 0in 0in 0in'>

size:10.0pt;=3D > > font-family:"Tahoma","sans-serif"'>From: style=3D3D'font-size=3D > > :10.0pt;font-family:"Tahoma","sans-serif"'> nvo3-bounces@ietf.org > [mailto:n=3D > > vo3-bounces@ietf.org] On Behalf Of Lucy yong
Sent: > Tuesday=3D > > , July 23, 2013 8:15 AM
To: Aldrin Isaac; Kireeti > Kompella
=3D > > Cc: thomas.morin@orange.com; L3VPN; Yakov Rekhter; > nvo3@ietf.org; Xuxia=3D > > ohu; Luyuan Fang (lufang); UTTARO, JAMES
Subject: Re: > [nvo3] The =3D > > possibility of using global MPLS labels as VNIs ... for l3vpn > pan>

class=3D3DMsoNormal> 

> oNormal> serif";=3D > > color:#1F497D'>For distributed based architecture, the local context ID > has=3D > > a lot of benefits. For centralized (or SDN) architecture, will the glo= bal =3D > > context ID have advance?  Another way to ask this is: is distribut= ed > a=3D > > rchitecture better than centralized architecture for VPN or virtual net= work=3D > > overlay?

style=3D3D'font-siz=3D > > e:11.0pt;font-family:"Calibri","sans- > serif";color:#1F497D'>  > >

size:11.0pt;font-famil=3D > > y:"Calibri","sans-serif";color:#1F497D'>Lucy

class=3D > > =3D3DMsoNormal> family:"Calibri","sans-se=3D > > rif";color:#1F497D'> 

style=3D3D'border:none;b=3D > > order-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
> order:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

cla=3D > > ss=3D3DMsoNormal> family:"Tahoma","san=3D > > s-serif"'>From: family:"Taho=3D > > ma","sans-serif"'> nvo3- > bounces@ie=3D > > tf.org [mailto:nvo3- > bounces@ie=3D > > tf.org] On Behalf Of Aldrin Isaac
Sent: Tuesday, > July =3D > > 23, 2013 8:00 AM
To: Kireeti Kompella
Cc: Luyuan > Fang (=3D > > lufang); L3VPN; Yakov Rekhter; href=3D3D"mailto:nvo3@ietf.org">nvo3@ietf.o=3D > > rg; Xuxiaohu; href=3D3D"mailto:thomas.morin@orange.com">thomas.morin@o=3D > > range.com; UTTARO, JAMES
Subject: Re: [nvo3] The > possibility =3D > > of using global MPLS labels as VNIs ... for > l3vpn

> v>

 

class=3D3DMsoNormal>+1.<=3D > > o:p>

class=3D3DMsoNormal> 

> class=3D3DMsoNormal>Network operators lose flexibility with Global > VNIDs=3D > > . Virtual topology will be fine tuned on top of VNIDs > by&nbs=3D > > p;squeezing a square peg (ACLs) into a round hole (where it's otherwise > not=3D > > needed).  I think local context IDs will make a come back on= ce > w=3D > > e regain our sanity.  :).

class=3D3DMso=3D > > Normal> 

On > Tuesday, July 23, =3D > > 2013, Kireeti Kompella wrote:

Hi > Xuxiaoh=3D > > u,

Sorry for the previous empty email.

On Jul 23, 2013, a= t > 4:=3D > > 51, Xuxiaohu <xuxiaohu@huawei.com> > wrote=3D > > :

> The reason that I started this discussion is to make sure > whe=3D > > ther the Virtual Network Context Identification contained in the data > packe=3D > > t is REALLY required to be globally unique in some cases.

No. > There'=3D > > s nothing useful that I know that one can do with global IDs in the dat= a pl=3D > > ane that one cannot do with local IDs, and local IDs are easier to allo= cate=3D > > and manage. So, I'd be going the other way and advocate locally signif= ican=3D > > t VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I > do)

Kir=3D > > > eeti
_______________________________________________
n > vo3 mailing lis=3D > > t
nvo3@ietf.org
href=3D3D"https://www.i=3D > > etf.org/mailman/listinfo/nvo3" > target=3D3D"_blank">https://www.ietf.org/mailm=3D > > > an/listinfo/nvo3

dy> > tml>=3D > > > > -- > _000_BB8D8AEC7DBA1F41810DCB5D38AF56ABA3B78814C8HQ1EXCH02corp_- > - > > From renwei.li@huawei.com Tue Jul 23 17:13:07 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3075911E8194; Tue, 23 Jul 2013 17:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[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 jvjaEom1zlkp; Tue, 23 Jul 2013 17:13:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3C17011E818D; Tue, 23 Jul 2013 17:12:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATS50903; Wed, 24 Jul 2013 00:12:49 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Jul 2013 01:12:34 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Jul 2013 01:12:30 +0100 Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Tue, 23 Jul 2013 17:12:19 -0700 From: Richard Li To: Kireeti Kompella , Lucy yong Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOh8QuDfEEhH3EQ0+i4jmbnJvLFJly9DMA Date: Wed, 24 Jul 2013 00:12:19 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D4527E2C4@dfweml509-mbx.china.huawei.com> <0DB8F45437AB844CBB5102F807A0AD9310469E53@xmb-rcd-x03.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D4527E309@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: L3VPN , Yakov Rekhter , "nvo3@ietf.org" , Aldrin Isaac , "thomas.morin@orange.com" , "UTTARO, JAMES" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 00:13:07 -0000 We may be able to get some wisdom from VLAN where both local and global ids= are used. The global vlan id is used to build a whole "subnet" across different and m= ulti-hop Ethernet segments.=20 -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of K= ireeti Kompella Sent: Wednesday, July 24, 2013 12:46 AM To: Lucy yong Cc: thomas.morin@orange.com; L3VPN; Yakov Rekhter; nvo3@ietf.org; Aldrin Is= aac; UTTARO, JAMES Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn On Jul 23, 2013, at 19:28, Lucy yong wrote: > Like to hear more the people opinions about: in SDN approach, will global= ID and local ID are equally good (just mater choice) or one is better than= other? The SDN (centralized) approach makes allocation of global IDs easier. Howev= er, Xiaohu asked a data plane question. Local IDs are much easier for the d= ata plane. BTW, I am not in favor of centralizing everything.=20 Kireeti From xuxiaohu@huawei.com Tue Jul 23 18:51:04 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD1F11E81AC; Tue, 23 Jul 2013 18:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=-1.098, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 tSen4aS7bZNZ; Tue, 23 Jul 2013 18:50:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BA26311E81B8; Tue, 23 Jul 2013 18:50:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATS55484; Wed, 24 Jul 2013 01:50:47 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Jul 2013 02:50:33 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Jul 2013 02:50:44 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.175]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Wed, 24 Jul 2013 09:50:33 +0800 From: Xuxiaohu To: Richard Li , Kireeti Kompella , Lucy yong Subject: re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOiAT021gHQA1tt0G/Jd1KUifSZZlzCaqg Date: Wed, 24 Jul 2013 01:50:32 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D860F@NKGEML512-MBS.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D4527E2C4@dfweml509-mbx.china.huawei.com> <0DB8F45437AB844CBB5102F807A0AD9310469E53@xmb-rcd-x03.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D4527E309@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: L3VPN , Yakov Rekhter , "nvo3@ietf.org" , Aldrin Isaac , "thomas.morin@orange.com" , "UTTARO, JAMES" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 01:51:04 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbnZvMy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFJpY2hhcmQNCj4gTGkNCj4gt6LL zcqxvOQ6IDIwMTPE6jfUwjI0yNUgODoxMg0KPiDK1bz+yMs6IEtpcmVldGkgS29tcGVsbGE7IEx1 Y3kgeW9uZw0KPiCzrcvNOiBMM1ZQTjsgWWFrb3YgUmVraHRlcjsgbnZvM0BpZXRmLm9yZzsgQWxk cmluIElzYWFjOw0KPiB0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbTsgVVRUQVJPLCBKQU1FUw0KPiDW 98ziOiBSZTogW252bzNdIFRoZSBwb3NzaWJpbGl0eSBvZiB1c2luZyBnbG9iYWwgTVBMUyBsYWJl bHMgYXMgVk5JcyAuLi4gZm9yIGwzdnBuDQo+IA0KPiBXZSBtYXkgYmUgYWJsZSB0byBnZXQgc29t ZSB3aXNkb20gZnJvbSBWTEFOIHdoZXJlIGJvdGggbG9jYWwgYW5kIGdsb2JhbCBpZHMNCj4gYXJl IHVzZWQuDQo+IA0KPiBUaGUgZ2xvYmFsIHZsYW4gaWQgaXMgdXNlZCB0byBidWlsZCBhIHdob2xl ICJzdWJuZXQiIGFjcm9zcyBkaWZmZXJlbnQgYW5kDQo+IG11bHRpLWhvcCBFdGhlcm5ldCBzZWdt ZW50cy4NCg0KV2hldGhlciBhIGdsb2JhbCBWTiBJRCBpbiB0aGUgZGF0YSBwYWNrZXQgaXMgcmVx dWlyZWQgbWF5IGRlcGVuZCBvbiB3aGV0aGVyIHRoZSB0cmFuc2l0IG5vZGVzIG5lZWQgdG8ga25v dyB0aGUgZ2xvYmFsIFZOIElELCBJTUhPLiBGb3IgVkxBTiwgdGhlIHRyYW5zaXQgbm9kZXMgbmVl ZCB0byBrbm93IHRoZSBnbG9iYWwgVk4gSUQgKGkuZS4sIFZMQU4gSUQpIGZvciBwYWNrZXQgZm9y d2FyZGluZy4gRm9yIFRSSUxMLCB0aGUgdHJhbnNpdCBSQiBub2RlcyBuZWVkIHRvIGtub3cgdGhl IGdsb2JhbCBWTiBJRCAoaS5lLiwgVkxBTiBJRCBvciBGR0wpIGZvciBWTEFOIG9yIEZHTCBwcnVu aW5nLiBGb3IgTlZvMywgSSBoYXZlbid0IHNlZW4gYW55IHVzZSBjYXNlIHlldCBhbmQgdGhlcmVm b3JlIEkgd2FudCB0byBtYWtlIHN1cmUgd2hldGhlciB0aGVyZSBpcyBhbnkgdXNlIGNhc2UgdGhh dCBJIGhhZCBtaXNzZWQuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IA0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsM3Zwbi1ib3VuY2VzQGlldGYub3JnIFttYWls dG86bDN2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IEtpcmVldGkgS29tcGVs bGENCj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDI0LCAyMDEzIDEyOjQ2IEFNDQo+IFRvOiBMdWN5 IHlvbmcNCj4gQ2M6IHRob21hcy5tb3JpbkBvcmFuZ2UuY29tOyBMM1ZQTjsgWWFrb3YgUmVraHRl cjsgbnZvM0BpZXRmLm9yZzsgQWxkcmluDQo+IElzYWFjOyBVVFRBUk8sIEpBTUVTDQo+IFN1Ympl Y3Q6IFJlOiBbbnZvM10gVGhlIHBvc3NpYmlsaXR5IG9mIHVzaW5nIGdsb2JhbCBNUExTIGxhYmVs cyBhcyBWTklzIC4uLiBmb3INCj4gbDN2cG4NCj4gDQo+IE9uIEp1bCAyMywgMjAxMywgYXQgMTk6 MjgsIEx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb20+IHdyb3RlOg0KPiANCj4gPiBMaWtl IHRvIGhlYXIgbW9yZSB0aGUgcGVvcGxlIG9waW5pb25zIGFib3V0OiBpbiBTRE4gYXBwcm9hY2gs IHdpbGwgZ2xvYmFsIElEDQo+IGFuZCBsb2NhbCBJRCBhcmUgZXF1YWxseSBnb29kIChqdXN0IG1h dGVyIGNob2ljZSkgb3Igb25lIGlzIGJldHRlciB0aGFuIG90aGVyPw0KPiANCj4gVGhlIFNETiAo Y2VudHJhbGl6ZWQpIGFwcHJvYWNoIG1ha2VzIGFsbG9jYXRpb24gb2YgZ2xvYmFsIElEcyBlYXNp ZXIuIEhvd2V2ZXIsDQo+IFhpYW9odSBhc2tlZCBhIGRhdGEgcGxhbmUgcXVlc3Rpb24uIExvY2Fs IElEcyBhcmUgbXVjaCBlYXNpZXIgZm9yIHRoZSBkYXRhDQo+IHBsYW5lLg0KPiANCj4gQlRXLCBJ IGFtIG5vdCBpbiBmYXZvciBvZiBjZW50cmFsaXppbmcgZXZlcnl0aGluZy4NCj4gDQo+IEtpcmVl dGkNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g bnZvMyBtYWlsaW5nIGxpc3QNCj4gbnZvM0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL252bzMNCg== From zhangmingui@huawei.com Tue Jul 23 18:52:27 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCEB11E81CA; Tue, 23 Jul 2013 18:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 T--qoCeOGOhA; Tue, 23 Jul 2013 18:52:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 17F3411E81B8; Tue, 23 Jul 2013 18:52:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVI99179; Wed, 24 Jul 2013 01:51:34 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Jul 2013 02:49:57 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Jul 2013 02:50:52 +0100 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.110]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.01.0323.007; Wed, 24 Jul 2013 09:50:47 +0800 From: Mingui Zhang To: "erosen@cisco.com" Subject: RE: FW: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt Thread-Topic: FW: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt Thread-Index: AQHOh7LW99aNIcBiiE+hzMF4FJ/BvJly/ZBA Date: Wed, 24 Jul 2013 01:50:47 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7335C7E3A@nkgeml508-mbx.china.huawei.com> References: Your message of Tue, 23 Jul 2013 08:21:14 -0000. <4552F0907735844E9204A62BBDD325E7335C7B0C@nkgeml508-mbx.china.huawei.com> <3086.1374590541@erosen-linux> In-Reply-To: <3086.1374590541@erosen-linux> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pwe3@ietf.org" , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 01:52:27 -0000 Hi Eric, Please see the comments in-line. Thanks, Mingui >-----Original Message----- >From: Eric Rosen [mailto:erosen@cisco.com] >Sent: Tuesday, July 23, 2013 10:42 PM >To: Mingui Zhang >Cc: l3vpn@ietf.org; pwe3@ietf.org; erosen@cisco.com >Subject: Re: FW: New Version Notification for >draft-zhang-l3vpn-label-sharing-00.txt > > >Eric> In Figure 2.1, you show CE2 connected to PE3 and PE4. Now suppose w= e also >Eric> have CE4 connected to PE3 and PE5. If PE3 fails, one might want use= PE4 as >Eric> a backup for CE2, while using PE5 as a backup for CE4. Your scheme = doesn't >Eric> seem to handle this. > >Mingui> If PE3 and PE4 allocate (1100, vNH1) for CE2 while PE3 and PE5 >Mingui> allocate (1101, vNH2) for CE4. The scheme works well. > >Are you now suggesting to allocate a vNH address and shared label for ever= y >CE? Since there are many more CEs than PEs, that would make the scaling >properties of the scheme a lot less favorable. That's not true. Please search the following sentence in the draft. "Egress PEs create a vNH router in IGP to represent the set of CEs dual-hom= ed to the same egress PEs in the Service Provider's backbone." I don't think this kind of allocation bears scalability issues. > >Eric> Also, even in the case of Figure 2.1, it seems entirely possibly tha= t >Eric> one might want PE3's primary route to CE2 to be via the directly >Eric> attached interface, while wanting PE4's primary route to CE2 to be v= ia >Eric> PE3. Does your scheme handle this case? > >Mingui> Yes, it handles. Please see the right part of eq1: Sxy3+M. If the >Mingui> backup tunnel goes through Pxy->PE4->PE3->vNH, then Sxy3+M < =3D >Mingui> Sxy4+S. That means eq1 does not hold. > >I think that equation is based only on the IGP link costs. A service >provider might use BGP LOCAL_PREF to give the PE3-->CE2 route a higher >degree of preference than the PE4-->CE2 route, in which case PE4's normal >route to CE2 could be via PE3, independent of the IGP link costs. Of >course, PE4 will switch to the directly attached route when it learns, >through IGP, that PE3 is not reachable. But in that case you might not me= et >the FRR goal. To achieve the goal of protection, the draft suggested the PEs in the RG us= e routes that they learn from the CE. If the service provider insists on using the route from just one PE, he is = ready to give up the reliability that can be provided by multiple PEs. From someshg@Brocade.COM Tue Jul 23 15:38:21 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF2611E813F; Tue, 23 Jul 2013 15:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.235 X-Spam-Level: X-Spam-Status: No, score=0.235 tagged_above=-999 required=5 tests=[AWL=-2.899, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_110=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_19=0.6, MANGLED_BODY=2.3, MANGLED_MEDS=2.3, 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 MlQ8VPOBiUMW; Tue, 23 Jul 2013 15:38:17 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id DD03C11E8150; Tue, 23 Jul 2013 15:38:16 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r6NM7pbh010479; Tue, 23 Jul 2013 15:38:06 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1dt0gur2tc-4 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 23 Jul 2013 15:38:06 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 23 Jul 2013 15:38:02 -0700 Received: from HQ1-EXCH02.corp.brocade.com ([fe80::c92a:772e:befa:c34c]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Tue, 23 Jul 2013 15:37:56 -0700 From: Somesh Gupta To: Yakov Rekhter Date: Tue, 23 Jul 2013 15:37:55 -0700 Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: Ac6H9BZcD10MrYgVRWuSYmO102WGqAAAA8og Message-ID: References: <0DB8F45437AB844CBB5102F807A0AD931044FBDC@xmb-rcd-x03.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D80F2@NKGEML512-MBS.china.huawei.com> <9921DABA-3484-4D52-813A-77119BEBAA58@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D4527E258@dfweml509-mbx.china.huawei.com> <201307232228.r6NMSlL52723@magenta.juniper.net> In-Reply-To: <201307232228.r6NMSlL52723@magenta.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-23_05:2013-07-22, 2013-07-23, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1307230170 X-Mailman-Approved-At: Wed, 24 Jul 2013 00:07:15 -0700 Cc: "thomas.morin@orange.com" , L3VPN , "nvo3@ietf.org" , Aldrin Isaac , "UTTARO, JAMES" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 22:38:21 -0000 Yaakov, I thought we were discussing virtual overlay networks (not VPNs) as related to virtualized data centers (maybe I assumed incorrectly). >From whatever I see from the vendors of these products, they seem to be shipping/moving towards centralized control plane. > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: Tuesday, July 23, 2013 3:29 PM > To: Somesh Gupta > Cc: Lucy yong; Aldrin Isaac; Kireeti Kompella; thomas.morin@orange.com; > L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; Luyuan Fang (lufang); > UTTARO, JAMES > Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs .= .. for > l3vpn >=20 > Somesh, >=20 > > A centralized architecture for a single domain is the way things > > will be in practice (already are). >=20 > We can all speculate about how "the things will be in practice". >=20 > However, in terms of how things "already are", 2547 VPNs, which are widel= y > deployed today, are *not* based on "a centralized architecture". >=20 > Yakov. >=20 > > One way or the other, non-virtualized > > network devices (physical switches etc) will have to fit into that > > model. > > > > Now we can debate the definition of a domain is :) It may > > be defined by the scope of a centralized control plane? > > > > Somesh > > > > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf > Of Luc=3D > > y yong > > Sent: Tuesday, July 23, 2013 8:15 AM > > To: Aldrin Isaac; Kireeti Kompella > > Cc: thomas.morin@orange.com; L3VPN; Yakov Rekhter; nvo3@ietf.org; > Xuxiaohu;=3D > > Luyuan Fang (lufang); UTTARO, JAMES > > Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs= ...=3D > > for l3vpn > > > > For distributed based architecture, the local context ID has a lot of b= enef=3D > > its. For centralized (or SDN) architecture, will the global context ID = have=3D > > advance? Another way to ask this is: is distributed architecture bett= er t=3D > > han centralized architecture for VPN or virtual network overlay? > > > > Lucy > > > > From: nvo3-bounces@ietf.org > [mailto:nvo3-boun=3D > > ces@ietf.org] On Behalf Of Aldrin Isaac > > Sent: Tuesday, July 23, 2013 8:00 AM > > To: Kireeti Kompella > > Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; > nvo3@ietf.org > etf.org>; Xuxiaohu; > thomas.morin@orange.com=3D > > ; UTTARO, JAMES > > Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs= ...=3D > > for l3vpn > > > > +1. > > > > Network operators lose flexibility with Global VNIDs. Virtual topology = will=3D > > be fine tuned on top of VNIDs by squeezing a square peg (ACLs) into a > roun=3D > > d hole (where it's otherwise not needed). I think local context IDs wi= ll m=3D > > ake a come back once we regain our sanity. :). > > > > On Tuesday, July 23, 2013, Kireeti Kompella wrote: > > Hi Xuxiaohu, > > > > Sorry for the previous empty email. > > > > On Jul 23, 2013, at 4:51, Xuxiaohu > > wrot=3D > > e: > > > > > The reason that I started this discussion is to make sure whether the= Vir=3D > > tual Network Context Identification contained in the data packet is REA= LLY > =3D > > required to be globally unique in some cases. > > > > No. There's nothing useful that I know that one can do with global IDs = in t=3D > > he data plane that one cannot do with local IDs, and local IDs are easi= er t=3D > > o allocate and manage. So, I'd be going the other way and advocate loca= lly > =3D > > significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I = do) > > > > Kireeti > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > -- > _000_BB8D8AEC7DBA1F41810DCB5D38AF56ABA3B78814C8HQ1EXCH02corp_ > > Content-Type: text/html; charset=3D"us-ascii" > > Content-Transfer-Encoding: quoted-printable > > > > xmlns:o=3D3D"urn:schemas-micr=3D > > osoft-com:office:office" xmlns:w=3D3D"urn:schemas-microsoft- > com:office:word" =3D > > xmlns:m=3D3D"http://schemas.microsoft.com/office/2004/12/omml" > xmlns=3D3D"http:=3D > > //www.w3.org/TR/REC-html40"> Type" CONTENT=3D > > =3D3D"text/html; charset=3D3Dus-ascii"> content=3D3D"Micros=3D > > oft Word 14 (filtered medium)"> link=3D3Dblue vli=3D > > nk=3D3Dpurple>

style=3D3D'f=3D > > ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>A cen= tral=3D > > ized architecture for a single domain is the way > things > p>

family:"Calibri=3D > > ","sans-serif";color:#1F497D'>will be in practice (already are). One wa= y or=3D > > the other, non-virtualized

class=3D3DMsoNormal> > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#= 1F497D=3D > > '>network devices (physical switches etc) will have to fit into that > o:p>

size:11.0pt;font-fa=3D > > mily:"Calibri","sans- > serif";color:#1F497D'>model.

> lass=3D3DMsoNormal> family:"Calibri","san=3D > > s-serif";color:#1F497D'> 

class=3D3DMsoNormal> > pan style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif";colo= r:#1F4=3D > > 97D'>Now we can debate the definition of a domain is style=3D3D'=3D > > font-size:11.0pt;font-family:Wingdings;color:#1F497D'>J style=3D > > =3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D= '> It =3D > > may

style=3D3D'font-size:11.0=3D > > pt;font-family:"Calibri","sans-serif";color:#1F497D'>be defined by the > scop=3D > > e of a centralized control plane?

class=3D3DMsoNormal=3D > > > > 1F497D'> 

style=3D3D'fon=3D > > t-size:11.0pt;font-family:"Calibri","sans- > serif";color:#1F497D'>Somesh=3D > >

size:11.0pt;font-=3D > > family:"Calibri","sans- > serif";color:#1F497D'> 

> iv style=3D3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in = 0in 4.=3D > > 0pt'>
1.0pt;padding:=3D > > 3.0pt 0in 0in 0in'>

size:10.0pt;=3D > > font-family:"Tahoma","sans-serif"'>From: style=3D3D'font-size=3D > > :10.0pt;font-family:"Tahoma","sans-serif"'> nvo3-bounces@ietf.org > [mailto:n=3D > > vo3-bounces@ietf.org] On Behalf Of Lucy yong
Sent: > Tuesday=3D > > , July 23, 2013 8:15 AM
To: Aldrin Isaac; Kireeti > Kompella
=3D > > Cc: thomas.morin@orange.com; L3VPN; Yakov Rekhter; > nvo3@ietf.org; Xuxia=3D > > ohu; Luyuan Fang (lufang); UTTARO, JAMES
Subject: Re: > [nvo3] The =3D > > possibility of using global MPLS labels as VNIs ... for l3vpn > pan>

class=3D3DMsoNormal> 

> oNormal> serif";=3D > > color:#1F497D'>For distributed based architecture, the local context ID > has=3D > > a lot of benefits. For centralized (or SDN) architecture, will the glo= bal =3D > > context ID have advance?  Another way to ask this is: is distribut= ed > a=3D > > rchitecture better than centralized architecture for VPN or virtual net= work=3D > > overlay?

style=3D3D'font-siz=3D > > e:11.0pt;font-family:"Calibri","sans- > serif";color:#1F497D'>  > >

size:11.0pt;font-famil=3D > > y:"Calibri","sans-serif";color:#1F497D'>Lucy

class=3D > > =3D3DMsoNormal> family:"Calibri","sans-se=3D > > rif";color:#1F497D'> 

style=3D3D'border:none;b=3D > > order-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
> order:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

cla=3D > > ss=3D3DMsoNormal> family:"Tahoma","san=3D > > s-serif"'>From: family:"Taho=3D > > ma","sans-serif"'> nvo3- > bounces@ie=3D > > tf.org [mailto:nvo3- > bounces@ie=3D > > tf.org] On Behalf Of Aldrin Isaac
Sent: Tuesday, > July =3D > > 23, 2013 8:00 AM
To: Kireeti Kompella
Cc: Luyuan > Fang (=3D > > lufang); L3VPN; Yakov Rekhter; href=3D3D"mailto:nvo3@ietf.org">nvo3@ietf.o=3D > > rg; Xuxiaohu; href=3D3D"mailto:thomas.morin@orange.com">thomas.morin@o=3D > > range.com; UTTARO, JAMES
Subject: Re: [nvo3] The > possibility =3D > > of using global MPLS labels as VNIs ... for > l3vpn

> v>

 

class=3D3DMsoNormal>+1.<=3D > > o:p>

class=3D3DMsoNormal> 

> class=3D3DMsoNormal>Network operators lose flexibility with Global > VNIDs=3D > > . Virtual topology will be fine tuned on top of VNIDs > by&nbs=3D > > p;squeezing a square peg (ACLs) into a round hole (where it's otherwise > not=3D > > needed).  I think local context IDs will make a come back on= ce > w=3D > > e regain our sanity.  :).

class=3D3DMso=3D > > Normal> 

On > Tuesday, July 23, =3D > > 2013, Kireeti Kompella wrote:

Hi > Xuxiaoh=3D > > u,

Sorry for the previous empty email.

On Jul 23, 2013, a= t > 4:=3D > > 51, Xuxiaohu <xuxiaohu@huawei.com> > wrote=3D > > :

> The reason that I started this discussion is to make sure > whe=3D > > ther the Virtual Network Context Identification contained in the data > packe=3D > > t is REALLY required to be globally unique in some cases.

No. > There'=3D > > s nothing useful that I know that one can do with global IDs in the dat= a pl=3D > > ane that one cannot do with local IDs, and local IDs are easier to allo= cate=3D > > and manage. So, I'd be going the other way and advocate locally signif= ican=3D > > t VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I > do)

Kir=3D > > > eeti
_______________________________________________
n > vo3 mailing lis=3D > > t
nvo3@ietf.org
href=3D3D"https://www.i=3D > > etf.org/mailman/listinfo/nvo3" > target=3D3D"_blank">https://www.ietf.org/mailm=3D > > > an/listinfo/nvo3

dy> > tml>=3D > > > > -- > _000_BB8D8AEC7DBA1F41810DCB5D38AF56ABA3B78814C8HQ1EXCH02corp_- > - > > From someshg@Brocade.COM Tue Jul 23 16:06:33 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D1F11E8172; Tue, 23 Jul 2013 16:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.685 X-Spam-Level: * X-Spam-Status: No, score=1.685 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_110=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_19=0.6, MANGLED_BODY=2.3, MANGLED_MEDS=2.3, 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 6wJd6Y4DO1Lp; Tue, 23 Jul 2013 16:06:29 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id C858B11E8163; Tue, 23 Jul 2013 16:06:28 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r6NM7pd0010479; Tue, 23 Jul 2013 16:06:21 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1dt0gur3ac-15 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 23 Jul 2013 16:06:21 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 23 Jul 2013 16:06:20 -0700 Received: from HQ1-EXCH02.corp.brocade.com ([fe80::c92a:772e:befa:c34c]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Tue, 23 Jul 2013 16:05:48 -0700 From: Somesh Gupta To: "UTTARO, JAMES" , Yakov Rekhter Date: Tue, 23 Jul 2013 16:05:47 -0700 Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOh/fHkMOsoXl31UGZ5HqEurAGdJly4Brw Message-ID: References: <0DB8F45437AB844CBB5102F807A0AD931044FBDC@xmb-rcd-x03.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D80F2@NKGEML512-MBS.china.huawei.com> <9921DABA-3484-4D52-813A-77119BEBAA58@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D4527E258@dfweml509-mbx.china.huawei.com> <201307232228.r6NMSlL52723@magenta.juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-23_05:2013-07-22, 2013-07-23, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1307230170 X-Mailman-Approved-At: Wed, 24 Jul 2013 00:07:15 -0700 Cc: "thomas.morin@orange.com" , L3VPN , "nvo3@ietf.org" , Aldrin Isaac X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 23:06:33 -0000 Jim, I agree with you on the need to support services spanning multiple "domains". If that is the focus of the group, then of course, distributed control plane makes sense. Somesh > -----Original Message----- > From: UTTARO, JAMES [mailto:ju1738@att.com] > Sent: Tuesday, July 23, 2013 3:56 PM > To: Somesh Gupta; Yakov Rekhter > Cc: Lucy yong; Aldrin Isaac; Kireeti Kompella; thomas.morin@orange.com; > L3VPN; nvo3@ietf.org; Xuxiaohu; Luyuan Fang (lufang) > Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs .= .. for > l3vpn > > Somesh, > > IMO one of the bigger use cases is "stitching" between data center > and WAN and data center 1 and data center 2 instances of a given VPN. > These two CUGs are not orthogonal, this is where it is important to defin= e > the services that will utilize the technology. > > Jim Uttaro > > -----Original Message----- > From: Somesh Gupta [mailto:someshg@brocade.com] > Sent: Tuesday, July 23, 2013 6:38 PM > To: Yakov Rekhter > Cc: Lucy yong; Aldrin Isaac; Kireeti Kompella; thomas.morin@orange.com; > L3VPN; nvo3@ietf.org; Xuxiaohu; Luyuan Fang (lufang); UTTARO, JAMES > Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs .= .. for > l3vpn > > Yaakov, > > I thought we were discussing virtual overlay networks (not VPNs) as relat= ed > to virtualized data centers (maybe I assumed incorrectly). > > From whatever I see from the vendors of these products, they seem to be > shipping/moving towards centralized control plane. > > > -----Original Message----- > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > Sent: Tuesday, July 23, 2013 3:29 PM > > To: Somesh Gupta > > Cc: Lucy yong; Aldrin Isaac; Kireeti Kompella; thomas.morin@orange.com; > > L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; Luyuan Fang (lufang); > > UTTARO, JAMES > > Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs= ... for > > l3vpn > > > > Somesh, > > > > > A centralized architecture for a single domain is the way things > > > will be in practice (already are). > > > > We can all speculate about how "the things will be in practice". > > > > However, in terms of how things "already are", 2547 VPNs, which are > widely > > deployed today, are *not* based on "a centralized architecture". > > > > Yakov. > > > > > One way or the other, non-virtualized > > > network devices (physical switches etc) will have to fit into that > > > model. > > > > > > Now we can debate the definition of a domain is :) It may > > > be defined by the scope of a centralized control plane? > > > > > > Somesh > > > > > > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf > > Of Luc=3D > > > y yong > > > Sent: Tuesday, July 23, 2013 8:15 AM > > > To: Aldrin Isaac; Kireeti Kompella > > > Cc: thomas.morin@orange.com; L3VPN; Yakov Rekhter; nvo3@ietf.org; > > Xuxiaohu;=3D > > > Luyuan Fang (lufang); UTTARO, JAMES > > > Subject: Re: [nvo3] The possibility of using global MPLS labels as VN= Is ...=3D > > > for l3vpn > > > > > > For distributed based architecture, the local context ID has a lot of= benef=3D > > > its. For centralized (or SDN) architecture, will the global context I= D have=3D > > > advance? Another way to ask this is: is distributed architecture be= tter t=3D > > > han centralized architecture for VPN or virtual network overlay? > > > > > > Lucy > > > > > > From: nvo3-bounces@ietf.org > > [mailto:nvo3-boun=3D > > > ces@ietf.org] On Behalf Of Aldrin Isaac > > > Sent: Tuesday, July 23, 2013 8:00 AM > > > To: Kireeti Kompella > > > Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; > > nvo3@ietf.org > > etf.org>; Xuxiaohu; > > thomas.morin@orange.com=3D > > > ; UTTARO, JAMES > > > Subject: Re: [nvo3] The possibility of using global MPLS labels as VN= Is ...=3D > > > for l3vpn > > > > > > +1. > > > > > > Network operators lose flexibility with Global VNIDs. Virtual topolog= y > will=3D > > > be fine tuned on top of VNIDs by squeezing a square peg (ACLs) into = a > > roun=3D > > > d hole (where it's otherwise not needed). I think local context IDs = will m=3D > > > ake a come back once we regain our sanity. :). > > > > > > On Tuesday, July 23, 2013, Kireeti Kompella wrote: > > > Hi Xuxiaohu, > > > > > > Sorry for the previous empty email. > > > > > > On Jul 23, 2013, at 4:51, Xuxiaohu = > > > wrot=3D > > > e: > > > > > > > The reason that I started this discussion is to make sure whether t= he > Vir=3D > > > tual Network Context Identification contained in the data packet is > REALLY > > =3D > > > required to be globally unique in some cases. > > > > > > No. There's nothing useful that I know that one can do with global ID= s in > t=3D > > > he data plane that one cannot do with local IDs, and local IDs are ea= sier t=3D > > > o allocate and manage. So, I'd be going the other way and advocate > locally > > =3D > > > significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And = I > do) > > > > > > Kireeti > > > _______________________________________________ > > > nvo3 mailing list > > > nvo3@ietf.org > > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > > -- > > > _000_BB8D8AEC7DBA1F41810DCB5D38AF56ABA3B78814C8HQ1EXCH02corp_ > > > Content-Type: text/html; charset=3D"us-ascii" > > > Content-Transfer-Encoding: quoted-printable > > > > > > > xmlns:o=3D3D"urn:schemas-micr=3D > > > osoft-com:office:office" xmlns:w=3D3D"urn:schemas-microsoft- > > com:office:word" =3D > > > xmlns:m=3D3D"http://schemas.microsoft.com/office/2004/12/omml" > > xmlns=3D3D"http:=3D > > > //www.w3.org/TR/REC-html40"> EQUIV=3D3D"Content- > > Type" CONTENT=3D > > > =3D3D"text/html; charset=3D3Dus-ascii"> > content=3D3D"Micros=3D > > > oft Word 14 (filtered medium)"> > link=3D3Dblue vli=3D > > > nk=3D3Dpurple>

class=3D3DMsoNormal> > style=3D3D'f=3D > > > ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>A > central=3D > > > ized architecture for a single domain is the way > > things > > p>

> family:"Calibri=3D > > > ","sans-serif";color:#1F497D'>will be in practice (already are). One = way > or=3D > > > the other, non-virtualized

> class=3D3DMsoNormal> > > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans- > serif";color:#1F497D=3D > > > '>network devices (physical switches etc) will have to fit into > that > > o:p>

> size:11.0pt;font-fa=3D > > > mily:"Calibri","sans- > > serif";color:#1F497D'>model.

> > lass=3D3DMsoNormal> > family:"Calibri","san=3D > > > s-serif";color:#1F497D'> 

> class=3D3DMsoNormal> > > pan style=3D3D'font-size:11.0pt;font-family:"Calibri","sans- > serif";color:#1F4=3D > > > 97D'>Now we can debate the definition of a domain is > style=3D3D'=3D > > > font-size:11.0pt;font-family:Wingdings;color:#1F497D'>J > style=3D > > > =3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F49= 7D'> It =3D > > > may

> style=3D3D'font-size:11.0=3D > > > pt;font-family:"Calibri","sans-serif";color:#1F497D'>be defined by th= e > > scop=3D > > > e of a centralized control plane?

> class=3D3DMsoNormal=3D > > > > serif";color:#=3D > > > 1F497D'> 

> style=3D3D'fon=3D > > > t-size:11.0pt;font-family:"Calibri","sans- > > serif";color:#1F497D'>Somesh=3D > > >

> size:11.0pt;font-=3D > > > family:"Calibri","sans- > > serif";color:#1F497D'> 

> > iv style=3D3D'border:none;border-left:solid blue 1.5pt;padding:0in 0i= n 0in > 4.=3D > > > 0pt'>
> 1.0pt;padding:=3D > > > 3.0pt 0in 0in 0in'>

> size:10.0pt;=3D > > > font-family:"Tahoma","sans-serif"'>From: > style=3D3D'font-size=3D > > > :10.0pt;font-family:"Tahoma","sans-serif"'> nvo3-bounces@ietf.org > > [mailto:n=3D > > > vo3-bounces@ietf.org] On Behalf Of Lucy > yong
Sent: > > Tuesday=3D > > > , July 23, 2013 8:15 AM
To: Aldrin Isaac; Kireeti > > Kompella
=3D > > > Cc: thomas.morin@orange.com; L3VPN; Yakov Rekhter; > > nvo3@ietf.org; Xuxia=3D > > > ohu; Luyuan Fang (lufang); UTTARO, JAMES
Subject: Re: > > [nvo3] The =3D > > > possibility of using global MPLS labels as VNIs ... for > l3vpn > > pan>

> class=3D3DMsoNormal> 

> > oNormal> > serif";=3D > > > color:#1F497D'>For distributed based architecture, the local context = ID > > has=3D > > > a lot of benefits. For centralized (or SDN) architecture, will the g= lobal =3D > > > context ID have advance?  Another way to ask this is: is distrib= uted > > a=3D > > > rchitecture better than centralized architecture for VPN or virtual > network=3D > > > overlay?

> style=3D3D'font-siz=3D > > > e:11.0pt;font-family:"Calibri","sans- > > serif";color:#1F497D'>  > > >

> size:11.0pt;font-famil=3D > > > y:"Calibri","sans-serif";color:#1F497D'>Lucy

> class=3D > > > =3D3DMsoNormal> > family:"Calibri","sans-se=3D > > > rif";color:#1F497D'> 

> style=3D3D'border:none;b=3D > > > order-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
style=3D3D'b=3D > > > order:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>=

> cla=3D > > > ss=3D3DMsoNormal> > family:"Tahoma","san=3D > > > s-serif"'>From: > family:"Taho=3D > > > ma","sans-serif"'> nvo3- > > bounces@ie=3D > > > tf.org [mailto:nvo3- > > bounces@ie=3D > > > tf.org] On Behalf Of Aldrin Isaac
Sent: Tuesday, > > July =3D > > > 23, 2013 8:00 AM
To: Kireeti Kompella
Cc: > Luyuan > > Fang (=3D > > > lufang); L3VPN; Yakov Rekhter; > href=3D3D"mailto:nvo3@ietf.org">nvo3@ietf.o=3D > > > rg; Xuxiaohu; > href=3D3D"mailto:thomas.morin@orange.com">thomas.morin@o=3D > > > range.com; UTTARO, JAMES
Subject: Re: [nvo3] The > > possibility =3D > > > of using global MPLS labels as VNIs ... for > > l3vpn

> > v>

 

> class=3D3DMsoNormal>+1.<=3D > > > o:p>

> class=3D3DMsoNormal> 

> > class=3D3DMsoNormal>Network operators lose flexibility with Glob= al > > VNIDs=3D > > > . Virtual topology will be fine tuned on top of VNIDs > > by&nbs=3D > > > p;squeezing a square peg (ACLs) into a round hole (where it's otherwi= se > > not=3D > > > needed).  I think local context IDs will make a come back > once > > w=3D > > > e regain our sanity.  :).

> class=3D3DMso=3D > > > Normal> 

On > > Tuesday, July 23, =3D > > > 2013, Kireeti Kompella wrote:

class=3D3DMsoNormal>Hi > > Xuxiaoh=3D > > > u,

Sorry for the previous empty email.

On Jul 23, 2013, > at > > 4:=3D > > > 51, Xuxiaohu < href=3D3D"javascript:;">xuxiaohu@huawei.com> > > wrote=3D > > > :

> The reason that I started this discussion is to make su= re > > whe=3D > > > ther the Virtual Network Context Identification contained in the data > > packe=3D > > > t is REALLY required to be globally unique in some cases.

No. > > There'=3D > > > s nothing useful that I know that one can do with global IDs in the d= ata pl=3D > > > ane that one cannot do with local IDs, and local IDs are easier to al= locate=3D > > > and manage. So, I'd be going the other way and advocate locally > significan=3D > > > t VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I > > do)

Kir=3D > > > > > > eeti
_______________________________________________
n > > vo3 mailing lis=3D > > > t
nvo3@ietf.org
> href=3D3D"https://www.i=3D > > > etf.org/mailman/listinfo/nvo3" > > target=3D3D"_blank">https://www.ietf.org/mailm=3D > > > > > > an/listinfo/nvo3

> dy> > > tml>=3D > > > > > > -- > > > _000_BB8D8AEC7DBA1F41810DCB5D38AF56ABA3B78814C8HQ1EXCH02corp_- > > - > > > From ju1738@att.com Tue Jul 23 16:25:13 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71EBC11E8173; Tue, 23 Jul 2013 16:25:13 -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=[AWL=-1.950, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_33=1, J_CHICKENPOX_110=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_19=0.6, MANGLED_BODY=2.3, MANGLED_MEDS=2.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 2VsskbrRap1d; Tue, 23 Jul 2013 16:24:57 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3081311E8171; Tue, 23 Jul 2013 16:24:56 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 8c01fe15.2aaada21c940.1962441.00-567.5371624.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 23 Jul 2013 23:24:56 +0000 (UTC) X-MXL-Hash: 51ef10c845cf6978-ebba0710b591321526160cea51edd602cefe1c59 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 2c01fe15.0.1962426.00-475.5371507.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 23 Jul 2013 23:24:51 +0000 (UTC) X-MXL-Hash: 51ef10c30bc2935e-c30d70cfda38404ad1d98d3d21064e017aea68b6 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6NNOlgV008836; Tue, 23 Jul 2013 19:24:49 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6NNOhho008794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jul 2013 19:24:43 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 23 Jul 2013 23:24:32 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0342.003; Tue, 23 Jul 2013 19:24:32 -0400 From: "UTTARO, JAMES" To: Somesh Gupta , Yakov Rekhter Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOh/fHkMOsoXl31UGZ5HqEurAGdJly4BrwgAAEgZA= Date: Tue, 23 Jul 2013 23:24:31 +0000 Message-ID: References: <0DB8F45437AB844CBB5102F807A0AD931044FBDC@xmb-rcd-x03.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D80F2@NKGEML512-MBS.china.huawei.com> <9921DABA-3484-4D52-813A-77119BEBAA58@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D4527E258@dfweml509-mbx.china.huawei.com> <201307232228.r6NMSlL52723@magenta.juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.70.179.156] Content-Type: multipart/mixed; boundary="_002_B17A6910EEDD1F45980687268941550F0623EEE6MISOUT7MSGUSR9I_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=Sa5AgItu c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=WSbCeTKtZzAA:10 a=40jasayI6h8A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=rAke-XTGM] X-AnalysisOut: [yIA:10 a=p-L6lgetAAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 ] X-AnalysisOut: [a=OUXY8nFuAAAA:8 a=ilg0rRk5AAAA:8 a=i0EeH86SAAAA:8 a=yMhMj] X-AnalysisOut: [lubAAAA:8 a=SSmOFEACAAAA:8 a=4vgIikcKAAAA:8 a=rRldHyOPAAAA] X-AnalysisOut: [:8 a=54CiDNnj4l8iMBh007YA:9 a=CjuIK1q_8ugA:10 a=UiCQ7L4-1S] X-AnalysisOut: [4A:10 a=qmVb32oy2m0A:10 a=LNyxSjUz4xgA:10 a=NWWHaA-u5HIA:1] X-AnalysisOut: [0 a=Vvg477KoImsA:10 a=8sUx55cWP4cA:10 a=oAXR_kdF8uMA:10 a=] X-AnalysisOut: [lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10 a=peF9eE_zjQwA:10 a=hPjd] X-AnalysisOut: [aMEvmhQA:10 a=jyAWf1FEGRAiAvGJ:21 a=YMtdswA1kgk3oBVw:21 a=] X-AnalysisOut: [EEh9wxxa5EiNpfUO:21 a=gxZvrgisAAAA:8 a=AUd_NHdVAAAA:8 a=k3] X-AnalysisOut: [c6bdWLAAAA:8 a=VnNF1IyMAAAA:8 a=G0_B3m8xAAAA:8 a=fDPXEVOGx] X-AnalysisOut: [4aTov29qD4A:9 a=demI2IUe3x4A:10 a=3FZX-ydVlcEA:10 a=JfD0Fc] X-AnalysisOut: [h1gWkA:10 a=G6Lr7oRM74YA:10 a=lW_bInUQU2sA:10 a=x0LPFJVN_O] X-AnalysisOut: [7Q_wKN:21 a=7Ow5p5-ExeVdcMO7:21 a=kPT58wB7Bh3A_ad0VkUA:9 a] X-AnalysisOut: [=gKO2Hq4RSVkA:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=JEg] X-AnalysisOut: [v49XRtNq-NP75:21 a=4hHSQh59KfFNmEQL:21 a=HZvlwfY_E-kqjGEL:] X-AnalysisOut: [21] X-Mailman-Approved-At: Wed, 24 Jul 2013 00:07:15 -0700 Cc: "thomas.morin@orange.com" , L3VPN , "Rex Fernando \(rex\)" , "nvo3@ietf.org" , Aldrin Isaac , "HASHMI Faisal \(fahashmi@cisco.com\)" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 23:25:13 -0000 --_002_B17A6910EEDD1F45980687268941550F0623EEE6MISOUT7MSGUSR9I_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The challenge I have had with NVO3 is determining the focus of the group. T= he message I have gotten is that it is solely focused on overlay technology= not on how it will be used outside of a single data center. There is a not= ion that some device will speak overlay technology and 2547 and this will b= e the GW but that is about it..This of course leads us to solutions which a= re at best myopic. So where do we capture the reqs that reflect the VPN in = the data center as part of a greater whole? This includes items like stitch= ing but also security, protocol definition, GW etc... I have attached my di= scussion thread with folks from earlier this year. At the time I was hoping= to create a reqs document that would address my biggest use case which is = extending a WAN VPN into a Data Center.. I would like to pursue this. Jim Uttaro -----Original Message----- From: Somesh Gupta [mailto:someshg@brocade.com]=20 Sent: Tuesday, July 23, 2013 7:06 PM To: UTTARO, JAMES; Yakov Rekhter Cc: Lucy yong; Aldrin Isaac; Kireeti Kompella; thomas.morin@orange.com; L3V= PN; nvo3@ietf.org; Xuxiaohu; Luyuan Fang (lufang) Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn=20 Jim, I agree with you on the need to support services spanning multiple "domains". If that is the focus of the group, then of course, distributed control plane makes sense. Somesh > -----Original Message----- > From: UTTARO, JAMES [mailto:ju1738@att.com] > Sent: Tuesday, July 23, 2013 3:56 PM > To: Somesh Gupta; Yakov Rekhter > Cc: Lucy yong; Aldrin Isaac; Kireeti Kompella; thomas.morin@orange.com; > L3VPN; nvo3@ietf.org; Xuxiaohu; Luyuan Fang (lufang) > Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs .= .. for > l3vpn > > Somesh, > > IMO one of the bigger use cases is "stitching" between data center > and WAN and data center 1 and data center 2 instances of a given VPN. > These two CUGs are not orthogonal, this is where it is important to defin= e > the services that will utilize the technology. > > Jim Uttaro > > -----Original Message----- > From: Somesh Gupta [mailto:someshg@brocade.com] > Sent: Tuesday, July 23, 2013 6:38 PM > To: Yakov Rekhter > Cc: Lucy yong; Aldrin Isaac; Kireeti Kompella; thomas.morin@orange.com; > L3VPN; nvo3@ietf.org; Xuxiaohu; Luyuan Fang (lufang); UTTARO, JAMES > Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs .= .. for > l3vpn > > Yaakov, > > I thought we were discussing virtual overlay networks (not VPNs) as relat= ed > to virtualized data centers (maybe I assumed incorrectly). > > From whatever I see from the vendors of these products, they seem to be > shipping/moving towards centralized control plane. > > > -----Original Message----- > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > Sent: Tuesday, July 23, 2013 3:29 PM > > To: Somesh Gupta > > Cc: Lucy yong; Aldrin Isaac; Kireeti Kompella; thomas.morin@orange.com; > > L3VPN; Yakov Rekhter; nvo3@ietf.org; Xuxiaohu; Luyuan Fang (lufang); > > UTTARO, JAMES > > Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs= ... for > > l3vpn > > > > Somesh, > > > > > A centralized architecture for a single domain is the way things > > > will be in practice (already are). > > > > We can all speculate about how "the things will be in practice". > > > > However, in terms of how things "already are", 2547 VPNs, which are > widely > > deployed today, are *not* based on "a centralized architecture". > > > > Yakov. > > > > > One way or the other, non-virtualized > > > network devices (physical switches etc) will have to fit into that > > > model. > > > > > > Now we can debate the definition of a domain is :) It may > > > be defined by the scope of a centralized control plane? > > > > > > Somesh > > > > > > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf > > Of Luc=3D > > > y yong > > > Sent: Tuesday, July 23, 2013 8:15 AM > > > To: Aldrin Isaac; Kireeti Kompella > > > Cc: thomas.morin@orange.com; L3VPN; Yakov Rekhter; nvo3@ietf.org; > > Xuxiaohu;=3D > > > Luyuan Fang (lufang); UTTARO, JAMES > > > Subject: Re: [nvo3] The possibility of using global MPLS labels as VN= Is ...=3D > > > for l3vpn > > > > > > For distributed based architecture, the local context ID has a lot of= benef=3D > > > its. For centralized (or SDN) architecture, will the global context I= D have=3D > > > advance? Another way to ask this is: is distributed architecture be= tter t=3D > > > han centralized architecture for VPN or virtual network overlay? > > > > > > Lucy > > > > > > From: nvo3-bounces@ietf.org > > [mailto:nvo3-boun=3D > > > ces@ietf.org] On Behalf Of Aldrin Isaac > > > Sent: Tuesday, July 23, 2013 8:00 AM > > > To: Kireeti Kompella > > > Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; > > nvo3@ietf.org > > etf.org>; Xuxiaohu; > > thomas.morin@orange.com=3D > > > ; UTTARO, JAMES > > > Subject: Re: [nvo3] The possibility of using global MPLS labels as VN= Is ...=3D > > > for l3vpn > > > > > > +1. > > > > > > Network operators lose flexibility with Global VNIDs. Virtual topolog= y > will=3D > > > be fine tuned on top of VNIDs by squeezing a square peg (ACLs) into = a > > roun=3D > > > d hole (where it's otherwise not needed). I think local context IDs = will m=3D > > > ake a come back once we regain our sanity. :). > > > > > > On Tuesday, July 23, 2013, Kireeti Kompella wrote: > > > Hi Xuxiaohu, > > > > > > Sorry for the previous empty email. > > > > > > On Jul 23, 2013, at 4:51, Xuxiaohu = > > > wrot=3D > > > e: > > > > > > > The reason that I started this discussion is to make sure whether t= he > Vir=3D > > > tual Network Context Identification contained in the data packet is > REALLY > > =3D > > > required to be globally unique in some cases. > > > > > > No. There's nothing useful that I know that one can do with global ID= s in > t=3D > > > he data plane that one cannot do with local IDs, and local IDs are ea= sier t=3D > > > o allocate and manage. So, I'd be going the other way and advocate > locally > > =3D > > > significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And = I > do) > > > > > > Kireeti > > > _______________________________________________ > > > nvo3 mailing list > > > nvo3@ietf.org > > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > > -- > > > _000_BB8D8AEC7DBA1F41810DCB5D38AF56ABA3B78814C8HQ1EXCH02corp_ > > > Content-Type: text/html; charset=3D"us-ascii" > > > Content-Transfer-Encoding: quoted-printable > > > > > > > xmlns:o=3D3D"urn:schemas-micr=3D > > > osoft-com:office:office" xmlns:w=3D3D"urn:schemas-microsoft- > > com:office:word" =3D > > > xmlns:m=3D3D"http://schemas.microsoft.com/office/2004/12/omml" > > xmlns=3D3D"http:=3D > > > //www.w3.org/TR/REC-html40"> EQUIV=3D3D"Content- > > Type" CONTENT=3D > > > =3D3D"text/html; charset=3D3Dus-ascii"> > content=3D3D"Micros=3D > > > oft Word 14 (filtered medium)"> > link=3D3Dblue vli=3D > > > nk=3D3Dpurple>

class=3D3DMsoNormal> > style=3D3D'f=3D > > > ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>A > central=3D > > > ized architecture for a single domain is the way > > things > > p>

> family:"Calibri=3D > > > ","sans-serif";color:#1F497D'>will be in practice (already are). One = way > or=3D > > > the other, non-virtualized

> class=3D3DMsoNormal> > > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans- > serif";color:#1F497D=3D > > > '>network devices (physical switches etc) will have to fit into > that > > o:p>

> size:11.0pt;font-fa=3D > > > mily:"Calibri","sans- > > serif";color:#1F497D'>model.

> > lass=3D3DMsoNormal> > family:"Calibri","san=3D > > > s-serif";color:#1F497D'> 

> class=3D3DMsoNormal> > > pan style=3D3D'font-size:11.0pt;font-family:"Calibri","sans- > serif";color:#1F4=3D > > > 97D'>Now we can debate the definition of a domain is > style=3D3D'=3D > > > font-size:11.0pt;font-family:Wingdings;color:#1F497D'>J > style=3D > > > =3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F49= 7D'> It =3D > > > may

> style=3D3D'font-size:11.0=3D > > > pt;font-family:"Calibri","sans-serif";color:#1F497D'>be defined by th= e > > scop=3D > > > e of a centralized control plane?

> class=3D3DMsoNormal=3D > > > > serif";color:#=3D > > > 1F497D'> 

> style=3D3D'fon=3D > > > t-size:11.0pt;font-family:"Calibri","sans- > > serif";color:#1F497D'>Somesh=3D > > >

> size:11.0pt;font-=3D > > > family:"Calibri","sans- > > serif";color:#1F497D'> 

> > iv style=3D3D'border:none;border-left:solid blue 1.5pt;padding:0in 0i= n 0in > 4.=3D > > > 0pt'>
> 1.0pt;padding:=3D > > > 3.0pt 0in 0in 0in'>

> size:10.0pt;=3D > > > font-family:"Tahoma","sans-serif"'>From: > style=3D3D'font-size=3D > > > :10.0pt;font-family:"Tahoma","sans-serif"'> nvo3-bounces@ietf.org > > [mailto:n=3D > > > vo3-bounces@ietf.org] On Behalf Of Lucy > yong
Sent: > > Tuesday=3D > > > , July 23, 2013 8:15 AM
To: Aldrin Isaac; Kireeti > > Kompella
=3D > > > Cc: thomas.morin@orange.com; L3VPN; Yakov Rekhter; > > nvo3@ietf.org; Xuxia=3D > > > ohu; Luyuan Fang (lufang); UTTARO, JAMES
Subject: Re: > > [nvo3] The =3D > > > possibility of using global MPLS labels as VNIs ... for > l3vpn > > pan>

> class=3D3DMsoNormal> 

> > oNormal> > serif";=3D > > > color:#1F497D'>For distributed based architecture, the local context = ID > > has=3D > > > a lot of benefits. For centralized (or SDN) architecture, will the g= lobal =3D > > > context ID have advance?  Another way to ask this is: is distrib= uted > > a=3D > > > rchitecture better than centralized architecture for VPN or virtual > network=3D > > > overlay?

> style=3D3D'font-siz=3D > > > e:11.0pt;font-family:"Calibri","sans- > > serif";color:#1F497D'>  > > >

> size:11.0pt;font-famil=3D > > > y:"Calibri","sans-serif";color:#1F497D'>Lucy

> class=3D > > > =3D3DMsoNormal> > family:"Calibri","sans-se=3D > > > rif";color:#1F497D'> 

> style=3D3D'border:none;b=3D > > > order-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
style=3D3D'b=3D > > > order:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>=

> cla=3D > > > ss=3D3DMsoNormal> > family:"Tahoma","san=3D > > > s-serif"'>From: > family:"Taho=3D > > > ma","sans-serif"'> nvo3- > > bounces@ie=3D > > > tf.org [mailto:nvo3- > > bounces@ie=3D > > > tf.org] On Behalf Of Aldrin Isaac
Sent: Tuesday, > > July =3D > > > 23, 2013 8:00 AM
To: Kireeti Kompella
Cc: > Luyuan > > Fang (=3D > > > lufang); L3VPN; Yakov Rekhter; > href=3D3D"mailto:nvo3@ietf.org">nvo3@ietf.o=3D > > > rg; Xuxiaohu; > href=3D3D"mailto:thomas.morin@orange.com">thomas.morin@o=3D > > > range.com; UTTARO, JAMES
Subject: Re: [nvo3] The > > possibility =3D > > > of using global MPLS labels as VNIs ... for > > l3vpn

> > v>

 

> class=3D3DMsoNormal>+1.<=3D > > > o:p>

> class=3D3DMsoNormal> 

> > class=3D3DMsoNormal>Network operators lose flexibility with Glob= al > > VNIDs=3D > > > . Virtual topology will be fine tuned on top of VNIDs > > by&nbs=3D > > > p;squeezing a square peg (ACLs) into a round hole (where it's otherwi= se > > not=3D > > > needed).  I think local context IDs will make a come back > once > > w=3D > > > e regain our sanity.  :).

> class=3D3DMso=3D > > > Normal> 

On > > Tuesday, July 23, =3D > > > 2013, Kireeti Kompella wrote:

class=3D3DMsoNormal>Hi > > Xuxiaoh=3D > > > u,

Sorry for the previous empty email.

On Jul 23, 2013, > at > > 4:=3D > > > 51, Xuxiaohu < href=3D3D"javascript:;">xuxiaohu@huawei.com> > > wrote=3D > > > :

> The reason that I started this discussion is to make su= re > > whe=3D > > > ther the Virtual Network Context Identification contained in the data > > packe=3D > > > t is REALLY required to be globally unique in some cases.

No. > > There'=3D > > > s nothing useful that I know that one can do with global IDs in the d= ata pl=3D > > > ane that one cannot do with local IDs, and local IDs are easier to al= locate=3D > > > and manage. So, I'd be going the other way and advocate locally > significan=3D > > > t VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I > > do)

Kir=3D > > > > > > eeti
_______________________________________________
n > > vo3 mailing lis=3D > > > t
nvo3@ietf.org
> href=3D3D"https://www.i=3D > > > etf.org/mailman/listinfo/nvo3" > > target=3D3D"_blank">https://www.ietf.org/mailm=3D > > > > > > an/listinfo/nvo3

> dy> > > tml>=3D > > > > > > -- > > > _000_BB8D8AEC7DBA1F41810DCB5D38AF56ABA3B78814C8HQ1EXCH02corp_- > > - > > > --_002_B17A6910EEDD1F45980687268941550F0623EEE6MISOUT7MSGUSR9I_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Tue, 23 Jul 2013 23:24:30 GMT"; modification-date="Tue, 23 Jul 2013 23:24:30 GMT" From: "UTTARO, JAMES" To: "'Balus, Florin Stelian (Florin)'" , "'Ali Sajassi (sajassi)'" , 'John E Drake' , 'Kireeti Kompella' , "'Henderickx, Wim (Wim)'" , "'Yakov Rekhter'" , 'Rex Fernando' , "'LASSERRE, MARC (MARC)'" , 'Nabil Mobile Bitar' CC: "LONGHITANO, ANTHONY C" , "NGUYEN, HAN Q" Subject: RE: Network Controller<->NVE Communication Channel Reqs Draft Thread-Topic: Network Controller<->NVE Communication Channel Reqs Draft Thread-Index: Ac4iqc5Gd+MG+HUTRUi+P0qWI59gSAAPdkEAACZPgIAAFyc7QP///3wA///Ez3CAAEduAP/0+U6w/+OTyCD/wPPQ0P94O6lg/vAsSwD931jOYPu+E9QA92yxyIDu1gimUN2rCcWQu1L/+LD2pflhgO1LsYtg Date: Wed, 24 Apr 2013 18:03:40 +0000 Message-ID: References: In-Reply-To: Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-organization-originalclientipaddress: 135.70.240.149 x-ms-exchange-organization-originalserveripaddress: 130.9.128.254 Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F056667B0MISOUT7MSGUSR9I_" MIME-Version: 1.0 --_000_B17A6910EEDD1F45980687268941550F056667B0MISOUT7MSGUSR9I_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Florin, Here is the excerpt from Larry which IMO does not support y= our position.. "NVO3 is about overlay networks in data centers (DC VPN), w= hich could be a service provider's DC (public) or an enterprise's DC (priva= te). " The use case that I need covered is for a SP private cloud. "As far as moving forward, I would welcome requirement text that uses the N= VO3 terminology (not 2547), and keeps within the current scope of the NVO3 = charter of a single data center. What do you think?" . A VPN can span both the WAN portion and multiple VPCs. I ne= ed that use case covered.. Communication Channel between NCO<->NVE.. I think as an industry we need to create reqs for the Comm Channel.. Today = folks are using different approaches XMPP, Netconf, etc.. That is cool but = all of these must reflective of a certain set of reqs. The other part are reqs for connectivity to a VPN instance = that is in a WAN or is distributed across multiple private clouds.. "The assumption in NVO3 has been that a device that supports both an NVO3 p= rotocol within the DC (L2 or L3) and another VPN technology (e.g. 2547) fo= r over the WAN, could interwork the two." I need to have this be much more than an assumption... So, at the end of the day if NVO3 feels that these items are in the charter= then that should be clearly called out. I would love to put this all in on= e place.. It just seems that from the feedback I have received NVO3 is not = the place for it..Let me know how to proceed.. Jim Uttaro From: Balus, Florin Stelian (Florin) [mailto:florin.balus@alcatel-lucent.co= m] Sent: Wednesday, April 24, 2013 12:56 PM To: UTTARO, JAMES; 'Ali Sajassi (sajassi)'; 'John E Drake'; 'Kireeti Kompel= la'; Henderickx, Wim (Wim); 'Yakov Rekhter'; Rex Fernando; LASSERRE, MARC (= MARC); Nabil Mobile Bitar Cc: LONGHITANO, ANTHONY C; NGUYEN, HAN Q Subject: Re: Network Controller<->NVE Communication Channel Reqs Draft Jim, See in-line... From: , JAMES > Date: Wednesday, April 24, 2013 6:38 AM To: "'Ali Sajassi (sajassi)'" >= , Florin Balus >, 'John E Drake' >, 'Kireeti Kompella' >, "Henderickx, Wim (Wim)" >, 'Yakov Rekhter' >, Rex Fernando > Cc: "LONGHITANO, ANTHONY C" >, "NGUYE= N, HAN Q" > Subject: RE: Network Controller<->NVE Communication Channel Reqs Draft All, IMO the NVO3 charter and subsequent requirements draft does= not cover the following: A) Network Controller<->NVE Communication Channel I believe this is part of the charter and we eluded to it in the framework = draft: http://datatracker.ietf.org/doc/draft-ietf-nvo3-framework/?include_t= ext=3D1 . B) VPC technology i.e CUGs etc.... The term Virtual Network (VN) and associated VNI means the same thing (see = the above document). People wanted to use different terminology and we went= through a lot of unnecessarily long exchanges to get this sorted out. If t= here are differences between what you have in mind for CUG and the VN descr= iption we should address them. C) WAN<->VPC(s) If you mean here the WAN-VN interworking (GW) function we used a DC GW func= tion and some description of the required functions in the above document. = Should we expand it or dedicate a section to it? The control plane requirem= ents is another place where this can be addressed. What are some of the thoughts as to how to proceed? First o= f all should we cover all three ( A,B,C )? I am most interested in getting = ( A ) organized in the industry so IMO I think we should build a reqs docum= ent around this.. Ali had suggested extending the scope but I am not sure o= f that.. Pls Comment... I believe the fastest way is to include the A, B, C in existing docs. Thanks, Jim Uttaro From: UTTARO, JAMES Sent: Monday, April 22, 2013 10:40 AM To: UTTARO, JAMES; 'Larry Kreeger (kreeger)'; 'LASSERRE, MARC (MARC)'; 'nar= ten@us.ibm.com'; 'david.black@emc.com' Cc: Ali Sajassi (sajassi); BALUS Florin; John E Drake; Kireeti Kompella; He= nderickx, Wim (Wim); Yakov Rekhter Subject: RE: Network Controller<->NVE Communication Channel Reqs Draft Larry, TBH the scope as described below is simply too narrow for m= y purposes.. I want to create a standard for extending a traditional VPN co= ntext into one or more data centers. Inherent in this is the ability to mai= ntain the same service definition/experience when instantiating and endpoin= t in a Virtual Private Data Center.. I think that I will pursue this in ei= ther L2 or L3 WGs. As I began describing there are four main areas.. Hopefu= lly we can re-use some of the work that was done in NVO3.. Jim Uttaro From: UTTARO, JAMES Sent: Sunday, April 21, 2013 6:52 PM To: 'Larry Kreeger (kreeger)'; 'LASSERRE, MARC (MARC)'; 'narten@us.ibm.com<= mailto:'narten@us.ibm.com>'; 'david.black@emc.com' Subject: RE: Network Controller<->NVE Communication Channel Reqs Draft Larry, I am trying to figure out how to move forward.. Give me a f= ew more days to think about this... Thanks, Jim Uttaro From: Larry Kreeger (kreeger) [mailto:kreeger@cisco.com] Sent: Friday, April 19, 2013 5:37 PM To: UTTARO, JAMES; 'LASSERRE, MARC (MARC)'; 'narten@us.ibm.com'; 'david.black@emc.com' Subject: Re: Network Controller<->NVE Communication Channel Reqs Draft Hi Jim, I sent the below to you 10 days ago. I'm just making sure it didn't slip t= hrough the cracks somewhere since I didn't see a reply from you. Thanks, Larry From: Larry Kreeger > Date: Tuesday, April 9, 2013 6:30 PM To: "UTTARO, JAMES" >, "'LASSERRE, MA= RC (MARC)'" >, "'ddutt@cisco.com'" >, "'narten@us.ibm.com'"= >, David Black >, "'muraris@microsoft.com'" > Subject: Re: Network Controller<->NVE Communication Channel Reqs Draft Hi Jim, NVO3 is about overlay networks in data centers (DC VPN), which could be a s= ervice provider's DC (public) or an enterprise's DC (private). The NVO3 fr= amework document (draft-ietf-nvo3-framework-02) defines a Virtual Data Cent= er as "A container for virtualized compute, storage and network services. M= anaged by a single tenant, a Virtual DC can contain multiple VNs and multip= le Tenant Systems that are connected to one or more of these VNs.". I'm no= t sure what your definition of VPC is (e.g. does it extend outside of a phy= sical data center?), or whether it has any bearing on the requirements as y= ou see them. The assumption in NVO3 has been that a device that supports b= oth an NVO3 protocol within the DC (L2 or L3) and another VPN technology (= e.g. 2547) for over the WAN, could interwork the two. Once upon a time, there was a long discussion on the NVO3 list about the CU= G terminology. Several people felt that a CUG could be represented by the = NVO3 term Virtual Network (a virtual L2 or L3 domain - depending on the ser= vice). The thread petered out and we do not have CUG defined anywhere. As far as moving forward, I would welcome requirement text that uses the NV= O3 terminology (not 2547), and keeps within the current scope of the NVO3 c= harter of a single data center. What do you think? Thanks, Larry From: , JAMES > Date: Tuesday, April 9, 2013 7:10 AM To: Larry Kreeger >, "'LASSERRE= , MARC (MARC)'" >, "'ddutt@cisco.com'" >, "'narten@us.ibm.com'" >, David Black >, "'muraris@microsoft.com'" > Subject: RE: Network Controller<->NVE Communication Channel Reqs Draft Larry, I am mostly focuses on the VPC ( Virtual Private Cloud ) as= opposed to a VDC which may support both private and public customers.. Th= e terminology is specific to maintaining CUGs in this VPC for VPN separatio= n, I tend to write in the language of 2547 but am agnostic in terms of solu= tion.. Comments In-Line.. Jim Uttaro From: Larry Kreeger (kreeger) [mailto:kreeger@cisco.com] Sent: Monday, April 08, 2013 8:51 PM To: UTTARO, JAMES; 'LASSERRE, MARC (MARC)'; 'ddutt@cisco.com'; 'narten@us.ibm.com'; 'david.black@e= mc.com'; 'muraris@microsoft.com' Subject: Re: Network Controller<->NVE Communication Channel Reqs Draft Hi Jim, Our draft does seem related to what you are discussing below, except for a = few things. For example, in NVO3 we are being very vague about the archite= cture at the moment and not assuming that there is a "controller" or "direc= tory service" but are instead calling this the "oracle", or hopefully the n= ew name "Information Mapping Authority". The NVO3 charter is focused on in= tra-DC overlays (which the charter calls Data Center VPNs), where I see men= tion below of WAN connectivity which seems out of scope for now. I also ge= t concerned when I see mention of BGP VPN terminology like CUGs, RTs, RDs s= ince the requirements need to be independent of what the solution is (BGP m= ay be one possible solution). Other than these differences, I do see usefu= l characteristics/requirements for the NVE-to-oracle protocol in the messag= e below! [Jim U>] Agreed.. How would you want to proceed? - Larry P.S. Does "VPC" stand for "Virtual Private Cloud"? If so, we have been usi= ng the term "Virtual Data Center (VDC)". Do you see these terms as being t= he same or different? [Jim U>] Yes, the VPC implies that the customers are private in nature and = want to ensure security and traditional CUG semantic in the VPC, furthermor= e implicit is the need to connect to their traditional VPN which may span m= ultiple WAN AS domains... From: , JAMES > Date: Monday, April 8, 2013 11:31 AM To: "'LASSERRE, MARC (MARC)'" >, Larry Kreeger >, "'ddutt@cisco.com'" >, "'narten@us.ibm.com'" >, David Black >, "'muraris@microsoft.com'" > Subject: RE: Network Controller<->NVE Communication Channel Reqs Draft All, I am attempting build a reqs document in re the Network Con= troller<->NVE ( See Below )... Folks have suggested that I open this up to = include all reqs relating to a VPC ( See Below )... Marc has suggested tha= t we expand the current kreeger draft and include these areas.. Pls Comment= .. IMO I need to create reqs for the comm. Channels and also I think it wou= ld be beneficial to all to capture addl reqs in re the VPC as described bel= ow.. Thanks, Jim Uttaro From: LASSERRE, MARC (MARC) [mailto:marc.lasserre@alcatel-lucent.com] Sent: Tuesday, April 02, 2013 10:47 AM To: UTTARO, JAMES; Balus, Florin Stelian (Florin); 'Sami Boutros (sboutros)= '; Henderickx, Wim (Wim) Cc: John E Drake; Kireeti Kompella; Yakov Rekhter; Samer Salam (ssalam); Re= x Fernando (rex); Ali Sajassi (sajassi); Khandekar, Sunil S (Sunil); LONGHI= TANO, ANTHONY C; NGUYEN, HAN Q Subject: RE: Network Controller<->NVE Communication Channel Reqs Draft Hi Jim, I did not get to see Ali's email as my name got added to the cc list later = on. I'd suggest to include Larry Kreeger in this discussion - being Ali's co-wo= rker. In order to make progress, it would be a good thing to add text related to = your points below into Larry's draft since it is already an nvo3 requiremen= ts milestone draft. Thanks, Marc _____ From: UTTARO, JAMES [mailto:ju1738@att.com] Sent: Friday, March 29, 2013 5:14 PM To: LASSERRE, MARC (MARC); Balus, Florin Stelian (Florin); 'Sami Boutros= (sboutros)'; Henderickx, Wim (Wim) Cc: John E Drake; Kireeti Kompella; Yakov Rekhter; Samer Salam (ssalam);= Rex Fernando (rex); Ali Sajassi (sajassi); Khandekar, Sunil S (Sunil); LON= GHITANO, ANTHONY C; NGUYEN, HAN Q Subject: RE: Network Controller<->NVE Communication Channel Reqs Draft Marc, Let me take another read on the draft.. Do you think the= items that Ali brought up in his e-mail are covered under kreeger? If not = should they be or should another draft be created that looks at these areas= : a) Controller<->NVE communication channel b) CUG Definition c) Fabric Encapsulation d) WAN<->VPC connectivity e) Application of SDN flowspec like directives to a VM/VNIC? Sami and I = had an interesting conversation about this.. f) Creating shared extranets on the NVE ( Function of a & b )? What else? I am not religious, I started this effort concerned that we did not have= set of reqs for ( a ) if folks believe we should expand to the who sheban= g I am supportive of that in any venue.. Thanks, Jim Uttaro From: LASSERRE, MARC (MARC) [mailto:marc.lasserre@alcatel-lucent.com] Sent: Monday, March 25, 2013 10:44 AM To: Balus, Florin Stelian (Florin); UTTARO, JAMES; 'Sami Boutros (sboutr= os)'; Henderickx, Wim (Wim) Cc: John E Drake; Kireeti Kompella; Yakov Rekhter; Samer Salam (ssalam);= Rex Fernando (rex); Ali Sajassi (sajassi); Khandekar, Sunil S (Sunil); LON= GHITANO, ANTHONY C; NGUYEN, HAN Q Subject: RE: Network Controller<->NVE Communication Channel Reqs Draft Jim, Florin, I agree that draft-kreeger-nvo3-overlay-cp is the right fit for addressi= ng channel specific requirements. Including a separate section in this draft would be useful. Marc _____ From: Balus, Florin Stelian (Florin) Sent: Monday, March 18, 2013 6:18 PM To: UTTARO, JAMES; 'Sami Boutros (sboutros)'; Henderickx, Wim (Wim) Cc: John E Drake; Kireeti Kompella; Yakov Rekhter; Samer Salam (ssala= m); Rex Fernando (rex); Ali Sajassi (sajassi); Khandekar, Sunil S (Sunil); = LONGHITANO, ANTHONY C; NGUYEN, HAN Q; LASSERRE, MARC (MARC) Subject: Re: Network Controller<->NVE Communication Channel Reqs Draf= t No the draft below is data plane requirements. I was talking about th= e following draft where this might fit: http://datatracker.ietf.org/doc/draft-kreeger-nvo3-overlay-cp/?includ= e_text=3D1 (There are others I might have missed see at http://datatracker.ietf.= org/wg/nvo3/ ....) This draft in my opinion needs your text badly. :) From: , JAMES > Date: Monday, March 18, 2013 10:09 AM To: Florin Balus >, "'Sami Boutros (sboutros)'" >, "Henderickx, Wim (Wim)" > Cc: John E Drake >, Kir= eeti Kompella >, Yakov Rekh= ter >, "Samer Salam (ssalam)" <= ssalam@cisco.com>, "Rex Fernando (rex)" >, "Ali Sajassi (sajassi)" >, "Khandekar, Sunil S (Sunil)" >, "LONGHITANO, AN= THONY C" >, "NGUYEN, HAN Q" >, "LASSERRE, MARC (MARC)" > Subject: RE: Network Controller<->NVE Communication Channel Reqs Draf= t Florin, I think the draft you are referencing is: http://tools.ietf.org/html/draft-bl-nvo3-dataplane-re= quirements-03 My thoughts is that we need to define the communicati= on channel independently of the architectural framework of an NVO.. This wi= ll allow for implementers to have a clear understanding of the reqs of the = channel independently of the data plane, OAM, GWs etc... In that regard may= be this does not belong in NVO3 but I seems the best fit.. Thanks, Jim Uttaro From: Balus, Florin Stelian (Florin) [mailto:florin.balus@alcatel-luc= ent.com] Sent: Monday, March 18, 2013 12:34 PM To: UTTARO, JAMES; 'Sami Boutros (sboutros)'; Henderickx, Wim (Wim) Cc: John E Drake; Kireeti Kompella; Yakov Rekhter; Samer Salam (ssala= m); Rex Fernando (rex); Ali Sajassi (sajassi); Khandekar, Sunil S (Sunil); = LONGHITANO, ANTHONY C; NGUYEN, HAN Q; LASSERRE, MARC (MARC) Subject: Re: Network Controller<->NVE Communication Channel Reqs Draf= t I agree. There is a draft already in place for control plane requirem= ents which will really benefit from additional operator input. From: , JAMES > Date: Monday, March 18, 2013 6:41 AM To: "'Sami Boutros (sboutros)'" >, "Henderickx, Wim (Wim)" > Cc: John E Drake >, Kir= eeti Kompella >, Yakov Rekh= ter >, "Samer Salam (ssalam)" <= ssalam@cisco.com>, "Rex Fernando (rex)" >, "Ali Sajassi (sajassi)" >, Florin Balus >, "Khandekar, Sunil S (Sunil)" >, "L= ONGHITANO, ANTHONY C" >, "NGUYEN, HAN= Q" >, "LASSERRE, MARC (MARC)" > Subject: RE: Network Controller<->NVE Communication Channel Reqs Draf= t IMO it seems that NVO3 is best suited for this effort.. Jim Uttaro From: Sami Boutros (sboutros) [mailto:sboutros@cisco.com] Sent: Sunday, March 17, 2013 5:33 PM To: Henderickx, Wim (Wim) Cc: UTTARO, JAMES; John E Drake; Kireeti Kompella; Yakov Rekhter; Sam= er Salam (ssalam); Rex Fernando (rex); Ali Sajassi (sajassi); Balus, Florin= Stelian (Florin); Khandekar, Sunil S (Sunil); LONGHITANO, ANTHONY C; NGUYE= N, HAN Q; LASSERRE, MARC (MARC) Subject: Re: Network Controller<->NVE Communication Channel Reqs Draf= t Agreed, Correcting Rex e-mail. Thanks, Sami On Mar 17, 2013, at 1:16 AM, Henderickx, Wim (Wim) wrote: Jim, this is a good start and we can start from this as a baseline. D= o you think we should progress this in NVO3? Adding Marc L. From: , JAMES > Date: Sunday 17 March 2013 01:53 To: John E Drake >, Kir= eeti Kompella >, Yakov Rekh= ter >, Wim Henderickx >, "Sami= Boutros (sboutros)" >, "(ssa= lam@cisco.com)" >, Rex Fernando >, sajassi = >, "Balus, Florin Stelian (Flor= in)" > Cc: "Khandekar, Sunil S (Sunil)" >, "LONGHITANO, ANTHONY C" >, "NGUYEN, HAN Q" > Subject: Network Controller<->NVE Communication Channel Reqs Draft All, I had a number of conversations with a bunch of you a= t the IETF this past week regarding the definition of the communication cha= nnel between the network controller and the NVE. From the presentations I h= ave seen and the meetings I have attended it is clear that this is an area = that needs definition. To that end I suggest that we pull together a reqs = draft that articulates the functionality and semantics of this communicatio= n channel.. We have had success with this approach in the past i.e EVPN Req= s, addpaths guidelines etc... Here is a first cut on my thoughts as to the = areas that need to be addressed.. I am not looking to over-constrain implem= entations but we need to define a specification.. Pls let me know if you wo= uld like to participate in this effort..I really think we need to do this b= efore we have solutions.. Pls forward if I missed anyone who you feel could= add to the effort... Functionality ( Bi-Dir Communication ) The channel needs to be able to deliver info that wil= l program the NVE.. This includes: 1) CUG Definition including RTs, RDs, VPN Label etc..= . How do know this is successful? Network Management 1) Statistics - Retrieving/Programming info. a) VM termination ? How should we precede on this is it the responsib= ility of "compute" to associate a given VM with a CUG ( Not a stats questio= n ;) )? Regardless it seems that the controller should be able to provide i= nfo as to which VMs are terminating in a CUG for network management etc... b) Server stats? We need to have this information packaged in a manne= r that is seamless to a customer.. So, if a customer is accessing stats via= OSS stack in the WAN the controller should be able to also get stats for t= he NVE and associated VMs.. i.e how is the NIC performing.. c) Customer validation ? Will customers want the ability to "Ping" th= e CUG on a server? This is a requirement for a number of managed services.. 2) Security a) Auditing. A record should be available when compute or network ass= ociates/disassociates a VM from a given CUG b) Access Control. How is access to the server controlled.. For a giv= en server there are principals whom are allowed to perform some set of oper= ations. c) Authentication. For a given NVE there are a set of network control= lers that are allowed to perform operations. How should this be done if at = all?? Routing State - The channel needs to deliver routing = state, associated semantics i.e path coloring etc and routing policy.. 1) Static a) The current thinking that I have seen revolves around programming = routing state analogous to a static route. This also includes NH Label? My= assumption is that the VPN label will be obtained by virtue of the path be= ing programmed in a given CUG 2) Dynamic a) Dynamic routing.. Assuming that the controller is also a straight = up reflector should we define the communication channel to provide the sema= ntics of a routing session? I am not sure on this but am not convinced that= it should not be precluded.. We may want to "advertise" other routing stat= e i.e dynamically build extranets for extending the SPs services into this = VPC ( SDN ).. This could of course be done via that programming method abov= e but let's be clear about what we are looking for.. Coordination Problem 1) Endpoint Failure. My assumption here is that each endpoint can fai= l and that failure is recognized.. The behavior needs to be defined as to "= what should happen" 2) Transient Failure. The communication channel itself may experience= transient failure.. What should be the behavior in terms of ensuring that = a subset of messages lost are recovered or not ? Election Problem 1) Given a system where have multiple controllers for redundancy shou= ld one of them be "elected" as the primary for all communication? Safety Property 1) Need to ensure that no "side effects" of the specification of the = communication channel are permitted that are not inherently part of the spe= cification.. IOW the domain of "effects' are bounded by the specification..= As an ex.. the communication channel may not increase memory for a given s= erver as this is the domain of "compute" or the FIFO nature of the channel = must service requests in the order of arrival. We would not want to change = the order such that a delete came prior to the add.. Liveness Property 1) The "channel" must eventually provide service to every request.. A= n example of this is that a given request must complete.. SDN Capability 1) The communication channel must be able to provide a mechanism to a= pply SDN constructs in both the data ( flow ) and control plane ( extranet = definition ).. The latter is sort of spoken about above in terms of routing= but one could imagine that SDN could also provide the ability to constrain= a CUG .. Sami and I had a long conversation as to what does flow policy mean w= hen all VMs are utilizing the same physical resources i.e NIC.. This is qui= te interesting.. This will be part 2 ;) Thanks, Jim Uttaro --_000_B17A6910EEDD1F45980687268941550F056667B0MISOUT7MSGUSR9I_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Florin,

 

   &nbs= p;            Here i= s the excerpt from Larry which IMO does not support your position..

 

           &nbs= p;    “NVO3 is about overlay networks in data centers (DC VPN), which could b= e a service provider's DC (public) or an enterprise's DC (private). “

 

The use case that I need covered is for a SP private cloud.=

 

 

“As far as moving forward, I would welcome requi= rement text that uses the NVO3 terminology (not 2547), and keeps within the= current scope of the NVO3 charter of a single data center.  What do you think?”

 

.    &n= bsp;          A VPN can span b= oth the WAN portion and multiple VPCs. I need that use case covered..<= /o:p>

 

Communication Channel between NCO<->NVE..

 

I think as an industry we need to create reqs for the Comm Channel.. T= oday folks are using different approaches XMPP, Netconf, etc.. That is cool= but all of these must reflective of  a certain set of reqs.

 

   &nbs= p;            The ot= her part are reqs for connectivity to a VPN instance that is in a WAN or is= distributed across multiple private clouds..

 

“The assumption in NVO3 has been that a device that s= upports both an NVO3 protocol within the DC  (L2 or L3) and another VPN technology (e.g. 2547) for over the WAN, could inte= rwork the two.”<= /span>

 

 

   &nbs= p;            I need= to have this be much more than an assumption…

 

So, at the end of the day if NVO3 feels that these items are in the ch= arter then that should be clearly called out. I would love to put this all = in one place.. It just seems that from the feedback I have received NVO3 is not the place for it..Let me know how= to proceed..

 

Jim Uttaro<= /span>

From: Balus, F= lorin Stelian (Florin) [mailto:florin.balus@alcatel-lucent.com]
Sent: Wednesday, April 24, 2013 12:56 PM
To: UTTARO, JAMES; 'Ali Sajassi (sajassi)'; 'John E Drake'; 'Kireeti= Kompella'; Henderickx, Wim (Wim); 'Yakov Rekhter'; Rex Fernando; LASSERRE,= MARC (MARC); Nabil Mobile Bitar
Cc: LONGHITANO, ANTHONY C; NGUYEN, HAN Q
Subject: Re: Network Controller<->NVE Communication Channel Re= qs Draft

 

Jim,

See in-= line…

&n= bsp;

From: <UTTARO>, JAMES <ju1738@att.com>
Date: Wednesday, April 24, 2013 6:38 AM
To: "'Ali Sajassi (sajassi)'" <sajassi@cisco.com>, Florin Balus <florin.balus@alcatel-lucent.com>, '= John E Drake' <jdrake@juniper.net<= /a>>, 'Kireeti Kompella' <kire= eti@contrailsystems.com>, "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-luc= ent.com>, 'Yakov Rekhter' <y= akov@juniper.net>, Rex Fernando <rex@juniper.net>= ;
Cc: "LONGHITANO, ANTHONY C" <al1457@att.com>, "NGUYEN, HAN Q" <hnguyen@att.com>
Subject: RE: Network Controller<->NVE Communication Channel Re= qs Draft

&n= bsp;

All,

 

   &nbs= p;            IMO th= e NVO3 charter and subsequent requirements draft does not cover the followi= ng:

 

   &nbs= p;            A) Net= work Controller<->NVE Communication Channel

&n= bsp;

I belie= ve this is part of the charter and we eluded to it in the framework draft:&= nbsp;http://datatracker.ietf.org/doc/draft-ietf-nvo3-framework= /?include_text=3D1 . 

 

   &nbs= p;            B) VPC= technology i.e CUGs etc….

&n= bsp;

The ter= m Virtual Network (VN) and associated VNI means the same thing (see the abo= ve document). People wanted to use different terminology and we went throug= h a lot of unnecessarily long exchanges to get this sorted out. If there are differences between what you have in = mind for CUG and the VN description we should address them.

 

   &nbs= p;            C) WAN= <->VPC(s)

&n= bsp;

If you = mean here the WAN-VN interworking (GW) function we used a DC GW function an= d some description of the required functions in the above document. Should = we expand it or dedicate a section to it? The control plane requirements is another place where this can be addr= essed.

 

   &nbs= p;            What a= re some of the thoughts as to how to proceed? First of all should we cover = all three ( A,B,C )? I am most interested in getting ( A ) organized in the= industry so IMO I think we should build a reqs document around this.. Ali had suggested extending the scope but I = am not sure of that.. Pls Comment…=

&n= bsp;

I belie= ve the fastest way is to include the A, B, C in existing docs. 

 

 

Thanks,

   &nbs= p;            Jim Ut= taro

 

   &nbs= p;           

 

From: UTTARO, JAMES
Sent: Monday, April 22, 2013 10:40 AM
To: UTTARO, JAMES; 'Larry Kreeger (kreeger)'; 'LASSERRE, MARC (MARC)= '; 'narten@us.ibm.com'; 'david.bla= ck@emc.com'
Cc: Ali Sajassi (sajassi); BALUS Florin; John E Drake; Kireeti Kompe= lla; Henderickx, Wim (Wim); Yakov Rekhter
Subject: RE: Network Controller<->NVE Communication Channel Re= qs Draft

 =

Larry,

 

   &nbs= p;            TBH th= e scope as described below is simply too narrow for my purposes.. I want to= create a standard for extending a traditional VPN context into one or more= data centers. Inherent in this is the ability to maintain the same service definition/experience when instantiat= ing and endpoint in a Virtual Private Data Center..  I think that I wi= ll pursue this in either L2 or L3 WGs. As I began describing there are four= main areas.. Hopefully we can re-use some of the work that was done in NVO3..

 

Jim Uttaro

 

From: UTTARO, JAMES
Sent: Sunday, April 21, 2013 6:52 PM
To: 'Larry Kreeger (kreeger)'; 'LASSERRE, MARC (MARC)'; 'narten@us.ibm.com'; 'david.bla= ck@emc.com'
Subject: RE: Network Controller<->NVE Communication Channel Re= qs Draft

 =

Larry,

 

   &nbs= p;            I am t= rying to figure out how to move forward.. Give me a few more days to think = about this…

 

Thanks,

   &nbs= p;            Jim Ut= taro

 

From: Larry Kreeger (kreeger) [mailto:kreeger@cisco.com]
Sent: Friday, April 19, 2013 5:37 PM
To: UTTARO, JAMES; 'LASSERRE, MARC (MARC)'; 'narten@us.ibm.com'; 'david.bla= ck@emc.com'
Subject: Re: Network Controller<->NVE Communication Channel Re= qs Draft

 =

Hi Jim,=

 <= /span>

I sent = the below to you 10 days ago.  I'm just making sure it didn't slip thr= ough the cracks somewhere since I didn't see a reply from you.

 <= /span>

Thanks,= Larry

 <= /span>

From: Larry Kreeger <kreeger@cisco.com>
Date: Tuesday, April 9, 2013 6:30 PM
To: "UTTARO, JAMES" <= ju1738@att.com>, "'LASSERRE, MARC (MARC)'" <marc.lasserre@alcatel-lucent.com>, "'ddutt@cisco.com'&quo= t; <ddutt@cisco.com>, "'narten@us.ibm.com'" = <narten@us.ibm.com>, David B= lack <david.black@emc.com>= , "'muraris@microsoft.com'" <muraris@microsoft.com>=
Subject: Re: Network Controller<->NVE Communication Channel Re= qs Draft

 <= /span>

Hi Jim,=

 <= /span>

NVO3 is= about overlay networks in data centers (DC VPN), which could be a service = provider's DC (public) or an enterprise's DC (private).  The NVO3 fram= ework document (draft-ietf-nvo3-framework-02) defines a Virtual Data Center as "A container for virtualized compute= , storage and network services. Managed by a single tenant, a Virtual DC ca= n contain multiple VNs and multiple Tenant Systems that are connected to on= e or more of these VNs.".  I'm not sure what your definition of VPC is (e.g. does it extend outside of a physical = data center?), or whether it has any bearing on the requirements as you see= them.  The assumption in NVO3 has be= en that a device that supports both an NVO3 protocol within the DC  (L2 or L3) and another VPN technology (e= .g. 2547) for over the WAN, could interwork the two.

 <= /span>

Once up= on a time, there was a long discussion on the NVO3 list about the CUG termi= nology.  Several people felt that a CUG could be represented by the NV= O3 term Virtual Network (a virtual L2 or L3 domain – depending on the service).  The thread petered out = and we do not have CUG defined anywhere.=

 <= /span>

As far = as moving forward, I would welcome requirement text that uses the NVO3 term= inology (not 2547), and keeps within the current scope of the NVO3 charter = of a single data center.  What do you think?

 <= /span>

Thanks,= Larry

 <= /span>

From: <UTTARO>, JAMES <ju1738@att.com>
Date: Tuesday, April 9, 2013 7:10 AM
To: Larry Kreeger <kreeger@c= isco.com>, "'LASSERRE, MARC (MARC)'" <marc.lasserre@alcatel-lucent.com>= , "'ddutt@cisco.com'" <ddutt@cisco.com>, "'narten@us.ibm.com'" <narten@us.ibm.com>, David Black <david.black@emc.com>, "'muraris@microsoft.com'" <muraris@microsoft.com>=
Subject: RE: Network Controller<->NVE Communication Channel Re= qs Draft

 <= /span>

Larry,

 

   &nbs= p;            I am m= ostly focuses on the VPC ( Virtual Private Cloud ) as opposed to a VDC whic= h may support both private and public customers..  The terminology is = specific to maintaining CUGs in this VPC for VPN separation, I tend to write in the language of 2547 but am agnosti= c in terms of solution..

 

Comments In-Line..

 

Jim Uttaro

 

From: Larry Kreeger (kreeger) [mailto:kreeger@cisco.com]
Sent: Monday, April 08, 2013 8:51 PM
To: UTTARO, JAMES; 'LASSERRE, MARC (MARC)'; 'ddutt@cisco.com'; 'narten@us.ibm= .com'; 'david.black@emc.com'; 'muraris@microsoft.com'
Subject: Re: Network Controller<->NVE Communication Channel Re= qs Draft

 =

Hi Jim,=

 <= /span>

Our dra= ft does seem related to what you are discussing below, except for a few thi= ngs.  For example, in NVO3 we are being very vague about the architect= ure at the moment and not assuming that there is a "controller" or "directory service" but are inste= ad calling this the "oracle", or hopefully the new name "Inf= ormation Mapping Authority".  The NVO3 charter is focused on intr= a-DC overlays (which the charter calls Data Center VPNs), where I see menti= on below of WAN connectivity which seems out of scope for now.  I also g= et concerned when I see mention of BGP VPN terminology like CUGs, RTs, RDs = since the requirements need to be independent of what the solution is (BGP = may be one possible solution).  Other than these differences, I do see useful characteristics/requirements for t= he NVE-to-oracle protocol in the message below!

[Jim U>] Agre= ed.. How would you want to proceed?

 <= /span>

 -= Larry

 <= /span>

P.S. Do= es "VPC" stand for "Virtual Private Cloud"?  If so= , we have been using the term "Virtual Data Center (VDC)".  = Do you see these terms as being the same or different?

[Jim U>] Yes,= the VPC implies that the customers are private in nature and want to ensur= e security and traditional CUG semantic in the VPC, furthermore implicit is= the need to connect to their traditional VPN which may span multiple WAN AS domains…

 <= /span>

 <= /span>

From: <UTTARO>, JAMES <ju1738@att.com>
Date: Monday, April 8, 2013 11:31 AM
To: "'LASSERRE, MARC (MARC)'" <marc.lasserre@alcatel-lucent.com>, Larry= Kreeger <kreeger@cisco.com>= , "'ddutt@cisco.com'" <ddutt@cisco.com>, "'narten@us.ibm.com'" <narten@us.ibm.com>, David Black <david.black@emc.com>, "'muraris@microsoft.com'" <muraris@microsoft.com>=
Subject: RE: Network Controller<->NVE Communication Channel Re= qs Draft

 <= /span>

All,

 

   &nbs= p;            I am a= ttempting build a reqs document in re the Network Controller<->NVE ( = See Below )… Folks have suggested that I open this up to include all = reqs relating to a VPC ( See Below )…  Marc has suggested that we expand the current kreeger draft and include these areas= .. Pls Comment.. IMO I need to create reqs for the comm. Channels and also = I think it would be beneficial to all to capture addl reqs in re the VPC as= described below..

 

Thanks,

   &nbs= p;            Jim Ut= taro

 

From: LASSERRE, MARC (MARC) [mailto:marc.lasserre@alcatel-lucent.com]
Sent: Tuesday, April 02, 2013 10:47 AM
To: UTTARO, JAMES; Balus, Florin Stelian (Florin); 'Sami Boutros (sb= outros)'; Henderickx, Wim (Wim)
Cc: John E Drake; Kireeti Kompella; Yakov Rekhter; Samer Salam (ssal= am); Rex Fernando (rex); Ali Sajassi (sajassi); Khandekar, Sunil S (Sunil);= LONGHITANO, ANTHONY C; NGUYEN, HAN Q
Subject: RE: Network Controller<->NVE Communication Channel Re= qs Draft

 =

Hi Jim,

 

I did not get to see Ali's ema= il as my name got added to the cc list later on.

I'd suggest to include Larry K= reeger in this discussion - being Ali's co-worker.

 

In order to make progress, it = would be a good thing to add text related to your points below into Larry's= draft since it is already an nvo3 requirements milestone draft.

 

Thanks,

Marc

 

From: UTTARO, JAMES [mailto:ju1738@att.com]
Sent: Friday, March 29, 2013 5:14 PM
To: LASSERRE, MARC (MARC); Balus, Florin Stelian (Florin); 'Sami Bou= tros (sboutros)'; Henderickx, Wim (Wim)
Cc: John E Drake; Kireeti Kompella; Yakov Rekhter; Samer Salam (ssal= am); Rex Fernando (rex); Ali Sajassi (sajassi); Khandekar, Sunil S (Sunil);= LONGHITANO, ANTHONY C; NGUYEN, HAN Q
Subject: RE: Network Controller<->NVE Communication Channel Re= qs Draft

Marc,

 

   &nbs= p;            Let me= take another read on the draft.. Do you think the items that Ali brought u= p in his e-mail are covered under kreeger? If not should they be or should = another draft be created that looks at these areas:

 

a) Controller<->= NVE communication channel

 

b) CUG Definition

 

c) Fabric Encapsulatio= n

 

d) WAN<->VPC con= nectivity

 

e) Application of SDN = flowspec like directives to a VM/VNIC? Sami and I had an interesting conver= sation about this..

 

f) Creating shared ext= ranets on the NVE ( Function of a & b )?

 

What else?

 

I am not religious, I = started this effort concerned that we did not have  set of reqs for ( = a ) if folks believe we should expand to the who shebang I am supportive of= that in any venue..

 

Thanks,

   &nbs= p;            Jim Ut= taro

 

From: LASSERRE, MARC (MARC) [mailto:marc.lasserre@alcatel-lucent.com]
Sent: Monday, March 25, 2013 10:44 AM
To: Balus, Florin Stelian (Florin); UTTARO, JAMES; 'Sami Boutros (sb= outros)'; Henderickx, Wim (Wim)
Cc: John E Drake; Kireeti Kompella; Yakov Rekhter; Samer Salam (ssal= am); Rex Fernando (rex); Ali Sajassi (sajassi); Khandekar, Sunil S (Sunil);= LONGHITANO, ANTHONY C; NGUYEN, HAN Q
Subject: RE: Network Controller<->NVE Communication Channel Re= qs Draft

 =

Jim, Fl= orin,

 <= /span>

I agree= that draft-kreeger-nvo3-overlay-cp is the right fit for addressing ch= annel specific requirements.<= /span>

Includi= ng a separate section in this draft would be useful.

Marc

From: Balus, Florin Stelian (Flori= n)
Sent: Monday, March 18, 2013 6:18 PM
To: UTTARO, JAMES; 'Sami Boutros (sboutros)'; Henderickx, Wim (Wim)<= br> Cc: John E Drake; Kireeti Kompella; Yakov Rekhter; Samer Salam (ssal= am); Rex Fernando (rex); Ali Sajassi (sajassi); Khandekar, Sunil S (Sunil);= LONGHITANO, ANTHONY C; NGUYEN, HAN Q; LASSERRE, MARC (MARC)
Subject: Re: Network Controller<->NVE Communication Channel Re= qs Draft

No the = draft below is data plane requirements. I was talking about the following d= raft where this might fit:

 <= /span>

(There = are others I might have missed see at http://datatracker.ietf.org/wg/nvo3/ ….)

This dr= aft in my opinion needs your text badly. :)

 <= /span>

From: <UTTARO>, JAMES <ju1738@att.com>
Date: Monday, March 18, 2013 10:09 AM
To: Florin Balus <florin.balus@alcatel-lucent.com>, "'Sami Boutros (sboutros)= '" <sboutros@cisco.com>= ;, "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>
Cc: John E Drake <jdrake@ju= niper.net>, Kireeti Kompella <kireeti@juniper.net>, Yakov Rekhter <yakov@juniper.net>, "Samer Salam (ssalam)" <ssalam@cisco.com>, "Re= x Fernando (rex)" <rex@cisco.com>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "Khandekar, Sunil S (Sunil)" &= lt;sunil.khandekar@al= catel-lucent.com>, "LONGHITANO, ANTHONY C" <al= 1457@att.com>, "NGUYEN, HAN Q" <hnguyen@att.com>, "LASSERRE, MARC (MARC)" <= marc.lasserre@alcatel-l= ucent.com>
Subject: RE: Network Controller<->NVE Communication Channel Re= qs Draft

 <= /span>

Florin,

   &nbs= p;            I thin= k the draft you are referencing is:=

   &nbs= p;            http://tools.ietf.org/html/draft-bl-nvo3-dataplane-requirements-03

   &nbs= p;            My tho= ughts is that we need to define the communication channel independently of = the architectural framework of an NVO.. This will allow for implementers to= have a clear understanding of the reqs of the channel independently of the data plane, OAM, GWs etc… In tha= t regard maybe this does not belong in NVO3 but I seems the best fit..

Thanks,

   &nbs= p;            Jim Ut= taro

From: Balus, Florin Stelian (Florin) [mailto:florin.balus@alcatel-lucent.com]
Sent: Monday, March 18, 2013 12:34 PM
To: UTTARO, JAMES; 'Sami Boutros (sboutros)'; Henderickx, Wim (Wim)<= br> Cc: John E Drake; Kireeti Kompella; Yakov Rekhter; Samer Salam (ssal= am); Rex Fernando (rex); Ali Sajassi (sajassi); Khandekar, Sunil S (Sunil);= LONGHITANO, ANTHONY C; NGUYEN, HAN Q; LASSERRE, MARC (MARC)
Subject: Re: Network Controller<->NVE Communication Channel Re= qs Draft

I agree= . There is a draft already in place for control plane requirements which wi= ll really benefit from additional operator input. 

From: <UTTARO>, JAMES <ju1738@att.com>
Date: Monday, March 18, 2013 6:41 AM
To: "'Sami Boutros (sboutros)'" <sboutros@cisco.com>, "Henderickx, Wim (Wim)&quo= t; <wim.henderickx@= alcatel-lucent.com>
Cc: John E Drake <jdrake@ju= niper.net>, Kireeti Kompella <kireeti@juniper.net>, Yakov Rekhter <yakov@juniper.net>, "Samer Salam (ssalam)" <ssalam@cisco.com>, "Re= x Fernando (rex)" <rex@cisco.com>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>, Florin Balus <florin.balus@alcatel-lucent.com>, "Khandekar, Sunil S (Sunil)" <sunil.khandekar@alcatel-lucent.com>, "LO= NGHITANO, ANTHONY C" <al1457@att.= com>, "NGUYEN, HAN Q" <hnguyen@att.com>, "LASSERRE, MARC (MARC)" <marc.lasserre@alcatel-lucent.com>
Subject: RE: Network Controller<->NVE Communication Channel Re= qs Draft

IMO it seems that NVO3= is best suited for this effort..

Jim Uttaro

From: Sami Boutros (sboutros) [mailto:sboutros@cisco.com]
Sent: Sunday, March 17, 2013 5:33 PM
To: Henderickx, Wim (Wim)
Cc: UTTARO, JAMES; John E Drake; Kireeti Kompella; Yakov Rekhter; Sa= mer Salam (ssalam); Rex Fernando (rex); Ali Sajassi (sajassi); Balus, Flori= n Stelian (Florin); Khandekar, Sunil S (Sunil); LONGHITANO, ANTHONY C; NGUY= EN, HAN Q; LASSERRE, MARC (MARC)
Subject: Re: Network Controller<->NVE Communication Channel Re= qs Draft

Agreed,

Correcting Rex e-mail.

Thanks,

Sami

On Mar 17, 2013, at 1:16= AM, Henderickx, Wim (Wim) wrote:





Jim, th= is is a good start and we can start from this as a baseline. Do you think w= e should progress this in NVO3?

Adding = Marc L.

From: <UTTARO>, JAMES <ju1738@att.com>
Date: Sunday 17 March 2013 01:53
To: John E Drake <jdrake@ju= niper.net>, Kireeti Kompella <kireeti@juniper.net>, Yakov Rekhter <yakov@juniper.net>, Wim Henderickx <wim.henderickx@alcatel-lucent.com&= gt;, "Sami Boutros (sboutros)" <sboutros@cisco.com>, "(= ssalam@cisco.com)" <ssalam@= cisco.com>, Rex Fernando <rex@= juniper.net>, sajassi <sajassi@cisco.com>= , "Balus, Florin Stelian (Florin)" <florin.balus@alcatel-lucent.com>
Cc: "Khandekar, Sunil S (Sunil)" <sunil.khandekar@alcatel-lucent.com>= , "LONGHITANO, ANTHONY C" <a= l1457@att.com>, "NGUYEN, HAN Q" <hnguyen@att.com>
Subject: Network Controller<->NVE Communication Channel Reqs D= raft

All,

    =             I had a = number of conversations with a bunch of you at the IETF this past week rega= rding the definition of the communication channel between the network contr= oller and the NVE. From the presentations I have seen and the meetings I have attended it is clear that this is an a= rea that needs  definition. To that end I suggest that we pull togethe= r a reqs draft that articulates the functionality and semantics of this com= munication channel.. We have had success with this approach in the past i.e EVPN Reqs, addpaths guidelines etc̷= 0; Here is a first cut on my thoughts as to the areas that need to be addre= ssed.. I am not looking to over-constrain implementations but we need to de= fine a specification.. Pls let me know if you would like to participate in this effort..I really think we need to= do this before we have solutions.. Pls forward if I missed anyone who you = feel could add to the effort…

Functionality ( Bi-Dir C= ommunication )

    =             The chan= nel needs to be able to deliver info that will program the NVE.. This inclu= des:

    =             &nb= sp;            =   

    =             1) CUG D= efinition including RTs, RDs, VPN Label etc… How do know this is succ= essful?

    =             Network = Management

    =             1) Stati= stics – Retrieving/Programming info.

a) VM termination ? How should we precede on this is it the responsibil= ity of “compute” to associate a given VM with a CUG ( Not a sta= ts question ;) )? Regardless it seems that the controller should be able to provide info as to which VMs are terminating in a CUG fo= r network management etc…

b) Server stats? We need to have this information packaged in a manner = that is seamless to a customer.. So, if a customer is accessing stats via O= SS stack in the WAN the controller should be able to also get stats for the NVE and associated VMs.. i.e how is the = NIC performing..

c) Customer validation ? Will customers want the ability to “Ping= ” the CUG on a server? This is a requirement for a number of managed = services..

2) Security

a) Auditing. A record should be available when compute = or network associates/disassociates a VM from a given CUG=

b) Access Control. How is access to the server controlled.. For a given= server there are principals whom are allowed to perform some set of operat= ions.

c) Authentication. For a given NVE there are a set of network controlle= rs that are allowed to perform operations. How should this be done if at al= l??

    =             Routing = State – The channel needs to deliver routing state, associated semant= ics i.e path coloring etc and routing policy..

1)  Static

a) The current thinking that I have seen revolves around programming ro= uting state analogous to a static route. This also includes NH  Label?= My assumption is that the VPN label will be obtained by virtue of the path being programmed in a given CUG<= /span>

2) Dynamic

a) Dynamic routing.. Assuming that the controller is also a straight up= reflector should we define the communication channel to provide the semant= ics of a routing session? I am not sure on this but am not convinced that it should not be precluded.. We may want= to “advertise” other routing state i.e dynamically build extra= nets for extending the SPs services into this VPC ( SDN ).. This could of c= ourse be done via that programming method above but let’s be clear about what we are looking for..=

    =             Coordina= tion Problem

1) Endpoint Failure. My assumption here is that each endpoint can fail a= nd that failure is recognized.. The behavior needs to be defined as to R= 20;what should happen”

2) Transient Failure. The communication channel itself may experience tr= ansient failure.. What should be the behavior in terms of ensuring that a s= ubset of messages lost are recovered or not ?

Election Problem

1) Given a system where have multiple controllers for redundancy should = one of them be “elected” as the primary for all communication?

Safety Property

1) Need to ensure that no “side effects” of the specificatio= n of the communication channel are permitted that are not inherently part o= f the specification.. IOW the domain of “effects’ are bounded by the specification.. As an ex.. the communication channel ma= y not increase memory for a given server as this is the domain of “co= mpute” or the FIFO nature of the channel must service requests in the= order of arrival. We would not want to change the order such that a delete came prior to the add..

Liveness Property

1) The “channel” must eventually provide service to every re= quest.. An example of this is that a given request must complete..

SDN Capability

1) The communication channel must be able to provide a mechanism to appl= y SDN constructs in both the data ( flow ) and control plane ( extranet def= inition ).. The latter is sort of spoken about above in terms of routing but one could imagine that SDN could also = provide the ability to constrain a CUG ..

Sami and I had a long conversation as to what does flow policy mean when= all VMs are utilizing the same physical resources i.e NIC.. This is quite = interesting.. This will be part 2 ;)

Thanks,

Jim Uttaro

--_000_B17A6910EEDD1F45980687268941550F056667B0MISOUT7MSGUSR9I_-- --_002_B17A6910EEDD1F45980687268941550F0623EEE6MISOUT7MSGUSR9I_-- From pthaler@broadcom.com Thu Jul 25 05:59:40 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CCC21F91C4; Thu, 25 Jul 2013 05:59:40 -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=[AWL=-0.300, 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 HFezikx81saV; Thu, 25 Jul 2013 05:59:36 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0237D21F91B4; Thu, 25 Jul 2013 05:59:35 -0700 (PDT) Received: from [10.9.208.53] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Thu, 25 Jul 2013 05:53:28 -0700 X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2 Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.14) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.1.438.0; Thu, 25 Jul 2013 05:59:30 -0700 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by SJEXCHCAS06.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Thu, 25 Jul 2013 05:59:29 -0700 From: "Pat Thaler" To: "Richard Li" , "Kireeti Kompella" , "Lucy yong" Subject: The meaning of "global" Thread-Topic: The meaning of "global" Thread-Index: Ac6JNT3ZyEBDRPOeR/qABjnqUMbKig== Date: Thu, 25 Jul 2013 12:59:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7DEFC0421R047864730-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 25 Jul 2013 06:10:01 -0700 Cc: L3VPN , Yakov Rekhter , "nvo3@ietf.org" , Aldrin Isaac , "thomas.morin@orange.com" , "UTTARO, JAMES" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 12:59:40 -0000 "Global" seems to be used in this discussion and the data plane requirement= s to mean "unique in the administrative domain" as contrasted to a "local" = identifier that is mapped to another value at some points in the domain. On the other hand, when discussing VN Name in the hyperviser - NVE control = plane, global is used in the sense that I understand global - i.e. unique i= n the world - e.g. a UUID. 24-bit identifiers aren't large enough to be glo= bal in that sense. It would be better to use another term when we mean unique in the administr= ative domain. Pat -----Original Message----- From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Ric= hard Li Sent: Tuesday, July 23, 2013 5:12 PM To: Kireeti Kompella; Lucy yong Cc: L3VPN; Yakov Rekhter; nvo3@ietf.org; Aldrin Isaac; thomas.morin@orange.= com; UTTARO, JAMES Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn We may be able to get some wisdom from VLAN where both local and global ids= are used. The global vlan id is used to build a whole "subnet" across different and m= ulti-hop Ethernet segments.=20 -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of K= ireeti Kompella Sent: Wednesday, July 24, 2013 12:46 AM To: Lucy yong Cc: thomas.morin@orange.com; L3VPN; Yakov Rekhter; nvo3@ietf.org; Aldrin Is= aac; UTTARO, JAMES Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn On Jul 23, 2013, at 19:28, Lucy yong wrote: > Like to hear more the people opinions about: in SDN approach, will global= ID and local ID are equally good (just mater choice) or one is better than= other? The SDN (centralized) approach makes allocation of global IDs easier. Howev= er, Xiaohu asked a data plane question. Local IDs are much easier for the d= ata plane. BTW, I am not in favor of centralizing everything.=20 Kireeti _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From donald.fedyk@alcatel-lucent.com Thu Jul 25 06:29:00 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17ABF21F93D4; Thu, 25 Jul 2013 06:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] 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 OcyXs4AtOj6M; Thu, 25 Jul 2013 06:28:54 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id B62C221F8C93; Thu, 25 Jul 2013 06:28:49 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6PDShc1012430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 Jul 2013 08:28:43 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r6PDSf3Z007321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jul 2013 09:28:42 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.28]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Thu, 25 Jul 2013 09:28:41 -0400 From: "Fedyk, Donald (Don)" To: Pat Thaler , Richard Li , Kireeti Kompella , Lucy yong Subject: RE: The meaning of "global" Thread-Topic: The meaning of "global" Thread-Index: Ac6JNT3ZyEBDRPOeR/qABjnqUMbKigAApyVg Date: Thu, 25 Jul 2013 13:28:40 +0000 Message-ID: <59E40B2663705C47B8C0A107CBFBA98814DE4412@US70TWXCHMBA11.zam.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: L3VPN , Yakov Rekhter , "nvo3@ietf.org" , Aldrin Isaac , "thomas.morin@orange.com" , "UTTARO, JAMES" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 13:29:00 -0000 Pat Good Point. We should refrain from global. Addresses (MAC and IP) that ar= e allocated and registered with a Number Authority are typically unique but= labels, and identifiers and even addresses with local scope can have varyi= ng degrees of uniqueness. I think some form of mapping or translation canno= t be ruled out if the packets/frames need to cross boundaries of the domain= s.=20 While this discussion has been focused on the data plane the scope of ids h= as impact on how the ids are distributed in the control and management plan= es too. Another point is in Ethernet VLAN is end to end consistent but the VID may = be local in scope.=20 Don=20 -----Original Message----- From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Pat= Thaler Sent: Thursday, July 25, 2013 8:59 AM To: Richard Li; Kireeti Kompella; Lucy yong Cc: L3VPN; Yakov Rekhter; nvo3@ietf.org; Aldrin Isaac; thomas.morin@orange.= com; UTTARO, JAMES Subject: [nvo3] The meaning of "global" "Global" seems to be used in this discussion and the data plane requirement= s to mean "unique in the administrative domain" as contrasted to a "local" = identifier that is mapped to another value at some points in the domain. On the other hand, when discussing VN Name in the hyperviser - NVE control = plane, global is used in the sense that I understand global - i.e. unique i= n the world - e.g. a UUID. 24-bit identifiers aren't large enough to be glo= bal in that sense. It would be better to use another term when we mean unique in the administr= ative domain. Pat -----Original Message----- From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Ric= hard Li Sent: Tuesday, July 23, 2013 5:12 PM To: Kireeti Kompella; Lucy yong Cc: L3VPN; Yakov Rekhter; nvo3@ietf.org; Aldrin Isaac; thomas.morin@orange.= com; UTTARO, JAMES Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn We may be able to get some wisdom from VLAN where both local and global ids= are used. The global vlan id is used to build a whole "subnet" across different and m= ulti-hop Ethernet segments.=20 -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of K= ireeti Kompella Sent: Wednesday, July 24, 2013 12:46 AM To: Lucy yong Cc: thomas.morin@orange.com; L3VPN; Yakov Rekhter; nvo3@ietf.org; Aldrin Is= aac; UTTARO, JAMES Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...= for l3vpn On Jul 23, 2013, at 19:28, Lucy yong wrote: > Like to hear more the people opinions about: in SDN approach, will global= ID and local ID are equally good (just mater choice) or one is better than= other? The SDN (centralized) approach makes allocation of global IDs easier. Howev= er, Xiaohu asked a data plane question. Local IDs are much easier for the d= ata plane. BTW, I am not in favor of centralizing everything.=20 Kireeti _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From kurtw@juniper.net Thu Jul 25 18:06:30 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1167D21F9034; Thu, 25 Jul 2013 18:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.489 X-Spam-Level: * X-Spam-Status: No, score=1.489 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, SARE_SUB_6CONS_WORD=0.356, UNRESOLVED_TEMPLATE=3.132] 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 WlF2XDFzVyfO; Thu, 25 Jul 2013 18:06:23 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0253.outbound.messaging.microsoft.com [213.199.154.253]) by ietfa.amsl.com (Postfix) with ESMTP id 993F921F9005; Thu, 25 Jul 2013 18:06:20 -0700 (PDT) Received: from mail138-db9-R.bigfish.com (10.174.16.242) by DB9EHSOBE002.bigfish.com (10.174.14.65) with Microsoft SMTP Server id 14.1.225.22; Fri, 26 Jul 2013 01:06:18 +0000 Received: from mail138-db9 (localhost [127.0.0.1]) by mail138-db9-R.bigfish.com (Postfix) with ESMTP id 6AF834001BC; Fri, 26 Jul 2013 01:06:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zz98dI9371I9feI148cI542I111aIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz1de098h1033IL1de097h8275dhz2fh2a8h683h839h946hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail138-db9: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=kurtw@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail138-db9 (localhost.localdomain [127.0.0.1]) by mail138-db9 (MessageSwitch) id 137480077619527_4249; Fri, 26 Jul 2013 01:06:16 +0000 (UTC) Received: from DB9EHSMHS006.bigfish.com (unknown [10.174.16.253]) by mail138-db9.bigfish.com (Postfix) with ESMTP id E62DE10004D; Fri, 26 Jul 2013 01:06:15 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.50) by DB9EHSMHS006.bigfish.com (10.174.14.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 26 Jul 2013 01:06:11 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMF01-SAC.jnpr.net (172.24.192.17) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 25 Jul 2013 18:06:07 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.3.146.0; Thu, 25 Jul 2013 18:06:07 -0700 Received: from CH1EHSOBE020.bigfish.com (216.32.181.182) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 25 Jul 2013 18:19:09 -0700 Received: from mail143-ch1-R.bigfish.com (10.43.68.239) by CH1EHSOBE020.bigfish.com (10.43.70.77) with Microsoft SMTP Server id 14.1.225.22; Fri, 26 Jul 2013 01:06:06 +0000 Received: from mail143-ch1 (localhost [127.0.0.1]) by mail143-ch1-R.bigfish.com (Postfix) with ESMTP id 0A0594C015D; Fri, 26 Jul 2013 01:06:06 +0000 (UTC) Received: from mail143-ch1 (localhost.localdomain [127.0.0.1]) by mail143-ch1 (MessageSwitch) id 1374800727582454_23851; Fri, 26 Jul 2013 01:05:27 +0000 (UTC) Received: from CH1EHSMHS034.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail143-ch1.bigfish.com (Postfix) with ESMTP id 7F9B8360047; Fri, 26 Jul 2013 01:05:27 +0000 (UTC) Received: from BLUPRD0511HT002.namprd05.prod.outlook.com (157.56.232.213) by CH1EHSMHS034.bigfish.com (10.43.70.34) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 26 Jul 2013 01:05:26 +0000 Received: from BLUPRD0511MB400.namprd05.prod.outlook.com ([169.254.1.78]) by BLUPRD0511HT002.namprd05.prod.outlook.com ([10.255.135.165]) with mapi id 14.16.0329.000; Fri, 26 Jul 2013 01:05:26 +0000 From: Kurt Windisch To: "erosen@cisco.com" , Pavan Kurapati Subject: RE: Comments on draft-kurapati-dynamicrp-bgpmvpn-00.txt Thread-Topic: Comments on draft-kurapati-dynamicrp-bgpmvpn-00.txt Thread-Index: AQHOcSUKs3O9E2vs5kyXkLhaaQPILJl2VZoQ Date: Fri, 26 Jul 2013 01:05:25 +0000 Message-ID: <543B206B73A1004589D6F816947517180F2644B7@BLUPRD0511MB400.namprd05.prod.outlook.com> References: <16686.1372110659@erosen-linux> In-Reply-To: <16686.1372110659@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "l3vpn@ietf.org" , "pim@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 01:06:30 -0000 Eric and Stig,=20 Sorry for the delay in responding to your excellent feedback. All of=20 your comments are very appreciated and I will try to address them as=20 best I can below. There are very good points here that can be=20 addressed in a new revision of the draft. Eric wrote: > We are wondering why the draft proposes to use a new SAFI, rather than reusing the MCAST-VPN SAFI. (=85) =20 The reason for choosing to use a new SAFI is for support of the=20 BSR routes to be negotiated by SAFI. If we were to find a way to leverage=20 end-of-rib signaling in routine sets of NLRI updates, a separate SAFI=20 would have other benefits (but see the end-of-rib comments below). Alternately, it may be possible to simply rely on implementations=20 to properly discard NLRIs of unknown types within the MCAST-VPN SAFI. > The draft seems to allow an AFI of "IPv6" to be used together with an IPv= 4 BSR address, or vice versa. (=85) =20 This is not the intent. The only intended use of "mixed" AFIs would=20 be in the "Originating PE's IP Address", which is the PE's address=20 in the service provider core and may be a different AFI than the AFI=20 of the customer network for which this SAFI is advertising BSR.=20 For consistency, we should adopt the convention of RFC 6515 here=20 as the issues are the same. We should also explicitly require that=20 the AFI of other IP addresses in the NLRIs match the AFI of the NLRI. Current language describing the possible values of "len of BSR=20 address" and other similar passages must be tightened accordingly. =20 > For RP addresses and Group addresses the draft proposes to use the "encoded" formats from the PIM spec. These formats contain an octet that identifies the address family. There should be a requirement that the address family as encoded in the "encoded format" be the same as the address family identified in the BGP Update's AFI, and that the lengths b= e appropriate for that address family. =20 Agreed. =20 > In the BGP Update, parsing would be simpler if the Length field that precedes an "encoded group format" field or an "encoded unicast address field" contains the length of that field, not the length of the address prefix that appears within the encoded format. =20 Agreed. =20 > The mention of the "VRF Route Import Extended Community" in section 4.1 should say "VRF Route Import Extended Community" or "VRF Route Import IPv= 6 Address Specific Extended Community", to cover the case of a SP with an IPv6 infrastructure. (It also needs to be made clear that this applies t= o the NLRI of sections 4.2 and 4.3 as well.) =20 Agreed. =20 > What action is to be taken if a BGP Update with an MCAST-VPN-BSR NLRI is received, but there is no BSR-BGP Path attribute? =20 Since all BGP-BSR NLRI route types must carry the BGP-BSR Path=20 attribute per the current text, I think the proper response to a route update lacking this attribute is to declare it malformed and=20 require that the NLRI be discarded without processing of its contents. =20 > It's hard to interpret phrases like "the group count for this NLRI is not set". How does one send this attribute without "setting" all its fields? Does "not set" just mean "set to zero", or does it mean only that certain fields are irrelevant to the processing of certain NLRIs. =20 While it's true that certain fields are not relevant to all NLRIs=20 (see the next comment), this language can be clarified to be "set to zero." The next comment does a nice job of defining these behaviors. =20 > The draft could use a little table to show which fields affect the processing which received NLRIs:=20 (=85) Where a particular NLRI/field combination is "No", perhaps what the draft should say is that the field MUST be ignored when processing that type of NLRI. That would allow the ignored field to carry any value, without ris= k of any interoperability problems. If one only says "SHOULD be ignored", there may be interoperability problems. =20 This is correct and the draft should adopt these excellent suggestion= s. =20 > Regarding Fragmentation Tags There don't seem to be any clear instructions as to when the fragmentatio= n tag field of the BSR-BGP attribute of a given NLRI actually needs to be changed. (=85) why can't fragmentation be entirely a local matter=20 (i.e., not communicated across the net)? =20 This is a good observation and we agree that the BSR Fragment Tag is= =20 not needed in BGP. It should be removed and the table from the previous=20 comment can also be updated accordingly. > Constructing BSMs from the Counts Suppose an ingress PE receives a BSM with 15 RP mappings for a given group. Then it receives another BSM with 15 RP mappings for that group, 10 of which are the same, and 5 of which are different. =20 It seems that if the egress PE receives "withdraw, update, withdraw, update, withdraw, update, withdraw, update, withdraw, update", it could generate five BSMs. Is our understanding correct, or are we missing something? =20 The egress PE may receive BGP NLRI updates as described above, such t= hat the counts contained in the NRLIs do not give the ability to determine complete reception of the full set of updates that came from the BSM on the ingress PE.=20 The worst-case would be that each withdraw and new update arrives in a=20 separate BGP UPDATE message, which depending on the implementation may=20 trigger BSR to attempt to generate multiple BSMs to CEs.=20 This is a worst-case scenario. The NRLI design attempts to account for=20 the full set of updates using the various counters so that it can know when it can send a complete BSM. But it must be acknowledged that the=20 update stream that you give is one in which this protocol cannot operate as well as native BSR. However, it's likely that the ingress PE would batch the individual NLRI=20 updates into a much fewer number of BGP UPDATE messages.=20 The draft could make recommendations for the implementation to process all= =20 BGP NLRI updates that it has received before generating the new BSM to=20 minimize the behavior above.=20 =20 One more point is that even if the NRLI updates arrive at the egress in=20 separate BGP UPDATE messages at different times, triggering separate=20 attempts to send BSMs, the BSR spec requires a minimum time between BSMs=20 being sent (RFC 5059 specifies BS_min_interval with default of 10sec).=20 Thus, it's likely that the second BSM would contain the updates to all=20 15 mappings and the worst-case you described is mitigated. The issue=20 then is the added delay to convergence introduced by the BS_min_interval so it is still not ideal in comparison to native BSR. > End of RIB=20 Given that there is almost always a route reflector between the ingress and egress PEs, how is the "End of RIB" marker going to be helpful in deciding when to originate a BSM? =20 Thanks for pointing this out, that is correct. Also, given tha= t=20 End of RIB implementations may differ, we will alter the draft=20 in our next version accordingly to remove it. > BS_Timeout There seems to be a problem with the following procedure from section 6.2.2 ("Missing BSM") (=85) =20 First off, I think this draft needs to clarify how it integrates with the BSR state machine in the same terms of RFC5059. The precise events and actions on the PEs needs to be specified so that it's clear how BGP events on PEs interact with the local RP-Set and PE-CE BSMs. Regarding the "Missing BSM" behavior, we need specify the following, which will revise the original text and procedures: * On the ingress PE, a timer must be run at the interval of=20 BS_Period (+ some small value to allow for jitter) such that if a BSM=20 has not been received from the local BSR, then the BSR Parameters NLRI. * On the egress PE, upon withdrawal of the BSR parameters NLRI, the PE=20 must set its BS_Timeout to be BS_Timeout - BS_Period and BSMs must not be sent while the BSR Parameters NLRI is not present. Thus, if timers are in sync and allowed jitter is small, behavior should=20 mirror what would happen in native BSR from the points of view of CEs on the egress side. However, since we cannot rely on timers being perfectly in sync, it is still possible for the egress site to retain the RPs from the missing=20 BSM for up to one BS_Period. This problem needs more thought to see if we can close this gap=20 in relation to the native BSR operations. > With regard to the sentence "As soon as the Type-1 is withdrawn, BS_Timeout period has to be started at the egress and upon its expiry, al= l the Type-2 and Type-3 entries MUST be deleted", it doesn't seem right for an egress PE to remove BGP installed routes based upon the expiry of a local timer. Yes, this should read something to the effect that when BS_Timeout expires on the egress PE, the RPs/groups discovered from the elected BSR should be removed from the local RP-Set. The BGP routes will be deleted when the ingress PE withdraws them. Thanks again for the valuable comments. We hope to produce a revisied draft in the coming weeks. Thanks again --Kurt -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of E= ric Rosen Sent: Monday, June 24, 2013 2:51 PM To: Pavan Kurapati Cc: erosen@cisco.com; l3vpn@ietf.org; pim@ietf.org Subject: Comments on draft-kurapati-dynamicrp-bgpmvpn-00.txt Stig Venaas and I have discussed draft-kurapati-dynamicrp-bgpmvpn-00.text, and together we have prepared the following set of questions and comments. - We are wondering why the draft proposes to use a new SAFI, rather than reusing the MCAST-VPN SAFI. =20 Using a new SAFI does provide a bit more freedom in designing the NLRI, but the draft sticks to the basic NLRI format of the MCAST-VPN SAFI anyway. I don't think the new SAFI would be used on a BGP session unless the MCAST-VPN SAFI is also used on that session, so why not just use the MCAST-VPN SAFI for the new route types? - The draft seems to allow an AFI of "IPv6" to be used together with an IPv= 4 BSR address, or vice versa. When using the type 1-7 routes of the MCAST-VPN SAFI, the AFI designates the address family being used by the customer. The address family being used by the service provider is inferred from the various length computations that are discussed in RFC 6515. It seems best to stick with that same convention for the new BSR route types. That would mean that the field "BSR Address" must be of the address family identified by the AFI. The address length would then have to be appropriate for that address family, or the Update would be considered malformed. On the other hand, if it were to be decided to use a new SAFI, it might make more sense to dispense with the RFC 6515 hacks altogether and explicitly encode the address family of each address. - For RP addresses and Group addresses the draft proposes to use the "encoded" formats from the PIM spec. These formats contain an octet that identifies the address family. There should be a requirement that the address family as encoded in the "encoded format" be the same as the address family identified in the BGP Update's AFI, and that the lengths b= e appropriate for that address family. - In the BGP Update, parsing would be simpler if the Length field that precedes an "encoded group format" field or an "encoded unicast address field" contains the length of that field, not the length of the address prefix that appears within the encoded format. - The mention of the "VRF Route Import Extended Community" in section 4.1 should say "VRF Route Import Extended Community" or "VRF Route Import IPv= 6 Address Specific Extended Community", to cover the case of a SP with an IPv6 infrastructure. (It also needs to be made clear that this applies t= o the NLRI of sections 4.2 and 4.3 as well.) - What action is to be taken if a BGP Update with an MCAST-VPN-BSR NLRI is received, but there is no BSR-BGP Path attribute? - It's hard to interpret phrases like "the group count for this NLRI is not set". How does one send this attribute without "setting" all its fields? Does "not set" just mean "set to zero", or does it mean only that certain fields are irrelevant to the processing of certain NLRIs. - The draft could use a little table to show which fields affect the processing which received NLRIs: NLRI FragTag RP Count Group Coun= t =20 BSR Parameters Yes No Yes =20 BSM Group Parameters Yes Yes No BSM RP Parameters Yes No No I think this table corresponds to your intentions. Where a particular NLRI/field combination is "No", perhaps what the draft should say is that the field MUST be ignored when processing that type of NLRI. That would allow the ignored field to carry any value, without ris= k of any interoperability problems. If one only says "SHOULD be ignored", there may be interoperability problems. - Regarding Fragmentation Tags There don't seem to be any clear instructions as to when the fragmentatio= n tag field of the BSR-BGP attribute of a given NLRI actually needs to be changed. As a result, it's difficult to figure out its uses. If some customer is sending fragmented BSMs every minute, one doesn't want to hav= e BGP update all its RP mappings every minute. So just when does the attribute value have to change? Hopefully not too often, or there will b= e a lot of BGP thrashing. It's difficult to understand why a fragmentation tag field is needed in t= he BSR-BGP attribute at all. The Group Count and RP Count fields are really what control when an egress PE can send a BSM. If an ingress PE doesn't advertise changes to a groups RP mappings until it has all the mappings for that group (which I think is required in BSR), why can't fragmentatio= n be entirely a local matter (i.e., not communicated across the net)? What are we missing? - Constructing BSMs from the Counts Suppose an ingress PE receives a BSM with 15 RP mappings for a given group. Then it receives another BSM with 15 RP mappings for that group, 10 of which are the same, and 5 of which are different. It seems that if the egress PE receives "withdraw, update, withdraw, update, withdraw, update, withdraw, update, withdraw, update", it could generate five BSMs. Is our understanding correct, or are we missing something? - End of RIB Given that there is almost always a route reflector between the ingress and egress PEs, how is the "End of RIB" marker going to be helpful in deciding when to originate a BSM? - BS_Timeout There seems to be a problem with the following procedure from section 6.2.2 ("Missing BSM"): "Egress PE receiving a withdrawn "BSR Parameters" route (Type-1) MUST still keep the corresponding Type-2 and Type-3 entries. However, it MUST NOT advertise the BSM to the CE without the Type-1 route present. As soon as the Type-1 is withdrawn, BS_Timeout period has to be started at the egress and upon its expiry, all the Type-2 and Type-3 entries MUST be deleted. Say the egress has generated BSM at t=3D0. At t=3D1 BS_Period expired at ingress PE and ingress PE did not get the periodic BSM. So, it withdraws type-1 (BSR Parameters). Egress PE has already generated BSM just before the type-1 withdrawal was received. The egress PE skips the next periodic BSM towards the CE. But CE is "off" by BS_Period interval by now. Once the BS_Timeout expires, egress PE removes all the type-2 and type-3 entries. CEs connected to egress PE will remove the same, a whole BS_Period later. Hence, to avoid this issue, once the BS_Timeout expires,an egress PE MUST generate a new BSM towards CE with RP hold time set to "0" for all the type-2 and type-3 entries. This will make the CEs in sinc with the the PEs. After generating the BSM, PE removes all the Type-2 and Type-3 entries as stated above. The problem is the following. The holding times of the individual RP mapping entries may be longer than the BS_Timeout. Typically if BS_Timeout fires, the remaining holding time of an RP mapping entry will be the difference between (a) its holding time as reported in the last received BSM and (b) BS_Timeout. The above seems to set the RP holding times to zero as soon as BS_Timeout expires. The problem with this is that it may cause the RP mappings to timeout before a new BSR can be elected. Perhaps the withdrawal of a BSR parameters route should trigger the transmission of a new BSM that doesn't set the RP-mapping holding times to zero, but that just reduces each RP-mapping holding time by BS_Timeout. Well, that would correct the RP-mapping holding times downstream of an egress PE, but it would also have the side effect of restarting the BS_Timeout at the routers downstream of the egress PE. S= o that doesn't seem right either. - With regard to the sentence "As soon as the Type-1 is withdrawn, BS_Timeout period has to be started at the egress and upon its expiry, al= l the Type-2 and Type-3 entries MUST be deleted", it doesn't seem right for an egress PE to remove BGP installed routes based upon the expiry of a local timer. =20 =20 =20 =20 =20 =20 =20 =20 =20 From iesg-secretary@ietf.org Fri Jul 26 03:13:58 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0670321F8616; Fri, 26 Jul 2013 03:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 Dd0yt0EXTKHp; Fri, 26 Jul 2013 03:13:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CF021F84A1; Fri, 26 Jul 2013 03:13:57 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Protocol Action: 'Virtual Hub-and-Spoke in BGP/MPLS VPNs' to Proposed Standard (draft-ietf-l3vpn-virtual-hub-08.txt) X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130726101357.27983.56768.idtracker@ietfa.amsl.com> Date: Fri, 26 Jul 2013 03:13:57 -0700 Cc: l3vpn chair , l3vpn mailing list , RFC Editor X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 10:13:58 -0000 The IESG has approved the following document: - 'Virtual Hub-and-Spoke in BGP/MPLS VPNs' (draft-ietf-l3vpn-virtual-hub-08.txt) as Proposed Standard This document is the product of the Layer 3 Virtual Private Networks Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-l3vpn-virtual-hub/ Technical Summary With BGP/MPLS VPNs, providing any-to-any connectivity among sites of a given Virtual Private Network would require each Provider Edge router that has one or more of these sites connected to it to hold all the routes of that Virtual Private Network. The approach described in this document allows to reduce the number of Provider Edge routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes. Furthermore, when Provider Edge routers use ingress replication to carry multicast traffic of VPN customers, the approach described in this document may under certain circumstances allow to reduce bandwidth inefficiency associated with ingress replication, and to redistribute the replication load among Provider Edge routers. Working Group Summary Nothing particular (There was no objection from working group contributors during adoption, not real objection during WGLC, except for one comment challenging the scope of the document but without a follow-up from the commenter). Document Quality There are no concerns about the document quality. An extensive review was done on WGLC by Eric Rosen (co-author of BGP/MPLS specifications to which these specifications relate), which were resolved after substantive changes to the document. No information has been provided related to current implementations or plans for implementations. Personnel Document Shepherd is Thomas Morin. Responsible Area Director is Stewart Bryant. From lucy.yong@huawei.com Fri Jul 26 11:26:40 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100A421F9A15; Fri, 26 Jul 2013 11:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.000, 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 3+6N9WVnZPxu; Fri, 26 Jul 2013 11:26:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5A20E21F99F6; Fri, 26 Jul 2013 11:26:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVL55559; Fri, 26 Jul 2013 18:26:25 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 26 Jul 2013 19:26:01 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 26 Jul 2013 19:26:20 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Fri, 26 Jul 2013 11:26:08 -0700 From: Lucy yong To: Pat Thaler , Richard Li , Kireeti Kompella , Lucy yong Subject: re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: Ac6JNT3ZyEBDRPOeR/qABjnqUMbKigA9mTJg Date: Fri, 26 Jul 2013 18:26:08 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4527F3FB@dfweml509-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.152.115] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: L3VPN , Yakov Rekhter , "nvo3@ietf.org" , Aldrin Isaac , "thomas.morin@orange.com" , "UTTARO, JAMES" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 18:26:40 -0000 (change back to the original subject title) For this context, the global VN ID means that the label is used as the VN i= dentifier in the data plane and is allocated per VN basis (maybe by NVA); t= he local (VN) ID means that the label is allocated by individual NVEs and o= nly has the significance for the NVE that creates it. Thus, each NVE has to= distribute the local (VN) ID to all the other NVEs that are the members of= the same VN, which requires some distributed control plane capability. The= NVE may create one local ID for a VN or several local IDs associated to a = VN. Local ID mechanism provides some flexibility to NVE in egress forwarding pr= ocess. However, if the major application of NVO3 is for the case that NVE r= esides on server, i.e. NVE and end-points resides on a same device, is this= flexibility necessary? Sometimes "flexibility" also means "complexity". Wh= en using separated NVE forwarder and NVE controller, and having SDN based N= VE controller, will local ID distribution make this solution more complex t= han using global VN ID? NVO3 requires supporting both NVE local and NVE remote. Can one solution fi= t both applications well? or we need more than one solution and let provide= rs to choose?=20 Lucy > -----Original Message----- > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of > Pat Thaler > Sent: Thursday, July 25, 2013 7:59 AM > To: Richard Li; Kireeti Kompella; Lucy yong > Cc: L3VPN; Yakov Rekhter; nvo3@ietf.org; Aldrin Isaac; > thomas.morin@orange.com; UTTARO, JAMES > Subject: [nvo3] The meaning of "global" >=20 > "Global" seems to be used in this discussion and the data plane > requirements to mean "unique in the administrative domain" as > contrasted to a "local" identifier that is mapped to another value at > some points in the domain. >=20 > On the other hand, when discussing VN Name in the hyperviser - NVE > control plane, global is used in the sense that I understand global - > i.e. unique in the world - e.g. a UUID. 24-bit identifiers aren't large > enough to be global in that sense. >=20 > It would be better to use another term when we mean unique in the > administrative domain. >=20 > Pat >=20 > -----Original Message----- > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of > Richard Li > Sent: Tuesday, July 23, 2013 5:12 PM > To: Kireeti Kompella; Lucy yong > Cc: L3VPN; Yakov Rekhter; nvo3@ietf.org; Aldrin Isaac; > thomas.morin@orange.com; UTTARO, JAMES > Subject: Re: [nvo3] The possibility of using global MPLS labels as > VNIs ... for l3vpn >=20 > We may be able to get some wisdom from VLAN where both local and global > ids are used. >=20 > The global vlan id is used to build a whole "subnet" across different > and multi-hop Ethernet segments. >=20 >=20 >=20 > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of Kireeti Kompella > Sent: Wednesday, July 24, 2013 12:46 AM > To: Lucy yong > Cc: thomas.morin@orange.com; L3VPN; Yakov Rekhter; nvo3@ietf.org; > Aldrin Isaac; UTTARO, JAMES > Subject: Re: [nvo3] The possibility of using global MPLS labels as > VNIs ... for l3vpn >=20 > On Jul 23, 2013, at 19:28, Lucy yong wrote: >=20 > > Like to hear more the people opinions about: in SDN approach, will > global ID and local ID are equally good (just mater choice) or one is > better than other? >=20 > The SDN (centralized) approach makes allocation of global IDs easier. > However, Xiaohu asked a data plane question. Local IDs are much easier > for the data plane. >=20 > BTW, I am not in favor of centralizing everything. >=20 > Kireeti > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 >=20 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From mbayramo@cisco.com Fri Jul 26 11:59:25 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CEB21F9A13; Fri, 26 Jul 2013 11:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] 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 dG7U6AauoaNJ; Fri, 26 Jul 2013 11:59:18 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8520121F99F7; Fri, 26 Jul 2013 11:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=825; q=dns/txt; s=iport; t=1374865158; x=1376074758; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Fqlg9zAW9XpQOkkmy3ctUDWidAncQ73NapUmeVnHA+U=; b=gsBQ+FQKUdXx901k8AYetYqe2/HqrFwd1TTOSSsXeHDttx+tm4JurC+a pG5RjxA0/D0xlo5O27b9ZUE3UwFvTZPPlyyaMdlJWjDFAQSdPtHDBpV/J 0AzcbmEXlrqN26zkjAdNaSB9LS05cDMSvvBvnvD2geCB4voNRAfXRrxq7 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAIvG8lGtJV2Z/2dsb2JhbABbgwaBBYJIuxaBGRZ0giQBAQEDATo/BQsCAQgYChQQIRElAgQOBQiHdgMJBrAJDYhejRWCNQIxB4MWbwOVdo4PhSaDFIIq X-IronPort-AV: E=Sophos;i="4.89,752,1367971200"; d="scan'208";a="239808104" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 26 Jul 2013 18:59:17 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6QIxH3o032678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jul 2013 18:59:17 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.26]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Fri, 26 Jul 2013 13:59:16 -0500 From: "Mustafa Bayramov (mbayramo)" To: Kireeti Kompella Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Topic: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn Thread-Index: AQHOh6e5KgStMZ029kqO3KZraBnsqplysyuAgAAB+ACAAApkgIAAAgyAgAAGN4CAAATogIAE3EKA Date: Fri, 26 Jul 2013 18:59:16 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D4527E2C4@dfweml509-mbx.china.huawei.com> <0DB8F45437AB844CBB5102F807A0AD9310469E53@xmb-rcd-x03.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D4527E309@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.57.23] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: L3VPN , Yakov Rekhter , "nvo3@ietf.org" , Aldrin Isaac , "thomas.morin@orange.com" , "UTTARO, JAMES" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 18:59:25 -0000 If it ultimate centralized yes but probably due to high availability , geo = redundancy and some other consideration you will never have completely centralized so at some point ID space need t= o be synchronized. : ) Mustafa On Jul 23, 2013, at 8:45 PM, Kireeti Kompella = wrote: > On Jul 23, 2013, at 19:28, Lucy yong wrote: >=20 >> Like to hear more the people opinions about: in SDN approach, will globa= l ID and local ID are equally good (just mater choice) or one is better tha= n other? >=20 > The SDN (centralized) approach makes allocation of global IDs easier. How= ever, Xiaohu asked a data plane question. Local IDs are much easier for the= data plane. >=20 > BTW, I am not in favor of centralizing everything.=20 >=20 > Kireeti From xuxiaohu@huawei.com Wed Jul 31 07:43:44 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9746D11E818B; Wed, 31 Jul 2013 07:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.341 X-Spam-Level: X-Spam-Status: No, score=-4.341 tagged_above=-999 required=5 tests=[AWL=1.658, 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 aUuyFaIZhkO3; Wed, 31 Jul 2013 07:43:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 97F9821F9EA1; Wed, 31 Jul 2013 07:43:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATY92694; Wed, 31 Jul 2013 14:43:33 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 15:43:00 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 15:43:11 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.175]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.01.0323.007; Wed, 31 Jul 2013 22:43:03 +0800 From: Xuxiaohu To: "nvo3@ietf.org" , "l3vpn@ietf.org" Subject: About gap analysis on L3VPN [RFC4365] Thread-Topic: About gap analysis on L3VPN [RFC4365] Thread-Index: AQHOjfqR4+7pITNBRkuTXoDlEf8Xag== Date: Wed, 31 Jul 2013 14:43:02 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081DABBC@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.131.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 14:43:44 -0000 Hi all, I noticed that L3VPN [RFC4365] is listed as one of the candidata technologi= es in the NVo3 gap analysis doc. However, IMHO, the current mechanism defin= ed in RFC4365 alone couldn't support VM mobility which is one of the basic = requirements of DC VPN. Hence, I believe it's much worthwhile to have an in= formational draft describing how to reuse the L3VPN mechanism for DC VPN be= fore performing gap analysis on the L3VPN technology.=20 Best regards, Xiaohu=