From david.black@emc.com Mon Apr 2 03:36:55 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E6F21F8866; Mon, 2 Apr 2012 03:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.763 X-Spam-Level: X-Spam-Status: No, score=-109.763 tagged_above=-999 required=5 tests=[AWL=0.836, 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 dJDSAg2zvuVr; Mon, 2 Apr 2012 03:36:55 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id D3B2F21F885E; Mon, 2 Apr 2012 03:36:51 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q32AanD2007186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Apr 2012 06:36:49 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Mon, 2 Apr 2012 06:36:22 -0400 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q32AaLnJ023575; Mon, 2 Apr 2012 06:36:21 -0400 Received: from mx14a.corp.emc.com ([169.254.1.70]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Mon, 2 Apr 2012 06:36:21 -0400 From: To: Date: Mon, 2 Apr 2012 06:36:19 -0400 Subject: RE: Response to some comments on IS-IS VPLS Thread-Topic: Response to some comments on IS-IS VPLS Thread-Index: AQHNDauno12B0RP+lEO1DyVa7X7/s5aBlXMQgAAXd5D//5jvgIABHOVpgAApX6KAAAtTuIAEwdXA Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80849@MX14A.corp.emc.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0CAE@szxeml525-mbs.china.huawei.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0E23@szxeml525-mbs.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0E23@szxeml525-mbs.china.huawei.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 X-EMM-MHVC: 1 X-Mailman-Approved-At: Mon, 02 Apr 2012 03:46:44 -0700 Cc: l2vpn@ietf.org, nvo3@ietf.org X-BeenThere: l2vpn@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, 02 Apr 2012 10:36:55 -0000 SmFtZXMsDQoNCkkgYmVsaWV2ZSB0aGUgc29sdXRpb24gcHJlZmVyZW5jZSBzdGFydHMgZnJvbSB0 aGlzIGJlbGllZiBhYm91dCBkYXRhIGNlbnRlciBhcmNoaXRlY3R1cmU6DQoNCj4+IEkgYmVsaWV2 ZSB0aGF0IHRoZSBkYXRhIGNlbnRlciBpcyBiZWNvbWluZyBtb3JlIGFuZCBtb3JlIGENCj4+IGR5 bmFtaWMgZXh0ZW5zaW9uIG9mIGEgY3VzdG9tZXLCuXMgbmV0d29yay4NCg0KVW5kZXIgdGhhdCBh c3N1bXB0aW9uLCBmb3IgYSBjYXJyaWVyIHdob3NlIG5ldHdvcmsgaXMgYmFzZWQgb24gbmV0d29y a2luZyB0ZWNobm9sb2dpZXMgbGlrZSBCR1AsIGV4dGVuZGluZyB0aG9zZSB0ZWNobm9sb2dpZXMg aW50byBhIGRhdGEgY2VudGVyIGlzIGEgZmluZSB0aGluZyB0byBkbywgYW5kIG5vdGhpbmcgaW4g dGhlIG52bzMgd29yayBpcyBpbnRlbmRlZCB0byBzdG9wIHRoYXQuDQoNCk9UT0gsIGZvciBhIG5v bi1jYXJyaWVyIGRhdGEgY2VudGVyIChlLmcuLCBlbnRlcnByaXNlKSwgbm90IG9ubHkgaXMgdGhl IGFib3ZlIHN0YXRlbWVudCByYXRoZXIgaW5jb3JyZWN0LCBidXQgdGhlIGVudGVycHJpc2UgbmV0 d29yayBtYXkgbm90IGJlIHJ1bm5pbmcgQkdQLiAgVGhpcyBjYW4gYmUgcGFydGljdWxhcmx5IHNv IGZvciBhIGRhdGEgY2VudGVyIHRoYXQgZGVzaXJlcyBmbGV4aWJpbGl0eSBpbiBjaG9pY2UgYW1v bmcgY2FycmllcnMsIGFuZCBoZW5jZSBvcGVyYXRlcyB1bmRlciB0aGUgcHJpbmNpcGxlIHRoYXQg b25lIG9mIHRoZSBqb2JzIG9mIHRoZSBDUEUgYm94IGlzIHRvIGtlZXAgdGhlIGNhcnJpZXIgdGVj aG5vbG9neSBvbiB0aGUgb3RoZXIgc2lkZSBpbiBvcmRlciB0byBsaW1pdCBsb2NrLWluLiAgVGhl IG52bzMgd29yayBpcyB0YXJnZXRlZCBhdCB0aGUgc29ydCBvZiB1c2UgY2FzZXMgZGVzY3JpYmVk IGluIHRoaXMgcGFyYWdyYXBoLg0KDQpUaGlzIHNvcnQgb2Ygc3Bpcml0ZWQgcHJvbW90aW9uIG9m IEJHUCBjb21lcyBhY3Jvc3MgYXMgYW4gYXR0ZW1wdCB0byBmb3JjZSBhIG9uZS1zaXplLWZpdHMt YWxsIHNvbHV0aW9uIG9uIHRob3NlIHdobyBkbyBub3QgY3VycmVudGx5IHVzZSBCR1AuICBJIGFt ICoqTk9UKiogYXJndWluZyB0aGF0IEJHUCBjYW4ndCBiZSBtYWRlIHRvIHdvcms7IEkgYW0gYXJn dWluZyB0aGF0IGl0J3MgYSBwb29yIGZpdCBmb3IgdGhlIHVzZSBjYXNlcyBvZiBpbnRlcmVzdC4N Cg0KVGhhbmtzLA0KLS1EYXZpZA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KRGF2aWQgTC4gQmxhY2ssIERpc3Rpbmd1aXNoZWQgRW5naW5lZXIN CkVNQyBDb3Jwb3JhdGlvbiwgMTc2IFNvdXRoIFN0LiwgSG9wa2ludG9uLCBNQcKgIDAxNzQ4DQor MSAoNTA4KSAyOTMtNzk1M8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBGQVg6ICsxICg1MDgpIDI5 My03Nzg2DQpkYXZpZC5ibGFja0BlbWMuY29twqDCoMKgwqDCoMKgwqAgTW9iaWxlOiArMSAoOTc4 KSAzOTQtNzc1NA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0K From ju1738@att.com Mon Apr 2 05:15:35 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BE721F8894; Mon, 2 Apr 2012 05:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 bIQzQdHMeQlk; Mon, 2 Apr 2012 05:15:34 -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 5327821F885E; Mon, 2 Apr 2012 05:15:34 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-8) with ESMTP id 668997f4.4dcb9940.201339.00-589.533265.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 02 Apr 2012 12:15:34 +0000 (UTC) X-MXL-Hash: 4f79986614a0e7ce-8a8450b81769afb52771da3873de61fb6260f5b7 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 368997f4.0.201327.00-433.533213.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 02 Apr 2012 12:15:32 +0000 (UTC) X-MXL-Hash: 4f799864366afc6a-728205ed90cc2f017f21f45a926c91bcad2b9511 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q32CFV0i026943; Mon, 2 Apr 2012 08:15:31 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q32CFOBk026908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Apr 2012 08:15:25 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by sflint02.pst.cso.att.com (RSA Interceptor); Mon, 2 Apr 2012 08:15:05 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.12]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.01.0355.002; Mon, 2 Apr 2012 08:15:05 -0400 From: "UTTARO, JAMES" To: "'david.black@emc.com'" Subject: RE: Response to some comments on IS-IS VPLS Thread-Topic: Response to some comments on IS-IS VPLS Thread-Index: AQHNDauno12B0RP+lEO1DyVa7X7/s5aBlXMQgAAXd5D//5jvgIABHOVpgAApX6KAAAtTuIAEwdXAgAAdhLA= Date: Mon, 2 Apr 2012 12:15:04 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0CAE@szxeml525-mbs.china.huawei.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0E23@szxeml525-mbs.china.huawei.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80849@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80849@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.182] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=g8Qva45Ca7EA:10 a=0cQrbQDqE-4A:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=IkcTkHD0fZMA:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=G0_B3m8xAAAA:8 a=48vgC7mUAAAA:8 a=97Hht6_H] X-AnalysisOut: [_69tTbqDWlMA:9 a=qn-2MtmieP011ETc_dIA:7 a=QEXdDO2ut3YA:10 ] X-AnalysisOut: [a=x32YNh-eXBMA:10 a=sXX8f2-lqQ8A:10 a=MuCzCmE08hAA:10 a=GM] X-AnalysisOut: [bka86qx8EA:10 a=jJ7F3QIqxRAA:10 a=2_NgnSQ5-uYA:10 a=lW_bIn] X-AnalysisOut: [UQU2sA:10 a=lZB815dzVvQA:10] Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" X-BeenThere: l2vpn@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, 02 Apr 2012 12:15:35 -0000 RGF2aWQsDQoNCglDb21tZW50cyBJbi1MaW5lLi4uDQoNClRoYW5rcywNCglKaW0gVXR0YXJvDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBkYXZpZC5ibGFja0BlbWMuY29tIFtt YWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNvbV0gDQpTZW50OiBNb25kYXksIEFwcmlsIDAyLCAyMDEy IDY6MzYgQU0NClRvOiBVVFRBUk8sIEpBTUVTDQpDYzogbDJ2cG5AaWV0Zi5vcmc7IG52bzNAaWV0 Zi5vcmcNClN1YmplY3Q6IFJFOiBSZXNwb25zZSB0byBzb21lIGNvbW1lbnRzIG9uIElTLUlTIFZQ TFMNCg0KSmFtZXMsDQoNCkkgYmVsaWV2ZSB0aGUgc29sdXRpb24gcHJlZmVyZW5jZSBzdGFydHMg ZnJvbSB0aGlzIGJlbGllZiBhYm91dCBkYXRhIGNlbnRlciBhcmNoaXRlY3R1cmU6DQoNCj4+IEkg YmVsaWV2ZSB0aGF0IHRoZSBkYXRhIGNlbnRlciBpcyBiZWNvbWluZyBtb3JlIGFuZCBtb3JlIGEN Cj4+IGR5bmFtaWMgZXh0ZW5zaW9uIG9mIGEgY3VzdG9tZXLCuXMgbmV0d29yay4NCg0KVW5kZXIg dGhhdCBhc3N1bXB0aW9uLCBmb3IgYSBjYXJyaWVyIHdob3NlIG5ldHdvcmsgaXMgYmFzZWQgb24g bmV0d29ya2luZyB0ZWNobm9sb2dpZXMgbGlrZSBCR1AsIGV4dGVuZGluZyB0aG9zZSB0ZWNobm9s b2dpZXMgaW50byBhIGRhdGEgY2VudGVyIGlzIGEgZmluZSB0aGluZyB0byBkbywgYW5kIG5vdGhp bmcgaW4gdGhlIG52bzMgd29yayBpcyBpbnRlbmRlZCB0byBzdG9wIHRoYXQuDQoNCk9UT0gsIGZv ciBhIG5vbi1jYXJyaWVyIGRhdGEgY2VudGVyIChlLmcuLCBlbnRlcnByaXNlKSwgbm90IG9ubHkg aXMgdGhlIGFib3ZlIHN0YXRlbWVudCByYXRoZXIgaW5jb3JyZWN0LCBidXQgdGhlIGVudGVycHJp c2UgbmV0d29yayBtYXkgbm90IGJlIHJ1bm5pbmcgQkdQLiAgVGhpcyBjYW4gYmUgcGFydGljdWxh cmx5IHNvIGZvciBhIGRhdGEgY2VudGVyIHRoYXQgZGVzaXJlcyBmbGV4aWJpbGl0eSBpbiBjaG9p Y2UgYW1vbmcgY2FycmllcnMsIGFuZCBoZW5jZSBvcGVyYXRlcyB1bmRlciB0aGUgcHJpbmNpcGxl IHRoYXQgb25lIG9mIHRoZSBqb2JzIG9mIHRoZSBDUEUgYm94IGlzIHRvIGtlZXAgdGhlIGNhcnJp ZXIgdGVjaG5vbG9neSBvbiB0aGUgb3RoZXIgc2lkZSBpbiBvcmRlciB0byBsaW1pdCBsb2NrLWlu LiAgVGhlIG52bzMgd29yayBpcyB0YXJnZXRlZCBhdCB0aGUgc29ydCBvZiB1c2UgY2FzZXMgZGVz Y3JpYmVkIGluIHRoaXMgcGFyYWdyYXBoLg0KW0ppbSBVPl0gU28sIGEgY291cGxlIG9mIGl0ZW1z Li4gQkdQIGlzIGEgZ2VuZXJhbCBwdXJwb3NlIHRvb2xzIHRoYXQgaXMgdXNlZCBpbiBhIHZhcmll dHkgb2YgYXBwbGljYXRpb25zIHdoZXJlIGRpc2NvdmVyeSwgZHluYW1pYyBzaWduYWxpbmcgZXRj Li4gaXMgcmVxdWlyZWQuLiBTbyBmb3IgYSBub24tY2FycmllciBkYXRhIGNlbnRlciBJIHdvdWxk IHRoaW5rIHRoYXQgdGhlIHNhbWUgcmVxcyB3b3VsZCBiZSBuZWVkZWQgZXZlbiBpZiB0aGUgc2Nv cGUgaXMgbGltaXRlZCB0byB0aGF0IHNpbmdsZSBub24tY2FycmllciBkYXRhIGNlbnRlci4uIElm IG9uZSB3ZXJlIHRvIGNvbnNpZGVyIGRlcGxveWluZyBhIHRlY2hub2xvZ3kgdG8gcmVhbGl6ZSB0 aGUgc2VydmljZSBuZWVkZWQgaXQgd291bGQgc2VlbSBwcnVkZW50IHRvIGNvbnNpZGVyIGFsbCBz b2x1dGlvbiBzcGFjZXMgYW5kIG5vdCBnZXQgY2F1Z2h0IHVwIGluIHRoZSBwZXJjZXB0aW9uIG9y IHVzIHZzLiB0aGVtIG1lbnRhbGl0eS4uIFRoZSBvdGhlciBub3Rpb24gaGVyZSBpcyB0aGF0IHVz aW5nIEJHUCBzb21laG93IHByZXZlbnRzIGlzb2xhdGlvbiBvciBsaW1pdHMgc2VsZWN0aW9uIG9m IGRpZmZlcmVudCBwcm92aWRlcnMsIG5laXRoZXIgb2YgdGhlc2UgYXNzdW1wdGlvbnMgaGF2ZSBi ZWVuIHByb3ZlbiB0byBiZSB0cnVlIGluIG90aGVyIGFwcGxpY2F0aW9ucyB0aGF0IHVzZSBCR1Au Lg0KDQpUaGlzIHNvcnQgb2Ygc3Bpcml0ZWQgcHJvbW90aW9uIG9mIEJHUCBjb21lcyBhY3Jvc3Mg YXMgYW4gYXR0ZW1wdCB0byBmb3JjZSBhIG9uZS1zaXplLWZpdHMtYWxsIHNvbHV0aW9uIG9uIHRo b3NlIHdobyBkbyBub3QgY3VycmVudGx5IHVzZSBCR1AuICBJIGFtICoqTk9UKiogYXJndWluZyB0 aGF0IEJHUCBjYW4ndCBiZSBtYWRlIHRvIHdvcms7IEkgYW0gYXJndWluZyB0aGF0IGl0J3MgYSBw b29yIGZpdCBmb3IgdGhlIHVzZSBjYXNlcyBvZiBpbnRlcmVzdC4NCltKaW0gVT5dIEkgZG8gbm90 IGFncmVlLi4gQkdQIHBlcm1pdHMgdGhlIGV2b2x1dGlvbiBvZiB0aGUgc2VydmljZXMgc3VjaCB0 aGF0IGFueSBhbmQgYWxsIGRhdGEgY2VudGVycyBjYW4gcGFydGljaXBhdGUgaW4gcHJvdmlkaW5n IHNlcnZpY2UsIGFuZCBhbnRpY2lwYXRlcyB1c2UgY2FzZXMgY3VycmVudGx5IG5vdCBjb25zaWRl cmVkIHN1Y2ggYXMgbXVsdGlwbGUgZGF0YSBjZW50ZXJzIGFjcm9zcyBjb21wYW5pZXMgcHJvdmlk aW5nIHNlcnZpY2UgZm9yIGEgZ2l2ZW4gY3VzdG9tZXIgaW4gYSBjb29wZXJhdGl2ZSBtYW5uZXIu LiBJIGRvIG5vdCBzZWUgaG93IHRoZSBzb2x1dGlvbnMgb3IgYXNzdW1wdGlvbnMgbWFkZSBpbiBO Vk8zIGNhcHR1cmUgdGhpcy4uLg0KDQpUaGFua3MsDQotLURhdmlkDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpEYXZpZCBMLiBCbGFjaywgRGlz dGluZ3Vpc2hlZCBFbmdpbmVlcg0KRU1DIENvcnBvcmF0aW9uLCAxNzYgU291dGggU3QuLCBIb3Br aW50b24sIE1BwqAgMDE3NDgNCisxICg1MDgpIDI5My03OTUzwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIEZBWDogKzEgKDUwOCkgMjkzLTc3ODYNCmRhdmlkLmJsYWNrQGVtYy5jb23CoMKgwqDCoMKg wqDCoCBNb2JpbGU6ICsxICg5NzgpIDM5NC03NzU0DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo= From sajassi@cisco.com Mon Apr 2 10:44:27 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386AB21F85C0; Mon, 2 Apr 2012 10:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 IGNkD16JHdo1; Mon, 2 Apr 2012 10:44:26 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB2C21F856A; Mon, 2 Apr 2012 10:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sajassi@cisco.com; l=950; q=dns/txt; s=iport; t=1333388665; x=1334598265; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=r1LkqZlP6xoGsc8uun6XIplTwJgp/4EEWchiO3K61Do=; b=Q1BhxeyTBGNgFzVZbqpuJNxRXc2FMJhaa5K82XxnibLKC+zGtnplb1hr dinOP1/iCEVikTKFuAdX0/w9nE/rvKAJ1fC6HOHFOY11gNhkqIlsvQdBn g2ueC4gL7hssa0C1xKmH3x52s0H3iFLc4fXtquhq0IZnZaLWtHIKoNZ7D U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscJAJ/keU+rRDoH/2dsb2JhbABFt3kCgQeCCQEBAQMBEgEnAgE8BQ0BCAmBFAEBBA4FGweHYgQBm12fBY1KgyQEiFiFKodfjkeBaIMH X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="35599168" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 02 Apr 2012 17:44:24 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q32HiPi4027220; Mon, 2 Apr 2012 17:44:25 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 10:44:24 -0700 Received: from 64.101.3.8 ([64.101.3.8]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Mon, 2 Apr 2012 17:44:24 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 02 Apr 2012 10:44:23 -0700 Subject: Re: Response to some comments on IS-IS VPLS From: sajassi To: Message-ID: Thread-Topic: Response to some comments on IS-IS VPLS Thread-Index: Ac0Q+D1MVBY1SGtI+UGEXf2JFyFtgQ== In-Reply-To: <4F758169.3070208@raszuk.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Apr 2012 17:44:24.0945 (UTC) FILETIME=[3E75BE10:01CD10F8] Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" X-BeenThere: l2vpn@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, 02 Apr 2012 17:44:27 -0000 Hi Robert, The connectivity between the two VMs is provided by L2VPN over MPLS/IP - e.g.,, VM1/VLAN1 an VM2/VLAN1 are mapped to the same L2VPN. Why do you think, the encap/decap must be done on the end-host (hypvervisor, OVS,etc.). Cheers, Ali On 3/30/12 2:48 AM, "Robert Raszuk" wrote: > Ali, > >> Third, before bashing E-VPN/PBB-EVPN, I would recommend that you >> understand what it is. > > Great point indeed. > > Could you share a pointer to the list which describes VM 1 on Host A's > hypervisor to VM 2 on host B's hypervisor interconnect model for both > above solutions just assuming that you have IP or MPLS reachability > between such hosts ? > > The requirement of my question is that any encapsulation/decapsulation > required for such interconnection should happen on the end hosts > (kernel, OVS, NIC etc ...) and not on the "network". > > Best regards, > R. > > > > From jon.hudson@gmail.com Mon Apr 2 10:46:45 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2213121F85B4; Mon, 2 Apr 2012 10:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 PpCHkRPnRg2M; Mon, 2 Apr 2012 10:46:44 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7527721F857F; Mon, 2 Apr 2012 10:46:44 -0700 (PDT) Received: by dady13 with SMTP id y13so3525027dad.27 for ; Mon, 02 Apr 2012 10:46:44 -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=WOF3KPYR+zXDMhgTZzcG0req5zjscMJYcNPtznV800k=; b=N0hoJ0CT3oNYF6/9VVpUxe0MPATY2k7wu8yHJtp0+f/U3O4xuls9skNbCNdc9PQWvI wKLYq7PIFiPJWmhI/vd/EC7u+vEDdfrR6boDLlwyxlpX980RjUyIWtVkAAKuFBIG/qde 5WNQKnZrpKrQTPKeKeoazhM3vy5h/N3gehdt3YtGd6isXyNtkhqiJpS3aOUHk6lrT4VZ HC5rDo7PrSXf1saeaWhzrMLH+J7tGA7ymxpoEPCFbOrSIwMX3uQZxVIYIkHcZ+6Vwxnn v9WA7XH+6XsYi1cxPb44oKkRunvuvz7ELBwBlLnVHncN1g16bs2VCUUmTDmJ5MWtPx58 qY0w== Received: by 10.68.204.234 with SMTP id lb10mr22028959pbc.98.1333388804208; Mon, 02 Apr 2012 10:46:44 -0700 (PDT) Received: from [10.132.129.55] ([166.205.138.76]) by mx.google.com with ESMTPS id f2sm14447687pbr.16.2012.04.02.10.46.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Apr 2012 10:46:42 -0700 (PDT) References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0CAE@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0E23@szxeml525-mbs.china.huawei.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80849@MX14A.corp.emc.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <90A28773-459A-44C3-A404-5000CFC043BC@gmail.com> X-Mailer: iPhone Mail (9B176) From: Jon Hudson Subject: Re: [nvo3] Response to some comments on IS-IS VPLS Date: Mon, 2 Apr 2012 10:45:32 -0700 To: "UTTARO, JAMES" X-Mailman-Approved-At: Mon, 02 Apr 2012 10:53:42 -0700 Cc: "l2vpn@ietf.org" , "david.black@emc.com" , "nvo3@ietf.org" X-BeenThere: l2vpn@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, 02 Apr 2012 17:46:45 -0000 I agree with David. It becomes an issue of in house knowledge and equipment budget vs whatever i= s already in place. Many Enterprise IT shops have humans that would love to learn BGP (or MPLS e= tc) but just don't have a background in it. This makes them very vendor depe= ndent for the expertise which makes some nervous. A week long BGP class does= not an expert make.=20 The second issue for some (which was brought up at the BoF) is that it's a c= ertain class of devices that have BGP support. It may be that to support BGP= new hardware needs to be acquired. I see these two issues most often as barriers to a proposal like this. J On Apr 2, 2012, at 5:15 AM, "UTTARO, JAMES" wrote: > David, >=20 > Comments In-Line... >=20 > Thanks, > Jim Uttaro >=20 > -----Original Message----- > From: david.black@emc.com [mailto:david.black@emc.com]=20 > Sent: Monday, April 02, 2012 6:36 AM > To: UTTARO, JAMES > Cc: l2vpn@ietf.org; nvo3@ietf.org > Subject: RE: Response to some comments on IS-IS VPLS >=20 > James, >=20 > I believe the solution preference starts from this belief about data cente= r architecture: >=20 >>> I believe that the data center is becoming more and more a >>> dynamic extension of a customer=C2=B9s network. >=20 > Under that assumption, for a carrier whose network is based on networking t= echnologies like BGP, extending those technologies into a data center is a f= ine thing to do, and nothing in the nvo3 work is intended to stop that. >=20 > OTOH, for a non-carrier data center (e.g., enterprise), not only is the ab= ove statement rather incorrect, but the enterprise network may not be runnin= g BGP. This can be particularly so for a data center that desires flexibili= ty in choice among carriers, and hence operates under the principle that one= of the jobs of the CPE box is to keep the carrier technology on the other s= ide in order to limit lock-in. The nvo3 work is targeted at the sort of use= cases described in this paragraph. > [Jim U>] So, a couple of items.. BGP is a general purpose tools that is us= ed in a variety of applications where discovery, dynamic signaling etc.. is r= equired.. So for a non-carrier data center I would think that the same reqs w= ould be needed even if the scope is limited to that single non-carrier data c= enter.. If one were to consider deploying a technology to realize the servic= e needed it would seem prudent to consider all solution spaces and not get c= aught up in the perception or us vs. them mentality.. The other notion here i= s that using BGP somehow prevents isolation or limits selection of different= providers, neither of these assumptions have been proven to be true in othe= r applications that use BGP.. >=20 > This sort of spirited promotion of BGP comes across as an attempt to force= a one-size-fits-all solution on those who do not currently use BGP. I am *= *NOT** arguing that BGP can't be made to work; I am arguing that it's a poor= fit for the use cases of interest. > [Jim U>] I do not agree.. BGP permits the evolution of the services such t= hat any and all data centers can participate in providing service, and antic= ipates use cases currently not considered such as multiple data centers acro= ss companies providing service for a given customer in a cooperative manner.= . I do not see how the solutions or assumptions made in NVO3 capture this...= >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From jon.hudson@gmail.com Mon Apr 2 10:58:04 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B472321F8629; Mon, 2 Apr 2012 10:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 YB59HrpskyZ9; Mon, 2 Apr 2012 10:58:04 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 10A5821F85BD; Mon, 2 Apr 2012 10:58:04 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so4603657pbb.31 for ; Mon, 02 Apr 2012 10:58:03 -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=Rp88DxMPDwJh3sZ7bRjgnbretkjmvOMIBaUMzFtGKQM=; b=FbV9aNmQPFkHkWLciZhUUTrgGKVKOZL325GLptTP+02rMXfEmkd6nSvS5oqCnK18S+ F7QVBJNQ38Wxu2qBZuOrKNStMnBDXeTJBJHPUNnQKvz4dFZmKPgogngGU7LB2txdbqGN C3lKRi7Zm9f8jAeJrsXCIPbmy2s89K6/82odPBLYElClXH9iIBsik2n4AoMSk/7WFs5E FDkZafrlXR0IwR5qEmjPvRZTc706xS/foqQMGNtmvb3/Fw66kCxo2d+Pq21GEwJn/crr tsk/OjNPidz4UONQE89kZUb2snVChUwPSOqzu2aOWnS+3ZAaJPD8GvyEHIY4NvPi4pO9 lPuQ== Received: by 10.68.74.197 with SMTP id w5mr22096523pbv.129.1333389483878; Mon, 02 Apr 2012 10:58:03 -0700 (PDT) Received: from [10.100.138.174] ([144.49.131.1]) by mx.google.com with ESMTPS id f8sm14456942pbe.42.2012.04.02.10.58.02 (version=SSLv3 cipher=OTHER); Mon, 02 Apr 2012 10:58:02 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <85DCB564-1551-4B7A-B08B-DE355D3D2221@gmail.com> X-Mailer: iPhone Mail (9B176) From: Jon Hudson Subject: Re: [nvo3] Response to some comments on IS-IS VPLS Date: Mon, 2 Apr 2012 10:54:27 -0700 To: sajassi X-Mailman-Approved-At: Mon, 02 Apr 2012 10:58:54 -0700 Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" , "" X-BeenThere: l2vpn@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, 02 Apr 2012 17:58:04 -0000 In my experience it's because it would require the virtualization folks to o= pen a ticket and interact with the network team. Many want to be able to on a whim create wormholes from any hypervisor(s) to= any hypervisors(s) without dependencies on other teams that would require a= ticket, change control or approval by a steering committee. J =20 On Apr 2, 2012, at 10:44 AM, sajassi wrote: > Hi Robert, >=20 > The connectivity between the two VMs is provided by L2VPN over MPLS/IP - > e.g.,, VM1/VLAN1 an VM2/VLAN1 are mapped to the same L2VPN. Why do you > think, the encap/decap must be done on the end-host (hypvervisor, OVS,etc.= ). >=20 > Cheers, > Ali >=20 >=20 > On 3/30/12 2:48 AM, "Robert Raszuk" wrote: >=20 >> Ali, >>=20 >>> Third, before bashing E-VPN/PBB-EVPN, I would recommend that you >>> understand what it is. >>=20 >> Great point indeed. >>=20 >> Could you share a pointer to the list which describes VM 1 on Host A's >> hypervisor to VM 2 on host B's hypervisor interconnect model for both >> above solutions just assuming that you have IP or MPLS reachability >> between such hosts ? >>=20 >> The requirement of my question is that any encapsulation/decapsulation >> required for such interconnection should happen on the end hosts >> (kernel, OVS, NIC etc ...) and not on the "network". >>=20 >> Best regards, >> R. >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From prvs=9439a02467=hshah@ciena.com Mon Apr 2 11:06:45 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87E321F8618; Mon, 2 Apr 2012 11:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 P5T6yIK5Nu61; Mon, 2 Apr 2012 11:06:43 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id AC4D121F8600; Mon, 2 Apr 2012 11:06:43 -0700 (PDT) Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q32I65bH018707; Mon, 2 Apr 2012 14:06:38 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0b-00103a01.pphosted.com with ESMTP id 13yh3gg025-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 02 Apr 2012 14:06:37 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT02.ciena.com ([::1]) with mapi; Mon, 2 Apr 2012 14:06:37 -0400 From: "Shah, Himanshu" To: Jon Hudson , "UTTARO, JAMES" Date: Mon, 2 Apr 2012 14:06:34 -0400 Subject: RE: [nvo3] Response to some comments on IS-IS VPLS Thread-Topic: [nvo3] Response to some comments on IS-IS VPLS Thread-Index: Ac0Q+Z8EVSS9isKsTgCLExCBFwDxHAAAPK4Q Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0CAE@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0E23@szxeml525-mbs.china.huawei.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80849@MX14A.corp.emc.com> <90A28773-459A-44C3-A404-5000CFC043BC@gmail.com> In-Reply-To: <90A28773-459A-44C3-A404-5000CFC043BC@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.800.1017-18814.001 x-tm-as-result: No--50.270100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-04-02_03:2012-04-02, 2012-04-02, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1204020184 Cc: "l2vpn@ietf.org" , "david.black@emc.com" , "nvo3@ietf.org" X-BeenThere: l2vpn@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, 02 Apr 2012 18:06:45 -0000 SSBhZ3JlZSB3aXRoIEpvbiBhbmQgRGF2aWQuIA0KQkdQIGlzIG5vIHNtYWxsIGZlYXQgdG8gdGFr ZSB1cC4NCkNvc3QgaXMgYW5vdGhlciBmYWN0b3IgKGNhcGV4IGFuZCBvcGV4KS4NCg0KL2hpbWFu c2h1DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsMnZwbi1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvbiBI dWRzb24NClNlbnQ6IE1vbmRheSwgQXByaWwgMDIsIDIwMTIgMTo0NiBQTQ0KVG86IFVUVEFSTywg SkFNRVMNCkNjOiBsMnZwbkBpZXRmLm9yZzsgZGF2aWQuYmxhY2tAZW1jLmNvbTsgbnZvM0BpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtudm8zXSBSZXNwb25zZSB0byBzb21lIGNvbW1lbnRzIG9uIElT LUlTIFZQTFMNCg0KDQpJIGFncmVlIHdpdGggRGF2aWQuDQoNCkl0IGJlY29tZXMgYW4gaXNzdWUg b2YgaW4gaG91c2Uga25vd2xlZGdlIGFuZCBlcXVpcG1lbnQgYnVkZ2V0IHZzIHdoYXRldmVyIGlz IGFscmVhZHkgaW4gcGxhY2UuDQoNCk1hbnkgRW50ZXJwcmlzZSBJVCBzaG9wcyBoYXZlIGh1bWFu cyB0aGF0IHdvdWxkIGxvdmUgdG8gbGVhcm4gQkdQIChvciBNUExTIGV0YykgYnV0IGp1c3QgZG9u J3QgaGF2ZSBhIGJhY2tncm91bmQgaW4gaXQuIFRoaXMgbWFrZXMgdGhlbSB2ZXJ5IHZlbmRvciBk ZXBlbmRlbnQgZm9yIHRoZSBleHBlcnRpc2Ugd2hpY2ggbWFrZXMgc29tZSBuZXJ2b3VzLiBBIHdl ZWsgbG9uZyBCR1AgY2xhc3MgZG9lcyBub3QgYW4gZXhwZXJ0IG1ha2UuIA0KDQpUaGUgc2Vjb25k IGlzc3VlIGZvciBzb21lICh3aGljaCB3YXMgYnJvdWdodCB1cCBhdCB0aGUgQm9GKSBpcyB0aGF0 IGl0J3MgYSBjZXJ0YWluIGNsYXNzIG9mIGRldmljZXMgdGhhdCBoYXZlIEJHUCBzdXBwb3J0LiBJ dCBtYXkgYmUgdGhhdCB0byBzdXBwb3J0IEJHUCBuZXcgaGFyZHdhcmUgbmVlZHMgdG8gYmUgYWNx dWlyZWQuDQoNCkkgc2VlIHRoZXNlIHR3byBpc3N1ZXMgbW9zdCBvZnRlbiBhcyBiYXJyaWVycyB0 byBhIHByb3Bvc2FsIGxpa2UgdGhpcy4NCg0KSg0KDQpPbiBBcHIgMiwgMjAxMiwgYXQgNToxNSBB TSwgIlVUVEFSTywgSkFNRVMiIDxqdTE3MzhAYXR0LmNvbT4gd3JvdGU6DQoNCj4gRGF2aWQsDQo+ IA0KPiAgICBDb21tZW50cyBJbi1MaW5lLi4uDQo+IA0KPiBUaGFua3MsDQo+ICAgIEppbSBVdHRh cm8NCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGRhdmlkLmJsYWNr QGVtYy5jb20gW21haWx0bzpkYXZpZC5ibGFja0BlbWMuY29tXSANCj4gU2VudDogTW9uZGF5LCBB cHJpbCAwMiwgMjAxMiA2OjM2IEFNDQo+IFRvOiBVVFRBUk8sIEpBTUVTDQo+IENjOiBsMnZwbkBp ZXRmLm9yZzsgbnZvM0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogUmVzcG9uc2UgdG8gc29tZSBj b21tZW50cyBvbiBJUy1JUyBWUExTDQo+IA0KPiBKYW1lcywNCj4gDQo+IEkgYmVsaWV2ZSB0aGUg c29sdXRpb24gcHJlZmVyZW5jZSBzdGFydHMgZnJvbSB0aGlzIGJlbGllZiBhYm91dCBkYXRhIGNl bnRlciBhcmNoaXRlY3R1cmU6DQo+IA0KPj4+IEkgYmVsaWV2ZSB0aGF0IHRoZSBkYXRhIGNlbnRl ciBpcyBiZWNvbWluZyBtb3JlIGFuZCBtb3JlIGENCj4+PiBkeW5hbWljIGV4dGVuc2lvbiBvZiBh IGN1c3RvbWVywrlzIG5ldHdvcmsuDQo+IA0KPiBVbmRlciB0aGF0IGFzc3VtcHRpb24sIGZvciBh IGNhcnJpZXIgd2hvc2UgbmV0d29yayBpcyBiYXNlZCBvbiBuZXR3b3JraW5nIHRlY2hub2xvZ2ll cyBsaWtlIEJHUCwgZXh0ZW5kaW5nIHRob3NlIHRlY2hub2xvZ2llcyBpbnRvIGEgZGF0YSBjZW50 ZXIgaXMgYSBmaW5lIHRoaW5nIHRvIGRvLCBhbmQgbm90aGluZyBpbiB0aGUgbnZvMyB3b3JrIGlz IGludGVuZGVkIHRvIHN0b3AgdGhhdC4NCj4gDQo+IE9UT0gsIGZvciBhIG5vbi1jYXJyaWVyIGRh dGEgY2VudGVyIChlLmcuLCBlbnRlcnByaXNlKSwgbm90IG9ubHkgaXMgdGhlIGFib3ZlIHN0YXRl bWVudCByYXRoZXIgaW5jb3JyZWN0LCBidXQgdGhlIGVudGVycHJpc2UgbmV0d29yayBtYXkgbm90 IGJlIHJ1bm5pbmcgQkdQLiAgVGhpcyBjYW4gYmUgcGFydGljdWxhcmx5IHNvIGZvciBhIGRhdGEg Y2VudGVyIHRoYXQgZGVzaXJlcyBmbGV4aWJpbGl0eSBpbiBjaG9pY2UgYW1vbmcgY2FycmllcnMs IGFuZCBoZW5jZSBvcGVyYXRlcyB1bmRlciB0aGUgcHJpbmNpcGxlIHRoYXQgb25lIG9mIHRoZSBq b2JzIG9mIHRoZSBDUEUgYm94IGlzIHRvIGtlZXAgdGhlIGNhcnJpZXIgdGVjaG5vbG9neSBvbiB0 aGUgb3RoZXIgc2lkZSBpbiBvcmRlciB0byBsaW1pdCBsb2NrLWluLiAgVGhlIG52bzMgd29yayBp cyB0YXJnZXRlZCBhdCB0aGUgc29ydCBvZiB1c2UgY2FzZXMgZGVzY3JpYmVkIGluIHRoaXMgcGFy YWdyYXBoLg0KPiBbSmltIFU+XSBTbywgYSBjb3VwbGUgb2YgaXRlbXMuLiBCR1AgaXMgYSBnZW5l cmFsIHB1cnBvc2UgdG9vbHMgdGhhdCBpcyB1c2VkIGluIGEgdmFyaWV0eSBvZiBhcHBsaWNhdGlv bnMgd2hlcmUgZGlzY292ZXJ5LCBkeW5hbWljIHNpZ25hbGluZyBldGMuLiBpcyByZXF1aXJlZC4u IFNvIGZvciBhIG5vbi1jYXJyaWVyIGRhdGEgY2VudGVyIEkgd291bGQgdGhpbmsgdGhhdCB0aGUg c2FtZSByZXFzIHdvdWxkIGJlIG5lZWRlZCBldmVuIGlmIHRoZSBzY29wZSBpcyBsaW1pdGVkIHRv IHRoYXQgc2luZ2xlIG5vbi1jYXJyaWVyIGRhdGEgY2VudGVyLi4gSWYgb25lIHdlcmUgdG8gY29u c2lkZXIgZGVwbG95aW5nIGEgdGVjaG5vbG9neSB0byByZWFsaXplIHRoZSBzZXJ2aWNlIG5lZWRl ZCBpdCB3b3VsZCBzZWVtIHBydWRlbnQgdG8gY29uc2lkZXIgYWxsIHNvbHV0aW9uIHNwYWNlcyBh bmQgbm90IGdldCBjYXVnaHQgdXAgaW4gdGhlIHBlcmNlcHRpb24gb3IgdXMgdnMuIHRoZW0gbWVu dGFsaXR5Li4gVGhlIG90aGVyIG5vdGlvbiBoZXJlIGlzIHRoYXQgdXNpbmcgQkdQIHNvbWVob3cg cHJldmVudHMgaXNvbGF0aW9uIG9yIGxpbWl0cyBzZWxlY3Rpb24gb2YgZGlmZmVyZW50IHByb3Zp ZGVycywgbmVpdGhlciBvZiB0aGVzZSBhc3N1bXB0aW9ucyBoYXZlIGJlZW4gcHJvdmVuIHRvIGJl IHRydWUgaW4gb3RoZXIgYXBwbGljYXRpb25zIHRoYXQgdXNlIEJHUC4uDQo+IA0KPiBUaGlzIHNv cnQgb2Ygc3Bpcml0ZWQgcHJvbW90aW9uIG9mIEJHUCBjb21lcyBhY3Jvc3MgYXMgYW4gYXR0ZW1w dCB0byBmb3JjZSBhIG9uZS1zaXplLWZpdHMtYWxsIHNvbHV0aW9uIG9uIHRob3NlIHdobyBkbyBu b3QgY3VycmVudGx5IHVzZSBCR1AuICBJIGFtICoqTk9UKiogYXJndWluZyB0aGF0IEJHUCBjYW4n dCBiZSBtYWRlIHRvIHdvcms7IEkgYW0gYXJndWluZyB0aGF0IGl0J3MgYSBwb29yIGZpdCBmb3Ig dGhlIHVzZSBjYXNlcyBvZiBpbnRlcmVzdC4NCj4gW0ppbSBVPl0gSSBkbyBub3QgYWdyZWUuLiBC R1AgcGVybWl0cyB0aGUgZXZvbHV0aW9uIG9mIHRoZSBzZXJ2aWNlcyBzdWNoIHRoYXQgYW55IGFu ZCBhbGwgZGF0YSBjZW50ZXJzIGNhbiBwYXJ0aWNpcGF0ZSBpbiBwcm92aWRpbmcgc2VydmljZSwg YW5kIGFudGljaXBhdGVzIHVzZSBjYXNlcyBjdXJyZW50bHkgbm90IGNvbnNpZGVyZWQgc3VjaCBh cyBtdWx0aXBsZSBkYXRhIGNlbnRlcnMgYWNyb3NzIGNvbXBhbmllcyBwcm92aWRpbmcgc2Vydmlj ZSBmb3IgYSBnaXZlbiBjdXN0b21lciBpbiBhIGNvb3BlcmF0aXZlIG1hbm5lci4uIEkgZG8gbm90 IHNlZSBob3cgdGhlIHNvbHV0aW9ucyBvciBhc3N1bXB0aW9ucyBtYWRlIGluIE5WTzMgY2FwdHVy ZSB0aGlzLi4uDQo+IA0KPiBUaGFua3MsDQo+IC0tRGF2aWQNCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBEYXZpZCBMLiBCbGFjaywgRGlz dGluZ3Vpc2hlZCBFbmdpbmVlcg0KPiBFTUMgQ29ycG9yYXRpb24sIDE3NiBTb3V0aCBTdC4sIEhv cGtpbnRvbiwgTUEgIDAxNzQ4DQo+ICsxICg1MDgpIDI5My03OTUzICAgICAgICAgICAgIEZBWDog KzEgKDUwOCkgMjkzLTc3ODYNCj4gZGF2aWQuYmxhY2tAZW1jLmNvbSAgICAgICAgTW9iaWxlOiAr MSAoOTc4KSAzOTQtNzc1NA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IG52bzMgbWFpbGluZyBsaXN0DQo+IG52bzNAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zDQo= From akatlas@gmail.com Mon Apr 2 11:30:57 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90AF421F86E4; Mon, 2 Apr 2012 11:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dG2lr0cjjgGQ; Mon, 2 Apr 2012 11:30:56 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id F0A3021F86A4; Mon, 2 Apr 2012 11:30:55 -0700 (PDT) Received: by iazz13 with SMTP id z13so5462307iaz.31 for ; Mon, 02 Apr 2012 11:30:55 -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:content-transfer-encoding; bh=5JBKL5YcZHIjy1TC3anWsCGnidvLG+QWCoyxZKOpALs=; b=QDtRc8W3ZD5XyOuPMCASKrynmkkGa5A3exYztx5cYiRNcwkPqarU/dyzSQ9tge3olN R6YC5DnP16XSGLfaOO+MR9/X3BYVrGq3TvCico+p5tptrNiaOsUyc/lCc+TB2TOhwRKo 1SJmzUV2x85hwbXoP23zHvNPIf8wwd5na78XnyWyEE15+pO4uuYGDjnSvVD1U8ycHxao bWOxH1a3Zqiy77LlEOjKUKF2HcrcNQ6TfGix3G3hvR/aXk2KzfHvINcZdiaJosDmyTdr F0uahAlZB3y1g4p/LK1EO/evpz1cl9OXXdXqI9eVRvltq348jYtnXYDG0zOq4hZ4mTni FlJA== MIME-Version: 1.0 Received: by 10.50.51.226 with SMTP id n2mr6498269igo.68.1333391455552; Mon, 02 Apr 2012 11:30:55 -0700 (PDT) Received: by 10.50.1.209 with HTTP; Mon, 2 Apr 2012 11:30:55 -0700 (PDT) In-Reply-To: <90A28773-459A-44C3-A404-5000CFC043BC@gmail.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0CAE@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0E23@szxeml525-mbs.china.huawei.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80849@MX14A.corp.emc.com> <90A28773-459A-44C3-A404-5000CFC043BC@gmail.com> Date: Mon, 2 Apr 2012 14:30:55 -0400 Message-ID: Subject: Re: [nvo3] Response to some comments on IS-IS VPLS From: Alia Atlas To: Jon Hudson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "l2vpn@ietf.org" , "david.black@emc.com" , "nvo3@ietf.org" , "UTTARO, JAMES" X-BeenThere: l2vpn@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, 02 Apr 2012 18:30:58 -0000 As Jim said, [Jim U>] So, a couple of items.. BGP is a general purpose tools that is used in a variety of applications where discovery, dynamic signaling etc.. is required.. For a data-center application, it isn't necessary to have available and configure all of the policy-based complexity of BGP. Instead, the necessary subset could be clearly defined as a BGP profile. The type of configuration and information needed would, I suspect, be quite similar for any application that is doing discovery, dynamic signaling, pushing VNID membership information, etc. So - which aspects of BGP are viewed as too complex for the Enterprise IT space? Are those the ones that would actually be needed for an L2VPN/EVPN application? As for which types of boxes support BGP vs. support an unspecified as-yet-undefined new solution, any box that can have new code written for a new solution could similarly have code written for the subset of BGP that is needed here. I certainly hear the trepidation about BGP complexity - but when all of BGP (for all applications) is compared to undefined future solution (where the complexity is always in the unconsidered/unspecified details), I am not yet persuaded that a simplified BGP profile wouldn't suffice. That said, I think the concern over BGP is rather like the elephant in the room that we hadn't been talking about. Since this strongly guides what types of solutions can be considered and how existing ones might need to be modified, I'm glad that we're starting this discussion. Alia On Mon, Apr 2, 2012 at 1:45 PM, Jon Hudson wrote: > > I agree with David. > > It becomes an issue of in house knowledge and equipment budget vs whateve= r is already in place. > > Many Enterprise IT shops have humans that would love to learn BGP (or MPL= S etc) but just don't have a background in it. This makes them very vendor = dependent for the expertise which makes some nervous. A week long BGP class= does not an expert make. > > The second issue for some (which was brought up at the BoF) is that it's = a certain class of devices that have BGP support. It may be that to support= BGP new hardware needs to be acquired. > > I see these two issues most often as barriers to a proposal like this. > > J > > On Apr 2, 2012, at 5:15 AM, "UTTARO, JAMES" wrote: > >> David, >> >> =A0 =A0Comments In-Line... >> >> Thanks, >> =A0 =A0Jim Uttaro >> >> -----Original Message----- >> From: david.black@emc.com [mailto:david.black@emc.com] >> Sent: Monday, April 02, 2012 6:36 AM >> To: UTTARO, JAMES >> Cc: l2vpn@ietf.org; nvo3@ietf.org >> Subject: RE: Response to some comments on IS-IS VPLS >> >> James, >> >> I believe the solution preference starts from this belief about data cen= ter architecture: >> >>>> I believe that the data center is becoming more and more a >>>> dynamic extension of a customer=B9s network. >> >> Under that assumption, for a carrier whose network is based on networkin= g technologies like BGP, extending those technologies into a data center is= a fine thing to do, and nothing in the nvo3 work is intended to stop that. >> >> OTOH, for a non-carrier data center (e.g., enterprise), not only is the = above statement rather incorrect, but the enterprise network may not be run= ning BGP. =A0This can be particularly so for a data center that desires fle= xibility in choice among carriers, and hence operates under the principle t= hat one of the jobs of the CPE box is to keep the carrier technology on the= other side in order to limit lock-in. =A0The nvo3 work is targeted at the = sort of use cases described in this paragraph. >> [Jim U>] So, a couple of items.. BGP is a general purpose tools that is = used in a variety of applications where discovery, dynamic signaling etc.. = is required.. So for a non-carrier data center I would think that the same = reqs would be needed even if the scope is limited to that single non-carrie= r data center.. If one were to consider deploying a technology to realize t= he service needed it would seem prudent to consider all solution spaces and= not get caught up in the perception or us vs. them mentality.. The other n= otion here is that using BGP somehow prevents isolation or limits selection= of different providers, neither of these assumptions have been proven to b= e true in other applications that use BGP.. >> >> This sort of spirited promotion of BGP comes across as an attempt to for= ce a one-size-fits-all solution on those who do not currently use BGP. =A0I= am **NOT** arguing that BGP can't be made to work; I am arguing that it's = a poor fit for the use cases of interest. >> [Jim U>] I do not agree.. BGP permits the evolution of the services such= that any and all data centers can participate in providing service, and an= ticipates use cases currently not considered such as multiple data centers = across companies providing service for a given customer in a cooperative ma= nner.. I do not see how the solutions or assumptions made in NVO3 capture t= his... >> >> Thanks, >> --David >> ---------------------------------------------------- >> David L. Black, Distinguished Engineer >> EMC Corporation, 176 South St., Hopkinton, MA =A001748 >> +1 (508) 293-7953 =A0 =A0 =A0 =A0 =A0 =A0 FAX: +1 (508) 293-7786 >> david.black@emc.com =A0 =A0 =A0 =A0Mobile: +1 (978) 394-7754 >> ---------------------------------------------------- >> _______________________________________________ >> 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 gregory.mirsky@ericsson.com Mon Apr 2 11:43:12 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB0D21F864E; Mon, 2 Apr 2012 11:43:12 -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 bOiCjYpMVTqb; Mon, 2 Apr 2012 11:43:12 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF6F21F8643; Mon, 2 Apr 2012 11:43:12 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q32Ih83k018225 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Apr 2012 13:43:09 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.170]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 2 Apr 2012 14:43:08 -0400 From: Gregory Mirsky To: Jon Hudson , sajassi Date: Mon, 2 Apr 2012 14:43:07 -0400 Subject: RE: [nvo3] Response to some comments on IS-IS VPLS Thread-Topic: [nvo3] Response to some comments on IS-IS VPLS Thread-Index: Ac0Q+llHfR64QVAYRfO+QijpQxExYQABPGQg Message-ID: References: <85DCB564-1551-4B7A-B08B-DE355D3D2221@gmail.com> In-Reply-To: <85DCB564-1551-4B7A-B08B-DE355D3D2221@gmail.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" , "" X-BeenThere: l2vpn@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, 02 Apr 2012 18:43:13 -0000 Hi Jon, For application to be able to do what you've described requires network to = be designed accordingly. IMHO, support of implicit requirements is rather a= ccidental and support of explicit requirements is limited by laws of physic= s. Regards, Greg -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of J= on Hudson Sent: Monday, April 02, 2012 10:54 AM To: sajassi Cc: l2vpn@ietf.org; nvo3@ietf.org; Subject: Re: [nvo3] Response to some comments on IS-IS VPLS In my experience it's because it would require the virtualization folks to = open a ticket and interact with the network team. Many want to be able to on a whim create wormholes from any hypervisor(s) t= o any hypervisors(s) without dependencies on other teams that would require= a ticket, change control or approval by a steering committee. J =20 On Apr 2, 2012, at 10:44 AM, sajassi wrote: > Hi Robert, >=20 > The connectivity between the two VMs is provided by L2VPN over MPLS/IP=20 > - e.g.,, VM1/VLAN1 an VM2/VLAN1 are mapped to the same L2VPN. Why do=20 > you think, the encap/decap must be done on the end-host (hypvervisor, OVS= ,etc.). >=20 > Cheers, > Ali >=20 >=20 > On 3/30/12 2:48 AM, "Robert Raszuk" wrote: >=20 >> Ali, >>=20 >>> Third, before bashing E-VPN/PBB-EVPN, I would recommend that you=20 >>> understand what it is. >>=20 >> Great point indeed. >>=20 >> Could you share a pointer to the list which describes VM 1 on Host=20 >> A's hypervisor to VM 2 on host B's hypervisor interconnect model for=20 >> both above solutions just assuming that you have IP or MPLS=20 >> reachability between such hosts ? >>=20 >> The requirement of my question is that any=20 >> encapsulation/decapsulation required for such interconnection should=20 >> happen on the end hosts (kernel, OVS, NIC etc ...) and not on the "netwo= rk". >>=20 >> Best regards, >> R. >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From kireeti@juniper.net Mon Apr 2 11:58:59 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB64B21F871E; Mon, 2 Apr 2012 11:58:59 -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 KGW82ni6Ybu8; Mon, 2 Apr 2012 11:58:59 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id ED5B321F871A; Mon, 2 Apr 2012 11:58:58 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKT3n28C+uQn0uWwiLRtWqE/0Lq3873g5M@postini.com; Mon, 02 Apr 2012 11:58:59 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 2 Apr 2012 11:58:16 -0700 From: Kireeti Kompella To: "david.black@emc.com" Date: Mon, 2 Apr 2012 11:58:11 -0700 Subject: Re: Response to some comments on IS-IS VPLS Thread-Topic: Response to some comments on IS-IS VPLS Thread-Index: Ac0RAo9D0ecHoJelR+G7SqfWLEefIg== Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0CAE@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0E23@szxeml525-mbs.china.huawei.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80849@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80849@MX14A.corp.emc.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" , "ju1738@att.com" X-BeenThere: l2vpn@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, 02 Apr 2012 18:58:59 -0000 Interesting discussion! (Thomas, see what one small sub-bullet can lead to= :-)) See more inline.=20 On Apr 2, 2012, at 3:46, "david.black@emc.com" wrote: > Under that assumption, for a carrier whose network is based on networking= technologies like BGP, extending those technologies into a data center is = a fine thing to do, and nothing in the nvo3 work is intended to stop that. >=20 > OTOH, for a non-carrier data center (e.g., enterprise), not only is the a= bove statement rather incorrect, but the enterprise network may not be runn= ing BGP. =20 Step back a bit. The non-carrier DC is not being asked to run BGP. The _clo= ud_ operator, in order to scale their DC, of which the non-carrier DC is ju= st a tenant, may want to run BGP. Just as enterprises running OSPF get con= nectivity services from carriers running BGP.=20 > This can be particularly so for a data center that desires flexibility in= choice among carriers, Actually, BGP is what carriers talk to each other, so I'm not sure how such= a choice limits flexibility. > and hence operates under the principle that one of the jobs of the CPE bo= x is to keep the carrier technology on the other side in order to limit loc= k-in. =20 The "other" side of a CPE box usually runs BGP.=20 Kireeti > The nvo3 work is targeted at the sort of use cases described in this para= graph. From sajassi@cisco.com Mon Apr 2 12:24:46 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D06E21F864C; Mon, 2 Apr 2012 12:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 HQZLTY5n3wRm; Mon, 2 Apr 2012 12:24:45 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 462B421F85C7; Mon, 2 Apr 2012 12:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sajassi@cisco.com; l=1830; q=dns/txt; s=iport; t=1333394682; x=1334604282; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=OQVd2g5xeD8gX3nDduukGr2vPhuJDMJjP0hq/+qnoGs=; b=O4+SrD/tm3xEUi0vkLDi9pf/yaLlt525KTb+VBwICNo+2B0p06VdO3om 4+xC5iYc8HyCD82Pn050lZ1slABXkYgiV816tBXXVFcbXtW/T4X8ZKWQz bZBfavHvxDhGxIQzlZ0oOLBdy+iu7JZwC1K1Y7eF3Q0C18xlPTdCF1wza E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgJAHz4eU+rRDoH/2dsb2JhbABFt3oCgQeCCQEBAQMBAQEBDwEnAgExCwUNAQgJD08GMAEBBA4FGweHYgQBC5tJnwsEihaGWASIWIUqh1+LM4MUgWiDBw X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="36154471" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 02 Apr 2012 19:24:42 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q32JOgMg028657; Mon, 2 Apr 2012 19:24:42 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 12:24:42 -0700 Received: from 64.101.3.8 ([64.101.3.8]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Mon, 2 Apr 2012 19:24:41 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 02 Apr 2012 12:24:39 -0700 Subject: Re: [nvo3] Response to some comments on IS-IS VPLS From: sajassi To: Jon Hudson Message-ID: Thread-Topic: [nvo3] Response to some comments on IS-IS VPLS Thread-Index: Ac0RBj8dm1Qm9KISPUqWPyUpFX767Q== In-Reply-To: <85DCB564-1551-4B7A-B08B-DE355D3D2221@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Apr 2012 19:24:42.0005 (UTC) FILETIME=[40E83C50:01CD1106] Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" , "" X-BeenThere: l2vpn@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, 02 Apr 2012 19:24:46 -0000 The interaction can be automated via the use of some protocol (e.g., VDP in 802.1Qbg) which is being talked about in NOV3. Cheers, Ali On 4/2/12 10:54 AM, "Jon Hudson" wrote: > In my experience it's because it would require the virtualization folks to > open a ticket and interact with the network team. > > Many want to be able to on a whim create wormholes from any hypervisor(s) to > any hypervisors(s) without dependencies on other teams that would require a > ticket, change control or approval by a steering committee. > > J > > On Apr 2, 2012, at 10:44 AM, sajassi wrote: > >> Hi Robert, >> >> The connectivity between the two VMs is provided by L2VPN over MPLS/IP - >> e.g.,, VM1/VLAN1 an VM2/VLAN1 are mapped to the same L2VPN. Why do you >> think, the encap/decap must be done on the end-host (hypvervisor, OVS,etc.). >> >> Cheers, >> Ali >> >> >> On 3/30/12 2:48 AM, "Robert Raszuk" wrote: >> >>> Ali, >>> >>>> Third, before bashing E-VPN/PBB-EVPN, I would recommend that you >>>> understand what it is. >>> >>> Great point indeed. >>> >>> Could you share a pointer to the list which describes VM 1 on Host A's >>> hypervisor to VM 2 on host B's hypervisor interconnect model for both >>> above solutions just assuming that you have IP or MPLS reachability >>> between such hosts ? >>> >>> The requirement of my question is that any encapsulation/decapsulation >>> required for such interconnection should happen on the end hosts >>> (kernel, OVS, NIC etc ...) and not on the "network". >>> >>> Best regards, >>> R. >>> >>> >>> >>> >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 From sajassi@cisco.com Mon Apr 2 12:30:36 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C94F21F86C2 for ; Mon, 2 Apr 2012 12:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.534 X-Spam-Level: X-Spam-Status: No, score=-7.534 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 mlBeYJ-bv9+o for ; Mon, 2 Apr 2012 12:30:35 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC7721F86BE for ; Mon, 2 Apr 2012 12:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sajassi@cisco.com; l=6146; q=dns/txt; s=iport; t=1333395035; x=1334604635; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=UG60LU67HKVor2bmCmNbWlDegebkWgtbwVQk+43j1TQ=; b=RIqzqFH1kJGwTEA1dtd+E7uLAc1p8iYTP6EvhW49AGdKTx1+pobBmtPN JLdO85F8nd2HHUxntQ179JE40R7flqXcCMHnuh4IrUMDZc/jLIzAMoq9r MeHMXWTYbq+RPRUz5QCj5dBkDwZDl6wWcXc2dpL6LKMzPSXdrAt7MAcH1 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4JAHz4eU+rRDoJ/2dsb2JhbABFhUexPnUCgQeCCQEBAQMBEgEQGQEwAQsFDQEGAgkIBAEBAQICIwMCSBEBAQQBDQUUBweHYgQBC5tJjQiSB4EviVuETIEYBIhYhSqHX4ERjTaBaIMHgTQ X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="35618461" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 02 Apr 2012 19:30:34 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q32JUYhq027760; Mon, 2 Apr 2012 19:30:34 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 12:30:34 -0700 Received: from 64.101.3.8 ([64.101.3.8]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Mon, 2 Apr 2012 19:30:34 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 02 Apr 2012 09:34:06 -0700 Subject: Re: Response to some comments on IS-IS VPLS From: sajassi To: Xuxiaohu , "robert@raszuk.net" , John E Drake Message-ID: Thread-Topic: Response to some comments on IS-IS VPLS Thread-Index: Ac0Q7mvFyiQyd3UgwEGhc0kfJk1xhg== In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0DDF@szxeml525-mbs.china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 02 Apr 2012 19:30:34.0598 (UTC) FILETIME=[1311A860:01CD1107] Cc: "l2vpn@ietf.org" , "UTTARO, JAMES" X-BeenThere: l2vpn@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, 02 Apr 2012 19:30:36 -0000 Hi Xuxiaohu, The draft that I wrote ten years ago (MVPLS) is analogous to VXLAN - both d= o the same thing but with different IP encap. MVPLS used L2TPv3 encap (since it was the encap-dejour of that time for IP :-); whereas, VXLAN uses UDP encap.=20 Since there are already three different encap proposals in NVo3 (UDP, GRE, and TCP), I am NOT planning to introduce yet another encap by resurrecting my draft. I think we should only pick a single encap among the three curren= t proposals in NVO3. Cheers, Ali =20 On 3/30/12 1:55 AM, "Xuxiaohu" wrote: > Hi Ali, >=20 > What's your attitude to your own draft as mentioned below from today's po= int > of view? good or bad? >=20 > Best regards, > Xiaohu >=20 > ________________________________________ > =E5=8F=91=E4=BB=B6=E4=BA=BA: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 sajassi > [sajassi@cisco.com] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B43=E6=9C=8830=E6=97=A5 16:43 > =E5=88=B0: robert@raszuk.net; John E Drake > Cc: l2vpn@ietf.org; UTTARO, JAMES > =E4=B8=BB=E9=A2=98: Re: Response to some comments on IS-IS VPLS >=20 > Hi Robert, >=20 > I won't get into the argument of whether this kind of solution is innovat= ion > or permutation. My point is that it is clearly outside of current L2VPN > charter and if this kind of solution is to be pursued in L2VPN WG, then i= t > needs to be re-chartered. >=20 > Also, if we are talking about VPLS service over IP and doing MAC learning > against IP addresses (as what this draft is talking about), I had a draft= 10 > years ago that cover this subject !! >=20 > http://tools.ietf.org/id/draft-sajassi-mvpls-00.txt >=20 > Cheers, > Ali >=20 >=20 > On 3/29/12 2:33 PM, "Robert Raszuk" wrote: >=20 >> Hi John, >>=20 >> I think you took it a little bit too far. >>=20 >> I have not heard anyone stating that current VPLS solutions suck. I also >> did not hear anyone claiming that BGP is difficult. The claim I have >> heard is that in some environments one may not like to use BGP for VPLS. >>=20 >> Ali's point is that current PEs will have problem supporting it as this >> is effectively TRILL over IP is valid from Ali's point of view. >>=20 >> However one could ask a question if IETF is still an organization to >> promote open innovation and consider new ideas (even if only in >> experimental mode) or is it just a forum to lock customers to limited >> set of solutions ? If it is the latter the trend to seek alternatives to >> IETF standardization process will continue to evolve. Especially now >> when control plane separation from data plane becomes reality. >>=20 >> I see nothing wrong to allocate perhaps in experimental mode VPLS Info >> TLV codepoint for VPLS over ISIS or for that matter well known >> destination port for STT from IANA and let companies who are asking for >> it develop the solutions, deploy it then report back the results to the >> community. >>=20 >> Best, >> R. >>=20 >>=20 >>> Jim, >>>=20 >>> You are completely correct , but let=C2=B9s not overlook the fun factor. >>> I.e., it=C2=B9s **fun** to say that everything that has gone before sucks a= nd >>> that the current initiative will be =C2=B3practically perfect=C2=B2 (c.f. =C5=92Mar= y >>> Poppins=C2=B9). >>>=20 >>> Thanks, >>>=20 >>> John >>>=20 >>> Sent from my iPhone >>>=20 >>> *From:*l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] *On Behal= f >>> Of *UTTARO, JAMES >>> *Sent:* Thursday, March 29, 2012 11:30 AM >>> *To:* 'Xuxiaohu'; l2vpn@ietf.org >>> *Subject:* RE: Response to some comments on IS-IS VPLS >>>=20 >>> IMHO=C5=A0 I am at a bit of a loss as to the notion that BGP is so >>> overwhelmingly difficult to deal with in a data center environment.. Wh= y >>> is that?? BGP is being used across a wide spectrum of applications and >>> is proven. I believe that the data center is becoming more and more a >>> dynamic extension of a customer=C2=B9s network. I also think it would be wi= se >>> to anticipate the world of tomorrow where customers may expect their >>> network may span multiple operators DCs. The right approach is to >>> leverage what has been done BGP and extend it where needed.. This >>> provides maximum flexibility and simplicity.. >>>=20 >>> To build solutions based on the notion that =C2=B3I don=C2=B9t like protocol X=C2= =B2 is >>> invalid.. >>>=20 >>> Jim Uttaro >>>=20 >>> *From:*l2vpn-bounces@ietf.org >>> [mailto:l2vpn-bounces@ietf.org] *On Behalf Of *Xuxiaohu >>> *Sent:* Thursday, March 29, 2012 2:59 PM >>> *To:* l2vpn@ietf.org >>> *Subject:* Response to some comments on IS-IS VPLS >>>=20 >>> Hi all, >>>=20 >>> VPLS (Virtual Private LAN Service) has different understandings for >>> different people, some people think it as a service while others think >>> it as a concrete technology, especially using PWs. Here, the "VPLS" is >>> deemed as a VPLS service. If the WG consensus is that "VPLS" should be >>> taken as a concrete technology, I have no objection to using another te= rm. >>>=20 >>> As said in the IS-IS VPLS draft, IS-IS VPLS is intended to be a >>> light-weight VPLS solution which can meet some DC operators' >>> requirements for simplicity. I don't want to argue in this mailing-list >>> whether BGP-based L2VPN solutions could meet well the requirements from >>> all DC operators. I personally believe that it would be better to ask >>> this question to NVo3. In addition, according to today's presentation o= f >>> E-VPN, I think E-VPN co-authors also admit that the exiting EVPN >>> solution seems complex to some DC operators. If my understanding is >>> wrong, pls correct me. >>>=20 >>> If I remembered correctly, L1VPN also has two RFCs using IS-IS and OSPF >>> for L1VPN auto-discovery, although there has been one solution using >>> BGP. Hence I don't know why can't we have a light-weight L2VPN using IS= -IS. >>>=20 >>> Best regards, >>>=20 >>> Xiaohu >>>=20 >>=20 From ju1738@att.com Mon Apr 2 12:52:33 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98DE621F866D; Mon, 2 Apr 2012 12:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 o26DcQ8wAihn; Mon, 2 Apr 2012 12:52:32 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 45B1E21F8666; Mon, 2 Apr 2012 12:52:32 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo04.seg.att.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-8) with ESMTP id 0830a7f4.5606a940.411620.00-564.1138009.nbfkord-smmo04.seg.att.com (envelope-from ); Mon, 02 Apr 2012 19:52:32 +0000 (UTC) X-MXL-Hash: 4f7a038016992ca8-ceed2e29120400713e21975a3e083437d753be9e Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 4730a7f4.0.411602.00-334.1137744.nbfkord-smmo04.seg.att.com (envelope-from ); Mon, 02 Apr 2012 19:52:20 +0000 (UTC) X-MXL-Hash: 4f7a037414e683bb-2b5340d91efb6c61c50880dd88f13b62447d4e9d Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q32JqJP1012721; Mon, 2 Apr 2012 15:52:20 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q32JqCNr012599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Apr 2012 15:52:12 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by sflint02.pst.cso.att.com (RSA Interceptor); Mon, 2 Apr 2012 15:51:43 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.12]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.01.0355.002; Mon, 2 Apr 2012 15:51:43 -0400 From: "UTTARO, JAMES" To: "'david.black@emc.com'" Subject: RE: Response to some comments on IS-IS VPLS Thread-Topic: Response to some comments on IS-IS VPLS Thread-Index: AQHNDauno12B0RP+lEO1DyVa7X7/s5aBlXMQgAAXd5D//5jvgIABHOVpgAApX6KAAAtTuIAEwdXAgAAdhLCAAHPX8IAADSGQ Date: Mon, 2 Apr 2012 19:51:43 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0CAE@szxeml525-mbs.china.huawei.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0E23@szxeml525-mbs.china.huawei.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80849@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80A91@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80A91@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.144.187] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=M4PYRFK9RzMA:10 a=0cQrbQDqE-4A:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=IkcTkHD0fZMA:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=G0_B3m8xAAAA:8 a=48vgC7mUAAAA:8 a=zQP7CpKO] X-AnalysisOut: [AAAA:8 a=G5ki2ughVQd6EFCTFu0A:9 a=I93g_bDGpQrEVog8PHsA:7 a] X-AnalysisOut: [=QEXdDO2ut3YA:10 a=x32YNh-eXBMA:10 a=sXX8f2-lqQ8A:10 a=MuC] X-AnalysisOut: [zCmE08hAA:10 a=GMbka86qx8EA:10 a=jJ7F3QIqxRAA:10 a=2_NgnSQ] X-AnalysisOut: [5-uYA:10 a=lW_bInUQU2sA:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0c] X-AnalysisOut: [A:10] Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" X-BeenThere: l2vpn@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, 02 Apr 2012 19:52:33 -0000 RGF2aWQsDQoNCkkgdGhpbmsgdGhhdCBtYXliZSBhIGdvb2Qgc3RhcnRpbmcgcG9pbnQgd291bGQg YmUgdG8gc3RhcnQgdG8gYnVpbGQgYSBzZXQgb2YgcmVxcyB0aGF0IG1pZ2h0IG1lZXQgYm90aCBT UC9EQyByZXFzIHdpdGggYW4gZXllIHRvd2FyZHMgZXZvbHZpbmcgaW50byB0aGUgZnV0dXJlLi5D b21tZW50cyBJbi1MaW5lLi4NCg0KVGhhbmtzLA0KCUppbSBVdHRhcm8NCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IGRhdmlkLmJsYWNrQGVtYy5jb20gW21haWx0bzpkYXZpZC5i bGFja0BlbWMuY29tXSANClNlbnQ6IE1vbmRheSwgQXByaWwgMDIsIDIwMTIgMzoyNCBQTQ0KVG86 IFVUVEFSTywgSkFNRVMNCkNjOiBsMnZwbkBpZXRmLm9yZzsgbnZvM0BpZXRmLm9yZw0KU3ViamVj dDogUkU6IFJlc3BvbnNlIHRvIHNvbWUgY29tbWVudHMgb24gSVMtSVMgVlBMUw0KDQpKaW0sDQoN Cj4gW0ppbSBVPl0gU28sIGEgY291cGxlIG9mIGl0ZW1zLi4gQkdQIGlzIGEgZ2VuZXJhbCBwdXJw b3NlIHRvb2xzIHRoYXQgaXMgdXNlZCBpbiBhIHZhcmlldHkgb2YNCj4gYXBwbGljYXRpb25zIHdo ZXJlIGRpc2NvdmVyeSwgZHluYW1pYyBzaWduYWxpbmcgZXRjLi4gaXMgcmVxdWlyZWQuLiBTbyBm b3IgYSBub24tY2FycmllciBkYXRhIGNlbnRlciBJDQo+IHdvdWxkIHRoaW5rIHRoYXQgdGhlIHNh bWUgcmVxcyB3b3VsZCBiZSBuZWVkZWQgZXZlbiBpZiB0aGUgc2NvcGUgaXMgbGltaXRlZCB0byB0 aGF0IHNpbmdsZSBub24tY2Fycmllcg0KPiBkYXRhIGNlbnRlci4uDQoNCk9rLCBidXQgZGF0YSBj ZW50ZXJzIHRlbmQgdG8gdXNlIG11Y2ggc2ltcGxlciByb3V0aW5nIHRlY2hub2xvZ3kuICBBcyBL aXJlZXRpIHBvaW50cyBvdXQsIG1hbnkgbm9uLVNQIGRhdGEgY2VudGVycyB1c2UgSUdQcyAtIE9T UEYgd2l0aCBFQ01QIGlzIGEgY29tbW9uIGV4YW1wbGUgdGhhdCBvbmUgY2FuIGV4cGVjdCB0byBz ZWUgaW4gdGhlIElQIG5ldHdvcmsgdW5kZXJseWluZyB0aGUgZW5jYXBzdWxhdGlvbi4gIEFub3Ro ZXIgaW50ZXJlc3RpbmcgcG9zc2liaWxpdHkgZm9yIG92ZXJsYXkgYWRkcmVzcyBtYXBwaW5nIGlz IHRoZSBzb3J0IG9mIGRpcmVjdG9yeS1iYXNlZCBpbmZyYXN0cnVjdHVyZSBub3cgYmVpbmcgdXNl ZCBieSBMSVNQIChJJ2xsIGxlYXZlIGl0IHRvIHRoZSBMSVNQIGZvbGtzIHRvIGV4cGxhaW4gd2hh dCB0aGlzIGlzIGFuZCBob3cvd2h5IGl0IG1heSBiZSBpbnRlcmVzdGluZykuDQpbSmltIFU+XSBI bW1tLi4gTElTUCBsaWtlIHRlY2hub2xvZ3kgY291bGQgYmUgaW50ZXJlc3RpbmcuLg0KDQo+IElm IG9uZSB3ZXJlIHRvIGNvbnNpZGVyIGRlcGxveWluZyBhIHRlY2hub2xvZ3kgdG8gcmVhbGl6ZSB0 aGUgc2VydmljZSBuZWVkZWQgaXQgd291bGQNCj4gc2VlbSBwcnVkZW50IHRvIGNvbnNpZGVyIGFs bCBzb2x1dGlvbiBzcGFjZXMgYW5kIG5vdCBnZXQgY2F1Z2h0IHVwIGluIHRoZSBwZXJjZXB0aW9u IG9yIHVzIHZzLiB0aGVtDQo+IG1lbnRhbGl0eS4uDQoNCkknbSBzb3JyeSwgYnV0IEJHUCdzIGNv bXBsZXhpdHkgKGUuZy4sIHBvbGljeSkgYnkgY29tcGFyaXNvbiB0byB0aGUgSUdQcyB0eXBpY2Fs bHkgdXNlZCBpbiBub24tY2FycmllciBkYXRhIGNlbnRlcnMgaXMgYSBtYXR0ZXIgb2YgZmFjdCwg bm90IHBlcmNlcHRpb24gb3Igb3Bpbmlvbi4gIE9UT0gsIEFsaWEncyBzdWdnZXN0aW9uIHRoYXQg YSBjdXQtZG93biBCR1AgcHJvZmlsZSBtaWdodCBiZSBhcHBsaWNhYmxlIGlzIGludGVyZXN0aW5n LCBJTUhPLg0KW0ppbSBVPl0gWWVzIEFsaWEgbWFrZXMgYSBncmVhdCBzZWxlY3Rpb24gaGVyZS4u IElmIHdlIGNhbiBkZXRlcm1pbmUgdGhlIHJlcXMgdGhlcmUgY291bGQgYmUgYW4gb3Bwb3J0dW5p dHkgdG8gdXNlIGEgQkdQIFByb2ZpbGUgaW4gdGhlIERDIHRoYXQgY291bGQgYmUgZWFzaWx5IGV4 dGVuZGVkDQoNClRoYW5rcywNCi0tRGF2aWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBVVFRBUk8sIEpBTUVTIFttYWlsdG86anUxNzM4QGF0dC5jb21dDQo+IFNlbnQ6 IE1vbmRheSwgQXByaWwgMDIsIDIwMTIgODoxNSBBTQ0KPiBUbzogQmxhY2ssIERhdmlkDQo+IENj OiBsMnZwbkBpZXRmLm9yZzsgbnZvM0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogUmVzcG9uc2Ug dG8gc29tZSBjb21tZW50cyBvbiBJUy1JUyBWUExTDQo+IA0KPiBEYXZpZCwNCj4gDQo+IAlDb21t ZW50cyBJbi1MaW5lLi4uDQo+IA0KPiBUaGFua3MsDQo+IAlKaW0gVXR0YXJvDQo+IA0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkYXZpZC5ibGFja0BlbWMuY29tIFttYWls dG86ZGF2aWQuYmxhY2tAZW1jLmNvbV0NCj4gU2VudDogTW9uZGF5LCBBcHJpbCAwMiwgMjAxMiA2 OjM2IEFNDQo+IFRvOiBVVFRBUk8sIEpBTUVTDQo+IENjOiBsMnZwbkBpZXRmLm9yZzsgbnZvM0Bp ZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogUmVzcG9uc2UgdG8gc29tZSBjb21tZW50cyBvbiBJUy1J UyBWUExTDQo+IA0KPiBKYW1lcywNCj4gDQo+IEkgYmVsaWV2ZSB0aGUgc29sdXRpb24gcHJlZmVy ZW5jZSBzdGFydHMgZnJvbSB0aGlzIGJlbGllZiBhYm91dCBkYXRhIGNlbnRlciBhcmNoaXRlY3R1 cmU6DQo+IA0KPiA+PiBJIGJlbGlldmUgdGhhdCB0aGUgZGF0YSBjZW50ZXIgaXMgYmVjb21pbmcg bW9yZSBhbmQgbW9yZSBhDQo+ID4+IGR5bmFtaWMgZXh0ZW5zaW9uIG9mIGEgY3VzdG9tZXLCuXMg bmV0d29yay4NCj4gDQo+IFVuZGVyIHRoYXQgYXNzdW1wdGlvbiwgZm9yIGEgY2FycmllciB3aG9z ZSBuZXR3b3JrIGlzIGJhc2VkIG9uIG5ldHdvcmtpbmcgdGVjaG5vbG9naWVzIGxpa2UgQkdQLA0K PiBleHRlbmRpbmcgdGhvc2UgdGVjaG5vbG9naWVzIGludG8gYSBkYXRhIGNlbnRlciBpcyBhIGZp bmUgdGhpbmcgdG8gZG8sIGFuZCBub3RoaW5nIGluIHRoZSBudm8zIHdvcmsgaXMNCj4gaW50ZW5k ZWQgdG8gc3RvcCB0aGF0Lg0KPiANCj4gT1RPSCwgZm9yIGEgbm9uLWNhcnJpZXIgZGF0YSBjZW50 ZXIgKGUuZy4sIGVudGVycHJpc2UpLCBub3Qgb25seSBpcyB0aGUgYWJvdmUgc3RhdGVtZW50IHJh dGhlcg0KPiBpbmNvcnJlY3QsIGJ1dCB0aGUgZW50ZXJwcmlzZSBuZXR3b3JrIG1heSBub3QgYmUg cnVubmluZyBCR1AuICBUaGlzIGNhbiBiZSBwYXJ0aWN1bGFybHkgc28gZm9yIGEgZGF0YQ0KPiBj ZW50ZXIgdGhhdCBkZXNpcmVzIGZsZXhpYmlsaXR5IGluIGNob2ljZSBhbW9uZyBjYXJyaWVycywg YW5kIGhlbmNlIG9wZXJhdGVzIHVuZGVyIHRoZSBwcmluY2lwbGUgdGhhdA0KPiBvbmUgb2YgdGhl IGpvYnMgb2YgdGhlIENQRSBib3ggaXMgdG8ga2VlcCB0aGUgY2FycmllciB0ZWNobm9sb2d5IG9u IHRoZSBvdGhlciBzaWRlIGluIG9yZGVyIHRvIGxpbWl0DQo+IGxvY2staW4uICBUaGUgbnZvMyB3 b3JrIGlzIHRhcmdldGVkIGF0IHRoZSBzb3J0IG9mIHVzZSBjYXNlcyBkZXNjcmliZWQgaW4gdGhp cyBwYXJhZ3JhcGguDQo+IFtKaW0gVT5dIFNvLCBhIGNvdXBsZSBvZiBpdGVtcy4uIEJHUCBpcyBh IGdlbmVyYWwgcHVycG9zZSB0b29scyB0aGF0IGlzIHVzZWQgaW4gYSB2YXJpZXR5IG9mDQo+IGFw cGxpY2F0aW9ucyB3aGVyZSBkaXNjb3ZlcnksIGR5bmFtaWMgc2lnbmFsaW5nIGV0Yy4uIGlzIHJl cXVpcmVkLi4gU28gZm9yIGEgbm9uLWNhcnJpZXIgZGF0YSBjZW50ZXIgSQ0KPiB3b3VsZCB0aGlu ayB0aGF0IHRoZSBzYW1lIHJlcXMgd291bGQgYmUgbmVlZGVkIGV2ZW4gaWYgdGhlIHNjb3BlIGlz IGxpbWl0ZWQgdG8gdGhhdCBzaW5nbGUgbm9uLWNhcnJpZXINCj4gZGF0YSBjZW50ZXIuLiBJZiBv bmUgd2VyZSB0byBjb25zaWRlciBkZXBsb3lpbmcgYSB0ZWNobm9sb2d5IHRvIHJlYWxpemUgdGhl IHNlcnZpY2UgbmVlZGVkIGl0IHdvdWxkDQo+IHNlZW0gcHJ1ZGVudCB0byBjb25zaWRlciBhbGwg c29sdXRpb24gc3BhY2VzIGFuZCBub3QgZ2V0IGNhdWdodCB1cCBpbiB0aGUgcGVyY2VwdGlvbiBv ciB1cyB2cy4gdGhlbQ0KPiBtZW50YWxpdHkuLiBUaGUgb3RoZXIgbm90aW9uIGhlcmUgaXMgdGhh dCB1c2luZyBCR1Agc29tZWhvdyBwcmV2ZW50cyBpc29sYXRpb24gb3IgbGltaXRzIHNlbGVjdGlv biBvZg0KPiBkaWZmZXJlbnQgcHJvdmlkZXJzLCBuZWl0aGVyIG9mIHRoZXNlIGFzc3VtcHRpb25z IGhhdmUgYmVlbiBwcm92ZW4gdG8gYmUgdHJ1ZSBpbiBvdGhlciBhcHBsaWNhdGlvbnMNCj4gdGhh dCB1c2UgQkdQLi4NCj4gDQo+IFRoaXMgc29ydCBvZiBzcGlyaXRlZCBwcm9tb3Rpb24gb2YgQkdQ IGNvbWVzIGFjcm9zcyBhcyBhbiBhdHRlbXB0IHRvIGZvcmNlIGEgb25lLXNpemUtZml0cy1hbGwN Cj4gc29sdXRpb24gb24gdGhvc2Ugd2hvIGRvIG5vdCBjdXJyZW50bHkgdXNlIEJHUC4gIEkgYW0g KipOT1QqKiBhcmd1aW5nIHRoYXQgQkdQIGNhbid0IGJlIG1hZGUgdG8gd29yazsNCj4gSSBhbSBh cmd1aW5nIHRoYXQgaXQncyBhIHBvb3IgZml0IGZvciB0aGUgdXNlIGNhc2VzIG9mIGludGVyZXN0 Lg0KPiBbSmltIFU+XSBJIGRvIG5vdCBhZ3JlZS4uIEJHUCBwZXJtaXRzIHRoZSBldm9sdXRpb24g b2YgdGhlIHNlcnZpY2VzIHN1Y2ggdGhhdCBhbnkgYW5kIGFsbCBkYXRhIGNlbnRlcnMNCj4gY2Fu IHBhcnRpY2lwYXRlIGluIHByb3ZpZGluZyBzZXJ2aWNlLCBhbmQgYW50aWNpcGF0ZXMgdXNlIGNh c2VzIGN1cnJlbnRseSBub3QgY29uc2lkZXJlZCBzdWNoIGFzDQo+IG11bHRpcGxlIGRhdGEgY2Vu dGVycyBhY3Jvc3MgY29tcGFuaWVzIHByb3ZpZGluZyBzZXJ2aWNlIGZvciBhIGdpdmVuIGN1c3Rv bWVyIGluIGEgY29vcGVyYXRpdmUNCj4gbWFubmVyLi4gSSBkbyBub3Qgc2VlIGhvdyB0aGUgc29s dXRpb25zIG9yIGFzc3VtcHRpb25zIG1hZGUgaW4gTlZPMyBjYXB0dXJlIHRoaXMuLi4NCj4gDQo+ IFRoYW5rcywNCj4gLS1EYXZpZA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IERhdmlkIEwuIEJsYWNrLCBEaXN0aW5ndWlzaGVkIEVuZ2lu ZWVyDQo+IEVNQyBDb3Jwb3JhdGlvbiwgMTc2IFNvdXRoIFN0LiwgSG9wa2ludG9uLCBNQcKgIDAx NzQ4DQo+ICsxICg1MDgpIDI5My03OTUzwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEZBWDogKzEg KDUwOCkgMjkzLTc3ODYNCj4gZGF2aWQuYmxhY2tAZW1jLmNvbcKgwqDCoMKgwqDCoMKgIE1vYmls ZTogKzEgKDk3OCkgMzk0LTc3NTQNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0K From david.black@emc.com Mon Apr 2 12:24:43 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146E721F85A7; Mon, 2 Apr 2012 12:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.972 X-Spam-Level: X-Spam-Status: No, score=-109.972 tagged_above=-999 required=5 tests=[AWL=0.627, 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 JfakrcRf-I-C; Mon, 2 Apr 2012 12:24:42 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 635A721F85A5; Mon, 2 Apr 2012 12:24:12 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q32JO8uj008762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Apr 2012 15:24:09 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Mon, 2 Apr 2012 15:23:58 -0400 Received: from mxhub07.corp.emc.com (mxhub07.corp.emc.com [128.222.70.204]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q32JNwoQ014361; Mon, 2 Apr 2012 15:23:58 -0400 Received: from mx14a.corp.emc.com ([169.254.1.70]) by mxhub07.corp.emc.com ([128.222.70.204]) with mapi; Mon, 2 Apr 2012 15:23:58 -0400 From: To: Date: Mon, 2 Apr 2012 15:23:54 -0400 Subject: RE: Response to some comments on IS-IS VPLS Thread-Topic: Response to some comments on IS-IS VPLS Thread-Index: AQHNDauno12B0RP+lEO1DyVa7X7/s5aBlXMQgAAXd5D//5jvgIABHOVpgAApX6KAAAtTuIAEwdXAgAAdhLCAAHPX8A== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80A91@MX14A.corp.emc.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0CAE@szxeml525-mbs.china.huawei.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0E23@szxeml525-mbs.china.huawei.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80849@MX14A.corp.emc.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Mon, 02 Apr 2012 13:09:15 -0700 Cc: l2vpn@ietf.org, nvo3@ietf.org X-BeenThere: l2vpn@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, 02 Apr 2012 19:24:43 -0000 SmltLA0KDQo+IFtKaW0gVT5dIFNvLCBhIGNvdXBsZSBvZiBpdGVtcy4uIEJHUCBpcyBhIGdlbmVy YWwgcHVycG9zZSB0b29scyB0aGF0IGlzIHVzZWQgaW4gYSB2YXJpZXR5IG9mDQo+IGFwcGxpY2F0 aW9ucyB3aGVyZSBkaXNjb3ZlcnksIGR5bmFtaWMgc2lnbmFsaW5nIGV0Yy4uIGlzIHJlcXVpcmVk Li4gU28gZm9yIGEgbm9uLWNhcnJpZXIgZGF0YSBjZW50ZXIgSQ0KPiB3b3VsZCB0aGluayB0aGF0 IHRoZSBzYW1lIHJlcXMgd291bGQgYmUgbmVlZGVkIGV2ZW4gaWYgdGhlIHNjb3BlIGlzIGxpbWl0 ZWQgdG8gdGhhdCBzaW5nbGUgbm9uLWNhcnJpZXINCj4gZGF0YSBjZW50ZXIuLg0KDQpPaywgYnV0 IGRhdGEgY2VudGVycyB0ZW5kIHRvIHVzZSBtdWNoIHNpbXBsZXIgcm91dGluZyB0ZWNobm9sb2d5 LiAgQXMgS2lyZWV0aSBwb2ludHMgb3V0LCBtYW55IG5vbi1TUCBkYXRhIGNlbnRlcnMgdXNlIElH UHMgLSBPU1BGIHdpdGggRUNNUCBpcyBhIGNvbW1vbiBleGFtcGxlIHRoYXQgb25lIGNhbiBleHBl Y3QgdG8gc2VlIGluIHRoZSBJUCBuZXR3b3JrIHVuZGVybHlpbmcgdGhlIGVuY2Fwc3VsYXRpb24u ICBBbm90aGVyIGludGVyZXN0aW5nIHBvc3NpYmlsaXR5IGZvciBvdmVybGF5IGFkZHJlc3MgbWFw cGluZyBpcyB0aGUgc29ydCBvZiBkaXJlY3RvcnktYmFzZWQgaW5mcmFzdHJ1Y3R1cmUgbm93IGJl aW5nIHVzZWQgYnkgTElTUCAoSSdsbCBsZWF2ZSBpdCB0byB0aGUgTElTUCBmb2xrcyB0byBleHBs YWluIHdoYXQgdGhpcyBpcyBhbmQgaG93L3doeSBpdCBtYXkgYmUgaW50ZXJlc3RpbmcpLg0KDQo+ IElmIG9uZSB3ZXJlIHRvIGNvbnNpZGVyIGRlcGxveWluZyBhIHRlY2hub2xvZ3kgdG8gcmVhbGl6 ZSB0aGUgc2VydmljZSBuZWVkZWQgaXQgd291bGQNCj4gc2VlbSBwcnVkZW50IHRvIGNvbnNpZGVy IGFsbCBzb2x1dGlvbiBzcGFjZXMgYW5kIG5vdCBnZXQgY2F1Z2h0IHVwIGluIHRoZSBwZXJjZXB0 aW9uIG9yIHVzIHZzLiB0aGVtDQo+IG1lbnRhbGl0eS4uDQoNCkknbSBzb3JyeSwgYnV0IEJHUCdz IGNvbXBsZXhpdHkgKGUuZy4sIHBvbGljeSkgYnkgY29tcGFyaXNvbiB0byB0aGUgSUdQcyB0eXBp Y2FsbHkgdXNlZCBpbiBub24tY2FycmllciBkYXRhIGNlbnRlcnMgaXMgYSBtYXR0ZXIgb2YgZmFj dCwgbm90IHBlcmNlcHRpb24gb3Igb3Bpbmlvbi4gIE9UT0gsIEFsaWEncyBzdWdnZXN0aW9uIHRo YXQgYSBjdXQtZG93biBCR1AgcHJvZmlsZSBtaWdodCBiZSBhcHBsaWNhYmxlIGlzIGludGVyZXN0 aW5nLCBJTUhPLg0KDQpUaGFua3MsDQotLURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogVVRUQVJPLCBKQU1FUyBbbWFpbHRvOmp1MTczOEBhdHQuY29tXQ0KPiBT ZW50OiBNb25kYXksIEFwcmlsIDAyLCAyMDEyIDg6MTUgQU0NCj4gVG86IEJsYWNrLCBEYXZpZA0K PiBDYzogbDJ2cG5AaWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFJlc3Bv bnNlIHRvIHNvbWUgY29tbWVudHMgb24gSVMtSVMgVlBMUw0KPiANCj4gRGF2aWQsDQo+IA0KPiAJ Q29tbWVudHMgSW4tTGluZS4uLg0KPiANCj4gVGhhbmtzLA0KPiAJSmltIFV0dGFybw0KPiANCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZGF2aWQuYmxhY2tAZW1jLmNvbSBb bWFpbHRvOmRhdmlkLmJsYWNrQGVtYy5jb21dDQo+IFNlbnQ6IE1vbmRheSwgQXByaWwgMDIsIDIw MTIgNjozNiBBTQ0KPiBUbzogVVRUQVJPLCBKQU1FUw0KPiBDYzogbDJ2cG5AaWV0Zi5vcmc7IG52 bzNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFJlc3BvbnNlIHRvIHNvbWUgY29tbWVudHMgb24g SVMtSVMgVlBMUw0KPiANCj4gSmFtZXMsDQo+IA0KPiBJIGJlbGlldmUgdGhlIHNvbHV0aW9uIHBy ZWZlcmVuY2Ugc3RhcnRzIGZyb20gdGhpcyBiZWxpZWYgYWJvdXQgZGF0YSBjZW50ZXIgYXJjaGl0 ZWN0dXJlOg0KPiANCj4gPj4gSSBiZWxpZXZlIHRoYXQgdGhlIGRhdGEgY2VudGVyIGlzIGJlY29t aW5nIG1vcmUgYW5kIG1vcmUgYQ0KPiA+PiBkeW5hbWljIGV4dGVuc2lvbiBvZiBhIGN1c3RvbWVy wrlzIG5ldHdvcmsuDQo+IA0KPiBVbmRlciB0aGF0IGFzc3VtcHRpb24sIGZvciBhIGNhcnJpZXIg d2hvc2UgbmV0d29yayBpcyBiYXNlZCBvbiBuZXR3b3JraW5nIHRlY2hub2xvZ2llcyBsaWtlIEJH UCwNCj4gZXh0ZW5kaW5nIHRob3NlIHRlY2hub2xvZ2llcyBpbnRvIGEgZGF0YSBjZW50ZXIgaXMg YSBmaW5lIHRoaW5nIHRvIGRvLCBhbmQgbm90aGluZyBpbiB0aGUgbnZvMyB3b3JrIGlzDQo+IGlu dGVuZGVkIHRvIHN0b3AgdGhhdC4NCj4gDQo+IE9UT0gsIGZvciBhIG5vbi1jYXJyaWVyIGRhdGEg Y2VudGVyIChlLmcuLCBlbnRlcnByaXNlKSwgbm90IG9ubHkgaXMgdGhlIGFib3ZlIHN0YXRlbWVu dCByYXRoZXINCj4gaW5jb3JyZWN0LCBidXQgdGhlIGVudGVycHJpc2UgbmV0d29yayBtYXkgbm90 IGJlIHJ1bm5pbmcgQkdQLiAgVGhpcyBjYW4gYmUgcGFydGljdWxhcmx5IHNvIGZvciBhIGRhdGEN Cj4gY2VudGVyIHRoYXQgZGVzaXJlcyBmbGV4aWJpbGl0eSBpbiBjaG9pY2UgYW1vbmcgY2Fycmll cnMsIGFuZCBoZW5jZSBvcGVyYXRlcyB1bmRlciB0aGUgcHJpbmNpcGxlIHRoYXQNCj4gb25lIG9m IHRoZSBqb2JzIG9mIHRoZSBDUEUgYm94IGlzIHRvIGtlZXAgdGhlIGNhcnJpZXIgdGVjaG5vbG9n eSBvbiB0aGUgb3RoZXIgc2lkZSBpbiBvcmRlciB0byBsaW1pdA0KPiBsb2NrLWluLiAgVGhlIG52 bzMgd29yayBpcyB0YXJnZXRlZCBhdCB0aGUgc29ydCBvZiB1c2UgY2FzZXMgZGVzY3JpYmVkIGlu IHRoaXMgcGFyYWdyYXBoLg0KPiBbSmltIFU+XSBTbywgYSBjb3VwbGUgb2YgaXRlbXMuLiBCR1Ag aXMgYSBnZW5lcmFsIHB1cnBvc2UgdG9vbHMgdGhhdCBpcyB1c2VkIGluIGEgdmFyaWV0eSBvZg0K PiBhcHBsaWNhdGlvbnMgd2hlcmUgZGlzY292ZXJ5LCBkeW5hbWljIHNpZ25hbGluZyBldGMuLiBp cyByZXF1aXJlZC4uIFNvIGZvciBhIG5vbi1jYXJyaWVyIGRhdGEgY2VudGVyIEkNCj4gd291bGQg dGhpbmsgdGhhdCB0aGUgc2FtZSByZXFzIHdvdWxkIGJlIG5lZWRlZCBldmVuIGlmIHRoZSBzY29w ZSBpcyBsaW1pdGVkIHRvIHRoYXQgc2luZ2xlIG5vbi1jYXJyaWVyDQo+IGRhdGEgY2VudGVyLi4g SWYgb25lIHdlcmUgdG8gY29uc2lkZXIgZGVwbG95aW5nIGEgdGVjaG5vbG9neSB0byByZWFsaXpl IHRoZSBzZXJ2aWNlIG5lZWRlZCBpdCB3b3VsZA0KPiBzZWVtIHBydWRlbnQgdG8gY29uc2lkZXIg YWxsIHNvbHV0aW9uIHNwYWNlcyBhbmQgbm90IGdldCBjYXVnaHQgdXAgaW4gdGhlIHBlcmNlcHRp b24gb3IgdXMgdnMuIHRoZW0NCj4gbWVudGFsaXR5Li4gVGhlIG90aGVyIG5vdGlvbiBoZXJlIGlz IHRoYXQgdXNpbmcgQkdQIHNvbWVob3cgcHJldmVudHMgaXNvbGF0aW9uIG9yIGxpbWl0cyBzZWxl Y3Rpb24gb2YNCj4gZGlmZmVyZW50IHByb3ZpZGVycywgbmVpdGhlciBvZiB0aGVzZSBhc3N1bXB0 aW9ucyBoYXZlIGJlZW4gcHJvdmVuIHRvIGJlIHRydWUgaW4gb3RoZXIgYXBwbGljYXRpb25zDQo+ IHRoYXQgdXNlIEJHUC4uDQo+IA0KPiBUaGlzIHNvcnQgb2Ygc3Bpcml0ZWQgcHJvbW90aW9uIG9m IEJHUCBjb21lcyBhY3Jvc3MgYXMgYW4gYXR0ZW1wdCB0byBmb3JjZSBhIG9uZS1zaXplLWZpdHMt YWxsDQo+IHNvbHV0aW9uIG9uIHRob3NlIHdobyBkbyBub3QgY3VycmVudGx5IHVzZSBCR1AuICBJ IGFtICoqTk9UKiogYXJndWluZyB0aGF0IEJHUCBjYW4ndCBiZSBtYWRlIHRvIHdvcms7DQo+IEkg YW0gYXJndWluZyB0aGF0IGl0J3MgYSBwb29yIGZpdCBmb3IgdGhlIHVzZSBjYXNlcyBvZiBpbnRl cmVzdC4NCj4gW0ppbSBVPl0gSSBkbyBub3QgYWdyZWUuLiBCR1AgcGVybWl0cyB0aGUgZXZvbHV0 aW9uIG9mIHRoZSBzZXJ2aWNlcyBzdWNoIHRoYXQgYW55IGFuZCBhbGwgZGF0YSBjZW50ZXJzDQo+ IGNhbiBwYXJ0aWNpcGF0ZSBpbiBwcm92aWRpbmcgc2VydmljZSwgYW5kIGFudGljaXBhdGVzIHVz ZSBjYXNlcyBjdXJyZW50bHkgbm90IGNvbnNpZGVyZWQgc3VjaCBhcw0KPiBtdWx0aXBsZSBkYXRh IGNlbnRlcnMgYWNyb3NzIGNvbXBhbmllcyBwcm92aWRpbmcgc2VydmljZSBmb3IgYSBnaXZlbiBj dXN0b21lciBpbiBhIGNvb3BlcmF0aXZlDQo+IG1hbm5lci4uIEkgZG8gbm90IHNlZSBob3cgdGhl IHNvbHV0aW9ucyBvciBhc3N1bXB0aW9ucyBtYWRlIGluIE5WTzMgY2FwdHVyZSB0aGlzLi4uDQo+ IA0KPiBUaGFua3MsDQo+IC0tRGF2aWQNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBEYXZpZCBMLiBCbGFjaywgRGlzdGluZ3Vpc2hlZCBF bmdpbmVlcg0KPiBFTUMgQ29ycG9yYXRpb24sIDE3NiBTb3V0aCBTdC4sIEhvcGtpbnRvbiwgTUHC oCAwMTc0OA0KPiArMSAoNTA4KSAyOTMtNzk1M8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBGQVg6 ICsxICg1MDgpIDI5My03Nzg2DQo+IGRhdmlkLmJsYWNrQGVtYy5jb23CoMKgwqDCoMKgwqDCoCBN b2JpbGU6ICsxICg5NzgpIDM5NC03NzU0DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== From david.black@emc.com Mon Apr 2 12:34:49 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46A221F86FE; Mon, 2 Apr 2012 12:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.098 X-Spam-Level: X-Spam-Status: No, score=-110.098 tagged_above=-999 required=5 tests=[AWL=0.501, 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 ANSKw9bvknl4; Mon, 2 Apr 2012 12:34:49 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1023C21F86F9; Mon, 2 Apr 2012 12:34:48 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q32JYjFm023023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Apr 2012 15:34:48 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Mon, 2 Apr 2012 15:34:19 -0400 Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q32JYIBE023286; Mon, 2 Apr 2012 15:34:18 -0400 Received: from mx14a.corp.emc.com ([169.254.1.70]) by mxhub32.corp.emc.com ([128.222.70.172]) with mapi; Mon, 2 Apr 2012 15:34:18 -0400 From: To: Date: Mon, 2 Apr 2012 15:34:16 -0400 Subject: RE: Response to some comments on IS-IS VPLS Thread-Topic: Response to some comments on IS-IS VPLS Thread-Index: Ac0RAo9D0ecHoJelR+G7SqfWLEefIgAA6AMw Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80AAC@MX14A.corp.emc.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0CAE@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0E23@szxeml525-mbs.china.huawei.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80849@MX14A.corp.emc.com> 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-EMM-MHVC: 1 X-Mailman-Approved-At: Mon, 02 Apr 2012 13:09:16 -0700 Cc: l2vpn@ietf.org, nvo3@ietf.org X-BeenThere: l2vpn@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, 02 Apr 2012 19:34:49 -0000 Hi Kireeti, We're in agreement, and thank you for your comments at the BOF. Here are a= few elaborations: > > OTOH, for a non-carrier data center (e.g., enterprise), not only is the= above statement rather > incorrect, but the enterprise network may not be running BGP. >=20 > Step back a bit. The non-carrier DC is not being asked to run BGP. Sure - you and I agree on this, but Jim wants to push BGP into non-carrier = data centers ... perhaps you can help convince him otherwise ... > The _cloud_ operator, in order to > scale their DC, of which the non-carrier DC is just a tenant, may want to= run BGP. Just as > enterprises running OSPF get connectivity services from carriers running = BGP. I absolutely agree, and nvo3 is applicable to non-carrier DCs. > > This can be particularly so for a data center that desires flexibility = in choice among carriers, >=20 > Actually, BGP is what carriers talk to each other, so I'm not sure how su= ch a > choice limits flexibility. If one extends the carrier's BGP instance into the data center, switching c= arriers becomes more difficult by comparison to ... > > and hence operates under the principle that one of the jobs of the CPE = box is to keep the carrier > technology on the other side in order to limit lock-in. >=20 > The "other" side of a CPE box usually runs BGP. ... having the CPE box do its job in keeping the carrier's instance of BGP = on the carrier's side ("other" side of the box) where the carrier's admins = can manage it without having to bother the data center admins much. Thanks, --David > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Monday, April 02, 2012 2:58 PM > To: Black, David > Cc: ju1738@att.com; l2vpn@ietf.org; nvo3@ietf.org > Subject: Re: Response to some comments on IS-IS VPLS >=20 > Interesting discussion! (Thomas, see what one small sub-bullet can lead = to :-)) >=20 > See more inline. >=20 > On Apr 2, 2012, at 3:46, "david.black@emc.com" wrot= e: >=20 > > Under that assumption, for a carrier whose network is based on networki= ng technologies like BGP, > extending those technologies into a data center is a fine thing to do, an= d nothing in the nvo3 work is > intended to stop that. > > > > OTOH, for a non-carrier data center (e.g., enterprise), not only is the= above statement rather > incorrect, but the enterprise network may not be running BGP. >=20 > Step back a bit. The non-carrier DC is not being asked to run BGP. The _c= loud_ operator, in order to > scale their DC, of which the non-carrier DC is just a tenant, may want to= run BGP. Just as > enterprises running OSPF get connectivity services from carriers running = BGP. >=20 > > This can be particularly so for a data center that desires flexibility = in choice among carriers, >=20 > Actually, BGP is what carriers talk to each other, so I'm not sure how su= ch a choice limits > flexibility. >=20 > > and hence operates under the principle that one of the jobs of the CPE = box is to keep the carrier > technology on the other side in order to limit lock-in. >=20 > The "other" side of a CPE box usually runs BGP. >=20 > Kireeti >=20 > > The nvo3 work is targeted at the sort of use cases described in this pa= ragraph. >=20 From david.black@emc.com Mon Apr 2 13:09:00 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022BB21F8638; Mon, 2 Apr 2012 13:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.181 X-Spam-Level: X-Spam-Status: No, score=-110.181 tagged_above=-999 required=5 tests=[AWL=0.418, 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 KfEvhY1eJyLT; Mon, 2 Apr 2012 13:08:59 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 011CF21F871C; Mon, 2 Apr 2012 13:08:58 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q32K8gNh023523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Apr 2012 16:08:55 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 2 Apr 2012 16:08:34 -0400 Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.222.70.236]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q32K8Xho001301; Mon, 2 Apr 2012 16:08:33 -0400 Received: from mx14a.corp.emc.com ([169.254.1.70]) by mxhub15.corp.emc.com ([128.222.70.236]) with mapi; Mon, 2 Apr 2012 16:08:33 -0400 From: To: Date: Mon, 2 Apr 2012 16:08:31 -0400 Subject: RE: Response to some comments on IS-IS VPLS Thread-Topic: Response to some comments on IS-IS VPLS Thread-Index: AQHNDauno12B0RP+lEO1DyVa7X7/s5aBlXMQgAAXd5D//5jvgIABHOVpgAApX6KAAAtTuIAEwdXAgAAdhLCAAHPX8IAADSGQgAAFczA= Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80AD7@MX14A.corp.emc.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0CAE@szxeml525-mbs.china.huawei.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0E23@szxeml525-mbs.china.huawei.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80849@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80A91@MX14A.corp.emc.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Mon, 02 Apr 2012 13:09:16 -0700 Cc: l2vpn@ietf.org, nvo3@ietf.org X-BeenThere: l2vpn@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, 02 Apr 2012 20:09:00 -0000 PiBJIHRoaW5rIHRoYXQgbWF5YmUgYSBnb29kIHN0YXJ0aW5nIHBvaW50IHdvdWxkIGJlIHRvIHN0 YXJ0IHRvIGJ1aWxkIGEgc2V0IG9mIHJlcXMgdGhhdCBtaWdodCBtZWV0IGJvdGgNCj4gU1AvREMg cmVxcyB3aXRoIGFuIGV5ZSB0b3dhcmRzIGV2b2x2aW5nIGludG8gdGhlIGZ1dHVyZS4uDQoNCkFs bG93IG1lIHRvIHN1Z2dlc3QgZHJhZnQta3JlZWdlci1udm8zLW92ZXJsYXktY3AtMDAgYXMgYSBz dGFydGluZyBwb2ludCAuLi4NCg0KVGhhbmtzLA0KLS1EYXZpZA0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IFVUVEFSTywgSkFNRVMgW21haWx0bzpqdTE3MzhAYXR0LmNv bV0NCj4gU2VudDogTW9uZGF5LCBBcHJpbCAwMiwgMjAxMiAzOjUyIFBNDQo+IFRvOiBCbGFjaywg RGF2aWQNCj4gQ2M6IGwydnBuQGlldGYub3JnOyBudm8zQGlldGYub3JnDQo+IFN1YmplY3Q6IFJF OiBSZXNwb25zZSB0byBzb21lIGNvbW1lbnRzIG9uIElTLUlTIFZQTFMNCj4gDQo+IERhdmlkLA0K PiANCj4gSSB0aGluayB0aGF0IG1heWJlIGEgZ29vZCBzdGFydGluZyBwb2ludCB3b3VsZCBiZSB0 byBzdGFydCB0byBidWlsZCBhIHNldCBvZiByZXFzIHRoYXQgbWlnaHQgbWVldCBib3RoDQo+IFNQ L0RDIHJlcXMgd2l0aCBhbiBleWUgdG93YXJkcyBldm9sdmluZyBpbnRvIHRoZSBmdXR1cmUuLkNv bW1lbnRzIEluLUxpbmUuLg0KPiANCj4gVGhhbmtzLA0KPiAJSmltIFV0dGFybw0KPiANCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZGF2aWQuYmxhY2tAZW1jLmNvbSBbbWFp bHRvOmRhdmlkLmJsYWNrQGVtYy5jb21dDQo+IFNlbnQ6IE1vbmRheSwgQXByaWwgMDIsIDIwMTIg MzoyNCBQTQ0KPiBUbzogVVRUQVJPLCBKQU1FUw0KPiBDYzogbDJ2cG5AaWV0Zi5vcmc7IG52bzNA aWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFJlc3BvbnNlIHRvIHNvbWUgY29tbWVudHMgb24gSVMt SVMgVlBMUw0KPiANCj4gSmltLA0KPiANCj4gPiBbSmltIFU+XSBTbywgYSBjb3VwbGUgb2YgaXRl bXMuLiBCR1AgaXMgYSBnZW5lcmFsIHB1cnBvc2UgdG9vbHMgdGhhdCBpcyB1c2VkIGluIGEgdmFy aWV0eSBvZg0KPiA+IGFwcGxpY2F0aW9ucyB3aGVyZSBkaXNjb3ZlcnksIGR5bmFtaWMgc2lnbmFs aW5nIGV0Yy4uIGlzIHJlcXVpcmVkLi4gU28gZm9yIGEgbm9uLWNhcnJpZXIgZGF0YSBjZW50ZXIN Cj4gSQ0KPiA+IHdvdWxkIHRoaW5rIHRoYXQgdGhlIHNhbWUgcmVxcyB3b3VsZCBiZSBuZWVkZWQg ZXZlbiBpZiB0aGUgc2NvcGUgaXMgbGltaXRlZCB0byB0aGF0IHNpbmdsZSBub24tDQo+IGNhcnJp ZXINCj4gPiBkYXRhIGNlbnRlci4uDQo+IA0KPiBPaywgYnV0IGRhdGEgY2VudGVycyB0ZW5kIHRv IHVzZSBtdWNoIHNpbXBsZXIgcm91dGluZyB0ZWNobm9sb2d5LiAgQXMgS2lyZWV0aSBwb2ludHMg b3V0LCBtYW55IG5vbi1TUA0KPiBkYXRhIGNlbnRlcnMgdXNlIElHUHMgLSBPU1BGIHdpdGggRUNN UCBpcyBhIGNvbW1vbiBleGFtcGxlIHRoYXQgb25lIGNhbiBleHBlY3QgdG8gc2VlIGluIHRoZSBJ UA0KPiBuZXR3b3JrIHVuZGVybHlpbmcgdGhlIGVuY2Fwc3VsYXRpb24uICBBbm90aGVyIGludGVy ZXN0aW5nIHBvc3NpYmlsaXR5IGZvciBvdmVybGF5IGFkZHJlc3MgbWFwcGluZyBpcw0KPiB0aGUg c29ydCBvZiBkaXJlY3RvcnktYmFzZWQgaW5mcmFzdHJ1Y3R1cmUgbm93IGJlaW5nIHVzZWQgYnkg TElTUCAoSSdsbCBsZWF2ZSBpdCB0byB0aGUgTElTUCBmb2xrcyB0bw0KPiBleHBsYWluIHdoYXQg dGhpcyBpcyBhbmQgaG93L3doeSBpdCBtYXkgYmUgaW50ZXJlc3RpbmcpLg0KPiBbSmltIFU+XSBI bW1tLi4gTElTUCBsaWtlIHRlY2hub2xvZ3kgY291bGQgYmUgaW50ZXJlc3RpbmcuLg0KPiANCj4g PiBJZiBvbmUgd2VyZSB0byBjb25zaWRlciBkZXBsb3lpbmcgYSB0ZWNobm9sb2d5IHRvIHJlYWxp emUgdGhlIHNlcnZpY2UgbmVlZGVkIGl0IHdvdWxkDQo+ID4gc2VlbSBwcnVkZW50IHRvIGNvbnNp ZGVyIGFsbCBzb2x1dGlvbiBzcGFjZXMgYW5kIG5vdCBnZXQgY2F1Z2h0IHVwIGluIHRoZSBwZXJj ZXB0aW9uIG9yIHVzIHZzLiB0aGVtDQo+ID4gbWVudGFsaXR5Li4NCj4gDQo+IEknbSBzb3JyeSwg YnV0IEJHUCdzIGNvbXBsZXhpdHkgKGUuZy4sIHBvbGljeSkgYnkgY29tcGFyaXNvbiB0byB0aGUg SUdQcyB0eXBpY2FsbHkgdXNlZCBpbiBub24tY2Fycmllcg0KPiBkYXRhIGNlbnRlcnMgaXMgYSBt YXR0ZXIgb2YgZmFjdCwgbm90IHBlcmNlcHRpb24gb3Igb3Bpbmlvbi4gIE9UT0gsIEFsaWEncyBz dWdnZXN0aW9uIHRoYXQgYSBjdXQtZG93bg0KPiBCR1AgcHJvZmlsZSBtaWdodCBiZSBhcHBsaWNh YmxlIGlzIGludGVyZXN0aW5nLCBJTUhPLg0KPiBbSmltIFU+XSBZZXMgQWxpYSBtYWtlcyBhIGdy ZWF0IHNlbGVjdGlvbiBoZXJlLi4gSWYgd2UgY2FuIGRldGVybWluZSB0aGUgcmVxcyB0aGVyZSBj b3VsZCBiZSBhbg0KPiBvcHBvcnR1bml0eSB0byB1c2UgYSBCR1AgUHJvZmlsZSBpbiB0aGUgREMg dGhhdCBjb3VsZCBiZSBlYXNpbHkgZXh0ZW5kZWQNCj4gDQo+IFRoYW5rcywNCj4gLS1EYXZpZA0K PiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFVUVEFSTywgSkFN RVMgW21haWx0bzpqdTE3MzhAYXR0LmNvbV0NCj4gPiBTZW50OiBNb25kYXksIEFwcmlsIDAyLCAy MDEyIDg6MTUgQU0NCj4gPiBUbzogQmxhY2ssIERhdmlkDQo+ID4gQ2M6IGwydnBuQGlldGYub3Jn OyBudm8zQGlldGYub3JnDQo+ID4gU3ViamVjdDogUkU6IFJlc3BvbnNlIHRvIHNvbWUgY29tbWVu dHMgb24gSVMtSVMgVlBMUw0KPiA+DQo+ID4gRGF2aWQsDQo+ID4NCj4gPiAJQ29tbWVudHMgSW4t TGluZS4uLg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IAlKaW0gVXR0YXJvDQo+ID4NCj4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IGRhdmlkLmJsYWNrQGVtYy5jb20gW21h aWx0bzpkYXZpZC5ibGFja0BlbWMuY29tXQ0KPiA+IFNlbnQ6IE1vbmRheSwgQXByaWwgMDIsIDIw MTIgNjozNiBBTQ0KPiA+IFRvOiBVVFRBUk8sIEpBTUVTDQo+ID4gQ2M6IGwydnBuQGlldGYub3Jn OyBudm8zQGlldGYub3JnDQo+ID4gU3ViamVjdDogUkU6IFJlc3BvbnNlIHRvIHNvbWUgY29tbWVu dHMgb24gSVMtSVMgVlBMUw0KPiA+DQo+ID4gSmFtZXMsDQo+ID4NCj4gPiBJIGJlbGlldmUgdGhl IHNvbHV0aW9uIHByZWZlcmVuY2Ugc3RhcnRzIGZyb20gdGhpcyBiZWxpZWYgYWJvdXQgZGF0YSBj ZW50ZXIgYXJjaGl0ZWN0dXJlOg0KPiA+DQo+ID4gPj4gSSBiZWxpZXZlIHRoYXQgdGhlIGRhdGEg Y2VudGVyIGlzIGJlY29taW5nIG1vcmUgYW5kIG1vcmUgYQ0KPiA+ID4+IGR5bmFtaWMgZXh0ZW5z aW9uIG9mIGEgY3VzdG9tZXLCuXMgbmV0d29yay4NCj4gPg0KPiA+IFVuZGVyIHRoYXQgYXNzdW1w dGlvbiwgZm9yIGEgY2FycmllciB3aG9zZSBuZXR3b3JrIGlzIGJhc2VkIG9uIG5ldHdvcmtpbmcg dGVjaG5vbG9naWVzIGxpa2UgQkdQLA0KPiA+IGV4dGVuZGluZyB0aG9zZSB0ZWNobm9sb2dpZXMg aW50byBhIGRhdGEgY2VudGVyIGlzIGEgZmluZSB0aGluZyB0byBkbywgYW5kIG5vdGhpbmcgaW4g dGhlIG52bzMgd29yaw0KPiBpcw0KPiA+IGludGVuZGVkIHRvIHN0b3AgdGhhdC4NCj4gPg0KPiA+ IE9UT0gsIGZvciBhIG5vbi1jYXJyaWVyIGRhdGEgY2VudGVyIChlLmcuLCBlbnRlcnByaXNlKSwg bm90IG9ubHkgaXMgdGhlIGFib3ZlIHN0YXRlbWVudCByYXRoZXINCj4gPiBpbmNvcnJlY3QsIGJ1 dCB0aGUgZW50ZXJwcmlzZSBuZXR3b3JrIG1heSBub3QgYmUgcnVubmluZyBCR1AuICBUaGlzIGNh biBiZSBwYXJ0aWN1bGFybHkgc28gZm9yIGENCj4gZGF0YQ0KPiA+IGNlbnRlciB0aGF0IGRlc2ly ZXMgZmxleGliaWxpdHkgaW4gY2hvaWNlIGFtb25nIGNhcnJpZXJzLCBhbmQgaGVuY2Ugb3BlcmF0 ZXMgdW5kZXIgdGhlIHByaW5jaXBsZQ0KPiB0aGF0DQo+ID4gb25lIG9mIHRoZSBqb2JzIG9mIHRo ZSBDUEUgYm94IGlzIHRvIGtlZXAgdGhlIGNhcnJpZXIgdGVjaG5vbG9neSBvbiB0aGUgb3RoZXIg c2lkZSBpbiBvcmRlciB0byBsaW1pdA0KPiA+IGxvY2staW4uICBUaGUgbnZvMyB3b3JrIGlzIHRh cmdldGVkIGF0IHRoZSBzb3J0IG9mIHVzZSBjYXNlcyBkZXNjcmliZWQgaW4gdGhpcyBwYXJhZ3Jh cGguDQo+ID4gW0ppbSBVPl0gU28sIGEgY291cGxlIG9mIGl0ZW1zLi4gQkdQIGlzIGEgZ2VuZXJh bCBwdXJwb3NlIHRvb2xzIHRoYXQgaXMgdXNlZCBpbiBhIHZhcmlldHkgb2YNCj4gPiBhcHBsaWNh dGlvbnMgd2hlcmUgZGlzY292ZXJ5LCBkeW5hbWljIHNpZ25hbGluZyBldGMuLiBpcyByZXF1aXJl ZC4uIFNvIGZvciBhIG5vbi1jYXJyaWVyIGRhdGEgY2VudGVyDQo+IEkNCj4gPiB3b3VsZCB0aGlu ayB0aGF0IHRoZSBzYW1lIHJlcXMgd291bGQgYmUgbmVlZGVkIGV2ZW4gaWYgdGhlIHNjb3BlIGlz IGxpbWl0ZWQgdG8gdGhhdCBzaW5nbGUgbm9uLQ0KPiBjYXJyaWVyDQo+ID4gZGF0YSBjZW50ZXIu LiBJZiBvbmUgd2VyZSB0byBjb25zaWRlciBkZXBsb3lpbmcgYSB0ZWNobm9sb2d5IHRvIHJlYWxp emUgdGhlIHNlcnZpY2UgbmVlZGVkIGl0IHdvdWxkDQo+ID4gc2VlbSBwcnVkZW50IHRvIGNvbnNp ZGVyIGFsbCBzb2x1dGlvbiBzcGFjZXMgYW5kIG5vdCBnZXQgY2F1Z2h0IHVwIGluIHRoZSBwZXJj ZXB0aW9uIG9yIHVzIHZzLiB0aGVtDQo+ID4gbWVudGFsaXR5Li4gVGhlIG90aGVyIG5vdGlvbiBo ZXJlIGlzIHRoYXQgdXNpbmcgQkdQIHNvbWVob3cgcHJldmVudHMgaXNvbGF0aW9uIG9yIGxpbWl0 cyBzZWxlY3Rpb24NCj4gb2YNCj4gPiBkaWZmZXJlbnQgcHJvdmlkZXJzLCBuZWl0aGVyIG9mIHRo ZXNlIGFzc3VtcHRpb25zIGhhdmUgYmVlbiBwcm92ZW4gdG8gYmUgdHJ1ZSBpbiBvdGhlciBhcHBs aWNhdGlvbnMNCj4gPiB0aGF0IHVzZSBCR1AuLg0KPiA+DQo+ID4gVGhpcyBzb3J0IG9mIHNwaXJp dGVkIHByb21vdGlvbiBvZiBCR1AgY29tZXMgYWNyb3NzIGFzIGFuIGF0dGVtcHQgdG8gZm9yY2Ug YSBvbmUtc2l6ZS1maXRzLWFsbA0KPiA+IHNvbHV0aW9uIG9uIHRob3NlIHdobyBkbyBub3QgY3Vy cmVudGx5IHVzZSBCR1AuICBJIGFtICoqTk9UKiogYXJndWluZyB0aGF0IEJHUCBjYW4ndCBiZSBt YWRlIHRvDQo+IHdvcms7DQo+ID4gSSBhbSBhcmd1aW5nIHRoYXQgaXQncyBhIHBvb3IgZml0IGZv ciB0aGUgdXNlIGNhc2VzIG9mIGludGVyZXN0Lg0KPiA+IFtKaW0gVT5dIEkgZG8gbm90IGFncmVl Li4gQkdQIHBlcm1pdHMgdGhlIGV2b2x1dGlvbiBvZiB0aGUgc2VydmljZXMgc3VjaCB0aGF0IGFu eSBhbmQgYWxsIGRhdGENCj4gY2VudGVycw0KPiA+IGNhbiBwYXJ0aWNpcGF0ZSBpbiBwcm92aWRp bmcgc2VydmljZSwgYW5kIGFudGljaXBhdGVzIHVzZSBjYXNlcyBjdXJyZW50bHkgbm90IGNvbnNp ZGVyZWQgc3VjaCBhcw0KPiA+IG11bHRpcGxlIGRhdGEgY2VudGVycyBhY3Jvc3MgY29tcGFuaWVz IHByb3ZpZGluZyBzZXJ2aWNlIGZvciBhIGdpdmVuIGN1c3RvbWVyIGluIGEgY29vcGVyYXRpdmUN Cj4gPiBtYW5uZXIuLiBJIGRvIG5vdCBzZWUgaG93IHRoZSBzb2x1dGlvbnMgb3IgYXNzdW1wdGlv bnMgbWFkZSBpbiBOVk8zIGNhcHR1cmUgdGhpcy4uLg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IC0t RGF2aWQNCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+ID4gRGF2aWQgTC4gQmxhY2ssIERpc3Rpbmd1aXNoZWQgRW5naW5lZXINCj4gPiBF TUMgQ29ycG9yYXRpb24sIDE3NiBTb3V0aCBTdC4sIEhvcGtpbnRvbiwgTUHCoCAwMTc0OA0KPiA+ ICsxICg1MDgpIDI5My03OTUzwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEZBWDogKzEgKDUwOCkg MjkzLTc3ODYNCj4gPiBkYXZpZC5ibGFja0BlbWMuY29twqDCoMKgwqDCoMKgwqAgTW9iaWxlOiAr MSAoOTc4KSAzOTQtNzc1NA0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg== From prvs=9439a02467=hshah@ciena.com Mon Apr 2 13:27:07 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A363021F85F9; Mon, 2 Apr 2012 13:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 eeTecZSPJ0Z7; Mon, 2 Apr 2012 13:27:06 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id AA48B21F85C7; Mon, 2 Apr 2012 13:27:06 -0700 (PDT) Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q32KPInY002429; Mon, 2 Apr 2012 16:27:03 -0400 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id 13yh3ggm4r-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 02 Apr 2012 16:27:02 -0400 Received: from MDWEXCHCGSIHT01.ciena.com (10.4.140.106) by MDWEXGHT01.ciena.com (10.4.140.138) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 2 Apr 2012 16:27:03 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXCHCGSIHT01.ciena.com ([::1]) with mapi; Mon, 2 Apr 2012 16:27:02 -0400 From: "Shah, Himanshu" To: "UTTARO, JAMES" , "'david.black@emc.com'" Date: Mon, 2 Apr 2012 16:27:00 -0400 Subject: RE: Response to some comments on IS-IS VPLS Thread-Topic: Response to some comments on IS-IS VPLS Thread-Index: AQHNDauno12B0RP+lEO1DyVa7X7/s5aBlXMQgAAXd5D//5jvgIABHOVpgAApX6KAAAtTuIAEwdXAgAAdhLCAAHPX8IAADSGQgAAJAsA= Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0CAE@szxeml525-mbs.china.huawei.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0E23@szxeml525-mbs.china.huawei.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80849@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80A91@MX14A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-TM-AS-Product-Ver: SMEX-10.0.0.1412-6.800.1017-18814.001 X-TM-AS-Result: No--32.043500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-04-02_03:2012-04-02, 2012-04-02, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1204020226 Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" X-BeenThere: l2vpn@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, 02 Apr 2012 20:27:07 -0000 V2hpbGUgaXQgbWlnaHQgYmUgZ29vZCB0byB0YWxrIGFib3V0IHRoZSBCR1AtbGlnaHQvc3VwZXJs aWdodC9mZWF0aGVyd2VpZ2h0IGZvciBpbnRyYS1EQyAoZW50ZXJwcmlzZSkgc29sdXRpb24sDQpp dCBpcyBoYXJkIHRvIGV4cGxhaW4gYXdheSByZWx1Y3RhbmNlIChvZiBEQyBvcGVyYXRvcnMpIGJh c2VkIG9uIHZhbGlkIGNvbmNlcm5zIChkaXNjdXNzZWQgYWxyZWFkeSBvbiB0aGlzIHRocmVhZCku DQogDQpJIGhvcGUgd2UgZG8gbm90IGNvbnN1bWUgdGhlIE5WTzMgd2l0aCBleHBsYWluLXRvLW1l LXdoeS1iZ3AtaXMtbm90LWdvb2QtZW5vdWdoIGFnYWluLWFuZC1hZ2Fpbi4NCg0KVGhhbmtzLA0K aGltYW5zaHUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG52bzMtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFVU VEFSTywgSkFNRVMNClNlbnQ6IE1vbmRheSwgQXByaWwgMDIsIDIwMTIgMzo1MiBQTQ0KVG86ICdk YXZpZC5ibGFja0BlbWMuY29tJw0KQ2M6IGwydnBuQGlldGYub3JnOyBudm8zQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW252bzNdIFJlc3BvbnNlIHRvIHNvbWUgY29tbWVudHMgb24gSVMtSVMgVlBM Uw0KDQpEYXZpZCwNCg0KSSB0aGluayB0aGF0IG1heWJlIGEgZ29vZCBzdGFydGluZyBwb2ludCB3 b3VsZCBiZSB0byBzdGFydCB0byBidWlsZCBhIHNldCBvZiByZXFzIHRoYXQgbWlnaHQgbWVldCBi b3RoIFNQL0RDIHJlcXMgd2l0aCBhbiBleWUgdG93YXJkcyBldm9sdmluZyBpbnRvIHRoZSBmdXR1 cmUuLkNvbW1lbnRzIEluLUxpbmUuLg0KDQpUaGFua3MsDQoJSmltIFV0dGFybw0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZGF2aWQuYmxhY2tAZW1jLmNvbSBbbWFpbHRvOmRh dmlkLmJsYWNrQGVtYy5jb21dIA0KU2VudDogTW9uZGF5LCBBcHJpbCAwMiwgMjAxMiAzOjI0IFBN DQpUbzogVVRUQVJPLCBKQU1FUw0KQ2M6IGwydnBuQGlldGYub3JnOyBudm8zQGlldGYub3JnDQpT dWJqZWN0OiBSRTogUmVzcG9uc2UgdG8gc29tZSBjb21tZW50cyBvbiBJUy1JUyBWUExTDQoNCkpp bSwNCg0KPiBbSmltIFU+XSBTbywgYSBjb3VwbGUgb2YgaXRlbXMuLiBCR1AgaXMgYSBnZW5lcmFs IHB1cnBvc2UgdG9vbHMgdGhhdCBpcyB1c2VkIGluIGEgdmFyaWV0eSBvZg0KPiBhcHBsaWNhdGlv bnMgd2hlcmUgZGlzY292ZXJ5LCBkeW5hbWljIHNpZ25hbGluZyBldGMuLiBpcyByZXF1aXJlZC4u IFNvIGZvciBhIG5vbi1jYXJyaWVyIGRhdGEgY2VudGVyIEkNCj4gd291bGQgdGhpbmsgdGhhdCB0 aGUgc2FtZSByZXFzIHdvdWxkIGJlIG5lZWRlZCBldmVuIGlmIHRoZSBzY29wZSBpcyBsaW1pdGVk IHRvIHRoYXQgc2luZ2xlIG5vbi1jYXJyaWVyDQo+IGRhdGEgY2VudGVyLi4NCg0KT2ssIGJ1dCBk YXRhIGNlbnRlcnMgdGVuZCB0byB1c2UgbXVjaCBzaW1wbGVyIHJvdXRpbmcgdGVjaG5vbG9neS4g IEFzIEtpcmVldGkgcG9pbnRzIG91dCwgbWFueSBub24tU1AgZGF0YSBjZW50ZXJzIHVzZSBJR1Bz IC0gT1NQRiB3aXRoIEVDTVAgaXMgYSBjb21tb24gZXhhbXBsZSB0aGF0IG9uZSBjYW4gZXhwZWN0 IHRvIHNlZSBpbiB0aGUgSVAgbmV0d29yayB1bmRlcmx5aW5nIHRoZSBlbmNhcHN1bGF0aW9uLiAg QW5vdGhlciBpbnRlcmVzdGluZyBwb3NzaWJpbGl0eSBmb3Igb3ZlcmxheSBhZGRyZXNzIG1hcHBp bmcgaXMgdGhlIHNvcnQgb2YgZGlyZWN0b3J5LWJhc2VkIGluZnJhc3RydWN0dXJlIG5vdyBiZWlu ZyB1c2VkIGJ5IExJU1AgKEknbGwgbGVhdmUgaXQgdG8gdGhlIExJU1AgZm9sa3MgdG8gZXhwbGFp biB3aGF0IHRoaXMgaXMgYW5kIGhvdy93aHkgaXQgbWF5IGJlIGludGVyZXN0aW5nKS4NCltKaW0g VT5dIEhtbW0uLiBMSVNQIGxpa2UgdGVjaG5vbG9neSBjb3VsZCBiZSBpbnRlcmVzdGluZy4uDQoN Cj4gSWYgb25lIHdlcmUgdG8gY29uc2lkZXIgZGVwbG95aW5nIGEgdGVjaG5vbG9neSB0byByZWFs aXplIHRoZSBzZXJ2aWNlIG5lZWRlZCBpdCB3b3VsZA0KPiBzZWVtIHBydWRlbnQgdG8gY29uc2lk ZXIgYWxsIHNvbHV0aW9uIHNwYWNlcyBhbmQgbm90IGdldCBjYXVnaHQgdXAgaW4gdGhlIHBlcmNl cHRpb24gb3IgdXMgdnMuIHRoZW0NCj4gbWVudGFsaXR5Li4NCg0KSSdtIHNvcnJ5LCBidXQgQkdQ J3MgY29tcGxleGl0eSAoZS5nLiwgcG9saWN5KSBieSBjb21wYXJpc29uIHRvIHRoZSBJR1BzIHR5 cGljYWxseSB1c2VkIGluIG5vbi1jYXJyaWVyIGRhdGEgY2VudGVycyBpcyBhIG1hdHRlciBvZiBm YWN0LCBub3QgcGVyY2VwdGlvbiBvciBvcGluaW9uLiAgT1RPSCwgQWxpYSdzIHN1Z2dlc3Rpb24g dGhhdCBhIGN1dC1kb3duIEJHUCBwcm9maWxlIG1pZ2h0IGJlIGFwcGxpY2FibGUgaXMgaW50ZXJl c3RpbmcsIElNSE8uDQpbSmltIFU+XSBZZXMgQWxpYSBtYWtlcyBhIGdyZWF0IHNlbGVjdGlvbiBo ZXJlLi4gSWYgd2UgY2FuIGRldGVybWluZSB0aGUgcmVxcyB0aGVyZSBjb3VsZCBiZSBhbiBvcHBv cnR1bml0eSB0byB1c2UgYSBCR1AgUHJvZmlsZSBpbiB0aGUgREMgdGhhdCBjb3VsZCBiZSBlYXNp bHkgZXh0ZW5kZWQNCg0KVGhhbmtzLA0KLS1EYXZpZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IFVUVEFSTywgSkFNRVMgW21haWx0bzpqdTE3MzhAYXR0LmNvbV0NCj4g U2VudDogTW9uZGF5LCBBcHJpbCAwMiwgMjAxMiA4OjE1IEFNDQo+IFRvOiBCbGFjaywgRGF2aWQN Cj4gQ2M6IGwydnBuQGlldGYub3JnOyBudm8zQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBSZXNw b25zZSB0byBzb21lIGNvbW1lbnRzIG9uIElTLUlTIFZQTFMNCj4gDQo+IERhdmlkLA0KPiANCj4g CUNvbW1lbnRzIEluLUxpbmUuLi4NCj4gDQo+IFRoYW5rcywNCj4gCUppbSBVdHRhcm8NCj4gDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGRhdmlkLmJsYWNrQGVtYy5jb20g W21haWx0bzpkYXZpZC5ibGFja0BlbWMuY29tXQ0KPiBTZW50OiBNb25kYXksIEFwcmlsIDAyLCAy MDEyIDY6MzYgQU0NCj4gVG86IFVUVEFSTywgSkFNRVMNCj4gQ2M6IGwydnBuQGlldGYub3JnOyBu dm8zQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBSZXNwb25zZSB0byBzb21lIGNvbW1lbnRzIG9u IElTLUlTIFZQTFMNCj4gDQo+IEphbWVzLA0KPiANCj4gSSBiZWxpZXZlIHRoZSBzb2x1dGlvbiBw cmVmZXJlbmNlIHN0YXJ0cyBmcm9tIHRoaXMgYmVsaWVmIGFib3V0IGRhdGEgY2VudGVyIGFyY2hp dGVjdHVyZToNCj4gDQo+ID4+IEkgYmVsaWV2ZSB0aGF0IHRoZSBkYXRhIGNlbnRlciBpcyBiZWNv bWluZyBtb3JlIGFuZCBtb3JlIGENCj4gPj4gZHluYW1pYyBleHRlbnNpb24gb2YgYSBjdXN0b21l csK5cyBuZXR3b3JrLg0KPiANCj4gVW5kZXIgdGhhdCBhc3N1bXB0aW9uLCBmb3IgYSBjYXJyaWVy IHdob3NlIG5ldHdvcmsgaXMgYmFzZWQgb24gbmV0d29ya2luZyB0ZWNobm9sb2dpZXMgbGlrZSBC R1AsDQo+IGV4dGVuZGluZyB0aG9zZSB0ZWNobm9sb2dpZXMgaW50byBhIGRhdGEgY2VudGVyIGlz IGEgZmluZSB0aGluZyB0byBkbywgYW5kIG5vdGhpbmcgaW4gdGhlIG52bzMgd29yayBpcw0KPiBp bnRlbmRlZCB0byBzdG9wIHRoYXQuDQo+IA0KPiBPVE9ILCBmb3IgYSBub24tY2FycmllciBkYXRh IGNlbnRlciAoZS5nLiwgZW50ZXJwcmlzZSksIG5vdCBvbmx5IGlzIHRoZSBhYm92ZSBzdGF0ZW1l bnQgcmF0aGVyDQo+IGluY29ycmVjdCwgYnV0IHRoZSBlbnRlcnByaXNlIG5ldHdvcmsgbWF5IG5v dCBiZSBydW5uaW5nIEJHUC4gIFRoaXMgY2FuIGJlIHBhcnRpY3VsYXJseSBzbyBmb3IgYSBkYXRh DQo+IGNlbnRlciB0aGF0IGRlc2lyZXMgZmxleGliaWxpdHkgaW4gY2hvaWNlIGFtb25nIGNhcnJp ZXJzLCBhbmQgaGVuY2Ugb3BlcmF0ZXMgdW5kZXIgdGhlIHByaW5jaXBsZSB0aGF0DQo+IG9uZSBv ZiB0aGUgam9icyBvZiB0aGUgQ1BFIGJveCBpcyB0byBrZWVwIHRoZSBjYXJyaWVyIHRlY2hub2xv Z3kgb24gdGhlIG90aGVyIHNpZGUgaW4gb3JkZXIgdG8gbGltaXQNCj4gbG9jay1pbi4gIFRoZSBu dm8zIHdvcmsgaXMgdGFyZ2V0ZWQgYXQgdGhlIHNvcnQgb2YgdXNlIGNhc2VzIGRlc2NyaWJlZCBp biB0aGlzIHBhcmFncmFwaC4NCj4gW0ppbSBVPl0gU28sIGEgY291cGxlIG9mIGl0ZW1zLi4gQkdQ IGlzIGEgZ2VuZXJhbCBwdXJwb3NlIHRvb2xzIHRoYXQgaXMgdXNlZCBpbiBhIHZhcmlldHkgb2YN Cj4gYXBwbGljYXRpb25zIHdoZXJlIGRpc2NvdmVyeSwgZHluYW1pYyBzaWduYWxpbmcgZXRjLi4g aXMgcmVxdWlyZWQuLiBTbyBmb3IgYSBub24tY2FycmllciBkYXRhIGNlbnRlciBJDQo+IHdvdWxk IHRoaW5rIHRoYXQgdGhlIHNhbWUgcmVxcyB3b3VsZCBiZSBuZWVkZWQgZXZlbiBpZiB0aGUgc2Nv cGUgaXMgbGltaXRlZCB0byB0aGF0IHNpbmdsZSBub24tY2Fycmllcg0KPiBkYXRhIGNlbnRlci4u IElmIG9uZSB3ZXJlIHRvIGNvbnNpZGVyIGRlcGxveWluZyBhIHRlY2hub2xvZ3kgdG8gcmVhbGl6 ZSB0aGUgc2VydmljZSBuZWVkZWQgaXQgd291bGQNCj4gc2VlbSBwcnVkZW50IHRvIGNvbnNpZGVy IGFsbCBzb2x1dGlvbiBzcGFjZXMgYW5kIG5vdCBnZXQgY2F1Z2h0IHVwIGluIHRoZSBwZXJjZXB0 aW9uIG9yIHVzIHZzLiB0aGVtDQo+IG1lbnRhbGl0eS4uIFRoZSBvdGhlciBub3Rpb24gaGVyZSBp cyB0aGF0IHVzaW5nIEJHUCBzb21laG93IHByZXZlbnRzIGlzb2xhdGlvbiBvciBsaW1pdHMgc2Vs ZWN0aW9uIG9mDQo+IGRpZmZlcmVudCBwcm92aWRlcnMsIG5laXRoZXIgb2YgdGhlc2UgYXNzdW1w dGlvbnMgaGF2ZSBiZWVuIHByb3ZlbiB0byBiZSB0cnVlIGluIG90aGVyIGFwcGxpY2F0aW9ucw0K PiB0aGF0IHVzZSBCR1AuLg0KPiANCj4gVGhpcyBzb3J0IG9mIHNwaXJpdGVkIHByb21vdGlvbiBv ZiBCR1AgY29tZXMgYWNyb3NzIGFzIGFuIGF0dGVtcHQgdG8gZm9yY2UgYSBvbmUtc2l6ZS1maXRz LWFsbA0KPiBzb2x1dGlvbiBvbiB0aG9zZSB3aG8gZG8gbm90IGN1cnJlbnRseSB1c2UgQkdQLiAg SSBhbSAqKk5PVCoqIGFyZ3VpbmcgdGhhdCBCR1AgY2FuJ3QgYmUgbWFkZSB0byB3b3JrOw0KPiBJ IGFtIGFyZ3VpbmcgdGhhdCBpdCdzIGEgcG9vciBmaXQgZm9yIHRoZSB1c2UgY2FzZXMgb2YgaW50 ZXJlc3QuDQo+IFtKaW0gVT5dIEkgZG8gbm90IGFncmVlLi4gQkdQIHBlcm1pdHMgdGhlIGV2b2x1 dGlvbiBvZiB0aGUgc2VydmljZXMgc3VjaCB0aGF0IGFueSBhbmQgYWxsIGRhdGEgY2VudGVycw0K PiBjYW4gcGFydGljaXBhdGUgaW4gcHJvdmlkaW5nIHNlcnZpY2UsIGFuZCBhbnRpY2lwYXRlcyB1 c2UgY2FzZXMgY3VycmVudGx5IG5vdCBjb25zaWRlcmVkIHN1Y2ggYXMNCj4gbXVsdGlwbGUgZGF0 YSBjZW50ZXJzIGFjcm9zcyBjb21wYW5pZXMgcHJvdmlkaW5nIHNlcnZpY2UgZm9yIGEgZ2l2ZW4g Y3VzdG9tZXIgaW4gYSBjb29wZXJhdGl2ZQ0KPiBtYW5uZXIuLiBJIGRvIG5vdCBzZWUgaG93IHRo ZSBzb2x1dGlvbnMgb3IgYXNzdW1wdGlvbnMgbWFkZSBpbiBOVk8zIGNhcHR1cmUgdGhpcy4uLg0K PiANCj4gVGhhbmtzLA0KPiAtLURhdmlkDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRGF2aWQgTC4gQmxhY2ssIERpc3Rpbmd1aXNoZWQg RW5naW5lZXINCj4gRU1DIENvcnBvcmF0aW9uLCAxNzYgU291dGggU3QuLCBIb3BraW50b24sIE1B wqAgMDE3NDgNCj4gKzEgKDUwOCkgMjkzLTc5NTPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgRkFY OiArMSAoNTA4KSAyOTMtNzc4Ng0KPiBkYXZpZC5ibGFja0BlbWMuY29twqDCoMKgwqDCoMKgwqAg TW9iaWxlOiArMSAoOTc4KSAzOTQtNzc1NA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KbnZvMyBtYWlsaW5nIGxpc3QNCm52bzNAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMw0K From robert@raszuk.net Mon Apr 2 13:35:03 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB8521F8735 for ; Mon, 2 Apr 2012 13:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] 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 a3i1LiQTUjhT for ; Mon, 2 Apr 2012 13:35:02 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 5F32A21F8732 for ; Mon, 2 Apr 2012 13:34:59 -0700 (PDT) Received: (qmail 5670 invoked by uid 399); 2 Apr 2012 20:34:58 -0000 Received: from unknown (HELO ?10.0.1.3?) (pbs:robert@raszuk.net@213.160.13.154) by mail1310.opentransfer.com with ESMTPM; 2 Apr 2012 20:34:58 -0000 X-Originating-IP: 213.160.13.154 Message-ID: <4F7A0D73.2030000@raszuk.net> Date: Mon, 02 Apr 2012 22:34:59 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: sajassi Subject: Re: Response to some comments on IS-IS VPLS References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 20:35:04 -0000 > Why do you think, the encap/decap must be done on the end-host > (hypvervisor, OVS,etc.). Very simple. Because I do not want to buy, install and operate network equipment from vendors even if this is interoperable across N vendors and rubber stamped by IETF. It is not only about cost savings, velocity about enhancement delivery speed by vendor, but also about service differentiation between my network and competition. Best, R. > Hi Robert, > > The connectivity between the two VMs is provided by L2VPN over MPLS/IP - > e.g.,, VM1/VLAN1 an VM2/VLAN1 are mapped to the same L2VPN. Why do you > think, the encap/decap must be done on the end-host (hypvervisor, OVS,etc.). > > Cheers, > Ali From jon.hudson@gmail.com Mon Apr 2 13:39:59 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6475B21F86FA; Mon, 2 Apr 2012 13:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 S7IuubkLmy2o; Mon, 2 Apr 2012 13:39:58 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id D411E21F8685; Mon, 2 Apr 2012 13:39:58 -0700 (PDT) Received: by dady13 with SMTP id y13so3734437dad.27 for ; Mon, 02 Apr 2012 13:39:58 -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=TGTF7+fUmNWZwMjAjH/c0e0BUjik4qiJssNlu/sr5uQ=; b=pPEI8vzqTVekMTlHK480oEINJXoZ74eFD6fBnnmvXIKvH/BJ3mCgmjQ3MefxGhP8CN Nf02gsg3cMXSkTxdHpnZIIqXq7QsTAXOKC5pAi7zOpySsT+JUqbPCVQdJOPuVHmsNiqU 4jk3pQVwfRPZVXLKCKgf/KtGHGmWnOj+OVA0oNTEcGEN/UUPkWIpEEv5vko5dEmTwQeu VmmEWCShuBteWuPtkcj6r6ithbELLpzE7wpWUggsPvIqBONOYPD6484dMPMGi+TBZqCR 5X3junpUfcgwXbOAAWptiu6F6VC4bVBEwNIgYHarPrb4CgZ3cx7Axuu3DN0Mp1oHYKP1 ZJ9Q== Received: by 10.68.219.72 with SMTP id pm8mr23714791pbc.116.1333399198615; Mon, 02 Apr 2012 13:39:58 -0700 (PDT) Received: from [10.100.138.28] ([144.49.131.1]) by mx.google.com with ESMTPS id p4sm14707785pbp.13.2012.04.02.13.39.56 (version=SSLv3 cipher=OTHER); Mon, 02 Apr 2012 13:39:57 -0700 (PDT) References: <85DCB564-1551-4B7A-B08B-DE355D3D2221@gmail.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <305592B0-6111-4743-BF05-6BC7581DCD43@gmail.com> X-Mailer: iPad Mail (9B176) From: Jon Hudson Subject: Re: [nvo3] Response to some comments on IS-IS VPLS Date: Mon, 2 Apr 2012 13:36:25 -0700 To: Gregory Mirsky X-Mailman-Approved-At: Mon, 02 Apr 2012 13:45:19 -0700 Cc: "l2vpn@ietf.org" , sajassi , "" , "nvo3@ietf.org" X-BeenThere: l2vpn@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, 02 Apr 2012 20:39:59 -0000 I have been assured that this whole neutrino "measurement issue" is just a t= emporary setback On Apr 2, 2012, at 11:43 AM, Gregory Mirsky wr= ote: > Hi Jon, > For application to be able to do what you've described requires network to= be designed accordingly. IMHO, support of implicit requirements is rather a= ccidental and support of explicit requirements is limited by laws of physics= . >=20 > Regards, > Greg >=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of J= on Hudson > Sent: Monday, April 02, 2012 10:54 AM > To: sajassi > Cc: l2vpn@ietf.org; nvo3@ietf.org; > Subject: Re: [nvo3] Response to some comments on IS-IS VPLS >=20 > In my experience it's because it would require the virtualization folks to= open a ticket and interact with the network team. >=20 > Many want to be able to on a whim create wormholes from any hypervisor(s) t= o any hypervisors(s) without dependencies on other teams that would require a= ticket, change control or approval by a steering committee. >=20 > J =20 >=20 > On Apr 2, 2012, at 10:44 AM, sajassi wrote: >=20 >> Hi Robert, >>=20 >> The connectivity between the two VMs is provided by L2VPN over MPLS/IP=20= >> - e.g.,, VM1/VLAN1 an VM2/VLAN1 are mapped to the same L2VPN. Why do=20 >> you think, the encap/decap must be done on the end-host (hypvervisor, OVS= ,etc.). >>=20 >> Cheers, >> Ali >>=20 >>=20 >> On 3/30/12 2:48 AM, "Robert Raszuk" wrote: >>=20 >>> Ali, >>>=20 >>>> Third, before bashing E-VPN/PBB-EVPN, I would recommend that you=20 >>>> understand what it is. >>>=20 >>> Great point indeed. >>>=20 >>> Could you share a pointer to the list which describes VM 1 on Host=20 >>> A's hypervisor to VM 2 on host B's hypervisor interconnect model for=20 >>> both above solutions just assuming that you have IP or MPLS=20 >>> reachability between such hosts ? >>>=20 >>> The requirement of my question is that any=20 >>> encapsulation/decapsulation required for such interconnection should=20 >>> happen on the end hosts (kernel, OVS, NIC etc ...) and not on the "netwo= rk". >>>=20 >>> Best regards, >>> R. >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 From jon.hudson@gmail.com Mon Apr 2 13:45:43 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E02321F86B4; Mon, 2 Apr 2012 13:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 6r3YqAVPFCBd; Mon, 2 Apr 2012 13:45:43 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D670C21F86A8; Mon, 2 Apr 2012 13:45:41 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so4734126pbb.31 for ; Mon, 02 Apr 2012 13:45:41 -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=wwYcS+yBGuKvnhwz0LHafWmD47Qz+/pBdwMGtiwK2MM=; b=gl1k0+qtq0G7M669r3j97kJV0p0EDvLUp5DmOiTcEWskgngXsnKzeNCKa2dc7kNpMA lqs8gAAlqnbff4k1FB6z6R0swKiVIJINTGKrSV9hsWDItk0sZpjL61pXxseLBb2RpzqL bj3Zdep0zjS/b4DY37fop7shWDKEKkvvMR6AHVjXzBB/JRAU0gwACN5sunkdScu0nD4K /usTT5HkIf4vaXclCbLFafN4Gan+V3goz+HyBkeuISgo31Y15mqjiTtCOY2X+EEioNM1 YWU1ZoU4+8dtd4zx7XfPbv5w0RVQpWFRkQZ+g5+y/e8jsryLZXysrbX1KotOwHerO8IO Dz1w== Received: by 10.68.219.34 with SMTP id pl2mr23597433pbc.56.1333399541699; Mon, 02 Apr 2012 13:45:41 -0700 (PDT) Received: from [10.100.138.28] ([144.49.131.1]) by mx.google.com with ESMTPS id q1sm6156590pbp.62.2012.04.02.13.45.39 (version=SSLv3 cipher=OTHER); Mon, 02 Apr 2012 13:45:40 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <3A783EDB-A936-4CCB-AA56-615B6D74B53B@gmail.com> X-Mailer: iPad Mail (9B176) From: Jon Hudson Subject: Re: [nvo3] Response to some comments on IS-IS VPLS Date: Mon, 2 Apr 2012 13:42:09 -0700 To: sajassi X-Mailman-Approved-At: Mon, 02 Apr 2012 13:50:07 -0700 Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" , "" X-BeenThere: l2vpn@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, 02 Apr 2012 20:45:43 -0000 Very true. And personally I like a coordinated solution. However the argument I repeate= dly get is " but we want to just do it ourselves. If we have to engage anoth= er group minutes become days" Not saying right or wrong, just what customers I speak to usually tell me wh= en I ask what their perceived value of encap/decap in the hypervisor is. On Apr 2, 2012, at 12:24 PM, sajassi wrote: >=20 > The interaction can be automated via the use of some protocol (e.g., VDP i= n > 802.1Qbg) which is being talked about in NOV3. >=20 > Cheers, > Ali >=20 >=20 > On 4/2/12 10:54 AM, "Jon Hudson" wrote: >=20 >> In my experience it's because it would require the virtualization folks t= o >> open a ticket and interact with the network team. >>=20 >> Many want to be able to on a whim create wormholes from any hypervisor(s)= to >> any hypervisors(s) without dependencies on other teams that would require= a >> ticket, change control or approval by a steering committee. >>=20 >> J =20 >>=20 >> On Apr 2, 2012, at 10:44 AM, sajassi wrote: >>=20 >>> Hi Robert, >>>=20 >>> The connectivity between the two VMs is provided by L2VPN over MPLS/IP -= >>> e.g.,, VM1/VLAN1 an VM2/VLAN1 are mapped to the same L2VPN. Why do you >>> think, the encap/decap must be done on the end-host (hypvervisor, OVS,et= c.). >>>=20 >>> Cheers, >>> Ali >>>=20 >>>=20 >>> On 3/30/12 2:48 AM, "Robert Raszuk" wrote: >>>=20 >>>> Ali, >>>>=20 >>>>> Third, before bashing E-VPN/PBB-EVPN, I would recommend that you >>>>> understand what it is. >>>>=20 >>>> Great point indeed. >>>>=20 >>>> Could you share a pointer to the list which describes VM 1 on Host A's >>>> hypervisor to VM 2 on host B's hypervisor interconnect model for both >>>> above solutions just assuming that you have IP or MPLS reachability >>>> between such hosts ? >>>>=20 >>>> The requirement of my question is that any encapsulation/decapsulation >>>> required for such interconnection should happen on the end hosts >>>> (kernel, OVS, NIC etc ...) and not on the "network". >>>>=20 >>>> Best regards, >>>> R. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >=20 From jon.hudson@gmail.com Mon Apr 2 13:49:19 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9507D21F8744; Mon, 2 Apr 2012 13:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 Mf8d6hzovzEf; Mon, 2 Apr 2012 13:49:19 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2BACB21F8734; Mon, 2 Apr 2012 13:49:19 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so4736841pbb.31 for ; Mon, 02 Apr 2012 13:49:19 -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=JlY+to9umbPhbg/UwwYafYlOvThxgbRazewQ7SsUKlE=; b=Zpji+ymIW88/vf+Mv15h3lTuRXHXEfg2ohuXOURPk95E1J+JTW08QCcqE+gN998pVR aK/MV5qoeJ7SamGGbOEik/BX59x3lgl1OP2xbbJw683swVIv8t9I1Ctc3XEEy/Z7AzOf rK8Efae3uX6DhtPYAWfR9kYgpJvaymyaaDO0AzxJuf+x79g0YwkWfQZaHsv836KEWD/P FY/F+lu81UChn5Q4stFjVUZj66ruwzd6+UlLDi0BJZZJml4NrsGD5h+osFDKzYbQBJ5K 6Icjc28TrTzmN3jo259TZSHUfIPnq2qbFxXt8qt/G4UixSUu5XNpgIYijnqY9IeukVJ+ YlMg== Received: by 10.68.231.169 with SMTP id th9mr551594pbc.86.1333399759020; Mon, 02 Apr 2012 13:49:19 -0700 (PDT) Received: from [10.100.138.28] ([144.49.131.1]) by mx.google.com with ESMTPS id j10sm12665148pbf.0.2012.04.02.13.49.16 (version=SSLv3 cipher=OTHER); Mon, 02 Apr 2012 13:49:17 -0700 (PDT) References: <4F7A0D73.2030000@raszuk.net> In-Reply-To: <4F7A0D73.2030000@raszuk.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B176) From: Jon Hudson Subject: Re: [nvo3] Response to some comments on IS-IS VPLS Date: Mon, 2 Apr 2012 13:43:28 -0700 To: "robert@raszuk.net" X-Mailman-Approved-At: Mon, 02 Apr 2012 13:50:07 -0700 Cc: "l2vpn@ietf.org" , sajassi , "nvo3@ietf.org" X-BeenThere: l2vpn@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, 02 Apr 2012 20:49:19 -0000 Bingo On Apr 2, 2012, at 1:34 PM, Robert Raszuk wrote: >=20 > > Why do you think, the encap/decap must be done on the end-host > > (hypvervisor, OVS,etc.). >=20 > Very simple. >=20 > Because I do not want to buy, install and operate network equipment from v= endors even if this is interoperable across N vendors and rubber stamped by I= ETF. >=20 > It is not only about cost savings, velocity about enhancement delivery spe= ed by vendor, but also about service differentiation between my network and c= ompetition. >=20 > Best, > R. >=20 >> Hi Robert, >>=20 >> The connectivity between the two VMs is provided by L2VPN over MPLS/IP - >> e.g.,, VM1/VLAN1 an VM2/VLAN1 are mapped to the same L2VPN. Why do you >> think, the encap/decap must be done on the end-host (hypvervisor, OVS,etc= .). >>=20 >> Cheers, >> Ali > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From kgray@juniper.net Mon Apr 2 14:34:44 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF8F21F869F; Mon, 2 Apr 2012 14:34:44 -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 54vf10CzUcw9; Mon, 2 Apr 2012 14:34:43 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 24CD421F8693; Mon, 2 Apr 2012 14:34:36 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKT3obadpzs2QOMyMa0Xs0eUpDuXiSrw38@postini.com; Mon, 02 Apr 2012 14:34:36 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 2 Apr 2012 14:33:04 -0700 From: Ken Gray To: Jon Hudson , "robert@raszuk.net" Date: Mon, 2 Apr 2012 14:33:02 -0700 Subject: Re: [nvo3] Response to some comments on IS-IS VPLS Thread-Topic: [nvo3] Response to some comments on IS-IS VPLS Thread-Index: Ac0RGC+/vgH+8D7ASbGHCde4MhjzrQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 02 Apr 2012 14:35:49 -0700 Cc: "l2vpn@ietf.org" , sajassi , "nvo3@ietf.org" X-BeenThere: l2vpn@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, 02 Apr 2012 21:34:44 -0000 The description below, of self-contained isolationism ..isn't a candidate for a standard at all. If you're writing it yourself, and you're not using any vendor's equipment (I'll do it all with COTS power and my own coding) ... I'd suggest that a proprietary solution is just fine for you (that's not meant as sarcasm ...I'm honoring the motivation of being independent of someone else's development cycles). On 4/2/12 4:43 PM, "Jon Hudson" wrote: > >Bingo > >On Apr 2, 2012, at 1:34 PM, Robert Raszuk wrote: > >>=20 >> > Why do you think, the encap/decap must be done on the end-host >> > (hypvervisor, OVS,etc.). >>=20 >> Very simple. >>=20 >> Because I do not want to buy, install and operate network equipment >>from vendors even if this is interoperable across N vendors and rubber >>stamped by IETF. >>=20 >> It is not only about cost savings, velocity about enhancement delivery >>speed by vendor, but also about service differentiation between my >>network and competition. >>=20 >> Best, >> R. >>=20 >>> Hi Robert, >>>=20 >>> The connectivity between the two VMs is provided by L2VPN over MPLS/IP >>>- >>> e.g.,, VM1/VLAN1 an VM2/VLAN1 are mapped to the same L2VPN. Why do you >>> think, the encap/decap must be done on the end-host (hypvervisor, >>>OVS,etc.). >>>=20 >>> Cheers, >>> Ali >> _______________________________________________ >> 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 robert@raszuk.net Mon Apr 2 14:43:19 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93EAA21F86B9 for ; Mon, 2 Apr 2012 14:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] 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 56adGAqJo636 for ; Mon, 2 Apr 2012 14:43:18 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9D121F86AA for ; Mon, 2 Apr 2012 14:43:18 -0700 (PDT) Received: (qmail 4956 invoked by uid 399); 2 Apr 2012 21:43:17 -0000 Received: from unknown (HELO ?10.0.1.3?) (pbs:robert@raszuk.net@213.160.13.154) by mail1310.opentransfer.com with ESMTPM; 2 Apr 2012 21:43:17 -0000 X-Originating-IP: 213.160.13.154 Message-ID: <4F7A1D71.5010403@raszuk.net> Date: Mon, 02 Apr 2012 23:43:13 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Ken Gray Subject: Re: [nvo3] Response to some comments on IS-IS VPLS References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" , sajassi , Jon Hudson X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 21:43:19 -0000 Hi Ken, I knew someone will misinterpret it. Where do you see in my message that I proposing isolated solution ? Where do you see that I am against standard based service NNI ? BGP is a perfect candidate for such NNI interface too. I like BGP or XMPP extension proposal. Do you think that standards based solutions are possible only to be build and delivered by few vendors ? I think those times are over .... I specifically said that I would like to have a solution which does not require to depend on hardware vendors which offer software + hardware bundles. Doing encap/decap in OVS on hypervisor completely does not mean that I am going to focus on my own "isolated" proprietary control plane solution. That very wrong interpretation completely opposite to the real goals. Contrary NVO3 could standardize a control plane solution which does not result in locking customers to vendors. That's the point. Best, R. > The description below, of self-contained isolationism ..isn't a candidate > for a standard at all. If you're writing it yourself, and you're not > using any vendor's equipment (I'll do it all with COTS power and my own > coding) ... I'd suggest that a proprietary solution is just fine for you > (that's not meant as sarcasm ...I'm honoring the motivation of being > independent of someone else's development cycles). > > > > On 4/2/12 4:43 PM, "Jon Hudson" wrote: > >> >> Bingo >> >> On Apr 2, 2012, at 1:34 PM, Robert Raszuk wrote: >> >>> >>>> Why do you think, the encap/decap must be done on the end-host >>>> (hypvervisor, OVS,etc.). >>> >>> Very simple. >>> >>> Because I do not want to buy, install and operate network equipment >> >from vendors even if this is interoperable across N vendors and rubber >>> stamped by IETF. >>> >>> It is not only about cost savings, velocity about enhancement delivery >>> speed by vendor, but also about service differentiation between my >>> network and competition. >>> >>> Best, >>> R. >>> >>>> Hi Robert, >>>> >>>> The connectivity between the two VMs is provided by L2VPN over MPLS/IP >>>> - >>>> e.g.,, VM1/VLAN1 an VM2/VLAN1 are mapped to the same L2VPN. Why do you >>>> think, the encap/decap must be done on the end-host (hypvervisor, >>>> OVS,etc.). >>>> >>>> Cheers, >>>> Ali >>> _______________________________________________ >>> 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 robert@raszuk.net Mon Apr 2 15:32:34 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21E121F8751 for ; Mon, 2 Apr 2012 15:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.226 X-Spam-Level: X-Spam-Status: No, score=-1.226 tagged_above=-999 required=5 tests=[AWL=-0.716, BAYES_05=-1.11, J_CHICKENPOX_32=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 mT5mVzY-2xxj for ; Mon, 2 Apr 2012 15:32:34 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id B123321F874A for ; Mon, 2 Apr 2012 15:32:33 -0700 (PDT) Received: (qmail 2299 invoked by uid 399); 2 Apr 2012 22:32:33 -0000 Received: from unknown (HELO ?10.0.1.3?) (pbs:robert@raszuk.net@213.160.13.154) by mail1310.opentransfer.com with ESMTPM; 2 Apr 2012 22:32:33 -0000 X-Originating-IP: 213.160.13.154 Message-ID: <4F7A28FE.8030500@raszuk.net> Date: Tue, 03 Apr 2012 00:32:30 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: l2vpn@ietf.org, nvo3@ietf.org Subject: Service primitives References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0CAE@szxeml525-mbs.china.huawei.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0E23@szxeml525-mbs.china.huawei.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80849@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80A91@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80A91@MX14A.corp.emc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 22:32:35 -0000 > Alia's suggestion that a cut-down BGP profile might be applicable is > interesting, IMHO. Really ? Can you or Alia specify what is going to be cut out of BGP to make it BGP4DC ? Can you please put the scissors back to the drawer ??? Actually I think this discussion is rather amusing. Should we rather then tons of emails on BGP or not BGP focus a bit on service primitives any protocol should support ? Focus on what elements needs to be exchanged between hosts to provide tenant isolation both intra and inter-domain first ? IETF historically were operating in principle let's define a protocol and let at least two vendors implement it. Then if they are lucky enough and not fighting each other the victory could be announced and the service inter-operates .. Hurraaaa time to invite customers with big wallets to purchase it. I think that model while many got used to it is no longer that appealing. Should we rather standardize open set of primitives to exchange sufficient information on a NNI boundaries to allow flexible interconnect ? Such primitives may be exchanged with BGP, but equally well they may be exchanged with other means - for example service bus two ASes would decided to use (provider - provider or provider - customer). In fact once we agree on the set of primitives there is no need to make one choice of transport for them everywhere. That should be local choice of given interconnect. Regards, R. From kireeti.kompella@gmail.com Mon Apr 2 17:52:43 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D063D21F859E; Mon, 2 Apr 2012 17:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 728ZZ2G-w8gW; Mon, 2 Apr 2012 17:52:42 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id C38C821F8569; Mon, 2 Apr 2012 17:52:42 -0700 (PDT) Received: by dady13 with SMTP id y13so3987442dad.27 for ; Mon, 02 Apr 2012 17:52:42 -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=mQDUQjZir95xwn+242N7NdUwcGwaEmBwFfsWRpBTrPc=; b=zmg6N1T48HgRmgUAF8GcqvNVZIOWGdWuuOL2fm2NYzcczT9s1rAbg1nQLH40ub6AHg LONRR8XklOMrKmw860WzReeB+f8EGMhJ5Q5uKjmKjgR45v41feiP4Y0mhAYMlcCa7um3 3b0irdRpKljCiLpfW2gWPgcKDucWFQnSzjDLjxI5GUzB3rQU+t4DBo1A6R73waMypY4N qGaaNgqYHVLFjoCXqI6sFrMpNr2QfuKvqNp8m/gkdIFOFgSQJr1LIjc2EoMfg2hyCD4v rCUDMeSA5Qwbjht/HqR1vHPr+E+UIr6Z5vTTp2J06NuOsQfk0d5G+Mf84gLdfF9XtDbE LoRw== MIME-Version: 1.0 Received: by 10.68.221.40 with SMTP id qb8mr24306723pbc.154.1333414362592; Mon, 02 Apr 2012 17:52:42 -0700 (PDT) Received: by 10.68.138.136 with HTTP; Mon, 2 Apr 2012 17:52:42 -0700 (PDT) In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80AAC@MX14A.corp.emc.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0CAE@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0E23@szxeml525-mbs.china.huawei.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80849@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80AAC@MX14A.corp.emc.com> Date: Mon, 2 Apr 2012 17:52:42 -0700 Message-ID: Subject: Re: [nvo3] Response to some comments on IS-IS VPLS From: Kireeti Kompella To: david.black@emc.com Content-Type: multipart/alternative; boundary=e89a8ff256a26bb6d604bcbbb979 X-Mailman-Approved-At: Tue, 03 Apr 2012 01:51:13 -0700 Cc: kireeti@juniper.net, l2vpn@ietf.org, nvo3@ietf.org X-BeenThere: l2vpn@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, 03 Apr 2012 00:52:44 -0000 --e89a8ff256a26bb6d604bcbbb979 Content-Type: text/plain; charset=ISO-8859-1 Hi David, On Mon, Apr 2, 2012 at 12:34 PM, wrote: > Hi Kireeti, > > We're in agreement, and thank you for your comments at the BOF. Here are > a few elaborations: It's great that (we think) we're in agreement, but just in case ... > > > OTOH, for a non-carrier data center (e.g., enterprise), not only is > the above statement rather > > incorrect, but the enterprise network may not be running BGP. > > > > Step back a bit. The non-carrier DC is not being asked to run BGP. > There are two ways to interpret "non-carrier DC": a) enterprises that have a DC but want to move to the clouds (i.e., customers); b) non-carriers that *build* clouds (e.g., EC2). It is a non-starter to ask those in (a) to run BGP (or to change any of their practices in any significant way). It is a definite possibility to ask the non-carrier cloud provider to adopt BGP as the scaling mechanism. (oh, oh -- the end of a beautiful friendship, just as it was getting going ... :-)) BGP is a well-tested protocol for scaling. Yes, there are complexities, some real, some perceived. The question is, is it easier to simplify BGP (along the lines that Alia said), or break loose and start again? The answer for SP-cloud providers seems clear. The answer for non-carrier cloud providers is open. I'm going to revisit this thread and see how many non-carrier cloud providers actually spoke up. > Sure - you and I agree on this, but Jim wants to push BGP into non-carrier > data centers ... > perhaps you can help convince him otherwise ... I could try, but it would be like . > > The _cloud_ operator, in order to > > scale their DC, of which the non-carrier DC is just a tenant, may want > to run BGP. Just as > > enterprises running OSPF get connectivity services from carriers running > BGP. > > I absolutely agree, and nvo3 is applicable to non-carrier DCs. NVO3 is indeed applicable to both carrier and non-carrier cloud providers. > > This can be particularly so for a data center that desires flexibility > in choice among carriers, > > > > Actually, BGP is what carriers talk to each other, so I'm not sure how > such a > > choice limits flexibility. > > If one extends the carrier's BGP instance into the data center, switching > carriers > becomes more difficult by comparison to ... > > > > and hence operates under the principle that one of the jobs of the CPE > box is to keep the carrier > > technology on the other side in order to limit lock-in. > > > > The "other" side of a CPE box usually runs BGP. > > ... having the CPE box do its job in keeping the carrier's instance of BGP > on the carrier's side ("other" side of the box) where the carrier's admins > can manage it without having to bother the data center admins much.f > Got it. Cheers, Kireeti. > Thanks, > --David --e89a8ff256a26bb6d604bcbbb979 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi David,

<= div class=3D"gmail_quote">
On= Mon, Apr 2, 2012 at 12:34 PM,=A0<david.b= lack@emc.com>=A0wrote:
Hi Kireeti,

We're in agreement, and thank you for your comments at the BOF. =A0= Here are a few elaborations:

It's= great that (we think) we're in agreement, but just in case ...
=A0
> > OTOH, for a non-carrier data center (e.g., enterprise), not = only is the above statement rather
> incorrect, but the enterprise ne= twork may not be running BGP.
>
> Step back a bit. The non-carr= ier DC is not being asked to run BGP.

There are two ways to interpre= t "non-carrier DC":
a) enterprises that have a DC but w= ant to move to the clouds (i.e., customers);
b) non-carriers that= *build* clouds (e.g., EC2).

It is a non-starter to ask those in (a) to run BGP (or = to change any of their practices in any significant way).

It is a definite possibility to ask the non-carrier cloud provider = to adopt BGP as the scaling mechanism.

(oh, oh -- the end of a beautiful friendship, just as i= t was getting going ... :-))

BGP is a well-tested = protocol for scaling. =A0Yes, there are complexities, some real, some perce= ived. =A0The question is, is it easier to simplify BGP (along the lines tha= t Alia said), or break loose and start again?

The answer for SP-cloud providers seems clear. =A0The a= nswer for non-carrier cloud providers is open. =A0I'm going to revisit = this thread and see how many non-carrier cloud providers actually spoke up.=
=A0
Sure - you and I agree on this, but Jim wants to push BGP into n= on-carrier data centers ...
perhaps you can help convince him otherwise = ...

I could try, but it would be like= <insert blasphemy here>.
=A0
> The _cloud_ operator, in order to
> scale their DC, of whic= h the non-carrier DC is just a tenant, may want to run BGP. =A0Just as
&= gt; enterprises running OSPF get connectivity services from carriers runnin= g BGP.

I absolutely agree, and nvo3 is applicable to non-carrier DCs.

NVO3 is indeed applicable to both carri= er and non-carrier cloud providers.

> > This can be p= articularly so for a data center that desires flexibility in choice among c= arriers,
>
> Actually, BGP is what carriers talk to each other,= so I'm not sure how such a
> choice limits flexibility.

If one extends the carrier'= ;s BGP instance into the data center, switching carriers
becomes more di= fficult by comparison to ...

> > and hence operates under= the principle that one of the jobs of the CPE box is to keep the carrier > technology on the other side in order to limit lock-in.
>
>= ; The "other" side of a CPE box usually runs BGP.

... having the CPE box do its job in keeping the carrier's instance= of BGP on the carrier's side ("other" side of the box) where= the carrier's admins can manage it without having to bother the data c= enter admins much.f

Got it.

Cheers,
Kireeti.
=A0
Thanks,
--David

--e89a8ff256a26bb6d604bcbbb979-- From tnadeau@lucidvision.com Tue Apr 3 05:06:47 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7832921F84D0; Tue, 3 Apr 2012 05:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 dtl-BE2Ew72Z; Tue, 3 Apr 2012 05:06:46 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id EFFB221F84C8; Tue, 3 Apr 2012 05:06:43 -0700 (PDT) Received: from [192.168.1.95] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 6599F1BF069; Tue, 3 Apr 2012 08:06:43 -0400 (EDT) Subject: Re: [nvo3] Response to some comments on IS-IS VPLS Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_7CB1728D-8AAD-4EE8-A476-3E3C84A9BBD1" From: Thomas Nadeau In-Reply-To: Date: Tue, 3 Apr 2012 08:06:42 -0400 Message-Id: <1746A111-DD94-45D1-A939-355299EC91F9@lucidvision.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0CAE@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0E23@szxeml525-mbs.china.huawei.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80849@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80AAC@MX14A.corp.emc.com> To: Kireeti Kompella X-Mailer: Apple Mail (2.1257) Cc: kireeti@juniper.net, l2vpn@ietf.org, david.black@emc.com, nvo3@ietf.org X-BeenThere: l2vpn@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, 03 Apr 2012 12:06:47 -0000 --Apple-Mail=_7CB1728D-8AAD-4EE8-A476-3E3C84A9BBD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 2, 2012:8:52 PM, at 8:52 PM, Kireeti Kompella wrote: > Hi David, >=20 > On Mon, Apr 2, 2012 at 12:34 PM, wrote: > Hi Kireeti, >=20 > We're in agreement, and thank you for your comments at the BOF. Here = are a few elaborations: >=20 > It's great that (we think) we're in agreement, but just in case ... > =20 > > > OTOH, for a non-carrier data center (e.g., enterprise), not only = is the above statement rather > > incorrect, but the enterprise network may not be running BGP. > > > > Step back a bit. The non-carrier DC is not being asked to run BGP. >=20 > There are two ways to interpret "non-carrier DC": > a) enterprises that have a DC but want to move to the clouds (i.e., = customers); > b) non-carriers that *build* clouds (e.g., EC2). There is a third that you are missing: simply enterprises that = have a DC today - whether or not they have moved any services to a XaaS = model or not is not that important per se. These are simply DCs (some = very late if you look at financial institutions). Some of these fall = into the categories being discussed around the hesitation around using = different protocols. I actually like to divide up the space a little differently: Traditional telco service providers (i.e.: att, vz, etc=85) "New" service providers (i.e.: google, salesforce.com, amazon, = rackspace, etc=85) Enterprise (large, med, small, and govt) If you look at things using that lens, I think the answers may = differ from your conclusions because as you will find, there are = differing levels of comfort for doing certain things, as well as = different business constraints/drivers - or resistors. =20 > It is a non-starter to ask those in (a) to run BGP (or to change any = of their practices in any significant way). >=20 > It is a definite possibility to ask the non-carrier cloud provider to = adopt BGP as the scaling mechanism. That depends on what their needs and level of expertise are. We = are making broad characterizations of enterprises that I think need to = be more granular for them to make sense (see above).=20 > (oh, oh -- the end of a beautiful friendship, just as it was getting = going ... :-)) >=20 > BGP is a well-tested protocol for scaling. Yes, there are = complexities, some real, some perceived. The question is, is it easier = to simplify BGP (along the lines that Alia said), or break loose and = start again? >=20 > The answer for SP-cloud providers seems clear. The answer for = non-carrier cloud providers is open. I'm going to revisit this thread = and see how many non-carrier cloud providers actually spoke up. I agree. This is where we need to get enterprises to chime in on = this topic. Unfortunately enterprises often do not participate at the = IETF, so our mileage may vary here. > =20 > Sure - you and I agree on this, but Jim wants to push BGP into = non-carrier data centers ... > perhaps you can help convince him otherwise ... >=20 > I could try, but it would be like . > =20 > > The _cloud_ operator, in order to > > scale their DC, of which the non-carrier DC is just a tenant, may = want to run BGP. Just as > > enterprises running OSPF get connectivity services from carriers = running BGP. >=20 > I absolutely agree, and nvo3 is applicable to non-carrier DCs. >=20 > NVO3 is indeed applicable to both carrier and non-carrier cloud = providers. It is applicable wherever people decide to use it, which is = still up for debate since it does not really exist yet in any deployable = form as far as I know. *) What is important is that people that = *think* they want to use it to step up and say so as soon as possible! --Tom >=20 > > > This can be particularly so for a data center that desires = flexibility in choice among carriers, > > > > Actually, BGP is what carriers talk to each other, so I'm not sure = how such a > > choice limits flexibility. >=20 > If one extends the carrier's BGP instance into the data center, = switching carriers > becomes more difficult by comparison to ... >=20 > > > and hence operates under the principle that one of the jobs of the = CPE box is to keep the carrier > > technology on the other side in order to limit lock-in. > > > > The "other" side of a CPE box usually runs BGP. >=20 > ... having the CPE box do its job in keeping the carrier's instance of = BGP on the carrier's side ("other" side of the box) where the carrier's = admins can manage it without having to bother the data center admins = much.f >=20 > Got it. >=20 > Cheers, > Kireeti. > =20 > Thanks, > --David >=20 --Apple-Mail=_7CB1728D-8AAD-4EE8-A476-3E3C84A9BBD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi David,

On Mon, Apr 2, 2012 at 12:34 = PM, <david.black@emc.com> wro= te:
Hi Kireeti,

We're in agreement, and thank you for your comments at the BOF. =  Here are a few = elaborations:

It's great that (we = think) we're in agreement, but just in case ...
 
> > OTOH, for a non-carrier data center (e.g., enterprise), = not only is the above statement rather
> incorrect, but the = enterprise network may not be running BGP.
>
> Step back a = bit. The non-carrier DC is not being asked to run BGP.

There are two ways to = interpret "non-carrier DC":
a) enterprises that have a DC but = want to move to the clouds (i.e., customers);
b) non-carriers = that *build* clouds (e.g., = EC2).

There is = a third that you are missing: simply enterprises that have a DC today - = whether or not they have moved any services to a XaaS model or not is = not that important per se.  These are simply DCs (some very late if = you look at financial institutions).  Some of these fall into the = categories being discussed around the hesitation around using different = protocols.

I actually like to divide up the = space a little differently:

= Traditional telco service providers (i.e.: att, vz, = etc=85)
"New" service providers (i.e.: = google, salesforce.com, amazon, = rackspace, etc=85)
Enterprise (large, med, small, = and govt)

If you look at things using that = lens, I think the answers may differ from your conclusions because as = you will find, there are differing levels of comfort for doing certain = things, as well as different business constraints/drivers - or = resistors.
 
It = is a non-starter to ask those in (a) to run BGP (or to change any of = their practices in any significant way).

It is a definite possibility to ask the non-carrier = cloud provider to adopt BGP as the scaling = mechanism.

That = depends on what their needs and level of expertise are. We are making = broad characterizations of enterprises that I think need to be more = granular for them to make sense (see above). 

(oh, oh -- the end of a beautiful friendship, just as = it was getting going ... :-))

BGP is a well-tested protocol for scaling. =  Yes, there are complexities, some real, some perceived.  The = question is, is it easier to simplify BGP (along the lines that Alia = said), or break loose and start again?

The answer for SP-cloud providers seems clear. =  The answer for non-carrier cloud providers is open.  I'm = going to revisit this thread and see how many non-carrier cloud = providers actually spoke = up.

I agree. = This is where we need to get enterprises to chime in on this topic. = Unfortunately enterprises often do not participate at the IETF, so our = mileage may vary here.

 
Sure - you and I agree on this, but Jim wants to push BGP = into non-carrier data centers ...
perhaps you can help convince him = otherwise ...

I could try, but it = would be like <insert blasphemy here>.
 
> The _cloud_ operator, in order to
> scale their DC, of = which the non-carrier DC is just a tenant, may want to run BGP. =  Just as
> enterprises running OSPF get connectivity services = from carriers running BGP.

I absolutely agree, and nvo3 is applicable to non-carrier = DCs.

NVO3 is indeed applicable to = both carrier and non-carrier cloud = providers.

It is = applicable wherever people decide to use it, which is still up for = debate since it does not really exist yet in any deployable form as far = as I know. *)   What is important is that people that *think* they = want to use it to step up and say so as soon as = possible!

--Tom


> > This can = be particularly so for a data center that desires flexibility in choice = among carriers,
>
> Actually, BGP is what carriers talk to = each other, so I'm not sure how such a
> choice limits flexibility.

If one extends the = carrier's BGP instance into the data center, switching = carriers
becomes more difficult by comparison to ...

> = > and hence operates under the principle that one of the jobs of the = CPE box is to keep the carrier
> technology on the other side in order to limit = lock-in.
>
> The "other" side of a CPE box usually runs = BGP.

... having the CPE box do its job in keeping the = carrier's instance of BGP on the carrier's side ("other" side of the = box) where the carrier's admins can manage it without having to bother = the data center admins much.f

Got = it.

Cheers,
Kireeti.
 
Thanks,
--David


= --Apple-Mail=_7CB1728D-8AAD-4EE8-A476-3E3C84A9BBD1-- From yhertogh@cisco.com Tue Apr 3 05:28:34 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B7821F8619; Tue, 3 Apr 2012 05:28: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 eK9Y4XCoxJqk; Tue, 3 Apr 2012 05:28:33 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0FC21F878A; Tue, 3 Apr 2012 05:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=yhertogh@cisco.com; l=3522; q=dns/txt; s=iport; t=1333456113; x=1334665713; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=1KSylUnm5yeMoZZfQ/abcofyrrIP50jn2XzKzWDH4Cs=; b=TSyzo9ku0nitKtdgHPWvyG9oodPnfz/WxHtPTfzSAq6gszOLa3OqIniE yiRCoNZxOif++/BcRoQgIKJyVK1vx49hbTj+WKXn3Rgwubj0v3Oatcdk/ i9VZMp7ppIvB4pd0ycGSq8WwGjilvfTyH40+ULIlOTtdv6vQ3GHpPnDdD c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEjsek+Q/khR/2dsb2JhbABFt3CBB4IJAQEBAwEBAQEPAR0KNAsFBwQCAQgRBAEBAQoGFwEGASAGHwkIAQEEARIIEweHYgULnCSfEgSKDoV1YwShFoMUgWmCaQ X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="70008277" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 03 Apr 2012 12:28:29 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q33CST1s021467; Tue, 3 Apr 2012 12:28:29 GMT Received: from xmb-ams-102.cisco.com ([144.254.74.77]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 14:28:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nvo3] Response to some comments on IS-IS VPLS Date: Tue, 3 Apr 2012 14:28:28 +0200 Message-ID: <3E615BDA133CA742BB1CC4E81899EFCB0816222E@XMB-AMS-102.cisco.com> In-Reply-To: <4F7A1D71.5010403@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nvo3] Response to some comments on IS-IS VPLS thread-index: Ac0RGaHyQG+hx0gkRIqn0mFPqufAMgAe1m+w References: <4F7A1D71.5010403@raszuk.net> From: "Yves Hertoghs (yhertogh)" To: , "Ken Gray" X-OriginalArrivalTime: 03 Apr 2012 12:28:29.0638 (UTC) FILETIME=[46A12E60:01CD1195] X-Mailman-Approved-At: Tue, 03 Apr 2012 05:47:53 -0700 Cc: l2vpn@ietf.org, nvo3@ietf.org, "Ali Sajassi \(sajassi\)" , Jon Hudson X-BeenThere: l2vpn@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, 03 Apr 2012 12:28:34 -0000 And lets not forget the hybrid case: NVO3 should support the use case of connectivity of VM's connected to a virtual switch to servers or network appliances connected to a 'real' switch. The control plane for host to location mapping should be the same for all three cases: * real switch to real switch * virtual switch to virtual switch * real to virtual switch Yves -----Original Message----- From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Monday, April 02, 2012 23:43 To: Ken Gray Cc: l2vpn@ietf.org; nvo3@ietf.org; Ali Sajassi (sajassi); Jon Hudson Subject: Re: [nvo3] Response to some comments on IS-IS VPLS Hi Ken, I knew someone will misinterpret it. Where do you see in my message that I proposing isolated solution ?=20 Where do you see that I am against standard based service NNI ? BGP is a perfect candidate for such NNI interface too. I like BGP or XMPP extension proposal. Do you think that standards based solutions are possible only to be build and delivered by few vendors ? I think those times are over .... I specifically said that I would like to have a solution which does not require to depend on hardware vendors which offer software + hardware bundles. Doing encap/decap in OVS on hypervisor completely does not mean that I am going to focus on my own "isolated" proprietary control plane solution. That very wrong interpretation completely opposite to the real goals. Contrary NVO3 could standardize a control plane solution which does not result in locking customers to vendors. That's the point. Best, R. > The description below, of self-contained isolationism ..isn't a=20 > candidate for a standard at all. If you're writing it yourself, and=20 > you're not using any vendor's equipment (I'll do it all with COTS=20 > power and my own > coding) ... I'd suggest that a proprietary solution is just fine for=20 > you (that's not meant as sarcasm ...I'm honoring the motivation of=20 > being independent of someone else's development cycles). > > > > On 4/2/12 4:43 PM, "Jon Hudson" wrote: > >> >> Bingo >> >> On Apr 2, 2012, at 1:34 PM, Robert Raszuk wrote: >> >>> >>>> Why do you think, the encap/decap must be done on the end-host=20 >>>> (hypvervisor, OVS,etc.). >>> >>> Very simple. >>> >>> Because I do not want to buy, install and operate network equipment >> >from vendors even if this is interoperable across N vendors and=20 >> >rubber >>> stamped by IETF. >>> >>> It is not only about cost savings, velocity about enhancement=20 >>> delivery speed by vendor, but also about service differentiation=20 >>> between my network and competition. >>> >>> Best, >>> R. >>> >>>> Hi Robert, >>>> >>>> The connectivity between the two VMs is provided by L2VPN over=20 >>>> MPLS/IP >>>> - >>>> e.g.,, VM1/VLAN1 an VM2/VLAN1 are mapped to the same L2VPN. Why do=20 >>>> you think, the encap/decap must be done on the end-host=20 >>>> (hypvervisor, OVS,etc.). >>>> >>>> Cheers, >>>> Ali >>> _______________________________________________ >>> 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 > > > _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From robert@raszuk.net Tue Apr 3 07:33:56 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208F521F8777 for ; Tue, 3 Apr 2012 07:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 yyuSYCdEbsj8 for ; Tue, 3 Apr 2012 07:33:55 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id F295121F8781 for ; Tue, 3 Apr 2012 07:33:54 -0700 (PDT) Received: (qmail 23447 invoked by uid 399); 3 Apr 2012 14:33:52 -0000 Received: from unknown (HELO ?10.140.221.33?) (pbs:robert@raszuk.net@80.187.201.77) by mail1310.opentransfer.com with ESMTPM; 3 Apr 2012 14:33:52 -0000 X-Originating-IP: 80.187.201.77 Message-ID: <4F7B0A50.3050602@raszuk.net> Date: Tue, 03 Apr 2012 16:33:52 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "Yves Hertoghs (yhertogh)" Subject: Re: [nvo3] Response to some comments on IS-IS VPLS References: <4F7A1D71.5010403@raszuk.net> <3E615BDA133CA742BB1CC4E81899EFCB0816222E@XMB-AMS-102.cisco.com> In-Reply-To: <3E615BDA133CA742BB1CC4E81899EFCB0816222E@XMB-AMS-102.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, nvo3@ietf.org, "Ali Sajassi \(sajassi\)" , Ken Gray , Jon Hudson X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 14:33:56 -0000 Yves, Use case is to make sure the connectivity can be achieved in all 3 below cases - no doubt. However it seems to me like clear mistake to mandate one control plane to fit all. I can interwork with BGP control plane or with LISP for that matter just fine and still program my OVSes or switches with the control plane of my choice so end points would inter-operate just fine. Best, R. > The control plane for host to > location mapping should be the same for all three cases: > * real switch to real switch > * virtual switch to virtual switch > * real to virtual switch From ju1738@att.com Tue Apr 3 09:53:29 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41E921F866E; Tue, 3 Apr 2012 09:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 IroHG41qe-7Q; Tue, 3 Apr 2012 09:53:25 -0700 (PDT) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id 03C1B21F85EA; Tue, 3 Apr 2012 09:53:24 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo03.seg.att.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-8) with ESMTP id 50b2b7f4.2aaaca409940.763638.00-573.2119743.nbfkord-smmo03.seg.att.com (envelope-from ); Tue, 03 Apr 2012 16:53:25 +0000 (UTC) X-MXL-Hash: 4f7b2b053a856fc7-ead41ef40f9b86c23e448b44eda607c7a2c296b1 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id cfa2b7f4.0.763557.00-390.2119493.nbfkord-smmo03.seg.att.com (envelope-from ); Tue, 03 Apr 2012 16:53:17 +0000 (UTC) X-MXL-Hash: 4f7b2afd0d387d1c-1fbb15d41219c0b889443ecb638c2a75a384a688 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q33GrGjk026093; Tue, 3 Apr 2012 12:53:16 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q33Gr7Ia025949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2012 12:53:09 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by sflint01.pst.cso.att.com (RSA Interceptor); Tue, 3 Apr 2012 12:52:49 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.12]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.01.0355.002; Tue, 3 Apr 2012 12:52:49 -0400 From: "UTTARO, JAMES" To: "'Thomas Nadeau'" , Kireeti Kompella Subject: RE: [nvo3] Response to some comments on IS-IS VPLS Thread-Topic: [nvo3] Response to some comments on IS-IS VPLS Thread-Index: Ac0RAo9Do12B0RP+lEO1DyVa7X7/swAA6AMwABPatgAAF4oIAAABLWjw Date: Tue, 3 Apr 2012 16:52:49 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0CAE@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0E23@szxeml525-mbs.china.huawei.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80849@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80AAC@MX14A.corp.emc.com> <1746A111-DD94-45D1-A939-355299EC91F9@lucidvision.com> In-Reply-To: <1746A111-DD94-45D1-A939-355299EC91F9@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.233.245] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FAB7B82MISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=zBuXR8exKQwA:10 a=9sJQ9ZpC_ycA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=OUXY8nFuAAAA:8 a=G0_B3m8xAAAA:8 a=FTg-WU4ZA] X-AnalysisOut: [AAA:8 a=Zg1smiEFAYJqnUHZazoA:9 a=4o_XmSWycpekMiYgELkA:7 a=] X-AnalysisOut: [CjuIK1q_8ugA:10 a=Z74KZzsu6UoA:10 a=lZB815dzVvQA:10 a=peF9] X-AnalysisOut: [eE_zjQwA:10 a=lW_bInUQU2sA:10 a=yMhMjlubAAAA:8 a=SSmOFEACA] X-AnalysisOut: [AAA:8 a=O5Wnyq50DCwDnpeysw4A:9 a=QVpcL3dLHmJl4H2NPPgA:7 a=] X-AnalysisOut: [gKO2Hq4RSVkA:10 a=hTZeC7Yk6K0A:10 a=tXsnliwV7b4A:10 a=_vud] X-AnalysisOut: [qbQabfQA:10 a=wwX0pvipsOoA:10] Cc: "kireeti@juniper.net" , "l2vpn@ietf.org" , "david.black@emc.com" , "nvo3@ietf.org" X-BeenThere: l2vpn@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, 03 Apr 2012 16:53:29 -0000 --_000_B17A6910EEDD1F45980687268941550FAB7B82MISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments In-Line Jim Uttaro From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of T= homas Nadeau Sent: Tuesday, April 03, 2012 8:07 AM To: Kireeti Kompella Cc: kireeti@juniper.net; l2vpn@ietf.org; david.black@emc.com; nvo3@ietf.org Subject: Re: [nvo3] Response to some comments on IS-IS VPLS On Apr 2, 2012:8:52 PM, at 8:52 PM, Kireeti Kompella wrote: Hi David, On Mon, Apr 2, 2012 at 12:34 PM, > wrote: Hi Kireeti, We're in agreement, and thank you for your comments at the BOF. Here are a= few elaborations: It's great that (we think) we're in agreement, but just in case ... > > OTOH, for a non-carrier data center (e.g., enterprise), not only is the= above statement rather > incorrect, but the enterprise network may not be running BGP. > > Step back a bit. The non-carrier DC is not being asked to run BGP. There are two ways to interpret "non-carrier DC": a) enterprises that have a DC but want to move to the clouds (i.e., custome= rs); b) non-carriers that *build* clouds (e.g., EC2). There is a third that you are missing: simply enterprises that = have a DC today - whether or not they have moved any services to a XaaS mod= el or not is not that important per se. These are simply DCs (some very la= te if you look at financial institutions). Some of these fall into the cat= egories being discussed around the hesitation around using different protoc= ols. I actually like to divide up the space a little differently: Traditional telco service providers (i.e.: att, vz, etc...) "New" service providers (i.e.: google, salesforce.com, amazon, rackspace, etc...) Enterprise (large, med, small, and govt) If you look at things using that lens, I think the answers may = differ from your conclusions because as you will find, there are differing = levels of comfort for doing certain things, as well as different business c= onstraints/drivers - or resistors. [Jim U>] Again I become lost.. You mention three categories.. I understand = the comment in re business constraints/drivers although I have not seen th= at documented anywhere as a rationale for technical solution... The notion = of "differing levels of comfort" seems to be code for adherence to a certai= n technology.. This I do not understand... The best path forward is t docum= ent the current reqs/business drivers, and anticipate how the service will = evolve.. If we do this we can have a discussion about the needs not the wan= ts.. It is a non-starter to ask those in (a) to run BGP (or to change any of the= ir practices in any significant way). It is a definite possibility to ask the non-carrier cloud provider to adopt= BGP as the scaling mechanism. That depends on what their needs and level of expertise are. We= are making broad characterizations of enterprises that I think need to be = more granular for them to make sense (see above). (oh, oh -- the end of a beautiful friendship, just as it was getting going = ... :-)) BGP is a well-tested protocol for scaling. Yes, there are complexities, so= me real, some perceived. The question is, is it easier to simplify BGP (al= ong the lines that Alia said), or break loose and start again? The answer for SP-cloud providers seems clear. The answer for non-carrier = cloud providers is open. I'm going to revisit this thread and see how many= non-carrier cloud providers actually spoke up. I agree. This is where we need to get enterprises to chime in o= n this topic. Unfortunately enterprises often do not participate at the IET= F, so our mileage may vary here. [Jim U>] How do we do that? Sure - you and I agree on this, but Jim wants to push BGP into non-carrier = data centers ... perhaps you can help convince him otherwise ... I could try, but it would be like . [Jim U>] LOL.. > The _cloud_ operator, in order to > scale their DC, of which the non-carrier DC is just a tenant, may want to= run BGP. Just as > enterprises running OSPF get connectivity services from carriers running = BGP. I absolutely agree, and nvo3 is applicable to non-carrier DCs. NVO3 is indeed applicable to both carrier and non-carrier cloud providers. It is applicable wherever people decide to use it, which is sti= ll up for debate since it does not really exist yet in any deployable form = as far as I know. *) What is important is that people that *think* they w= ant to use it to step up and say so as soon as possible! [Jim U>] But what is equally important is to know what any solution does an= d does not solve... --Tom > > This can be particularly so for a data center that desires flexibility = in choice among carriers, > > Actually, BGP is what carriers talk to each other, so I'm not sure how su= ch a > choice limits flexibility. If one extends the carrier's BGP instance into the data center, switching c= arriers becomes more difficult by comparison to ... > > and hence operates under the principle that one of the jobs of the CPE = box is to keep the carrier > technology on the other side in order to limit lock-in. > > The "other" side of a CPE box usually runs BGP. ... having the CPE box do its job in keeping the carrier's instance of BGP = on the carrier's side ("other" side of the box) where the carrier's admins = can manage it without having to bother the data center admins much.f Got it. Cheers, Kireeti. Thanks, --David --_000_B17A6910EEDD1F45980687268941550FAB7B82MISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Comments In-Line

 

          =       Jim Uttaro

 

From: l2vpn-bo= unces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Thomas Nadeau
Sent: Tuesday, April 03, 2012 8:07 AM
To: Kireeti Kompella
Cc: kireeti@juniper.net; l2vpn@ietf.org; david.black@emc.com; nvo3@i= etf.org
Subject: Re: [nvo3] Response to some comments on IS-IS VPLS

 

 

On Apr 2, 2012:8:52 PM, at 8:52 PM, Kireeti Kompella= wrote:



Hi David,

On Mon, Apr 2, 2012 at 12:34 PM, <david.= black@emc.com> wrote:

Hi Kireeti,

We're in agreement, and thank you for your comments at the BOF.  Here = are a few elaborations:

 

It's great that (we think) we're in agreement, but just in c= ase ...

 

> > OTOH, for a non-carrier data center (e.g., enterpr= ise), not only is the above statement rather
> incorrect, but the enterprise network may not be running BGP.
>
> Step back a bit. The non-carrier DC is not being asked to run BGP.

 

There are two ways to interpret "non-carrier DC":<= o:p>

a) enterprises that have a DC but want to move to the clouds= (i.e., customers);

b) non-carriers that *build* clouds (e.g., EC2).<= /span>

 

   &nb= sp;        There is a third that = you are missing: simply enterprises that have a DC today - whether or not t= hey have moved any services to a XaaS model or not is not that important pe= r se.  These are simply DCs (some very late if you look at financial institutions).  S= ome of these fall into the categories being discussed around the hesitation= around using different protocols.

 

   &nb= sp;        I actually like to div= ide up the space a little differently:

 

   &nb= sp;        Traditional telco serv= ice providers (i.e.: att, vz, etc…)

   &nb= sp;        "New" servic= e providers (i.e.: google, salesforce.com, amazon, rackspace, et= c…)

   &nb= sp;        Enterprise (large, med= , small, and govt)

 

   &nb= sp;        If you look at things = using that lens, I think the answers may differ from your conclusions becau= se as you will find, there are differing levels of comfort for doing certai= n things, as well as different business constraints/drivers - or resistors.

[Jim U>] Again I become lost.. You mention three categori= es.. I understand the comment in re business  constraints/drivers alth= ough I have not seen that documented anywhere as a rationale for technical solution… The = notion of “differing levels of comfort” seems to be code for ad= herence to a certain technology.. This I do not understand… The best = path forward is t document the current reqs/business drivers, and anticipate how the service will evolve.. If we do this we can have a d= iscussion about the needs not the wants..

 

It is a= non-starter to ask those in (a) to run BGP (or to change any of their prac= tices in any significant way).

 

It is a definite possibility to ask the non-carrier cloud pr= ovider to adopt BGP as the scaling mechanism.

 

   &nb= sp;        That depends on what t= heir needs and level of expertise are. We are making broad characterization= s of enterprises that I think need to be more granular for them to make sen= se (see above). 



(oh, oh= -- the end of a beautiful friendship, just as it was getting going ... :-)= )

 

BGP is a well-tested protocol for scaling.  Yes, there = are complexities, some real, some perceived.  The question is, is it e= asier to simplify BGP (along the lines that Alia said), or break loose and start again?

 

The answer for SP-cloud providers seems clear.  The ans= wer for non-carrier cloud providers is open.  I'm going to revisit thi= s thread and see how many non-carrier cloud providers actually spoke up.

 

   &nb= sp;        I agree. This is where= we need to get enterprises to chime in on this topic. Unfortunately enterp= rises often do not participate at the IETF, so our mileage may vary here.

[Jim U>] How do we do that?



 

Sure - you and I agree on this, but Jim wants to push BGP in= to non-carrier data centers ...
perhaps you can help convince him otherwise ...

 

I could try, but it would be like <insert blasphemy here&= gt;.

[Jim U>] LOL..=

 

> Th= e _cloud_ operator, in order to
> scale their DC, of which the non-carrier DC is just a tenant, may want= to run BGP.  Just as
> enterprises running OSPF get connectivity services from carriers runni= ng BGP.

I absolutely agree, and nvo3 is applicable to non-carrier DC= s.

 

NVO3 is indeed applicable to both carrier and non-carrier cl= oud providers.

 

   &nb= sp;        It is applicable where= ver people decide to use it, which is still up for debate since it does not= really exist yet in any deployable form as far as I know. *)   What i= s important is that people that *think* they want to use it to step up and say so as soon as possible= !

[Jim U>] But what is equally important is to know what an= y solution does and does not solve…  

   &nb= sp;        --Tom



 

> &g= t; This can be particularly so for a data center that desires flexibility i= n choice among carriers,
>
> Actually, BGP is what carriers talk to each other, so I'm not sure how= such a
> choice limits flexibility.

If one extends the carrier's BGP instance into the data cent= er, switching carriers
becomes more difficult by comparison to ...


> > and hence operates under the principle that one of the jobs of th= e CPE box is to keep the carrier
> technology on the other side in order to limit lock-in.
>
> The "other" side of a CPE box usually runs BGP.

... having the CPE box do its job in keeping the carrier's i= nstance of BGP on the carrier's side ("other" side of the box) wh= ere the carrier's admins can manage it without having to bother the data center admins much.f

 

Got it.

 

Cheers,

Kireeti.

 

Thanks,
--David

 

 

--_000_B17A6910EEDD1F45980687268941550FAB7B82MISOUT7MSGUSR9IIT_-- From kireeti.kompella@gmail.com Tue Apr 3 11:45:50 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38F211E80DC; Tue, 3 Apr 2012 11:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 JvvK8gOkedhh; Tue, 3 Apr 2012 11:45:50 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id E022611E8083; Tue, 3 Apr 2012 11:45:49 -0700 (PDT) Received: by dady13 with SMTP id y13so16748dad.27 for ; Tue, 03 Apr 2012 11:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:mime-version:references:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date; bh=UK7/W//0exKyPV6pbEeAtV53Hdbnw1PycKCg2NzrajQ=; b=bRLZhmIXt03EpuAmKIyoFpzGJ9CFppMbd+CH0W1U36s77apcPJ03/88WY9jGK0t1dy rIUUkr2fGzlnO8/6QXnjB5g2N8yStsxfmOXCkZA+mjCJOwyyLiC8fX4YW7YQffsm2xvo eAcAv3ANajZv/xzNP5XjWtPrau7cSLU8A8eROV/+n4JrHRucPX7FKWTLQE92cF8HxyeA aVPVo7CpM281tx87dr1hdW8QhKVgMcX4Qb9qbD0gPQnVNJDv5gnVB3U/sT/f/0PXcHMk sTozi0ySUMbEe7w2pAkeWohXsAZMwv1CciY/JEyzqBsRkgWQU8htkvfeXyVFZcEUajjf SDRw== Received: by 10.68.201.65 with SMTP id jy1mr30898210pbc.5.1333478749684; Tue, 03 Apr 2012 11:45:49 -0700 (PDT) Received: from [192.168.107.201] (adsl-69-106-227-22.dsl.pltn13.pacbell.net. [69.106.227.22]) by mx.google.com with ESMTPS id mg3sm10811577pbc.51.2012.04.03.11.45.48 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Apr 2012 11:45:49 -0700 (PDT) To: Chris Wright Mime-Version: 1.0 (1.0) References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0CAE@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0E23@szxeml525-mbs.china.huawei.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80849@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80AAC@MX14A.corp.emc.com> <20120403181525.GJ19952@sequoia.sous-sol.org> In-Reply-To: <20120403181525.GJ19952@sequoia.sous-sol.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (9A405) From: Kireeti Kompella Subject: Re: [nvo3] Response to some comments on IS-IS VPLS Date: Tue, 3 Apr 2012 11:45:53 -0700 X-Mailman-Approved-At: Tue, 03 Apr 2012 13:33:14 -0700 Cc: "kireeti@juniper.net" , "l2vpn@ietf.org" , "david.black@emc.com" , "nvo3@ietf.org" X-BeenThere: l2vpn@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, 03 Apr 2012 18:45:50 -0000 On Apr 3, 2012, at 11:15, Chris Wright wrote: > * Kireeti Kompella (kireeti.kompella@gmail.com) wrote: >> There are two ways to interpret "non-carrier DC": >> a) enterprises that have a DC but want to move to the clouds (i.e., >> customers); >=20 > I think you missed a large portion of the enterprise DC world. > Enterprises that have a DC and are beginning to run their DC internally > as a cloud, aka the private cloud. Good point. Which brings me back to the charter: is NVO3 aimed at _large_ virtualized DC= s, or _any_ vDCs? To Chris's point, if an enterprise builds/converts their DC into a private c= loud of a thousand or two VMs, would that be in scope for NVO3? I'm not looking for a threshold, rather whether scale is (should be) part of= the charter? Kireeti=20 > thanks, > -chris From robert@raszuk.net Tue Apr 3 13:37:47 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A50311E820A for ; Tue, 3 Apr 2012 13:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 1iizBzil9gQo for ; Tue, 3 Apr 2012 13:37:46 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id BEF8111E820B for ; Tue, 3 Apr 2012 13:37:45 -0700 (PDT) Received: (qmail 29836 invoked by uid 399); 3 Apr 2012 20:37:44 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.9.128.186) by mail1310.opentransfer.com with ESMTPM; 3 Apr 2012 20:37:44 -0000 X-Originating-IP: 83.9.128.186 Message-ID: <4F7B5F97.4010301@raszuk.net> Date: Tue, 03 Apr 2012 22:37:43 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Kireeti Kompella Subject: Re: [nvo3] Response to some comments on IS-IS VPLS References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0CAE@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0E23@szxeml525-mbs.china.huawei.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80849@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80AAC@MX14A.corp.emc.com> <20120403181525.GJ19952@sequoia.sous-sol.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Chris Wright , "kireeti@juniper.net" , "david.black@emc.com" , "nvo3@ietf.org" , "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 20:37:47 -0000 > To Chris's point, if an enterprise builds/converts their DC into a > private cloud of a thousand or two VMs, would that be in scope for > NVO3? Why not ? Oooo maybe BGP based solution would be a bit suboptimal for 2 or 22 VMs case ? Bad luck :( Best, R. From kreeger@cisco.com Tue Apr 3 14:50:19 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A9021F86D6; Tue, 3 Apr 2012 14:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 P37EvbH7Fvru; Tue, 3 Apr 2012 14:50:17 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 88BF421F86CE; Tue, 3 Apr 2012 14:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kreeger@cisco.com; l=2726; q=dns/txt; s=iport; t=1333489817; x=1334699417; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=LcAPNJLTxoQSYGK8HafP1Vm10MLnNlbRCU1d/UAb1VI=; b=OnNUBJxxpr6+FLdv31NLq5Y1Bq8PLYLH348v7UxncNsFkiIJfzV6ocBe GuDj9OPEUitn0Aa87JQNgA6mpnMPkQ1g0PET7YSakTMpEOzZUXISldxee tYgJQ5Ax0buBtqMQ7V7E0/FHCupURDw7XXEPP0rADtsHHOL6Zev5rgaQc U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4IAG5we0+rRDoJ/2dsb2JhbABDuCACgQeCCQEBAQMBEgEnAgEqBgMJBQ0BCBhPNgEBBAENBRsHh2IEn2+XC4oOhlgEiFiNC4szgxQngUKDBw X-IronPort-AV: E=Sophos;i="4.75,365,1330905600"; d="scan'208";a="38926794" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 03 Apr 2012 21:50:11 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q33LoA4F003511; Tue, 3 Apr 2012 21:50:10 GMT Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 14:50:10 -0700 Received: from 171.70.214.10 ([171.70.214.10]) by xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) via Exchange Front-End Server email.cisco.com ([128.107.191.79]) with Microsoft Exchange Server HTTP-DAV ; Tue, 3 Apr 2012 21:50:10 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 03 Apr 2012 14:50:10 -0700 Subject: Re: [nvo3] Response to some comments on IS-IS VPLS From: Larry Kreeger To: Kireeti Kompella , Chris Wright Message-ID: Thread-Topic: [nvo3] Response to some comments on IS-IS VPLS Thread-Index: Ac0R472cUeNdnVh/+E2mvJjz0E/gtw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Apr 2012 21:50:10.0702 (UTC) FILETIME=[BE0772E0:01CD11E3] Cc: "kireeti@juniper.net" , "l2vpn@ietf.org" , David Black , "nvo3@ietf.org" X-BeenThere: l2vpn@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, 03 Apr 2012 21:50:20 -0000 On 4/3/12 11:45 AM, "Kireeti Kompella" wrote: > On Apr 3, 2012, at 11:15, Chris Wright wrote: > >> * Kireeti Kompella (kireeti.kompella@gmail.com) wrote: > > > >>> There are two ways to interpret "non-carrier DC": >>> a) enterprises that have a DC but want to move to the clouds (i.e., >>> customers); >> >> I think you missed a large portion of the enterprise DC world. >> Enterprises that have a DC and are beginning to run their DC internally >> as a cloud, aka the private cloud. > > Good point. > > Which brings me back to the charter: is NVO3 aimed at _large_ virtualized DCs, > or _any_ vDCs? > > To Chris's point, if an enterprise builds/converts their DC into a private > cloud of a thousand or two VMs, would that be in scope for NVO3? > > I'm not looking for a threshold, rather whether scale is (should be) part of > the charter? Kireeti, IMO, the goal of the WG should be to address the needs of small/medium enterprise private clouds all the way up to large cloud service providers. In an earlier version of the proposed WG charter put out on the nvo3 list by Thomas Narten on March 24th, he tried to address this with the following text which was later removed to simplify/generalize the charter: "A key area of work is the development of requirements for (and to find solutions for) control plane functions that allow an ingress to the overlay to map the "inner" (tenant VM) address into an "outer" (underlying network) address in order to tunnel a packet to the destination VM. Two different approaches will be pursued, targeting two different deployment environments. The first approach will document a data plane learning mechanism similar to IEEE 802.1Q learning and would be appropriate for smaller data centers where flooding of frames to unknown destinations is not considered a major problem. This document is expected to be relatively short, as IEEE 802.1Q learning is well-documented and understood. The second approach will focus on a control plane aimed at large data centers, capable of scaling to hundreds of thousands of nodes. This control plane will be the major work item for this WG. A key requirement will be to avoid the need for flooding in the case where a mapping from an inner source VM to a target tunnel end point address is not present at the ingress to the overlay network. A second requirement may be that the control plane must also be applicable to geographically dispersed data centers supporting a single overlay. The first work item is to develop requirements for this control protocol." - Larry > Kireeti > >> thanks, >> -chris > From kreeger@cisco.com Tue Apr 3 14:55:19 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E32E11E809F; Tue, 3 Apr 2012 14:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.833 X-Spam-Level: X-Spam-Status: No, score=-7.833 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 bBrCkAZCx+TQ; Tue, 3 Apr 2012 14:55:18 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 762CA21F870B; Tue, 3 Apr 2012 14:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kreeger@cisco.com; l=2439; q=dns/txt; s=iport; t=1333490118; x=1334699718; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=X8rIjfCLcLtr8lZmToyWipnSmSGfW91FWEuPbmbJGBY=; b=Jn013adnMU0TBNEV3lGtDRaNLFv8fa3dwf9V1rREWyA7gJuNMVlN1qZd jiSaIXu1npLHaVpWI5xmaHO3/w0h7ZhacC5eLGzYmLns3ce0qYvg1tL3k mPi4DJrmzUdvY233uTPSjxPBtXAz/DLBQIOtW0Fw0suxr96kUHRAyWsEr Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEJAGJxe0+rRDoG/2dsb2JhbABFgka0VncCgQeCCQEBAQMBEgEqKgkJEgEIBAEJgQ8BAQQBDQUih2IEAZtLnnGQZgSIWI0LjkcngUKDBw X-IronPort-AV: E=Sophos;i="4.75,365,1330905600"; d="scan'208,217";a="38836929" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 03 Apr 2012 21:55:18 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q33LtIqR025025; Tue, 3 Apr 2012 21:55:18 GMT Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 14:55:12 -0700 Received: from 171.70.214.10 ([171.70.214.10]) by xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) via Exchange Front-End Server email.cisco.com ([171.70.151.174]) with Microsoft Exchange Server HTTP-DAV ; Tue, 3 Apr 2012 21:55:12 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 03 Apr 2012 14:55:10 -0700 Subject: Re: [nvo3] Response to some comments on IS-IS VPLS From: Larry Kreeger To: Thomas Nadeau , Kireeti Kompella Message-ID: Thread-Topic: [nvo3] Response to some comments on IS-IS VPLS Thread-Index: Ac0R5HBsLTebSFHNdU2VZw6959fdiA== In-Reply-To: <1746A111-DD94-45D1-A939-355299EC91F9@lucidvision.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3416309710_1003592" X-OriginalArrivalTime: 03 Apr 2012 21:55:12.0754 (UTC) FILETIME=[7210ED20:01CD11E4] Cc: kireeti@juniper.net, l2vpn@ietf.org, David Black , nvo3@ietf.org X-BeenThere: l2vpn@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, 03 Apr 2012 21:55:19 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3416309710_1003592 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I agree that is very unlikely that any small/medium enterprises are monitoring this list in order to chime in. I think the closest we will be able to get may be hypervisor vendors that talk with customers like these to hear their requirements. - Larry On 4/3/12 5:06 AM, "Thomas Nadeau" wrote: >> The answer for SP-cloud providers seems clear. The answer for non-carrier >> cloud providers is open. I'm going to revisit this thread and see how many >> non-carrier cloud providers actually spoke up. > > I agree. This is where we need to get enterprises to chime in on this topic. > Unfortunately enterprises often do not participate at the IETF, so our mileage > may vary here. --B_3416309710_1003592 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [nvo3] Response to some comments on IS-IS VPLS I agree that is very unlikely that any small/medium enterprises are monito= ring this list in order to chime in.  I think the closest we will be ab= le to get may be hypervisor vendors that talk with customers like these to h= ear their requirements.

 - Larry


On 4/3/12 5:06 AM, "Thomas Nadeau" <tnadeau@lucidvision.com> wrote:

The answer for SP-cloud providers seems clear. &nb= sp;The answer for non-carrier cloud providers is open.  I'm going to re= visit this thread and see how many non-carrier cloud providers actually spok= e up.

I agree. This is where we need to get enterprises to chime in on this topic= . Unfortunately enterprises often do not participate at the IETF, so our mil= eage may vary here.
--B_3416309710_1003592-- From kireeti.kompella@gmail.com Tue Apr 3 15:33:49 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB0F11E809D; Tue, 3 Apr 2012 15:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 U4canY76y9GH; Tue, 3 Apr 2012 15:33:48 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C1E9911E8086; Tue, 3 Apr 2012 15:33:48 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so319511pbb.31 for ; Tue, 03 Apr 2012 15:33:48 -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-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; bh=DN67KDAYWgp/6YfaYUfhrzQMz9D/7MzruCo1R64il1E=; b=lLuYJ31dn2DzZTBT87XSDaPR0JCIOC8KbGckAmIwPidsuMFLc8lcztWXxT4Wa+7IV4 E49G7MUJxSwXmhVz26jlXXRJF66EPvmYG1onlAZCBVQGw2uDwQOofL7TqV3pcoUuDzx4 cLJIlRGLlzV66WKS2sYGv8y4Z9BcHGZlB0rgMqHO5RMME+Mmf/3CtbXPj9CzOvwuJnro kYrTMOfvKzoNGICVJ2vf5RjviWxzITmk3uCwnbNikadt12na7EObhW49J2s0/juSl5ZN xIulvYz8wSNcWtpCUOFehuxAH5za/uv4+U53mflqfMNaJP7GXDREm19jaJ1F1MB9tvJM ebxA== Received: by 10.68.222.165 with SMTP id qn5mr31904698pbc.88.1333492428591; Tue, 03 Apr 2012 15:33:48 -0700 (PDT) Received: from [192.168.107.201] (adsl-69-106-227-22.dsl.pltn13.pacbell.net. [69.106.227.22]) by mx.google.com with ESMTPS id o7sm17179044pbq.8.2012.04.03.15.33.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Apr 2012 15:33:48 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <7E61C263-A4B8-4A3D-8293-147ACDC1CDB7@gmail.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (9A405) From: Kireeti Kompella Subject: Re: [nvo3] Response to some comments on IS-IS VPLS Date: Tue, 3 Apr 2012 15:33:51 -0700 To: Larry Kreeger X-Mailman-Approved-At: Tue, 03 Apr 2012 15:48:02 -0700 Cc: Chris Wright , "kireeti@juniper.net" , David Black , "nvo3@ietf.org" , "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 03 Apr 2012 22:33:49 -0000 Hi Larry, On Apr 3, 2012, at 14:50, Larry Kreeger wrote: > IMO, the goal of the WG should be to address the needs of small/medium > enterprise private clouds all the way up to large cloud service providers.= The question is, is there really a problem to solve in the small/medium priv= ate cloud space? There is an existence proof that existing methodologies (l= ayer 2) work adequately here. So, a rationale for including these cases wou= ld be helpful. Kireeti From sajassi@cisco.com Tue Apr 3 17:09:30 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1865F11E8103; Tue, 3 Apr 2012 17:09:30 -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 SI7suVyN47+t; Tue, 3 Apr 2012 17:09:29 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5E90911E8074; Tue, 3 Apr 2012 17:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sajassi@cisco.com; l=1051; q=dns/txt; s=iport; t=1333498169; x=1334707769; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=ysliERS9/CE8Fxu4G7RWhYtveldXJWA9ZPIqVn6GxuE=; b=SdCcksvTk8iE6fWjD1KDCdoPGWZBXD+VQ2yF7+1itmP9/1xJXyHIRcVo g1SDlrwbQtngNtfmIoN/Vd4qUyIdypyEzuzzBhqX7PtVI0/vugdD90yCr deR44IvOvma2g+seQ+Cv+jHDaAsMgGzAdjm+609a9FLLdvzfrfG1wpeq3 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYKALyQe0+rRDoG/2dsb2JhbABDtxEDgQyBB4IJAQEBAwESAScCATwSAQgJgRQBAQQOBSKHYgQBn2eXDotDgWKDJASIWIUqh2GOR4Fpgwc X-IronPort-AV: E=Sophos;i="4.75,365,1330905600"; d="scan'208";a="35827578" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 04 Apr 2012 00:09:28 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3409SEM006443; Wed, 4 Apr 2012 00:09:29 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 17:09:28 -0700 Received: from 10.21.124.124 ([10.21.124.124]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Wed, 4 Apr 2012 00:09:28 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 03 Apr 2012 17:09:28 -0700 Subject: Re: Response to some comments on IS-IS VPLS From: sajassi To: Message-ID: Thread-Topic: Response to some comments on IS-IS VPLS Thread-Index: Ac0R9zNdCyw3737mhU2LEhm4zhkDNA== In-Reply-To: <4F7A0D73.2030000@raszuk.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Apr 2012 00:09:28.0812 (UTC) FILETIME=[33D9D2C0:01CD11F7] Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" X-BeenThere: l2vpn@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, 04 Apr 2012 00:09:30 -0000 Hi Robert, Is this NTT strategy for both their SPDC and MSDC ? BTW, in case of SPDC, if the connectivity among DCs needs to span across different ASes, how do you plan to accommodate that? Cheers, Ali On 4/2/12 1:34 PM, "Robert Raszuk" wrote: > >> Why do you think, the encap/decap must be done on the end-host >> (hypvervisor, OVS,etc.). > > Very simple. > > Because I do not want to buy, install and operate network equipment from > vendors even if this is interoperable across N vendors and rubber > stamped by IETF. > > It is not only about cost savings, velocity about enhancement delivery > speed by vendor, but also about service differentiation between my > network and competition. > > Best, > R. > >> Hi Robert, >> >> The connectivity between the two VMs is provided by L2VPN over MPLS/IP - >> e.g.,, VM1/VLAN1 an VM2/VLAN1 are mapped to the same L2VPN. Why do you >> think, the encap/decap must be done on the end-host (hypvervisor, OVS,etc.). >> >> Cheers, >> Ali From kreeger@cisco.com Tue Apr 3 20:25:13 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9165611E80CD; Tue, 3 Apr 2012 20:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 P61j8UKkH04L; Tue, 3 Apr 2012 20:25:13 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id F2B1611E8072; Tue, 3 Apr 2012 20:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kreeger@cisco.com; l=1476; q=dns/txt; s=iport; t=1333509912; x=1334719512; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=vnbixxikfzvUWmPwIscGOvww6H+hEkVtUGzE/8XIIfs=; b=I+RqsLSsDv+BEcuafn3PEsgVqvNeDs7Yi/UjjjaH2FZw1Cevt5nAPhbd JrD+RDroKWwOoJLT1QCW+czCdH77lUvxPwcQnt3AbQzJQGAkDgN51z7CS 9XEsY6LMprrzfQiYBBfeY5MULnru1GocSInslNzAJn8cZ+A2GffvwzGJs I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwIAHK+e0+rRDoG/2dsb2JhbABDuCICgQeCCQEBAQMBAQEBDwEnAgExAgkFDQEIGE8GMAEBBA4FIodiBAELn2KXBQSKDnWFRgSIWI0LizODFCeBQoMHgTU X-IronPort-AV: E=Sophos;i="4.75,366,1330905600"; d="scan'208";a="35846148" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 04 Apr 2012 03:25:12 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q343PCJh017762; Wed, 4 Apr 2012 03:25:12 GMT Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 20:25:12 -0700 Received: from 171.71.13.147 ([171.71.13.147]) by xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) via Exchange Front-End Server email.cisco.com ([171.70.151.174]) with Microsoft Exchange Server HTTP-DAV ; Wed, 4 Apr 2012 03:25:12 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 03 Apr 2012 20:25:10 -0700 Subject: Re: [nvo3] Response to some comments on IS-IS VPLS From: Larry Kreeger To: Kireeti Kompella Message-ID: Thread-Topic: [nvo3] Response to some comments on IS-IS VPLS Thread-Index: Ac0SEooknmRplf7NMkmFnzUjr+Ewsg== In-Reply-To: <7E61C263-A4B8-4A3D-8293-147ACDC1CDB7@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Apr 2012 03:25:12.0691 (UTC) FILETIME=[8BBF8C30:01CD1212] Cc: Chris Wright , "kireeti@juniper.net" , David Black , "nvo3@ietf.org" , "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 04 Apr 2012 03:25:13 -0000 Kireeti, I think most of the reasons listed in the problem statement draft can apply to small/medium enterprise private clouds. However, one important rationale for a small/medium enterprise private cloud to use an overlay is to support dynamic extension of the overlay to the proper hypervisors on demand as the application load on the cloud changes and VMs migrate across the compute infrastructure. It is also possible that physical networks equipment can reach VLAN exhaustion well below the 4K theoretical VLAN limit both in the absolute number of VLANs supported and the number of virtual ports if they resort to trunking a couple of thousand VLANs to every single server for operational flexibility. - Larry On 4/3/12 3:33 PM, "Kireeti Kompella" wrote: > Hi Larry, > > On Apr 3, 2012, at 14:50, Larry Kreeger wrote: > >> IMO, the goal of the WG should be to address the needs of small/medium >> enterprise private clouds all the way up to large cloud service providers. > > The question is, is there really a problem to solve in the small/medium > private cloud space? There is an existence proof that existing methodologies > (layer 2) work adequately here. So, a rationale for including these cases > would be helpful. > > Kireeti > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From chrisw@sous-sol.org Tue Apr 3 17:27:27 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD03421F865C; Tue, 3 Apr 2012 17:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 j76EuX7M98oE; Tue, 3 Apr 2012 17:27:27 -0700 (PDT) Received: from mail.sous-sol.org (sous-sol.org [216.99.217.87]) by ietfa.amsl.com (Postfix) with ESMTP id 4811221F8658; Tue, 3 Apr 2012 17:27:27 -0700 (PDT) Received: from sequoia.sous-sol.org (sequoia.sous-sol.org [127.0.0.1]) by sequoia.sous-sol.org (8.14.3/8.14.3) with ESMTP id q33JaDDV007473; Tue, 3 Apr 2012 12:36:13 -0700 Received: (from chrisw@localhost) by sequoia.sous-sol.org (8.14.3/8.14.3/Submit) id q33JaCS4007471; Tue, 3 Apr 2012 12:36:12 -0700 Date: Tue, 3 Apr 2012 12:36:12 -0700 From: Chris Wright To: Kireeti Kompella Subject: Re: [nvo3] Response to some comments on IS-IS VPLS Message-ID: <20120403193612.GL19952@sequoia.sous-sol.org> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0CAE@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0E23@szxeml525-mbs.china.huawei.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80849@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80AAC@MX14A.corp.emc.com> <20120403181525.GJ19952@sequoia.sous-sol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-08-17) X-Virus-Scanned: clamav-milter 0.95.3 at sequoia.sous-sol.org X-Virus-Status: Clean X-Mailman-Approved-At: Tue, 03 Apr 2012 23:15:05 -0700 Cc: Chris Wright , "kireeti@juniper.net" , "david.black@emc.com" , "nvo3@ietf.org" , "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 04 Apr 2012 00:27:27 -0000 * Kireeti Kompella (kireeti.kompella@gmail.com) wrote: > On Apr 3, 2012, at 11:15, Chris Wright wrote: > > > * Kireeti Kompella (kireeti.kompella@gmail.com) wrote: > > >> There are two ways to interpret "non-carrier DC": > >> a) enterprises that have a DC but want to move to the clouds (i.e., > >> customers); > > > > I think you missed a large portion of the enterprise DC world. > > Enterprises that have a DC and are beginning to run their DC internally > > as a cloud, aka the private cloud. > > Good point. > > Which brings me back to the charter: is NVO3 aimed at _large_ virtualized DCs, or _any_ vDCs? > > To Chris's point, if an enterprise builds/converts their DC into a private cloud of a thousand or two VMs, would that be in scope for NVO3? Personally, I expect it would be in scope. > I'm not looking for a threshold, rather whether scale is (should be) part of the charter? Something like sizing of a virtual network ID is tough to discuss w/out some concrete notion of expected scale on the upper end. On the lower end, it may be the flexibility of an overlay that is more important than scaling. So I think scale is at least relevant. thanks, -chris From chrisw@sous-sol.org Tue Apr 3 17:27:28 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A692221F865D; Tue, 3 Apr 2012 17:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 JmoKzLCHtEsa; Tue, 3 Apr 2012 17:27:28 -0700 (PDT) Received: from mail.sous-sol.org (sous-sol.org [216.99.217.87]) by ietfa.amsl.com (Postfix) with ESMTP id 2C59021F8658; Tue, 3 Apr 2012 17:27:28 -0700 (PDT) Received: from sequoia.sous-sol.org (sequoia.sous-sol.org [127.0.0.1]) by sequoia.sous-sol.org (8.14.3/8.14.3) with ESMTP id q33IFQRS007005; Tue, 3 Apr 2012 11:15:26 -0700 Received: (from chrisw@localhost) by sequoia.sous-sol.org (8.14.3/8.14.3/Submit) id q33IFPqP007004; Tue, 3 Apr 2012 11:15:25 -0700 Date: Tue, 3 Apr 2012 11:15:25 -0700 From: Chris Wright To: Kireeti Kompella Subject: Re: [nvo3] Response to some comments on IS-IS VPLS Message-ID: <20120403181525.GJ19952@sequoia.sous-sol.org> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0CAE@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0E23@szxeml525-mbs.china.huawei.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80849@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80AAC@MX14A.corp.emc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-08-17) X-Virus-Scanned: clamav-milter 0.95.3 at sequoia.sous-sol.org X-Virus-Status: Clean X-Mailman-Approved-At: Tue, 03 Apr 2012 23:15:05 -0700 Cc: kireeti@juniper.net, l2vpn@ietf.org, david.black@emc.com, nvo3@ietf.org X-BeenThere: l2vpn@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, 04 Apr 2012 00:27:28 -0000 * Kireeti Kompella (kireeti.kompella@gmail.com) wrote: > Hi David, > > On Mon, Apr 2, 2012 at 12:34 PM, wrote: > > > Hi Kireeti, > > > > We're in agreement, and thank you for your comments at the BOF. Here are > > a few elaborations: > > > It's great that (we think) we're in agreement, but just in case ... > > > > > > OTOH, for a non-carrier data center (e.g., enterprise), not only is > > the above statement rather > > > incorrect, but the enterprise network may not be running BGP. > > > > > > Step back a bit. The non-carrier DC is not being asked to run BGP. > > > > There are two ways to interpret "non-carrier DC": > a) enterprises that have a DC but want to move to the clouds (i.e., > customers); I think you missed a large portion of the enterprise DC world. Enterprises that have a DC and are beginning to run their DC internally as a cloud, aka the private cloud. thanks, -chris From robert@raszuk.net Wed Apr 4 02:33:57 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573F321F873A for ; Wed, 4 Apr 2012 02:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, SARE_SXLIFE=1.07] 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 8EC4kGYnwCuK for ; Wed, 4 Apr 2012 02:33:56 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 9878521F8739 for ; Wed, 4 Apr 2012 02:33:56 -0700 (PDT) Received: (qmail 26050 invoked by uid 399); 4 Apr 2012 09:33:55 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.9.208.199) by mail1310.opentransfer.com with ESMTPM; 4 Apr 2012 09:33:55 -0000 X-Originating-IP: 83.9.208.199 Message-ID: <4F7C1583.3060501@raszuk.net> Date: Wed, 04 Apr 2012 11:33:55 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: sajassi Subject: Re: Response to some comments on IS-IS VPLS References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 09:33:57 -0000 Hi Ali, > BTW, in case of SPDC, if the connectivity among DCs needs to span across > different ASes, how do you plan to accommodate that? There are many choices for such interconnect today. Both regarding interconnect between your own ASes as well as between your partners/customers own DCs. The interconnect signalling can be realized on multiple levels: application level (network just provides IP connectivity), service level (APIs between your orchestration tools), network level (VPN like service with well defined NNI). I see you and Kireeti for obvious reasons are pushing for BGP based network level interconnect standard. I think interconnect standard at application level or service level could be much more attractive from NVO3 pov. Network could be left alone assuming IP connectivity is there any to any (including native multicast if needed :). As I said I have nothing against BGP in itself - it is very simple protocol and very easy to operate. The showstopper agianst BGP is that my hosts do not run it even if I would introduce hierarchy of RRs to deal with session scaling. If those with BGP implementations commit to open source it and submit to all major linux distributions we could perhaps start conversation about BGP. XMPP is an alternative too as proposed by Pedro. Best, R. From narten@us.ibm.com Wed Apr 4 14:12:15 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6ACA11E8110 for ; Wed, 4 Apr 2012 14:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 4vN4hcvRBDrC for ; Wed, 4 Apr 2012 14:12:15 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id 1579A11E810B for ; Wed, 4 Apr 2012 14:12:14 -0700 (PDT) Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 4 Apr 2012 15:12:14 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 4 Apr 2012 15:12:11 -0600 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id B4D503E40036; Wed, 4 Apr 2012 15:12:10 -0600 (MDT) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q34LBpre165932; Wed, 4 Apr 2012 15:11:52 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q34LBml1004691; Wed, 4 Apr 2012 15:11:50 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-76-147-140.mts.ibm.com [9.76.147.140]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q34LBjCr004541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2012 15:11:47 -0600 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q34LBdrj022253; Wed, 4 Apr 2012 17:11:40 -0400 Message-Id: <201204042111.q34LBdrj022253@cichlid.raleigh.ibm.com> To: Kireeti Kompella Subject: Re: [nvo3] Response to some comments on IS-IS VPLS In-reply-to: <7E61C263-A4B8-4A3D-8293-147ACDC1CDB7@gmail.com> References: <7E61C263-A4B8-4A3D-8293-147ACDC1CDB7@gmail.com> Comments: In-reply-to Kireeti Kompella message dated "Tue, 03 Apr 2012 15:33:51 -0700." Date: Wed, 04 Apr 2012 17:11:39 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12040421-3270-0000-0000-0000055481AB Cc: "l2vpn@ietf.org" , "kireeti@juniper.net" , David Black , "nvo3@ietf.org" , Chris Wright X-BeenThere: l2vpn@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, 04 Apr 2012 21:12:16 -0000 Hi Kireeti. > On Apr 3, 2012, at 14:50, Larry Kreeger wrote: > > IMO, the goal of the WG should be to address the needs of small/medium > > enterprise private clouds all the way up to large cloud service providers. > The question is, is there really a problem to solve in the > small/medium private cloud space? There is an existence proof that > existing methodologies (layer 2) work adequately here. So, a > rationale for including these cases would be helpful. What do you define as "small/medium"? I agree that where existing L2 VLANs do the job, NVO3 won't be very attractive. But exactly where it is perceived that L2 no longer suffices, that will vary and different folk will have different ideas. E.g., TRILL/SPB could expand the definition of how big you can use L2 techniques. But not everyone may want to go that route. In an earlier version of the charter, we tried to describe two cases that were "small" and "large". The first case would be where "learning" was adequate for building mapping tables and the second case was where some sort of backend "oracle" or "directory-based system" supplied the mappings. So I think there is room for two "sizes" of deployments, *both* of which are interested in an NVO3 approach. Thomas From xuxiaohu@huawei.com Wed Apr 4 20:28:49 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E67421F858A for ; Wed, 4 Apr 2012 20:28:49 -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 1JHA8JP8URt0 for ; Wed, 4 Apr 2012 20:28:48 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2B721F8587 for ; Wed, 4 Apr 2012 20:28:48 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AER10516; Wed, 04 Apr 2012 23:28:48 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Apr 2012 20:20:37 -0700 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Apr 2012 20:20:42 -0700 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.158]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Thu, 5 Apr 2012 11:20:36 +0800 From: Xuxiaohu To: sajassi , "robert@raszuk.net" , John E Drake Subject: re: Response to some comments on IS-IS VPLS Thread-Topic: Response to some comments on IS-IS VPLS Thread-Index: AQHNDauno12B0RP+lEO1DyVa7X7/s5aBlXMQgAAXd5D//5jvgIAAuvyAgACIz5mABLG/AIAEXVAw Date: Thu, 5 Apr 2012 03:20:35 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE1C9E@szxeml525-mbs.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0DDF@szxeml525-mbs.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-cr-hashedpuzzle: DOW0 Dn3w ElP2 OF9g SB1J VVT+ V2rY WLbq Wvjf e+aQ g0lP g3rq nNt6 /Ve7 AAKxqQ== AAQNvA==; 5; agBkAHIAYQBrAGUAQABqAHUAbgBpAHAAZQByAC4AbgBlAHQAOwBqAHUAMQA3ADMAOABAAGEAdAB0AC4AYwBvAG0AOwBsADIAdgBwAG4AQABpAGUAdABmAC4AbwByAGcAOwByAG8AYgBlAHIAdABAAHIAYQBzAHoAdQBrAC4AbgBlAHQAOwBzAGEAagBhAHMAcwBpAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Sosha1_v1; 7; {63C54365-37C0-4574-AFA9-FFCA7D1CE775}; eAB1AHgAaQBhAG8AaAB1AEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Thu, 05 Apr 2012 03:20:48 GMT; cgBlADoAIABSAGUAcwBwAG8AbgBzAGUAIAB0AG8AIABzAG8AbQBlACAAYwBvAG0AbQBlAG4AdABzACAAbwBuACAASQBTAC0ASQBTACAAVgBQAEwAUwA= x-cr-puzzleid: {63C54365-37C0-4574-AFA9-FFCA7D1CE775} x-originating-ip: [10.108.4.99] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , "UTTARO, JAMES" X-BeenThere: l2vpn@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, 05 Apr 2012 03:28:49 -0000 DQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBzYWphc3NpIFttYWlsdG86 c2FqYXNzaUBjaXNjby5jb21dDQo+IOWPkemAgeaXtumXtDogMjAxMuW5tDTmnIgz5pelIDA6MzQN Cj4g5pS25Lu25Lq6OiBYdXhpYW9odTsgcm9iZXJ0QHJhc3p1ay5uZXQ7IEpvaG4gRSBEcmFrZQ0K PiDmioTpgIE6IGwydnBuQGlldGYub3JnOyBVVFRBUk8sIEpBTUVTDQo+IOS4u+mimDogUmU6IFJl c3BvbnNlIHRvIHNvbWUgY29tbWVudHMgb24gSVMtSVMgVlBMUw0KPiANCj4gSGkgWHV4aWFvaHUs DQo+IA0KPiBUaGUgZHJhZnQgdGhhdCBJIHdyb3RlIHRlbiB5ZWFycyBhZ28gKE1WUExTKSBpcyBh bmFsb2dvdXMgdG8gVlhMQU4gLSBib3RoIGRvDQo+IHRoZSBzYW1lIHRoaW5nIGJ1dCB3aXRoIGRp ZmZlcmVudCBJUCBlbmNhcC4gTVZQTFMgdXNlZCBMMlRQdjMgZW5jYXAgKHNpbmNlDQo+IGl0IHdh cyB0aGUgZW5jYXAtZGVqb3VyIG9mIHRoYXQgdGltZSBmb3IgSVAgOi0pOyB3aGVyZWFzLCBWWExB TiB1c2VzIFVEUA0KPiBlbmNhcC4NCj4gDQo+IFNpbmNlIHRoZXJlIGFyZSBhbHJlYWR5IHRocmVl IGRpZmZlcmVudCBlbmNhcCBwcm9wb3NhbHMgaW4gTlZvMyAoVURQLCBHUkUsDQo+IGFuZCBUQ1Ap LCBJIGFtIE5PVCBwbGFubmluZyB0byBpbnRyb2R1Y2UgeWV0IGFub3RoZXIgZW5jYXAgYnkgcmVz dXJyZWN0aW5nDQo+IG15IGRyYWZ0LiBJIHRoaW5rIHdlIHNob3VsZCBvbmx5IHBpY2sgYSBzaW5n bGUgZW5jYXAgYW1vbmcgdGhlIHRocmVlIGN1cnJlbnQNCj4gcHJvcG9zYWxzIGluIE5WTzMuDQoN CkhpIEFsaSwNCg0KRG9lcyB0aGF0IG1lYW4geW91IGFsc28gYmVsaWV2ZSBhIHNpbXBsaWZpZWQg TDJWUE4gYXBwcm9hY2ggb3RoZXIgdGhhbiBFVlBOIGlzIG5lZWRlZCBmb3IgZGF0YSBjZW50ZXIg bmV0d29ya3M/IE90aGVyd2lzZSB3aHkgZG8geW91IHN1Z2dlc3QgcGlja2luZyBvbmUgcmF0aGVy IHRoYW4gZHJvcHBpbmcgdGhlbSBhbGw/DQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IA0K PiBDaGVlcnMsDQo+IEFsaQ0KPiANCj4gDQo+IE9uIDMvMzAvMTIgMTo1NSBBTSwgIlh1eGlhb2h1 IiA8eHV4aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+IA0KPiA+IEhpIEFsaSwNCj4gPg0KPiA+ IFdoYXQncyB5b3VyIGF0dGl0dWRlIHRvIHlvdXIgb3duIGRyYWZ0IGFzIG1lbnRpb25lZCBiZWxv dyBmcm9tIHRvZGF5J3MNCj4gcG9pbnQNCj4gPiBvZiB2aWV3PyBnb29kIG9yIGJhZD8NCj4gPg0K PiA+IEJlc3QgcmVnYXJkcywNCj4gPiBYaWFvaHUNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiDlj5Hku7bkuro6IGwydnBuLWJvdW5jZXNAaWV0 Zi5vcmcgW2wydnBuLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBzYWphc3NpDQo+ID4gW3NhamFz c2lAY2lzY28uY29tXQ0KPiA+IOWPkemAgeaXtumXtDogMjAxMuW5tDPmnIgzMOaXpSAxNjo0Mw0K PiA+IOWIsDogcm9iZXJ0QHJhc3p1ay5uZXQ7IEpvaG4gRSBEcmFrZQ0KPiA+IENjOiBsMnZwbkBp ZXRmLm9yZzsgVVRUQVJPLCBKQU1FUw0KPiA+IOS4u+mimDogUmU6IFJlc3BvbnNlIHRvIHNvbWUg Y29tbWVudHMgb24gSVMtSVMgVlBMUw0KPiA+DQo+ID4gSGkgUm9iZXJ0LA0KPiA+DQo+ID4gSSB3 b24ndCBnZXQgaW50byB0aGUgYXJndW1lbnQgb2Ygd2hldGhlciB0aGlzIGtpbmQgb2Ygc29sdXRp b24gaXMgaW5ub3ZhdGlvbg0KPiA+IG9yIHBlcm11dGF0aW9uLiBNeSBwb2ludCBpcyB0aGF0IGl0 IGlzIGNsZWFybHkgb3V0c2lkZSBvZiBjdXJyZW50IEwyVlBODQo+ID4gY2hhcnRlciBhbmQgaWYg dGhpcyBraW5kIG9mIHNvbHV0aW9uIGlzIHRvIGJlIHB1cnN1ZWQgaW4gTDJWUE4gV0csIHRoZW4g aXQNCj4gPiBuZWVkcyB0byBiZSByZS1jaGFydGVyZWQuDQo+ID4NCj4gPiBBbHNvLCBpZiB3ZSBh cmUgdGFsa2luZyBhYm91dCBWUExTIHNlcnZpY2Ugb3ZlciBJUCBhbmQgZG9pbmcgTUFDIGxlYXJu aW5nDQo+ID4gYWdhaW5zdCBJUCBhZGRyZXNzZXMgKGFzIHdoYXQgdGhpcyBkcmFmdCBpcyB0YWxr aW5nIGFib3V0KSwgSSBoYWQgYSBkcmFmdCAxMA0KPiA+IHllYXJzIGFnbyB0aGF0IGNvdmVyIHRo aXMgc3ViamVjdCAhIQ0KPiA+DQo+ID4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXNh amFzc2ktbXZwbHMtMDAudHh0DQo+ID4NCj4gPiBDaGVlcnMsDQo+ID4gQWxpDQo+ID4NCj4gPg0K PiA+IE9uIDMvMjkvMTIgMjozMyBQTSwgIlJvYmVydCBSYXN6dWsiIDxyb2JlcnRAcmFzenVrLm5l dD4gd3JvdGU6DQo+ID4NCj4gPj4gSGkgSm9obiwNCj4gPj4NCj4gPj4gSSB0aGluayB5b3UgdG9v ayBpdCBhIGxpdHRsZSBiaXQgdG9vIGZhci4NCj4gPj4NCj4gPj4gSSBoYXZlIG5vdCBoZWFyZCBh bnlvbmUgc3RhdGluZyB0aGF0IGN1cnJlbnQgVlBMUyBzb2x1dGlvbnMgc3Vjay4gSSBhbHNvDQo+ ID4+IGRpZCBub3QgaGVhciBhbnlvbmUgY2xhaW1pbmcgdGhhdCBCR1AgaXMgZGlmZmljdWx0LiBU aGUgY2xhaW0gSSBoYXZlDQo+ID4+IGhlYXJkIGlzIHRoYXQgaW4gc29tZSBlbnZpcm9ubWVudHMg b25lIG1heSBub3QgbGlrZSB0byB1c2UgQkdQIGZvciBWUExTLg0KPiA+Pg0KPiA+PiBBbGkncyBw b2ludCBpcyB0aGF0IGN1cnJlbnQgUEVzIHdpbGwgaGF2ZSBwcm9ibGVtIHN1cHBvcnRpbmcgaXQg YXMgdGhpcw0KPiA+PiBpcyBlZmZlY3RpdmVseSBUUklMTCBvdmVyIElQIGlzIHZhbGlkIGZyb20g QWxpJ3MgcG9pbnQgb2Ygdmlldy4NCj4gPj4NCj4gPj4gSG93ZXZlciBvbmUgY291bGQgYXNrIGEg cXVlc3Rpb24gaWYgSUVURiBpcyBzdGlsbCBhbiBvcmdhbml6YXRpb24gdG8NCj4gPj4gcHJvbW90 ZSBvcGVuIGlubm92YXRpb24gYW5kIGNvbnNpZGVyIG5ldyBpZGVhcyAoZXZlbiBpZiBvbmx5IGlu DQo+ID4+IGV4cGVyaW1lbnRhbCBtb2RlKSBvciBpcyBpdCBqdXN0IGEgZm9ydW0gdG8gbG9jayBj dXN0b21lcnMgdG8gbGltaXRlZA0KPiA+PiBzZXQgb2Ygc29sdXRpb25zID8gSWYgaXQgaXMgdGhl IGxhdHRlciB0aGUgdHJlbmQgdG8gc2VlayBhbHRlcm5hdGl2ZXMgdG8NCj4gPj4gSUVURiBzdGFu ZGFyZGl6YXRpb24gcHJvY2VzcyB3aWxsIGNvbnRpbnVlIHRvIGV2b2x2ZS4gRXNwZWNpYWxseSBu b3cNCj4gPj4gd2hlbiBjb250cm9sIHBsYW5lIHNlcGFyYXRpb24gZnJvbSBkYXRhIHBsYW5lIGJl Y29tZXMgcmVhbGl0eS4NCj4gPj4NCj4gPj4gSSBzZWUgbm90aGluZyB3cm9uZyB0byBhbGxvY2F0 ZSBwZXJoYXBzIGluIGV4cGVyaW1lbnRhbCBtb2RlIFZQTFMgSW5mbw0KPiA+PiBUTFYgY29kZXBv aW50IGZvciBWUExTIG92ZXIgSVNJUyBvciBmb3IgdGhhdCBtYXR0ZXIgd2VsbCBrbm93bg0KPiA+ PiBkZXN0aW5hdGlvbiBwb3J0IGZvciBTVFQgZnJvbSBJQU5BIGFuZCBsZXQgY29tcGFuaWVzIHdo byBhcmUgYXNraW5nIGZvcg0KPiA+PiBpdCBkZXZlbG9wIHRoZSBzb2x1dGlvbnMsIGRlcGxveSBp dCB0aGVuIHJlcG9ydCBiYWNrIHRoZSByZXN1bHRzIHRvIHRoZQ0KPiA+PiBjb21tdW5pdHkuDQo+ ID4+DQo+ID4+IEJlc3QsDQo+ID4+IFIuDQo+ID4+DQo+ID4+DQo+ID4+PiBKaW0sDQo+ID4+Pg0K PiA+Pj4gWW91IGFyZSBjb21wbGV0ZWx5IGNvcnJlY3QgLCBidXQgbGV0wrlzIG5vdCBvdmVybG9v ayB0aGUgZnVuIGZhY3Rvci4NCj4gPj4+IEkuZS4sIGl0wrlzICoqZnVuKiogdG8gc2F5IHRoYXQg ZXZlcnl0aGluZyB0aGF0IGhhcyBnb25lIGJlZm9yZSBzdWNrcyBhbmQNCj4gPj4+IHRoYXQgdGhl IGN1cnJlbnQgaW5pdGlhdGl2ZSB3aWxsIGJlIMKzcHJhY3RpY2FsbHkgcGVyZmVjdMKyIChjLmYu IMWSTWFyeQ0KPiA+Pj4gUG9wcGluc8K5KS4NCj4gPj4+DQo+ID4+PiBUaGFua3MsDQo+ID4+Pg0K PiA+Pj4gSm9obg0KPiA+Pj4NCj4gPj4+IFNlbnQgZnJvbSBteSBpUGhvbmUNCj4gPj4+DQo+ID4+ PiAqRnJvbToqbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0 Zi5vcmddICpPbg0KPiBCZWhhbGYNCj4gPj4+IE9mICpVVFRBUk8sIEpBTUVTDQo+ID4+PiAqU2Vu dDoqIFRodXJzZGF5LCBNYXJjaCAyOSwgMjAxMiAxMTozMCBBTQ0KPiA+Pj4gKlRvOiogJ1h1eGlh b2h1JzsgbDJ2cG5AaWV0Zi5vcmcNCj4gPj4+ICpTdWJqZWN0OiogUkU6IFJlc3BvbnNlIHRvIHNv bWUgY29tbWVudHMgb24gSVMtSVMgVlBMUw0KPiA+Pj4NCj4gPj4+IElNSE/FoCBJIGFtIGF0IGEg Yml0IG9mIGEgbG9zcyBhcyB0byB0aGUgbm90aW9uIHRoYXQgQkdQIGlzIHNvDQo+ID4+PiBvdmVy d2hlbG1pbmdseSBkaWZmaWN1bHQgdG8gZGVhbCB3aXRoIGluIGEgZGF0YSBjZW50ZXIgZW52aXJv bm1lbnQuLiBXaHkNCj4gPj4+IGlzIHRoYXQ/PyBCR1AgaXMgYmVpbmcgdXNlZCBhY3Jvc3MgYSB3 aWRlIHNwZWN0cnVtIG9mIGFwcGxpY2F0aW9ucyBhbmQNCj4gPj4+IGlzIHByb3Zlbi4gSSBiZWxp ZXZlIHRoYXQgdGhlIGRhdGEgY2VudGVyIGlzIGJlY29taW5nIG1vcmUgYW5kIG1vcmUgYQ0KPiA+ Pj4gZHluYW1pYyBleHRlbnNpb24gb2YgYSBjdXN0b21lcsK5cyBuZXR3b3JrLiBJIGFsc28gdGhp bmsgaXQgd291bGQgYmUgd2lzZQ0KPiA+Pj4gdG8gYW50aWNpcGF0ZSB0aGUgd29ybGQgb2YgdG9t b3Jyb3cgd2hlcmUgY3VzdG9tZXJzIG1heSBleHBlY3QgdGhlaXINCj4gPj4+IG5ldHdvcmsgbWF5 IHNwYW4gbXVsdGlwbGUgb3BlcmF0b3JzIERDcy4gVGhlIHJpZ2h0IGFwcHJvYWNoIGlzIHRvDQo+ ID4+PiBsZXZlcmFnZSB3aGF0IGhhcyBiZWVuIGRvbmUgQkdQIGFuZCBleHRlbmQgaXQgd2hlcmUg bmVlZGVkLi4gVGhpcw0KPiA+Pj4gcHJvdmlkZXMgbWF4aW11bSBmbGV4aWJpbGl0eSBhbmQgc2lt cGxpY2l0eS4uDQo+ID4+Pg0KPiA+Pj4gVG8gYnVpbGQgc29sdXRpb25zIGJhc2VkIG9uIHRoZSBu b3Rpb24gdGhhdCDCs0kgZG9uwrl0IGxpa2UgcHJvdG9jb2wgWMKyIGlzDQo+ID4+PiBpbnZhbGlk Li4NCj4gPj4+DQo+ID4+PiBKaW0gVXR0YXJvDQo+ID4+Pg0KPiA+Pj4gKkZyb206KmwydnBuLWJv dW5jZXNAaWV0Zi5vcmcgPG1haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnPg0KPiA+Pj4gW21h aWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpYdXhpYW9odQ0KPiA+ Pj4gKlNlbnQ6KiBUaHVyc2RheSwgTWFyY2ggMjksIDIwMTIgMjo1OSBQTQ0KPiA+Pj4gKlRvOiog bDJ2cG5AaWV0Zi5vcmcgPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4NCj4gPj4+ICpTdWJqZWN0Oiog UmVzcG9uc2UgdG8gc29tZSBjb21tZW50cyBvbiBJUy1JUyBWUExTDQo+ID4+Pg0KPiA+Pj4gSGkg YWxsLA0KPiA+Pj4NCj4gPj4+IFZQTFMgKFZpcnR1YWwgUHJpdmF0ZSBMQU4gU2VydmljZSkgaGFz IGRpZmZlcmVudCB1bmRlcnN0YW5kaW5ncyBmb3INCj4gPj4+IGRpZmZlcmVudCBwZW9wbGUsIHNv bWUgcGVvcGxlIHRoaW5rIGl0IGFzIGEgc2VydmljZSB3aGlsZSBvdGhlcnMgdGhpbmsNCj4gPj4+ IGl0IGFzIGEgY29uY3JldGUgdGVjaG5vbG9neSwgZXNwZWNpYWxseSB1c2luZyBQV3MuIEhlcmUs IHRoZSAiVlBMUyIgaXMNCj4gPj4+IGRlZW1lZCBhcyBhIFZQTFMgc2VydmljZS4gSWYgdGhlIFdH IGNvbnNlbnN1cyBpcyB0aGF0ICJWUExTIiBzaG91bGQgYmUNCj4gPj4+IHRha2VuIGFzIGEgY29u Y3JldGUgdGVjaG5vbG9neSwgSSBoYXZlIG5vIG9iamVjdGlvbiB0byB1c2luZyBhbm90aGVyIHRl cm0uDQo+ID4+Pg0KPiA+Pj4gQXMgc2FpZCBpbiB0aGUgSVMtSVMgVlBMUyBkcmFmdCwgSVMtSVMg VlBMUyBpcyBpbnRlbmRlZCB0byBiZSBhDQo+ID4+PiBsaWdodC13ZWlnaHQgVlBMUyBzb2x1dGlv biB3aGljaCBjYW4gbWVldCBzb21lIERDIG9wZXJhdG9ycycNCj4gPj4+IHJlcXVpcmVtZW50cyBm b3Igc2ltcGxpY2l0eS4gSSBkb24ndCB3YW50IHRvIGFyZ3VlIGluIHRoaXMgbWFpbGluZy1saXN0 DQo+ID4+PiB3aGV0aGVyIEJHUC1iYXNlZCBMMlZQTiBzb2x1dGlvbnMgY291bGQgbWVldCB3ZWxs IHRoZSByZXF1aXJlbWVudHMNCj4gZnJvbQ0KPiA+Pj4gYWxsIERDIG9wZXJhdG9ycy4gSSBwZXJz b25hbGx5IGJlbGlldmUgdGhhdCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gYXNrDQo+ID4+PiB0aGlz IHF1ZXN0aW9uIHRvIE5WbzMuIEluIGFkZGl0aW9uLCBhY2NvcmRpbmcgdG8gdG9kYXkncyBwcmVz ZW50YXRpb24gb2YNCj4gPj4+IEUtVlBOLCBJIHRoaW5rIEUtVlBOIGNvLWF1dGhvcnMgYWxzbyBh ZG1pdCB0aGF0IHRoZSBleGl0aW5nIEVWUE4NCj4gPj4+IHNvbHV0aW9uIHNlZW1zIGNvbXBsZXgg dG8gc29tZSBEQyBvcGVyYXRvcnMuIElmIG15IHVuZGVyc3RhbmRpbmcgaXMNCj4gPj4+IHdyb25n LCBwbHMgY29ycmVjdCBtZS4NCj4gPj4+DQo+ID4+PiBJZiBJIHJlbWVtYmVyZWQgY29ycmVjdGx5 LCBMMVZQTiBhbHNvIGhhcyB0d28gUkZDcyB1c2luZyBJUy1JUyBhbmQgT1NQRg0KPiA+Pj4gZm9y IEwxVlBOIGF1dG8tZGlzY292ZXJ5LCBhbHRob3VnaCB0aGVyZSBoYXMgYmVlbiBvbmUgc29sdXRp b24gdXNpbmcNCj4gPj4+IEJHUC4gSGVuY2UgSSBkb24ndCBrbm93IHdoeSBjYW4ndCB3ZSBoYXZl IGEgbGlnaHQtd2VpZ2h0IEwyVlBOIHVzaW5nDQo+IElTLUlTLg0KPiA+Pj4NCj4gPj4+IEJlc3Qg cmVnYXJkcywNCj4gPj4+DQo+ID4+PiBYaWFvaHUNCj4gPj4+DQo+ID4+DQoNCg== From xuxiaohu@huawei.com Wed Apr 4 21:09:25 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2929811E8074; Wed, 4 Apr 2012 21:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.103 X-Spam-Level: X-Spam-Status: No, score=0.103 tagged_above=-999 required=5 tests=[AWL=-2.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 8JXwHvoVlOkZ; Wed, 4 Apr 2012 21:09:24 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2348E21F85AE; Wed, 4 Apr 2012 21:09:24 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEZ10557; Thu, 05 Apr 2012 00:09:23 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Apr 2012 21:03:42 -0700 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Apr 2012 21:03:46 -0700 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.158]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Thu, 5 Apr 2012 12:03:43 +0800 From: Xuxiaohu To: Kireeti Kompella , "david.black@emc.com" Subject: re: [nvo3] Response to some comments on IS-IS VPLS Thread-Topic: [nvo3] Response to some comments on IS-IS VPLS Thread-Index: AQHNDauno12B0RP+lEO1DyVa7X7/s5aBlXMQgAAXd5D//5jvgIABHOVpgAApX6KAAAtTuIAEwdXAgAAKYICAAAoVAIAAWPgAgAPfFYA= Date: Thu, 5 Apr 2012 04:03:43 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE1CB2@szxeml525-mbs.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0CAE@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE0E23@szxeml525-mbs.china.huawei.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80849@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E80AAC@MX14A.corp.emc.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.108.4.99] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE1CB2szxeml525mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "kireeti@juniper.net" , "l2vpn@ietf.org" , "nvo3@ietf.org" X-BeenThere: l2vpn@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, 05 Apr 2012 04:09:25 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE1CB2szxeml525mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgS2lyZWV0aSwNCg0Kt6K8/sjLOiBudm8zLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpudm8z LWJvdW5jZXNAaWV0Zi5vcmddILT6se0gS2lyZWV0aSBLb21wZWxsYQ0Kt6LLzcqxvOQ6IDIwMTLE 6jTUwjPI1SA4OjUzDQrK1bz+yMs6IGRhdmlkLmJsYWNrQGVtYy5jb20NCrOty806IGtpcmVldGlA anVuaXBlci5uZXQ7IGwydnBuQGlldGYub3JnOyBudm8zQGlldGYub3JnDQrW98ziOiBSZTogW252 bzNdIFJlc3BvbnNlIHRvIHNvbWUgY29tbWVudHMgb24gSVMtSVMgVlBMUw0KDQpIaSBEYXZpZCwN Ck9uIE1vbiwgQXByIDIsIDIwMTIgYXQgMTI6MzQgUE0sIDxkYXZpZC5ibGFja0BlbWMuY29tPG1h aWx0bzpkYXZpZC5ibGFja0BlbWMuY29tPj4gd3JvdGU6DQpIaSBLaXJlZXRpLA0KDQpXZSdyZSBp biBhZ3JlZW1lbnQsIGFuZCB0aGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMgYXQgdGhlIEJPRi4g IEhlcmUgYXJlIGEgZmV3IGVsYWJvcmF0aW9uczoNCg0KSXQncyBncmVhdCB0aGF0ICh3ZSB0aGlu aykgd2UncmUgaW4gYWdyZWVtZW50LCBidXQganVzdCBpbiBjYXNlIC4uLg0KDQo+ID4gT1RPSCwg Zm9yIGEgbm9uLWNhcnJpZXIgZGF0YSBjZW50ZXIgKGUuZy4sIGVudGVycHJpc2UpLCBub3Qgb25s eSBpcyB0aGUgYWJvdmUgc3RhdGVtZW50IHJhdGhlcg0KPiBpbmNvcnJlY3QsIGJ1dCB0aGUgZW50 ZXJwcmlzZSBuZXR3b3JrIG1heSBub3QgYmUgcnVubmluZyBCR1AuDQo+DQo+IFN0ZXAgYmFjayBh IGJpdC4gVGhlIG5vbi1jYXJyaWVyIERDIGlzIG5vdCBiZWluZyBhc2tlZCB0byBydW4gQkdQLg0K DQpUaGVyZSBhcmUgdHdvIHdheXMgdG8gaW50ZXJwcmV0ICJub24tY2FycmllciBEQyI6DQphKSBl bnRlcnByaXNlcyB0aGF0IGhhdmUgYSBEQyBidXQgd2FudCB0byBtb3ZlIHRvIHRoZSBjbG91ZHMg KGkuZS4sIGN1c3RvbWVycyk7DQpiKSBub24tY2FycmllcnMgdGhhdCAqYnVpbGQqIGNsb3VkcyAo ZS5nLiwgRUMyKS4NCg0KSXQgaXMgYSBub24tc3RhcnRlciB0byBhc2sgdGhvc2UgaW4gKGEpIHRv IHJ1biBCR1AgKG9yIHRvIGNoYW5nZSBhbnkgb2YgdGhlaXIgcHJhY3RpY2VzIGluIGFueSBzaWdu aWZpY2FudCB3YXkpLg0KDQpJdCBpcyBhIGRlZmluaXRlIHBvc3NpYmlsaXR5IHRvIGFzayB0aGUg bm9uLWNhcnJpZXIgY2xvdWQgcHJvdmlkZXIgdG8gYWRvcHQgQkdQIGFzIHRoZSBzY2FsaW5nIG1l Y2hhbmlzbS4NCg0KKG9oLCBvaCAtLSB0aGUgZW5kIG9mIGEgYmVhdXRpZnVsIGZyaWVuZHNoaXAs IGp1c3QgYXMgaXQgd2FzIGdldHRpbmcgZ29pbmcgLi4uIDotKSkNCg0KQkdQIGlzIGEgd2VsbC10 ZXN0ZWQgcHJvdG9jb2wgZm9yIHNjYWxpbmcuICBZZXMsIHRoZXJlIGFyZSBjb21wbGV4aXRpZXMs IHNvbWUgcmVhbCwgc29tZSBwZXJjZWl2ZWQuICBUaGUgcXVlc3Rpb24gaXMsIGlzIGl0IGVhc2ll ciB0byBzaW1wbGlmeSBCR1AgKGFsb25nIHRoZSBsaW5lcyB0aGF0IEFsaWEgc2FpZCksIG9yIGJy ZWFrIGxvb3NlIGFuZCBzdGFydCBhZ2Fpbj8NCg0KW1hJQU9IVV0gVGhlIHF1ZXN0aW9uIGlzIGhh cmQgdG8gYW5zd2VyIHNpbmNlIGRpZmZlcmVudCBwZW9wbGUgbWF5IGhhdmUgZGlmZmVyZW50IGFu c3dlcnMuIFRoYXShr3Mgd2h5IElTLUlTIGFuZCBPU1BGIGJhc2VkIEwxVlBOIGFwcHJvYWNoZXMg d2VyZSBwcm9wb3NlZCBhbmQgYWNjZXB0ZWQgZXZlbiB3aGVuIEJHUC1iYXNlZCBMMVZQTiBhcHBy b2FjaCBoYXMgYWxyZWFkeSBiZWVuIHRoZXJlIGJlZm9yZS4NCg0KQmVzdCByZWdhcmRzLA0KWGlh b2h1DQoNClRoZSBhbnN3ZXIgZm9yIFNQLWNsb3VkIHByb3ZpZGVycyBzZWVtcyBjbGVhci4gIFRo ZSBhbnN3ZXIgZm9yIG5vbi1jYXJyaWVyIGNsb3VkIHByb3ZpZGVycyBpcyBvcGVuLiAgSSdtIGdv aW5nIHRvIHJldmlzaXQgdGhpcyB0aHJlYWQgYW5kIHNlZSBob3cgbWFueSBub24tY2FycmllciBj bG91ZCBwcm92aWRlcnMgYWN0dWFsbHkgc3Bva2UgdXAuDQoNClN1cmUgLSB5b3UgYW5kIEkgYWdy ZWUgb24gdGhpcywgYnV0IEppbSB3YW50cyB0byBwdXNoIEJHUCBpbnRvIG5vbi1jYXJyaWVyIGRh dGEgY2VudGVycyAuLi4NCnBlcmhhcHMgeW91IGNhbiBoZWxwIGNvbnZpbmNlIGhpbSBvdGhlcndp c2UgLi4uDQoNCkkgY291bGQgdHJ5LCBidXQgaXQgd291bGQgYmUgbGlrZSA8aW5zZXJ0IGJsYXNw aGVteSBoZXJlPi4NCg0KPiBUaGUgX2Nsb3VkXyBvcGVyYXRvciwgaW4gb3JkZXIgdG8NCj4gc2Nh bGUgdGhlaXIgREMsIG9mIHdoaWNoIHRoZSBub24tY2FycmllciBEQyBpcyBqdXN0IGEgdGVuYW50 LCBtYXkgd2FudCB0byBydW4gQkdQLiAgSnVzdCBhcw0KPiBlbnRlcnByaXNlcyBydW5uaW5nIE9T UEYgZ2V0IGNvbm5lY3Rpdml0eSBzZXJ2aWNlcyBmcm9tIGNhcnJpZXJzIHJ1bm5pbmcgQkdQLg0K SSBhYnNvbHV0ZWx5IGFncmVlLCBhbmQgbnZvMyBpcyBhcHBsaWNhYmxlIHRvIG5vbi1jYXJyaWVy IERDcy4NCg0KTlZPMyBpcyBpbmRlZWQgYXBwbGljYWJsZSB0byBib3RoIGNhcnJpZXIgYW5kIG5v bi1jYXJyaWVyIGNsb3VkIHByb3ZpZGVycy4NCg0KPiA+IFRoaXMgY2FuIGJlIHBhcnRpY3VsYXJs eSBzbyBmb3IgYSBkYXRhIGNlbnRlciB0aGF0IGRlc2lyZXMgZmxleGliaWxpdHkgaW4gY2hvaWNl IGFtb25nIGNhcnJpZXJzLA0KPg0KPiBBY3R1YWxseSwgQkdQIGlzIHdoYXQgY2FycmllcnMgdGFs ayB0byBlYWNoIG90aGVyLCBzbyBJJ20gbm90IHN1cmUgaG93IHN1Y2ggYQ0KPiBjaG9pY2UgbGlt aXRzIGZsZXhpYmlsaXR5Lg0KSWYgb25lIGV4dGVuZHMgdGhlIGNhcnJpZXIncyBCR1AgaW5zdGFu Y2UgaW50byB0aGUgZGF0YSBjZW50ZXIsIHN3aXRjaGluZyBjYXJyaWVycw0KYmVjb21lcyBtb3Jl IGRpZmZpY3VsdCBieSBjb21wYXJpc29uIHRvIC4uLg0KDQo+ID4gYW5kIGhlbmNlIG9wZXJhdGVz IHVuZGVyIHRoZSBwcmluY2lwbGUgdGhhdCBvbmUgb2YgdGhlIGpvYnMgb2YgdGhlIENQRSBib3gg aXMgdG8ga2VlcCB0aGUgY2Fycmllcg0KPiB0ZWNobm9sb2d5IG9uIHRoZSBvdGhlciBzaWRlIGlu IG9yZGVyIHRvIGxpbWl0IGxvY2staW4uDQo+DQo+IFRoZSAib3RoZXIiIHNpZGUgb2YgYSBDUEUg Ym94IHVzdWFsbHkgcnVucyBCR1AuDQouLi4gaGF2aW5nIHRoZSBDUEUgYm94IGRvIGl0cyBqb2Ig aW4ga2VlcGluZyB0aGUgY2FycmllcidzIGluc3RhbmNlIG9mIEJHUCBvbiB0aGUgY2Fycmllcidz IHNpZGUgKCJvdGhlciIgc2lkZSBvZiB0aGUgYm94KSB3aGVyZSB0aGUgY2FycmllcidzIGFkbWlu cyBjYW4gbWFuYWdlIGl0IHdpdGhvdXQgaGF2aW5nIHRvIGJvdGhlciB0aGUgZGF0YSBjZW50ZXIg YWRtaW5zIG11Y2guZg0KDQpHb3QgaXQuDQoNCkNoZWVycywNCktpcmVldGkuDQoNClRoYW5rcywN Ci0tRGF2aWQNCg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE1CB2szxeml525mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Kireeti= ,

 = ;

=B7=A2=BC=FE=C8=CB: nvo3-bounces@ietf.org= [mailto:nvo3-bounces@ietf.org] =B4=FA=B1=ED = Kireeti Kompella
=B7=A2=CB=CD= =CA=B1=BC=E4: 2012=C4=EA4=D4=C2<= span lang=3D"EN-US">3=C8=D5 8:53
=CA=D5=BC=FE=C8=CB: david.black@emc.com
=B3=AD=CB=CD: kireeti@juniper.net; l2vpn@ietf.org; nvo3@ietf.org
=D6=F7=CC=E2: Re: [nvo3] Response to some comments on IS-IS VPLS

 

Hi David,

On Mon, Apr = 2, 2012 at 12:34 PM, <david.black@emc.com>= ; wrote:

Hi Kireeti,<= br>
We're in agreement, and thank you for your comments at the BOF.  Here = are a few elaborations:

 <= /o:p>

It's great t= hat (we think) we're in agreement, but just in case ...

 <= /o:p>

> > OT= OH, for a non-carrier data center (e.g., enterprise), not only is the above= statement rather
> incorrect, but the enterprise network may not be running BGP.
>
> Step back a bit. The non-carrier DC is not being asked to run BGP.

 <= /o:p>

There are tw= o ways to interpret "non-carrier DC":

a) enterpris= es that have a DC but want to move to the clouds (i.e., customers);

b) non-carri= ers that *build* clouds (e.g., EC2).

 <= /o:p>

It is a non-= starter to ask those in (a) to run BGP (or to change any of their practices= in any significant way).

 <= /o:p>

It is a defi= nite possibility to ask the non-carrier cloud provider to adopt BGP as the = scaling mechanism.

 <= /o:p>

(oh, oh -- t= he end of a beautiful friendship, just as it was getting going ... :-))

 <= /o:p>

BGP is a wel= l-tested protocol for scaling.  Yes, there are complexities, some real= , some perceived.  The question is, is it easier to simplify BGP (along the lines that Alia said), or break loose and start again?

 = ;

[XIAOHU] T= he question is hard to answer since different people may have different ans= wers. That=A1=AFs why IS-IS and OSPF based L1VPN approaches were proposed and accepted even when BGP-based L1VPN approach has already been = there before.

 = ;

Best regar= ds,

Xiaohu

 <= /o:p>

The answer f= or SP-cloud providers seems clear.  The answer for non-carrier cloud p= roviders is open.  I'm going to revisit this thread and see how many non-carrier cloud providers actually spoke up.

 <= /o:p>

Sure - you a= nd I agree on this, but Jim wants to push BGP into non-carrier data centers= ...
perhaps you can help convince him otherwise ...

 <= /o:p>

I could try,= but it would be like <insert blasphemy here>.

 <= /o:p>

> The _cloud_ operator, in order to
> scale their DC, of which the non-carrier DC is just a tenant, may want= to run BGP.  Just as
> enterprises running OSPF get connectivity services from carriers runni= ng BGP.

I absolutely= agree, and nvo3 is applicable to non-carrier DCs.

 <= /o:p>

NVO3 is inde= ed applicable to both carrier and non-carrier cloud providers.

 <= /o:p>

> > This can be particularly so for a data center = that desires flexibility in choice among carriers,
>
> Actually, BGP is what carriers talk to each other, so I'm not sure how= such a
> choice limits flexibility.

If one exten= ds the carrier's BGP instance into the data center, switching carriers
becomes more difficult by comparison to ...


> > and hence operates under the principle that one of the jobs of th= e CPE box is to keep the carrier
> technology on the other side in order to limit lock-in.
>
> The "other" side of a CPE box usually runs BGP.

... having t= he CPE box do its job in keeping the carrier's instance of BGP on the carri= er's side ("other" side of the box) where the carrier's admins can manage it without having to bother the data center admins much.f<= /o:p>

 <= /o:p>

Got it.=

 <= /o:p>

Cheers,=

Kireeti.

 <= /o:p>

Thanks,
--David

 

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE1CB2szxeml525mbschi_-- From sajassi@cisco.com Thu Apr 5 22:07:37 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7C411E8093 for ; Thu, 5 Apr 2012 22:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, 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 rK-t8jQDi6sL for ; Thu, 5 Apr 2012 22:07:36 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8C411E8072 for ; Thu, 5 Apr 2012 22:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sajassi@cisco.com; l=7921; q=dns/txt; s=iport; t=1333688856; x=1334898456; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=D4cPbNwWkhV86PBJREk0VxWLmyZug4bcZKqkCnBfmJA=; b=X8fiDKPVla+E2iOpMihNh0jmPTjsex4wX4NapYstoRBsSO+HIzBWT1AP qKgkj3zb/Wo+fGwwLCYejiSpYH8w8RUo5oqU4IsFlnzIfM04rGpcNVbai bJwHureLyD9TI0P9M93DGMNbYHkexJ4sLupIJKVY7mdckBP6fVbFt3HbN 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANR5fk+rRDoI/2dsb2JhbABDhXuyInaBB4IJAQEBBBIBEBkBMAELEgEGAgkIBAEBAQICIwMCSBECBAENBRQHB4drAQufGY0IinOBL4lphBuBGASIWYUsh2aBEY06gWmDB4E0 X-IronPort-AV: E=Sophos;i="4.75,380,1330905600"; d="scan'208";a="36752676" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 06 Apr 2012 05:07:35 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3657Z3r008962; Fri, 6 Apr 2012 05:07:35 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 22:07:34 -0700 Received: from 10.21.83.103 ([10.21.83.103]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Fri, 6 Apr 2012 05:07:34 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 05 Apr 2012 22:07:34 -0700 Subject: Re: Response to some comments on IS-IS VPLS From: sajassi To: Xuxiaohu , "robert@raszuk.net" , John E Drake Message-ID: Thread-Topic: Response to some comments on IS-IS VPLS Thread-Index: AQHNDauno12B0RP+lEO1DyVa7X7/s5aBlXMQgAAXd5D//5jvgIAAuvyAgACIz5mABLG/AIAEXVAwgAGyT/k= In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE1C9E@szxeml525-mbs.china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 06 Apr 2012 05:07:34.0935 (UTC) FILETIME=[2DA31A70:01CD13B3] Cc: "l2vpn@ietf.org" , "UTTARO, JAMES" X-BeenThere: l2vpn@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, 06 Apr 2012 05:07:37 -0000 Hi Xuxiaohu, I think when we talk about a given solution, we should also talk about the framework and the requirements for which the solution is intended for. Ther= e is a requirement draft for EVPN/PBB-EVPN solution and there is also a requirement/framework draft for nov3 solutions. Frankly, between these two sets of framework and their corresponding solutions, I think we are coverin= g host-based v.s. network-based, intraDC v.s. InterDC, as well as different kinds of DCs. If you think, there is an area that it is not covered by thes= e two sets, then you should start from there and articulate those requirements. Cheers, Ali =20 On 4/4/12 8:20 PM, "Xuxiaohu" wrote: >=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: sajassi [mailto:sajassi@cisco.com] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B44=E6=9C=883=E6=97=A5 0:34 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; robert@raszuk.net; John E Drake >> =E6=8A=84=E9=80=81: l2vpn@ietf.org; UTTARO, JAMES >> =E4=B8=BB=E9=A2=98: Re: Response to some comments on IS-IS VPLS >>=20 >> Hi Xuxiaohu, >>=20 >> The draft that I wrote ten years ago (MVPLS) is analogous to VXLAN - bot= h do >> the same thing but with different IP encap. MVPLS used L2TPv3 encap (sin= ce >> it was the encap-dejour of that time for IP :-); whereas, VXLAN uses UDP >> encap. >>=20 >> Since there are already three different encap proposals in NVo3 (UDP, GR= E, >> and TCP), I am NOT planning to introduce yet another encap by resurrecti= ng >> my draft. I think we should only pick a single encap among the three cur= rent >> proposals in NVO3. >=20 > Hi Ali, >=20 > Does that mean you also believe a simplified L2VPN approach other than EV= PN is > needed for data center networks? Otherwise why do you suggest picking one > rather than dropping them all? >=20 > Best regards, > Xiaohu >=20 >>=20 >> Cheers, >> Ali >>=20 >>=20 >> On 3/30/12 1:55 AM, "Xuxiaohu" wrote: >>=20 >>> Hi Ali, >>>=20 >>> What's your attitude to your own draft as mentioned below from today's >> point >>> of view? good or bad? >>>=20 >>> Best regards, >>> Xiaohu >>>=20 >>> ________________________________________ >>> =E5=8F=91=E4=BB=B6=E4=BA=BA: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 sajas= si >>> [sajassi@cisco.com] >>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B43=E6=9C=8830=E6=97=A5 16:43 >>> =E5=88=B0: robert@raszuk.net; John E Drake >>> Cc: l2vpn@ietf.org; UTTARO, JAMES >>> =E4=B8=BB=E9=A2=98: Re: Response to some comments on IS-IS VPLS >>>=20 >>> Hi Robert, >>>=20 >>> I won't get into the argument of whether this kind of solution is innov= ation >>> or permutation. My point is that it is clearly outside of current L2VPN >>> charter and if this kind of solution is to be pursued in L2VPN WG, then= it >>> needs to be re-chartered. >>>=20 >>> Also, if we are talking about VPLS service over IP and doing MAC learni= ng >>> against IP addresses (as what this draft is talking about), I had a dra= ft 10 >>> years ago that cover this subject !! >>>=20 >>> http://tools.ietf.org/id/draft-sajassi-mvpls-00.txt >>>=20 >>> Cheers, >>> Ali >>>=20 >>>=20 >>> On 3/29/12 2:33 PM, "Robert Raszuk" wrote: >>>=20 >>>> Hi John, >>>>=20 >>>> I think you took it a little bit too far. >>>>=20 >>>> I have not heard anyone stating that current VPLS solutions suck. I al= so >>>> did not hear anyone claiming that BGP is difficult. The claim I have >>>> heard is that in some environments one may not like to use BGP for VPL= S. >>>>=20 >>>> Ali's point is that current PEs will have problem supporting it as thi= s >>>> is effectively TRILL over IP is valid from Ali's point of view. >>>>=20 >>>> However one could ask a question if IETF is still an organization to >>>> promote open innovation and consider new ideas (even if only in >>>> experimental mode) or is it just a forum to lock customers to limited >>>> set of solutions ? If it is the latter the trend to seek alternatives = to >>>> IETF standardization process will continue to evolve. Especially now >>>> when control plane separation from data plane becomes reality. >>>>=20 >>>> I see nothing wrong to allocate perhaps in experimental mode VPLS Info >>>> TLV codepoint for VPLS over ISIS or for that matter well known >>>> destination port for STT from IANA and let companies who are asking fo= r >>>> it develop the solutions, deploy it then report back the results to th= e >>>> community. >>>>=20 >>>> Best, >>>> R. >>>>=20 >>>>=20 >>>>> Jim, >>>>>=20 >>>>> You are completely correct , but let=C2=B9s not overlook the fun factor. >>>>> I.e., it=C2=B9s **fun** to say that everything that has gone before sucks= and >>>>> that the current initiative will be =C2=B3practically perfect=C2=B2 (c.f. =C5=92M= ary >>>>> Poppins=C2=B9). >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> John >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>> *From:*l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] *On >> Behalf >>>>> Of *UTTARO, JAMES >>>>> *Sent:* Thursday, March 29, 2012 11:30 AM >>>>> *To:* 'Xuxiaohu'; l2vpn@ietf.org >>>>> *Subject:* RE: Response to some comments on IS-IS VPLS >>>>>=20 >>>>> IMHO=C5=A0 I am at a bit of a loss as to the notion that BGP is so >>>>> overwhelmingly difficult to deal with in a data center environment.. = Why >>>>> is that?? BGP is being used across a wide spectrum of applications an= d >>>>> is proven. I believe that the data center is becoming more and more a >>>>> dynamic extension of a customer=C2=B9s network. I also think it would be = wise >>>>> to anticipate the world of tomorrow where customers may expect their >>>>> network may span multiple operators DCs. The right approach is to >>>>> leverage what has been done BGP and extend it where needed.. This >>>>> provides maximum flexibility and simplicity.. >>>>>=20 >>>>> To build solutions based on the notion that =C2=B3I don=C2=B9t like protocol = X=C2=B2 is >>>>> invalid.. >>>>>=20 >>>>> Jim Uttaro >>>>>=20 >>>>> *From:*l2vpn-bounces@ietf.org >>>>> [mailto:l2vpn-bounces@ietf.org] *On Behalf Of *Xuxiaohu >>>>> *Sent:* Thursday, March 29, 2012 2:59 PM >>>>> *To:* l2vpn@ietf.org >>>>> *Subject:* Response to some comments on IS-IS VPLS >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> VPLS (Virtual Private LAN Service) has different understandings for >>>>> different people, some people think it as a service while others thin= k >>>>> it as a concrete technology, especially using PWs. Here, the "VPLS" i= s >>>>> deemed as a VPLS service. If the WG consensus is that "VPLS" should b= e >>>>> taken as a concrete technology, I have no objection to using another = term. >>>>>=20 >>>>> As said in the IS-IS VPLS draft, IS-IS VPLS is intended to be a >>>>> light-weight VPLS solution which can meet some DC operators' >>>>> requirements for simplicity. I don't want to argue in this mailing-li= st >>>>> whether BGP-based L2VPN solutions could meet well the requirements >> from >>>>> all DC operators. I personally believe that it would be better to ask >>>>> this question to NVo3. In addition, according to today's presentation= of >>>>> E-VPN, I think E-VPN co-authors also admit that the exiting EVPN >>>>> solution seems complex to some DC operators. If my understanding is >>>>> wrong, pls correct me. >>>>>=20 >>>>> If I remembered correctly, L1VPN also has two RFCs using IS-IS and OS= PF >>>>> for L1VPN auto-discovery, although there has been one solution using >>>>> BGP. Hence I don't know why can't we have a light-weight L2VPN using >> IS-IS. >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Xiaohu >>>>>=20 >>>>=20 >=20 From xuxiaohu@huawei.com Fri Apr 6 00:11:24 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0022321F8570; Fri, 6 Apr 2012 00:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.641 X-Spam-Level: X-Spam-Status: No, score=-0.641 tagged_above=-999 required=5 tests=[AWL=1.358, 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 5BWpbhiGzsqe; Fri, 6 Apr 2012 00:11:23 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B66B821F84E7; Fri, 6 Apr 2012 00:11:22 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEZ84688; Fri, 06 Apr 2012 03:11:22 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 6 Apr 2012 00:10:38 -0700 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 6 Apr 2012 00:10:44 -0700 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.158]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Fri, 6 Apr 2012 15:08:56 +0800 From: Xuxiaohu To: sajassi , "robert@raszuk.net" , John E Drake Subject: re: Response to some comments on IS-IS VPLS Thread-Topic: Response to some comments on IS-IS VPLS Thread-Index: AQHNDauno12B0RP+lEO1DyVa7X7/s5aBlXMQgAAXd5D//5jvgIAAuvyAgACIz5mABLG/AIAEXVAwgAGyT/mAAA0+UA== Date: Fri, 6 Apr 2012 07:08:56 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE2148@szxeml525-mbs.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE1C9E@szxeml525-mbs.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.108.4.99] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" , "UTTARO, JAMES" X-BeenThere: l2vpn@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, 06 Apr 2012 07:11:24 -0000 SGkgQWxp77yMDQoNCkkgc3VnZ2VzdCB5b3UgcmVhZGluZyB0aGUgbGF0ZXN0IHZlcnNpb24gb2Yg SVMtSVMgVlBMUyBkcmFmdCAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtbDJ2 cG4tdnBscy1pc2lzLTAzKSAsIGVzcGVjaWFsbHkgdGhlIGZpcnN0IHNlY3Rpb24gd2hpY2ggZGVz Y3JpYmVzIHRoZSByZXF1aXJlbWVudHMgaW4gZGV0YWlscy4gSSBiZWxpZXZlIHlvdSBjb3VsZCBm aW5kIHRoZSBhbnN3ZXIgdG8geW91ciBxdWVzdGlvbiBhbmQgYWxzbyBmaW5kIHRoZSBvYnZpb3Vz IGRpZmZlcmVuY2VzIGJldHdlZW4gSVMtSVMgVlBMUyBhbmQgeW91ciBNVlBMUyBvbmNlIHlvdSBo YXZlIGZpbmlzaGVkIHJlYWRpbmcgdGhhdCBkcmFmdC4NCg0KT2YgY291cnNlLCBpZiB0aGUgV0cg Y29uc2Vuc3VzIGlzIHRvIHNlcGFyYXRlIHRoZSByZXF1aXJlbWVudHMgYXMgYW4gaW5kZXBlbmRl bnQgZHJhZnQsIEkgY291bGQgZG8gdGhhdC4NCg0KQnkgdGhlIHdheSwgc2luY2UgeW91IG1lbnRp b25lZCB0aGUgcmVxdWlyZW1lbnQvZnJhbWV3b3JrIGRyYWZ0IGZvciBub3YzIHNvbHV0aW9ucywg eW91IG1heSBoYXZlIG5vdGljZWQgdGhhdCBvbmUgb2YgdGhlIGNvbnRyb2wgcGxhbmUgcmVxdWly ZW1lbnRzIGRlc2NyaWJlZCBpbiB0aGUgcmVxdWlyZW1lbnQgZHJhZnQgaXMgIkRvIG5vdCByZWx5 IG9uIElQIE11bHRpY2FzdCBpbiB0aGUgVW5kZXJseWluZyBOZXR3b3JrICIgKFNlZSB0aGUgc2Vj dGlvbiBvZiBDb250cm9sIFBsYW5lIENoYXJhY3RlcmlzdGljcyksIGFuZCB5b3UgbWF5IGhhdmUg YWxzbyBub3RpY2VkIHNlY3Rpb24gNC4yLjMuIkhhbmRsaW5nIEJyb2FkY2FzdCwgVW5rbm93biBV bmljYXN0IGFuZCBNdWx0aWNhc3QgKEJVTSkgdHJhZmZpYyIgb2YgdGhlIGZyYW1ld29yayBkcmFm dCwgd2hpY2ggZXhwbGljaXRseSBzYWlkICJEZXBlbmRpbmcgdXBvbiB0aGUgc2l6ZSBvZiB0aGUg ZGF0YSBjZW50ZXIgbmV0d29yayBhbmQgaGVuY2UgdGhlIG51bWJlciBvZiAoUyxHKSBlbnRyaWVz LCBidXQgYWxzbyB0aGUgZHVyYXRpb24gb2YgbXVsdGljYXN0IGZsb3dzLCB0aGUgdXNlIG9mIGNv cmUgbXVsdGljYXN0IHRyZWVzIGNhbiBiZSBhIGNoYWxsZW5nZSAiLiBIZW5jZSBJIHdvbmRlciB3 aGV0aGVyIHlvdSBoYXZlIGFueSBkaWZmZXJlbnQgb3BpbmlvbnMgaW4gdGhpcyByZWdhcmQuIElm IG5vLCBiYXNlZCBvbiB0aGUgYWJzdHJhY3Qgb2YgeW91ciBNVlBMUyBkcmFmdCBzaG93biBhcyBm b2xsb3dzLCBJIHRoaW5rIHlvdSB3b3VsZCBhbHNvIGFncmVlIHRoYXQgTVZQTFMgaXMgbm90IGEg c3VpdGFibGUgY2FuZGlkYXRlIHNvbHV0aW9uIGZvciBkYXRhIGNlbnRlciBuZXR3b3Jrcy4NCg0K KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqDQogICAgICAgICAgICBBYnN0cmFjdCANCiAgICAgICAgICAgICANCiAgICAgICAg ICAgIFZpcnR1YWwgUHJpdmF0ZSBMQU4gU2VydmljZSAoVlBMUykgaXMgYSB0eXBlIG9mIExheWVy LTIgUHJvdmlkZXIgDQogICAgICAgICAgICBQcm92aXNpb25lZCBWaXJ0dWFsIFByaXZhdGUgTmV0 d29yayAoTDIgUFBWUE4pIG9mZmVyZWQgc2VydmljZSwgd2hpY2ggDQogICAgICAgICAgICBoYXMg YmVlbiBkZXNjcmliZWQgaW4gW1BQVlBOLUZSV0tdLiBJZiB0aGUgU2VydmljZSBQcm92aWRlciBu ZXR3b3JrIA0KICAgICAgICAgICAgcHJvdmlkZXMgSVAgbXVsdGljYXN0IGZ1bmN0aW9uYWxpdHks IHRoZW4gdGhpcyBuZXR3b3JrIGNhcGFiaWxpdHkgY2FuIA0KICAgICAgICAgICAgYmUgbGV2ZXJh Z2VkIGluIHByb3ZpZGluZyB2ZXJ5IGVmZmljaWVudCBWUExTIHNlcnZpY2UgYW5kIHlldCANCiAg ICAgICAgICAgIHNpbXBsaWZ5aW5nIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiBzdWNoIHNlcnZpY2Uu IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIA0KICAgICAgICAgICAgYSBzb2x1dGlvbiBmb3IgcHJv dmlkaW5nIFZQTFMgc2VydmljZSBiYXNlZCBvbiBJUCBtdWx0aWNhc3QgZmVhdHVyZSANCiAgICAg ICAgICAgIHJlZmVycmVkIHRvIGFzIE11bHRpY2FzdCBWaXJ0dWFsIFByaXZhdGUgTEFOIFNlcnZp Y2UgKE1WUExTKS4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioNCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gLS0t LS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IHNhamFzc2kgW21haWx0bzpzYWphc3Np QGNpc2NvLmNvbV0NCj4g5Y+R6YCB5pe26Ze0OiAyMDEy5bm0NOaciDbml6UgMTM6MDgNCj4g5pS2 5Lu25Lq6OiBYdXhpYW9odTsgcm9iZXJ0QHJhc3p1ay5uZXQ7IEpvaG4gRSBEcmFrZQ0KPiDmioTp gIE6IGwydnBuQGlldGYub3JnOyBVVFRBUk8sIEpBTUVTDQo+IOS4u+mimDogUmU6IFJlc3BvbnNl IHRvIHNvbWUgY29tbWVudHMgb24gSVMtSVMgVlBMUw0KPiANCj4gSGkgWHV4aWFvaHUsDQo+IA0K PiBJIHRoaW5rIHdoZW4gd2UgdGFsayBhYm91dCBhIGdpdmVuIHNvbHV0aW9uLCB3ZSBzaG91bGQg YWxzbyB0YWxrIGFib3V0IHRoZQ0KPiBmcmFtZXdvcmsgYW5kIHRoZSByZXF1aXJlbWVudHMgZm9y IHdoaWNoIHRoZSBzb2x1dGlvbiBpcyBpbnRlbmRlZCBmb3IuIFRoZXJlDQo+IGlzIGEgcmVxdWly ZW1lbnQgZHJhZnQgZm9yIEVWUE4vUEJCLUVWUE4gc29sdXRpb24gYW5kIHRoZXJlIGlzIGFsc28g YQ0KPiByZXF1aXJlbWVudC9mcmFtZXdvcmsgZHJhZnQgZm9yIG5vdjMgc29sdXRpb25zLiBGcmFu a2x5LCBiZXR3ZWVuIHRoZXNlIHR3bw0KPiBzZXRzIG9mIGZyYW1ld29yayBhbmQgdGhlaXIgY29y cmVzcG9uZGluZyBzb2x1dGlvbnMsIEkgdGhpbmsgd2UgYXJlIGNvdmVyaW5nDQo+IGhvc3QtYmFz ZWQgdi5zLiBuZXR3b3JrLWJhc2VkLCAgaW50cmFEQyB2LnMuIEludGVyREMsIGFzIHdlbGwgYXMg ZGlmZmVyZW50DQo+IGtpbmRzIG9mIERDcy4gSWYgeW91IHRoaW5rLCB0aGVyZSBpcyBhbiBhcmVh IHRoYXQgaXQgaXMgbm90IGNvdmVyZWQgYnkgdGhlc2UNCj4gdHdvIHNldHMsIHRoZW4geW91IHNo b3VsZCBzdGFydCBmcm9tIHRoZXJlIGFuZCBhcnRpY3VsYXRlIHRob3NlDQo+IHJlcXVpcmVtZW50 cy4NCj4gDQo+IENoZWVycywNCj4gQWxpDQo+IA0KPiANCj4gT24gNC80LzEyIDg6MjAgUE0sICJY dXhpYW9odSIgPHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiANCj4gPg0KPiA+PiAtLS0t LemCruS7tuWOn+S7ti0tLS0tDQo+ID4+IOWPkeS7tuS6ujogc2FqYXNzaSBbbWFpbHRvOnNhamFz c2lAY2lzY28uY29tXQ0KPiA+PiDlj5HpgIHml7bpl7Q6IDIwMTLlubQ05pyIM+aXpSAwOjM0DQo+ ID4+IOaUtuS7tuS6ujogWHV4aWFvaHU7IHJvYmVydEByYXN6dWsubmV0OyBKb2huIEUgRHJha2UN Cj4gPj4g5oqE6YCBOiBsMnZwbkBpZXRmLm9yZzsgVVRUQVJPLCBKQU1FUw0KPiA+PiDkuLvpopg6 IFJlOiBSZXNwb25zZSB0byBzb21lIGNvbW1lbnRzIG9uIElTLUlTIFZQTFMNCj4gPj4NCj4gPj4g SGkgWHV4aWFvaHUsDQo+ID4+DQo+ID4+IFRoZSBkcmFmdCB0aGF0IEkgd3JvdGUgdGVuIHllYXJz IGFnbyAoTVZQTFMpIGlzIGFuYWxvZ291cyB0byBWWExBTiAtIGJvdGgNCj4gZG8NCj4gPj4gdGhl IHNhbWUgdGhpbmcgYnV0IHdpdGggZGlmZmVyZW50IElQIGVuY2FwLiBNVlBMUyB1c2VkIEwyVFB2 MyBlbmNhcCAoc2luY2UNCj4gPj4gaXQgd2FzIHRoZSBlbmNhcC1kZWpvdXIgb2YgdGhhdCB0aW1l IGZvciBJUCA6LSk7IHdoZXJlYXMsIFZYTEFOIHVzZXMgVURQDQo+ID4+IGVuY2FwLg0KPiA+Pg0K PiA+PiBTaW5jZSB0aGVyZSBhcmUgYWxyZWFkeSB0aHJlZSBkaWZmZXJlbnQgZW5jYXAgcHJvcG9z YWxzIGluIE5WbzMgKFVEUCwgR1JFLA0KPiA+PiBhbmQgVENQKSwgSSBhbSBOT1QgcGxhbm5pbmcg dG8gaW50cm9kdWNlIHlldCBhbm90aGVyIGVuY2FwIGJ5IHJlc3VycmVjdGluZw0KPiA+PiBteSBk cmFmdC4gSSB0aGluayB3ZSBzaG91bGQgb25seSBwaWNrIGEgc2luZ2xlIGVuY2FwIGFtb25nIHRo ZSB0aHJlZSBjdXJyZW50DQo+ID4+IHByb3Bvc2FscyBpbiBOVk8zLg0KPiA+DQo+ID4gSGkgQWxp LA0KPiA+DQo+ID4gRG9lcyB0aGF0IG1lYW4geW91IGFsc28gYmVsaWV2ZSBhIHNpbXBsaWZpZWQg TDJWUE4gYXBwcm9hY2ggb3RoZXIgdGhhbg0KPiBFVlBOIGlzDQo+ID4gbmVlZGVkIGZvciBkYXRh IGNlbnRlciBuZXR3b3Jrcz8gT3RoZXJ3aXNlIHdoeSBkbyB5b3Ugc3VnZ2VzdCBwaWNraW5nIG9u ZQ0KPiA+IHJhdGhlciB0aGFuIGRyb3BwaW5nIHRoZW0gYWxsPw0KPiA+DQo+ID4gQmVzdCByZWdh cmRzLA0KPiA+IFhpYW9odQ0KPiA+DQo+ID4+DQo+ID4+IENoZWVycywNCj4gPj4gQWxpDQo+ID4+ DQo+ID4+DQo+ID4+IE9uIDMvMzAvMTIgMTo1NSBBTSwgIlh1eGlhb2h1IiA8eHV4aWFvaHVAaHVh d2VpLmNvbT4gd3JvdGU6DQo+ID4+DQo+ID4+PiBIaSBBbGksDQo+ID4+Pg0KPiA+Pj4gV2hhdCdz IHlvdXIgYXR0aXR1ZGUgdG8geW91ciBvd24gZHJhZnQgYXMgbWVudGlvbmVkIGJlbG93IGZyb20g dG9kYXkncw0KPiA+PiBwb2ludA0KPiA+Pj4gb2Ygdmlldz8gZ29vZCBvciBiYWQ/DQo+ID4+Pg0K PiA+Pj4gQmVzdCByZWdhcmRzLA0KPiA+Pj4gWGlhb2h1DQo+ID4+Pg0KPiA+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4g5Y+R5Lu25Lq6OiBsMnZwbi1i b3VuY2VzQGlldGYub3JnIFtsMnZwbi1ib3VuY2VzQGlldGYub3JnXSDku6Pooaggc2FqYXNzaQ0K PiA+Pj4gW3NhamFzc2lAY2lzY28uY29tXQ0KPiA+Pj4g5Y+R6YCB5pe26Ze0OiAyMDEy5bm0M+ac iDMw5pelIDE2OjQzDQo+ID4+PiDliLA6IHJvYmVydEByYXN6dWsubmV0OyBKb2huIEUgRHJha2UN Cj4gPj4+IENjOiBsMnZwbkBpZXRmLm9yZzsgVVRUQVJPLCBKQU1FUw0KPiA+Pj4g5Li76aKYOiBS ZTogUmVzcG9uc2UgdG8gc29tZSBjb21tZW50cyBvbiBJUy1JUyBWUExTDQo+ID4+Pg0KPiA+Pj4g SGkgUm9iZXJ0LA0KPiA+Pj4NCj4gPj4+IEkgd29uJ3QgZ2V0IGludG8gdGhlIGFyZ3VtZW50IG9m IHdoZXRoZXIgdGhpcyBraW5kIG9mIHNvbHV0aW9uIGlzIGlubm92YXRpb24NCj4gPj4+IG9yIHBl cm11dGF0aW9uLiBNeSBwb2ludCBpcyB0aGF0IGl0IGlzIGNsZWFybHkgb3V0c2lkZSBvZiBjdXJy ZW50IEwyVlBODQo+ID4+PiBjaGFydGVyIGFuZCBpZiB0aGlzIGtpbmQgb2Ygc29sdXRpb24gaXMg dG8gYmUgcHVyc3VlZCBpbiBMMlZQTiBXRywgdGhlbiBpdA0KPiA+Pj4gbmVlZHMgdG8gYmUgcmUt Y2hhcnRlcmVkLg0KPiA+Pj4NCj4gPj4+IEFsc28sIGlmIHdlIGFyZSB0YWxraW5nIGFib3V0IFZQ TFMgc2VydmljZSBvdmVyIElQIGFuZCBkb2luZyBNQUMgbGVhcm5pbmcNCj4gPj4+IGFnYWluc3Qg SVAgYWRkcmVzc2VzIChhcyB3aGF0IHRoaXMgZHJhZnQgaXMgdGFsa2luZyBhYm91dCksIEkgaGFk IGEgZHJhZnQgMTANCj4gPj4+IHllYXJzIGFnbyB0aGF0IGNvdmVyIHRoaXMgc3ViamVjdCAhIQ0K PiA+Pj4NCj4gPj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1zYWphc3NpLW12cGxz LTAwLnR4dA0KPiA+Pj4NCj4gPj4+IENoZWVycywNCj4gPj4+IEFsaQ0KPiA+Pj4NCj4gPj4+DQo+ ID4+PiBPbiAzLzI5LzEyIDI6MzMgUE0sICJSb2JlcnQgUmFzenVrIiA8cm9iZXJ0QHJhc3p1ay5u ZXQ+IHdyb3RlOg0KPiA+Pj4NCj4gPj4+PiBIaSBKb2huLA0KPiA+Pj4+DQo+ID4+Pj4gSSB0aGlu ayB5b3UgdG9vayBpdCBhIGxpdHRsZSBiaXQgdG9vIGZhci4NCj4gPj4+Pg0KPiA+Pj4+IEkgaGF2 ZSBub3QgaGVhcmQgYW55b25lIHN0YXRpbmcgdGhhdCBjdXJyZW50IFZQTFMgc29sdXRpb25zIHN1 Y2suIEkgYWxzbw0KPiA+Pj4+IGRpZCBub3QgaGVhciBhbnlvbmUgY2xhaW1pbmcgdGhhdCBCR1Ag aXMgZGlmZmljdWx0LiBUaGUgY2xhaW0gSSBoYXZlDQo+ID4+Pj4gaGVhcmQgaXMgdGhhdCBpbiBz b21lIGVudmlyb25tZW50cyBvbmUgbWF5IG5vdCBsaWtlIHRvIHVzZSBCR1AgZm9yIFZQTFMuDQo+ ID4+Pj4NCj4gPj4+PiBBbGkncyBwb2ludCBpcyB0aGF0IGN1cnJlbnQgUEVzIHdpbGwgaGF2ZSBw cm9ibGVtIHN1cHBvcnRpbmcgaXQgYXMgdGhpcw0KPiA+Pj4+IGlzIGVmZmVjdGl2ZWx5IFRSSUxM IG92ZXIgSVAgaXMgdmFsaWQgZnJvbSBBbGkncyBwb2ludCBvZiB2aWV3Lg0KPiA+Pj4+DQo+ID4+ Pj4gSG93ZXZlciBvbmUgY291bGQgYXNrIGEgcXVlc3Rpb24gaWYgSUVURiBpcyBzdGlsbCBhbiBv cmdhbml6YXRpb24gdG8NCj4gPj4+PiBwcm9tb3RlIG9wZW4gaW5ub3ZhdGlvbiBhbmQgY29uc2lk ZXIgbmV3IGlkZWFzIChldmVuIGlmIG9ubHkgaW4NCj4gPj4+PiBleHBlcmltZW50YWwgbW9kZSkg b3IgaXMgaXQganVzdCBhIGZvcnVtIHRvIGxvY2sgY3VzdG9tZXJzIHRvIGxpbWl0ZWQNCj4gPj4+ PiBzZXQgb2Ygc29sdXRpb25zID8gSWYgaXQgaXMgdGhlIGxhdHRlciB0aGUgdHJlbmQgdG8gc2Vl ayBhbHRlcm5hdGl2ZXMgdG8NCj4gPj4+PiBJRVRGIHN0YW5kYXJkaXphdGlvbiBwcm9jZXNzIHdp bGwgY29udGludWUgdG8gZXZvbHZlLiBFc3BlY2lhbGx5IG5vdw0KPiA+Pj4+IHdoZW4gY29udHJv bCBwbGFuZSBzZXBhcmF0aW9uIGZyb20gZGF0YSBwbGFuZSBiZWNvbWVzIHJlYWxpdHkuDQo+ID4+ Pj4NCj4gPj4+PiBJIHNlZSBub3RoaW5nIHdyb25nIHRvIGFsbG9jYXRlIHBlcmhhcHMgaW4gZXhw ZXJpbWVudGFsIG1vZGUgVlBMUyBJbmZvDQo+ID4+Pj4gVExWIGNvZGVwb2ludCBmb3IgVlBMUyBv dmVyIElTSVMgb3IgZm9yIHRoYXQgbWF0dGVyIHdlbGwga25vd24NCj4gPj4+PiBkZXN0aW5hdGlv biBwb3J0IGZvciBTVFQgZnJvbSBJQU5BIGFuZCBsZXQgY29tcGFuaWVzIHdobyBhcmUgYXNraW5n IGZvcg0KPiA+Pj4+IGl0IGRldmVsb3AgdGhlIHNvbHV0aW9ucywgZGVwbG95IGl0IHRoZW4gcmVw b3J0IGJhY2sgdGhlIHJlc3VsdHMgdG8gdGhlDQo+ID4+Pj4gY29tbXVuaXR5Lg0KPiA+Pj4+DQo+ ID4+Pj4gQmVzdCwNCj4gPj4+PiBSLg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pj4gSmltLA0KPiA+ Pj4+Pg0KPiA+Pj4+PiBZb3UgYXJlIGNvbXBsZXRlbHkgY29ycmVjdCAsIGJ1dCBsZXTCuXMgbm90 IG92ZXJsb29rIHRoZSBmdW4gZmFjdG9yLg0KPiA+Pj4+PiBJLmUuLCBpdMK5cyAqKmZ1bioqIHRv IHNheSB0aGF0IGV2ZXJ5dGhpbmcgdGhhdCBoYXMgZ29uZSBiZWZvcmUgc3Vja3MgYW5kDQo+ID4+ Pj4+IHRoYXQgdGhlIGN1cnJlbnQgaW5pdGlhdGl2ZSB3aWxsIGJlIMKzcHJhY3RpY2FsbHkgcGVy ZmVjdMKyIChjLmYuIMWSTWFyeQ0KPiA+Pj4+PiBQb3BwaW5zwrkpLg0KPiA+Pj4+Pg0KPiA+Pj4+ PiBUaGFua3MsDQo+ID4+Pj4+DQo+ID4+Pj4+IEpvaG4NCj4gPj4+Pj4NCj4gPj4+Pj4gU2VudCBm cm9tIG15IGlQaG9uZQ0KPiA+Pj4+Pg0KPiA+Pj4+PiAqRnJvbToqbDJ2cG4tYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddICpPbg0KPiA+PiBCZWhhbGYNCj4g Pj4+Pj4gT2YgKlVUVEFSTywgSkFNRVMNCj4gPj4+Pj4gKlNlbnQ6KiBUaHVyc2RheSwgTWFyY2gg MjksIDIwMTIgMTE6MzAgQU0NCj4gPj4+Pj4gKlRvOiogJ1h1eGlhb2h1JzsgbDJ2cG5AaWV0Zi5v cmcNCj4gPj4+Pj4gKlN1YmplY3Q6KiBSRTogUmVzcG9uc2UgdG8gc29tZSBjb21tZW50cyBvbiBJ Uy1JUyBWUExTDQo+ID4+Pj4+DQo+ID4+Pj4+IElNSE/FoCBJIGFtIGF0IGEgYml0IG9mIGEgbG9z cyBhcyB0byB0aGUgbm90aW9uIHRoYXQgQkdQIGlzIHNvDQo+ID4+Pj4+IG92ZXJ3aGVsbWluZ2x5 IGRpZmZpY3VsdCB0byBkZWFsIHdpdGggaW4gYSBkYXRhIGNlbnRlciBlbnZpcm9ubWVudC4uIFdo eQ0KPiA+Pj4+PiBpcyB0aGF0Pz8gQkdQIGlzIGJlaW5nIHVzZWQgYWNyb3NzIGEgd2lkZSBzcGVj dHJ1bSBvZiBhcHBsaWNhdGlvbnMgYW5kDQo+ID4+Pj4+IGlzIHByb3Zlbi4gSSBiZWxpZXZlIHRo YXQgdGhlIGRhdGEgY2VudGVyIGlzIGJlY29taW5nIG1vcmUgYW5kIG1vcmUgYQ0KPiA+Pj4+PiBk eW5hbWljIGV4dGVuc2lvbiBvZiBhIGN1c3RvbWVywrlzIG5ldHdvcmsuIEkgYWxzbyB0aGluayBp dCB3b3VsZCBiZQ0KPiB3aXNlDQo+ID4+Pj4+IHRvIGFudGljaXBhdGUgdGhlIHdvcmxkIG9mIHRv bW9ycm93IHdoZXJlIGN1c3RvbWVycyBtYXkgZXhwZWN0IHRoZWlyDQo+ID4+Pj4+IG5ldHdvcmsg bWF5IHNwYW4gbXVsdGlwbGUgb3BlcmF0b3JzIERDcy4gVGhlIHJpZ2h0IGFwcHJvYWNoIGlzIHRv DQo+ID4+Pj4+IGxldmVyYWdlIHdoYXQgaGFzIGJlZW4gZG9uZSBCR1AgYW5kIGV4dGVuZCBpdCB3 aGVyZSBuZWVkZWQuLiBUaGlzDQo+ID4+Pj4+IHByb3ZpZGVzIG1heGltdW0gZmxleGliaWxpdHkg YW5kIHNpbXBsaWNpdHkuLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUbyBidWlsZCBzb2x1dGlvbnMgYmFz ZWQgb24gdGhlIG5vdGlvbiB0aGF0IMKzSSBkb27CuXQgbGlrZSBwcm90b2NvbCBYwrIgaXMNCj4g Pj4+Pj4gaW52YWxpZC4uDQo+ID4+Pj4+DQo+ID4+Pj4+IEppbSBVdHRhcm8NCj4gPj4+Pj4NCj4g Pj4+Pj4gKkZyb206KmwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgPG1haWx0bzpsMnZwbi1ib3VuY2Vz QGlldGYub3JnPg0KPiA+Pj4+PiBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBC ZWhhbGYgT2YgKlh1eGlhb2h1DQo+ID4+Pj4+ICpTZW50OiogVGh1cnNkYXksIE1hcmNoIDI5LCAy MDEyIDI6NTkgUE0NCj4gPj4+Pj4gKlRvOiogbDJ2cG5AaWV0Zi5vcmcgPG1haWx0bzpsMnZwbkBp ZXRmLm9yZz4NCj4gPj4+Pj4gKlN1YmplY3Q6KiBSZXNwb25zZSB0byBzb21lIGNvbW1lbnRzIG9u IElTLUlTIFZQTFMNCj4gPj4+Pj4NCj4gPj4+Pj4gSGkgYWxsLA0KPiA+Pj4+Pg0KPiA+Pj4+PiBW UExTIChWaXJ0dWFsIFByaXZhdGUgTEFOIFNlcnZpY2UpIGhhcyBkaWZmZXJlbnQgdW5kZXJzdGFu ZGluZ3MgZm9yDQo+ID4+Pj4+IGRpZmZlcmVudCBwZW9wbGUsIHNvbWUgcGVvcGxlIHRoaW5rIGl0 IGFzIGEgc2VydmljZSB3aGlsZSBvdGhlcnMgdGhpbmsNCj4gPj4+Pj4gaXQgYXMgYSBjb25jcmV0 ZSB0ZWNobm9sb2d5LCBlc3BlY2lhbGx5IHVzaW5nIFBXcy4gSGVyZSwgdGhlICJWUExTIiBpcw0K PiA+Pj4+PiBkZWVtZWQgYXMgYSBWUExTIHNlcnZpY2UuIElmIHRoZSBXRyBjb25zZW5zdXMgaXMg dGhhdCAiVlBMUyIgc2hvdWxkIGJlDQo+ID4+Pj4+IHRha2VuIGFzIGEgY29uY3JldGUgdGVjaG5v bG9neSwgSSBoYXZlIG5vIG9iamVjdGlvbiB0byB1c2luZyBhbm90aGVyDQo+IHRlcm0uDQo+ID4+ Pj4+DQo+ID4+Pj4+IEFzIHNhaWQgaW4gdGhlIElTLUlTIFZQTFMgZHJhZnQsIElTLUlTIFZQTFMg aXMgaW50ZW5kZWQgdG8gYmUgYQ0KPiA+Pj4+PiBsaWdodC13ZWlnaHQgVlBMUyBzb2x1dGlvbiB3 aGljaCBjYW4gbWVldCBzb21lIERDIG9wZXJhdG9ycycNCj4gPj4+Pj4gcmVxdWlyZW1lbnRzIGZv ciBzaW1wbGljaXR5LiBJIGRvbid0IHdhbnQgdG8gYXJndWUgaW4gdGhpcyBtYWlsaW5nLWxpc3QN Cj4gPj4+Pj4gd2hldGhlciBCR1AtYmFzZWQgTDJWUE4gc29sdXRpb25zIGNvdWxkIG1lZXQgd2Vs bCB0aGUgcmVxdWlyZW1lbnRzDQo+ID4+IGZyb20NCj4gPj4+Pj4gYWxsIERDIG9wZXJhdG9ycy4g SSBwZXJzb25hbGx5IGJlbGlldmUgdGhhdCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gYXNrDQo+ID4+ Pj4+IHRoaXMgcXVlc3Rpb24gdG8gTlZvMy4gSW4gYWRkaXRpb24sIGFjY29yZGluZyB0byB0b2Rh eSdzIHByZXNlbnRhdGlvbiBvZg0KPiA+Pj4+PiBFLVZQTiwgSSB0aGluayBFLVZQTiBjby1hdXRo b3JzIGFsc28gYWRtaXQgdGhhdCB0aGUgZXhpdGluZyBFVlBODQo+ID4+Pj4+IHNvbHV0aW9uIHNl ZW1zIGNvbXBsZXggdG8gc29tZSBEQyBvcGVyYXRvcnMuIElmIG15IHVuZGVyc3RhbmRpbmcgaXMN Cj4gPj4+Pj4gd3JvbmcsIHBscyBjb3JyZWN0IG1lLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJZiBJIHJl bWVtYmVyZWQgY29ycmVjdGx5LCBMMVZQTiBhbHNvIGhhcyB0d28gUkZDcyB1c2luZyBJUy1JUyBh bmQgT1NQRg0KPiA+Pj4+PiBmb3IgTDFWUE4gYXV0by1kaXNjb3ZlcnksIGFsdGhvdWdoIHRoZXJl IGhhcyBiZWVuIG9uZSBzb2x1dGlvbiB1c2luZw0KPiA+Pj4+PiBCR1AuIEhlbmNlIEkgZG9uJ3Qg a25vdyB3aHkgY2FuJ3Qgd2UgaGF2ZSBhIGxpZ2h0LXdlaWdodCBMMlZQTiB1c2luZw0KPiA+PiBJ Uy1JUy4NCj4gPj4+Pj4NCj4gPj4+Pj4gQmVzdCByZWdhcmRzLA0KPiA+Pj4+Pg0KPiA+Pj4+PiBY aWFvaHUNCj4gPj4+Pj4NCj4gPj4+Pg0KPiA+DQoNCg== From sajassi@cisco.com Fri Apr 6 09:56:40 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23AF21F846B; Fri, 6 Apr 2012 09:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.102 X-Spam-Level: X-Spam-Status: No, score=-9.102 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, 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 NLxBw5GD4piY; Fri, 6 Apr 2012 09:56:39 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id A8B2C21F8463; Fri, 6 Apr 2012 09:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sajassi@cisco.com; l=12023; q=dns/txt; s=iport; t=1333731399; x=1334940999; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=jmoFa70oyIYBwN/wRfzvil0nFOYwL1RlwlmPQyaiDhg=; b=ci7XJTgrcmO7Ug6gUhqBYfngmq36+HAaW2E2DSB/gxMtTkGOjDTzUFEH CPjx80LGtELWqGa4/kVuHn+KkXzf1yFIkHSF2Ajr3L9RVAO6dGwD0SFwp RUjfvKc/ab4bpw6qZYZTZ0VANEj+aVgFG2Jay+I0wyM4kK41HX6uibZqB 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAEUff0+rRDoG/2dsb2JhbABFhW+yOHaBB4IJAQEBAwESARAZATABCwUNAQYCCQgEAQEBAgIjAwJIEQIEAQ0FFAcHh2cEAQuadY0KkmaBL4luhBuBGASIWoUsh2aBEY08gWmDB4E0CA X-IronPort-AV: E=Sophos;i="4.75,381,1330905600"; d="scan'208";a="36815673" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 06 Apr 2012 16:56:36 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q36GuaR3001698; Fri, 6 Apr 2012 16:56:36 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Apr 2012 09:56:36 -0700 Received: from 10.128.2.14 ([10.128.2.14]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Fri, 6 Apr 2012 16:56:35 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 06 Apr 2012 09:56:35 -0700 Subject: Re: Response to some comments on IS-IS VPLS From: sajassi To: Xuxiaohu , "robert@raszuk.net" , John E Drake Message-ID: Thread-Topic: Response to some comments on IS-IS VPLS Thread-Index: AQHNDauno12B0RP+lEO1DyVa7X7/s5aBlXMQgAAXd5D//5jvgIAAuvyAgACIz5mABLG/AIAEXVAwgAGyT/mAAA0+UIAAuNsy In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CE2148@szxeml525-mbs.china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 06 Apr 2012 16:56:36.0398 (UTC) FILETIME=[3A5334E0:01CD1416] Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" , "UTTARO, JAMES" X-BeenThere: l2vpn@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, 06 Apr 2012 16:56:40 -0000 Hi Xuxiaohu, In my previous email, I said " If you think, there is an area that it is no= t covered by these two sets, then you should start from there and articulate those requirements". The requirements that you have listed in your draft are "mother-hood and apple-pie" which are covered by other drafts. If there are any new requirements above and beyond the ones captured by e-vpn requirements and nov3 requirements/framework, then you should articulate what those requirements are. As, I mentioned before, your proposal is clearly outside of L2VPN charter but it may fit within NOV3 charter. If you are going to take it there, then you need to articulate what are the benefits of this proposal over the existing ones. Cheers, Ali On 4/6/12 12:08 AM, "Xuxiaohu" wrote: > Hi Ali=EF=BC=8C >=20 > I suggest you reading the latest version of IS-IS VPLS draft > (http://tools.ietf.org/html/draft-xu-l2vpn-vpls-isis-03) , especially the > first section which describes the requirements in details. I believe you = could > find the answer to your question and also find the obvious differences be= tween > IS-IS VPLS and your MVPLS once you have finished reading that draft. >=20 > Of course, if the WG consensus is to separate the requirements as an > independent draft, I could do that. >=20 > By the way, since you mentioned the requirement/framework draft for nov3 > solutions, you may have noticed that one of the control plane requirement= s > described in the requirement draft is "Do not rely on IP Multicast in the > Underlying Network " (See the section of Control Plane Characteristics), = and > you may have also noticed section 4.2.3."Handling Broadcast, Unknown Unic= ast > and Multicast (BUM) traffic" of the framework draft, which explicitly sai= d > "Depending upon the size of the data center network and hence the number = of > (S,G) entries, but also the duration of multicast flows, the use of core > multicast trees can be a challenge ". Hence I wonder whether you have any > different opinions in this regard. If no, based on the abstract of your M= VPLS > draft shown as follows, I think you would also agree that MVPLS is not a > suitable candidate solution for data center networks. >=20 > ****************************************************************** > Abstract > =20 > Virtual Private LAN Service (VPLS) is a type of Layer-2 Provi= der > Provisioned Virtual Private Network (L2 PPVPN) offered servic= e, > which=20 > has been described in [PPVPN-FRWK]. If the Service Provider > network=20 > provides IP multicast functionality, then this network capabi= lity > can=20 > be leveraged in providing very efficient VPLS service and yet > simplifying the implementation of such service. This document > describes=20 > a solution for providing VPLS service based on IP multicast > feature=20 > referred to as Multicast Virtual Private LAN Service (MVPLS). > ******************************************************************* >=20 > Best regards, > Xiaohu >=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: sajassi [mailto:sajassi@cisco.com] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B44=E6=9C=886=E6=97=A5 13:08 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; robert@raszuk.net; John E Drake >> =E6=8A=84=E9=80=81: l2vpn@ietf.org; UTTARO, JAMES >> =E4=B8=BB=E9=A2=98: Re: Response to some comments on IS-IS VPLS >>=20 >> Hi Xuxiaohu, >>=20 >> I think when we talk about a given solution, we should also talk about t= he >> framework and the requirements for which the solution is intended for. T= here >> is a requirement draft for EVPN/PBB-EVPN solution and there is also a >> requirement/framework draft for nov3 solutions. Frankly, between these t= wo >> sets of framework and their corresponding solutions, I think we are cove= ring >> host-based v.s. network-based, intraDC v.s. InterDC, as well as differe= nt >> kinds of DCs. If you think, there is an area that it is not covered by t= hese >> two sets, then you should start from there and articulate those >> requirements. >>=20 >> Cheers, >> Ali >>=20 >>=20 >> On 4/4/12 8:20 PM, "Xuxiaohu" wrote: >>=20 >>>=20 >>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: sajassi [mailto:sajassi@cisco.com] >>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B44=E6=9C=883=E6=97=A5 0:34 >>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; robert@raszuk.net; John E Drake >>>> =E6=8A=84=E9=80=81: l2vpn@ietf.org; UTTARO, JAMES >>>> =E4=B8=BB=E9=A2=98: Re: Response to some comments on IS-IS VPLS >>>>=20 >>>> Hi Xuxiaohu, >>>>=20 >>>> The draft that I wrote ten years ago (MVPLS) is analogous to VXLAN - b= oth >> do >>>> the same thing but with different IP encap. MVPLS used L2TPv3 encap (s= ince >>>> it was the encap-dejour of that time for IP :-); whereas, VXLAN uses U= DP >>>> encap. >>>>=20 >>>> Since there are already three different encap proposals in NVo3 (UDP, = GRE, >>>> and TCP), I am NOT planning to introduce yet another encap by resurrec= ting >>>> my draft. I think we should only pick a single encap among the three >>>> current >>>> proposals in NVO3. >>>=20 >>> Hi Ali, >>>=20 >>> Does that mean you also believe a simplified L2VPN approach other than >> EVPN is >>> needed for data center networks? Otherwise why do you suggest picking o= ne >>> rather than dropping them all? >>>=20 >>> Best regards, >>> Xiaohu >>>=20 >>>>=20 >>>> Cheers, >>>> Ali >>>>=20 >>>>=20 >>>> On 3/30/12 1:55 AM, "Xuxiaohu" wrote: >>>>=20 >>>>> Hi Ali, >>>>>=20 >>>>> What's your attitude to your own draft as mentioned below from today'= s >>>> point >>>>> of view? good or bad? >>>>>=20 >>>>> Best regards, >>>>> Xiaohu >>>>>=20 >>>>> ________________________________________ >>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 saj= assi >>>>> [sajassi@cisco.com] >>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B43=E6=9C=8830=E6=97=A5 16:43 >>>>> =E5=88=B0: robert@raszuk.net; John E Drake >>>>> Cc: l2vpn@ietf.org; UTTARO, JAMES >>>>> =E4=B8=BB=E9=A2=98: Re: Response to some comments on IS-IS VPLS >>>>>=20 >>>>> Hi Robert, >>>>>=20 >>>>> I won't get into the argument of whether this kind of solution is >>>>> innovation >>>>> or permutation. My point is that it is clearly outside of current L2V= PN >>>>> charter and if this kind of solution is to be pursued in L2VPN WG, th= en it >>>>> needs to be re-chartered. >>>>>=20 >>>>> Also, if we are talking about VPLS service over IP and doing MAC lear= ning >>>>> against IP addresses (as what this draft is talking about), I had a d= raft >>>>> 10 >>>>> years ago that cover this subject !! >>>>>=20 >>>>> http://tools.ietf.org/id/draft-sajassi-mvpls-00.txt >>>>>=20 >>>>> Cheers, >>>>> Ali >>>>>=20 >>>>>=20 >>>>> On 3/29/12 2:33 PM, "Robert Raszuk" wrote: >>>>>=20 >>>>>> Hi John, >>>>>>=20 >>>>>> I think you took it a little bit too far. >>>>>>=20 >>>>>> I have not heard anyone stating that current VPLS solutions suck. I = also >>>>>> did not hear anyone claiming that BGP is difficult. The claim I have >>>>>> heard is that in some environments one may not like to use BGP for V= PLS. >>>>>>=20 >>>>>> Ali's point is that current PEs will have problem supporting it as t= his >>>>>> is effectively TRILL over IP is valid from Ali's point of view. >>>>>>=20 >>>>>> However one could ask a question if IETF is still an organization to >>>>>> promote open innovation and consider new ideas (even if only in >>>>>> experimental mode) or is it just a forum to lock customers to limite= d >>>>>> set of solutions ? If it is the latter the trend to seek alternative= s to >>>>>> IETF standardization process will continue to evolve. Especially now >>>>>> when control plane separation from data plane becomes reality. >>>>>>=20 >>>>>> I see nothing wrong to allocate perhaps in experimental mode VPLS In= fo >>>>>> TLV codepoint for VPLS over ISIS or for that matter well known >>>>>> destination port for STT from IANA and let companies who are asking = for >>>>>> it develop the solutions, deploy it then report back the results to = the >>>>>> community. >>>>>>=20 >>>>>> Best, >>>>>> R. >>>>>>=20 >>>>>>=20 >>>>>>> Jim, >>>>>>>=20 >>>>>>> You are completely correct , but let=C2=B9s not overlook the fun factor= . >>>>>>> I.e., it=C2=B9s **fun** to say that everything that has gone before suc= ks and >>>>>>> that the current initiative will be =C2=B3practically perfect=C2=B2 (c.f. =C5= =92Mary >>>>>>> Poppins=C2=B9). >>>>>>>=20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> John >>>>>>>=20 >>>>>>> Sent from my iPhone >>>>>>>=20 >>>>>>> *From:*l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] *On >>>> Behalf >>>>>>> Of *UTTARO, JAMES >>>>>>> *Sent:* Thursday, March 29, 2012 11:30 AM >>>>>>> *To:* 'Xuxiaohu'; l2vpn@ietf.org >>>>>>> *Subject:* RE: Response to some comments on IS-IS VPLS >>>>>>>=20 >>>>>>> IMHO=C5=A0 I am at a bit of a loss as to the notion that BGP is so >>>>>>> overwhelmingly difficult to deal with in a data center environment.= . Why >>>>>>> is that?? BGP is being used across a wide spectrum of applications = and >>>>>>> is proven. I believe that the data center is becoming more and more= a >>>>>>> dynamic extension of a customer=C2=B9s network. I also think it would b= e >> wise >>>>>>> to anticipate the world of tomorrow where customers may expect thei= r >>>>>>> network may span multiple operators DCs. The right approach is to >>>>>>> leverage what has been done BGP and extend it where needed.. This >>>>>>> provides maximum flexibility and simplicity.. >>>>>>>=20 >>>>>>> To build solutions based on the notion that =C2=B3I don=C2=B9t like protoco= l X=C2=B2 is >>>>>>> invalid.. >>>>>>>=20 >>>>>>> Jim Uttaro >>>>>>>=20 >>>>>>> *From:*l2vpn-bounces@ietf.org >>>>>>> [mailto:l2vpn-bounces@ietf.org] *On Behalf Of *Xuxiaohu >>>>>>> *Sent:* Thursday, March 29, 2012 2:59 PM >>>>>>> *To:* l2vpn@ietf.org >>>>>>> *Subject:* Response to some comments on IS-IS VPLS >>>>>>>=20 >>>>>>> Hi all, >>>>>>>=20 >>>>>>> VPLS (Virtual Private LAN Service) has different understandings for >>>>>>> different people, some people think it as a service while others th= ink >>>>>>> it as a concrete technology, especially using PWs. Here, the "VPLS"= is >>>>>>> deemed as a VPLS service. If the WG consensus is that "VPLS" should= be >>>>>>> taken as a concrete technology, I have no objection to using anothe= r >> term. >>>>>>>=20 >>>>>>> As said in the IS-IS VPLS draft, IS-IS VPLS is intended to be a >>>>>>> light-weight VPLS solution which can meet some DC operators' >>>>>>> requirements for simplicity. I don't want to argue in this mailing-= list >>>>>>> whether BGP-based L2VPN solutions could meet well the requirements >>>> from >>>>>>> all DC operators. I personally believe that it would be better to a= sk >>>>>>> this question to NVo3. In addition, according to today's presentati= on of >>>>>>> E-VPN, I think E-VPN co-authors also admit that the exiting EVPN >>>>>>> solution seems complex to some DC operators. If my understanding is >>>>>>> wrong, pls correct me. >>>>>>>=20 >>>>>>> If I remembered correctly, L1VPN also has two RFCs using IS-IS and = OSPF >>>>>>> for L1VPN auto-discovery, although there has been one solution usin= g >>>>>>> BGP. Hence I don't know why can't we have a light-weight L2VPN usin= g >>>> IS-IS. >>>>>>>=20 >>>>>>> Best regards, >>>>>>>=20 >>>>>>> Xiaohu >>>>>>>=20 >>>>>>=20 >>>=20 >=20 From lizhong.jin@zte.com.cn Fri Apr 6 23:50:40 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF87A21F851B for ; Fri, 6 Apr 2012 23:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.485 X-Spam-Level: X-Spam-Status: No, score=-99.485 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, 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 titPmeMPecYz for ; Fri, 6 Apr 2012 23:50:39 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 37B3021F8504 for ; Fri, 6 Apr 2012 23:50:38 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 28620577109098; Sat, 7 Apr 2012 14:13:34 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 30949.6912904769; Sat, 7 Apr 2012 14:50:14 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q376oTA7049178; Sat, 7 Apr 2012 14:50:29 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: <2073A6C5467C99478898544C6EBA3F4602BED62799@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> MIME-Version: 1.0 To: "Balus, Florin Stelian (Florin)" Subject: RE: Comments of draft-ietf-l2vpn-vpls-ldp-mac-opt-05 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Sat, 7 Apr 2012 14:49:31 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-07 14:50:31, Serialize complete at 2012-04-07 14:50:31 Content-Type: multipart/alternative; boundary="=_alternative 0025954F482579D9_=" X-MAIL: mse02.zte.com.cn q376oTA7049178 Cc: "l2vpn@ietf.org" , "ostokes@extremenetworks.com" X-BeenThere: l2vpn@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: Sat, 07 Apr 2012 06:50:40 -0000 This is a multipart message in MIME format. --=_alternative 0025954F482579D9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgRmxvcmluLA0KU29ycnkgZm9yIHRoZSBsYXRlIHJlcGx5LCBwbGVhc2Ugc2VlIGlubGluZS4N Cg0KVGhhbmtzDQpMaXpob25nDQogDQoNCiJCYWx1cywgRmxvcmluIFN0ZWxpYW4gKEZsb3Jpbiki IDxmbG9yaW4uYmFsdXNAYWxjYXRlbC1sdWNlbnQuY29tPiB3cm90ZSANCjIwMTIvMDIvMTEgMDU6 NDc6MjI6DQoNCj4gTGl6aG9uZywNCj4gDQo+IEZyb206IExpemhvbmcgSmluIFttYWlsdG86bGl6 aG9uZy5qaW5AenRlLmNvbS5jbl0gDQo+IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDA3LCAyMDEy IDExOjUxIFBNDQo+IFRvOiBCYWx1cywgRmxvcmluIFN0ZWxpYW4gKEZsb3JpbikNCj4gQ2M6IGdl cmFsZGluZS5jYWx2aWduYWNAb3JhbmdlLWZ0Z3JvdXAuY29tOyBsMnZwbkBpZXRmLm9yZzsgDQo+ IG9zdG9rZXNAZXh0cmVtZW5ldHdvcmtzLmNvbTsgRHV0dGEsIFByYW5qYWwgSyAoUHJhbmphbCkN Cj4gU3ViamVjdDogUkU6IENvbW1lbnRzIG9mIGRyYWZ0LWlldGYtbDJ2cG4tdnBscy1sZHAtbWFj LW9wdC0wNQ0KPiANCj4gRmxvcmluLCANCj4gVGhhbmtzIGZvciB0aGUgcmVwbHksIHNlZSBpbmxp bmUgYmVsb3cuIA0KPiBSZWdhcmRzIA0KPiBMaXpob25nIA0KPiANCj4gIkJhbHVzLCBGbG9yaW4g U3RlbGlhbiAoRmxvcmluKSIgPGZsb3Jpbi5iYWx1c0BhbGNhdGVsLWx1Y2VudC5jb20+IA0KPiB3 cm90ZSAyMDEyLzAyLzA3IDIzOjUxOjU1Og0KPiA+IExpemhvbmcsIA0KPiA+IFNlZSBpbi1saW5l oa0gDQo+ID4gDQo+ID4gRnJvbTogTGl6aG9uZyBKaW4gW21haWx0bzpsaXpob25nLmppbkB6dGUu Y29tLmNuXSANCj4gPiBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAwNywgMjAxMiAxMjo0NSBBTQ0K PiA+IFRvOiBEdXR0YSwgUHJhbmphbCBLIChQcmFuamFsKTsgQmFsdXMsIEZsb3JpbiBTdGVsaWFu IChGbG9yaW4pOyANCj4gPiBnZXJhbGRpbmUuY2FsdmlnbmFjQG9yYW5nZS1mdGdyb3VwLmNvbTsg b3N0b2tlc0BleHRyZW1lbmV0d29ya3MuY29tDQo+ID4gQ2M6IGwydnBuQGlldGYub3JnDQo+ID4g U3ViamVjdDogQ29tbWVudHMgb2YgZHJhZnQtaWV0Zi1sMnZwbi12cGxzLWxkcC1tYWMtb3B0LTA1 IA0KPiA+IA0KPiA+IA0KPiA+IEhpIGF1dGhvcnMsIA0KPiA+IFNpbmNlIHYwNCBvZiB0aGlzIGRy YWZ0LCB0aGUgUEUtSUQgVExWIGhhcyBiZWVuIHJlbW92ZWQgYW5kIHJlcGxhY2VkDQo+ID4gYnkg TUFDIEZsdXNoIFBhcmFtZXRlcnMgVExWLiBJbiBzZWN0aW9uIDQuMS4xLCBpdCBzYXlzICJUaGUg c291cmNlIA0KPiA+IChtaW5lL21lKSBpcyBkZWZpbmVkIGVpdGhlciBhcyB0aGUgUFcgYXNzb2Np YXRlZCB3aXRoIHRoZSBMRFAgDQo+ID4gc2Vzc2lvbiBvbiB3aGljaCB0aGUgTERQIE1BQyBXaXRo ZHJhdyB3YXMgcmVjZWl2ZWQgb3Igd2l0aCB0aGUgDQo+ID4gQk1BQyhzKSBsaXN0ZWQgaW4gdGhl IEJNQUMgU3ViLVRMViIuIA0KPiA+IFRoYXQgbWVhbnMgdGhlIE1BQyBmbHVzaGluZyBhc3NvY2lh dGVkIFBXIGVuZHBvaW50IGFkZHJlc3MgaXMgZml4ZWQgDQo+ID4gd2l0aCB0aGUgc2VuZGluZyBQ RS4gDQo+ID4gSW4gc29tZSBjYXNlcywgaXQgbWF5IGJlIHVzZWZ1bCBmb3IgYSBQRSB0byBzZW5k IE1BQyB3aXRoZHJhdyB3aXRoIA0KPiA+IG90aGVyIHNvdXJjZSBlbmRwb2ludCBhZGRyZXNzIG9m IG90aGVyIFBXLiBFLmcsIGluIGEgZHVhbC1ob21lZCANCj4gPiBzY2VuYXJpbyBpbiBmaWd1cmUg NSBvZiBSRkM0NzYyLCBpZiB0aGUgUEUxLXJzIHdpdGggcHJpbWFyeSBQVyBpcyANCj4gPiBkb3du LCB0aGUgUEUzLXJzIHdpdGggc2Vjb25kYXJ5IFBXIGNvdWxkIHNlbmQgTUFDIHdpdGhkcmF3IHdp dGggUEUxLQ0KPiA+IHJzIGFkZHJlc3MsIHRvIHRlbGwgb3RoZXIgUEUtcnMgdG8gZmx1c2ggYWxs IE1BQyBhZGRyZXNzIGZyb20gUEUxLXJzLiANCj4gPiANCj4gPiBGQj4gSWYgUEUxLXJzIGlzIGRv d24gdGhlIG90aGVyIFBFcyBpbiB0aGUgbWVzaCB3aWxsIGtub3cgYWJvdXQgaXQgDQo+ID4gaW4g YSBudW1iZXIgb2Ygd2F5czogdGhlaXIgdHVubmVsL1BXIHRvIFBFMS1ycyB3aWxsIGJlIGRvd24v bmV4dGhvcCANCj4gPiB0cmFja2luZyAoSUdQKSB3aWxsIGluZGljYXRlIFBFMS1ycyBpcyBnb25l IGV0Y6GtIEFzIGEgcmVzdWx0IA0KPiA+IGV2ZXJ5Ym9keSB3aWxsIGZsdXNoIHRoZWlyIE1BQyBh ZGRyZXNzZXMgZnJvbSBQRTEgYW55aG93LiBJZiBhbm90aGVyDQo+ID4gUEUgc2VuZHMgdGhlIE1B QyBGbHVzaCBpdCB3aWxsIGluY3JlYXNlIHRoZSBmbG9vZGluZyB0aW1lIGJ5IGRvaW5nIA0KPiA+ IGFuIHVubmVjZXNzYXJ5IHNlY29uZCBmbHVzaC4gDQo+IFtMaXpob25nXSBUaGUgcHJlY29uZGl0 aW9uIGlzIHRoYXQgdGhlcmUgaXMgT0FNIHJ1bm5pbmcgYmV0d2VlbiBQRTEtDQo+IHJzIGFuZCBv dGhlciBQRXMuIElmIHRoZXJlIGlzIG5vIE9BTSwgaXQgaGFzIHRvIHJlbHkgb24gTERQIHNlc3Np b24gDQo+IHRpbWVvdXQgb3IgSUdQIGNvbnZlcmdlbmNlIHdoaWNoIG1heWJlIGEgYml0IHNsb3cu IEluIG1hbnkgY2FzZXMsIA0KPiBQRTMtcnMgd2lsbCBrbm93IHRoZSBmYWlsdXJlIG9mIHByaW1h cnkgUFcgZmFzdGVyIHRoYW4gb3RoZXIgUEUtcnMuIA0KPiBXaGF0J3MgbW9yZSwgaW4gUkZDNDc2 MiwgUEUzLXJzIHdpbGwgYWx3YXlzIHNlbmQgTUFDIHdpdGhkcmF3IHdpdGggDQo+IGVtcHR5IE1B QyBsaXN0IHdoYXRldmVyIFBFMS1ycyBpcyBkb3duIG9yIG5vdCAoUEUzLXJzIHdpbGwgc2VuZCAN Cj4gd2l0aGRyYXcgd2hlbiBzZWNvbmQgUFcgZnJvbSBzdGFuZGJ5IHRvIGFjdGl2ZSksIHdoaWNo IHdvcnNlIHRoZSANCnNpdHVhdGlvbi4gDQo+IEZCPkkgdGhpbmsgeW91IGFyZSBzYXlpbmcgdGhh dCB0aGVyZSB3aWxsIGJlIHByb2JsZW1zIGlmIGJvdGggTUFDIA0KPiBXaXRoZHJhdyBiZWhhdmlv cnMgYXJlIGFjdGl2ZSB3aGljaCBpcyB0cnVlLiBEZWZpbml0ZWx5IG9ubHkgb25lIA0KPiB0eXBl IG9mIE1BQyBXaXRoZHJhdyBzaG91bGQgYmUgdXNlZCBmb3IgYSBjZXJ0YWluIE11bHRpLWhvbWlu ZyANCj4gcmVsYXRpb24uIFdlIGhhdmUgdGhlIHBvc2l0aXZlL25lZ2F0aXZlIGZsYWcgaW5kaWNh dGlvbiB0byANCj4gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIHRoZW0uIFRoZSBwcm9jZWR1cmUgaW4g UkZDIDQ3NjIgaXMgdGhlIGRlZmF1bHQNCj4gb25lLCB0aGUgbmVnYXRpdmUgTUFDIEZsdXNoIGNh biBiZSBhY3RpdmF0ZWQgYXMgYW4gYWx0ZXJuYXRpdmUuIA0KW0xpemhvbmddIGRyYWZ0LWlldGYt bDJ2cG4tdnBscy1sZHAtbWFjLW9wdCBkb2VzIG5vdCBzYXkgYW55dGhpbmcgYWJvdXQgDQp0aGUg TUFDIHdpdGhkcmF3IGNhcGFiaWxpdHkgbmVnb3RpYXRpb24uIEluIENFIG11bHRpaG9taW5nIHNj ZW5hcmlvLCBib3RoIA0KUEVzIHdpbGwgc2VuZCBNQUMgd2l0aGRyYXcgbWVzc2FnZS4gDQpkcmFm dC1saXUtbDJ2cG4tdnBscy1pbnRlci1kb21haW4tcmVkdW5kYW5jeSBkZWZpbmVzIHRoZSBNQUMg d2l0aGRyYXcgDQpjYXBhYmlsaXR5IG5lZ290aWF0aW9uIGluIElDQ1AgY2FzZS4gT25lIG1vcmUg YmVuZWZpdCBvZiBuZWdhdGl2ZSBNQUMgDQpGbHVzaCB3aXRoIFBFLUlEIFRMViBpcyB3aGVuIFBF MS1ycyBkb2VzIG5vdCBzdXBwb3J0IG5lZ2F0aXZlIGNhcGFiaWxpdHksIA0KdGhlbiBQRTMtcnMg Y291bGQgc2VuZCBuZWdhdGl2ZSBNQUMgd2l0aGRyYXcgd2l0aCBQRTEtcnMgSUQgVExWLCB0byAN Cm9wdGltaXplIE1BQyBmbHVzaC4NCg0KPiANCj4gT25lIG1vcmUgdXNlZnVsIHNjZW5hcmlvIGlz IENFIG11bHRpaG9taW5nIHdpdGggSUNDUCBkZXBsb3llZCwgdGhlIA0KPiBzdGFuZGJ5IFBFIHdv dWxkIGtub3cgdGhlIHByaW1hcnkgUEUgZmFpbHVyZSBmYXN0ZXIgdGhhbiBvdGhlciBQRSwgDQo+ IGFuZCBpdCB3b3VsZCBiZSBiZXR0ZXIgZm9yIG9yaWdpbmFsIHN0YW5kYnkgUEUgdG8gc2VuZCBN QUMgd2l0aGRyYXcgDQo+IHdpdGggZmFpbGVkIFBFIGFkZHJlc3MsIGluc3RlYWQgb2YgTUFDIHdp dGhkcmF3IHdpdGggZW1wdHkgbGlzdC4gDQo+IEZCPiBXaGV0aGVyIGl0IGlzIGZhc3RlciBvciBu b3QgZGVwZW5kcyByZWFsbHkgb24gd2hpY2ggZmFpbHVyZSANCj4gc2NlbmFyaW9zIGFyZSBjb25z aWRlcmVkIHRoZSBtb3N0IGNvbW1vbi4gSWYgdGhlIGFjdGl2ZSBsaW5rIGZhaWxzIA0KPiB0aGUg UEUgdGhhdCBvd25zIHRoZSBmYWlsZWQgbGluayB3aWxsIGtub3cgcmlnaHQgYXdheSBzbyB0aGUg Y3VycmVudA0KPiBwcm9jZWR1cmUgaW4gdGhlIGRyYWZ0IGlzIGZhc3Rlci4gVGhpcyB3YXMgb25l IG9mIHRoZSB1c2UgY2FzZXMgSSANCj4gaGVhcmQgbW9yZSBvZnRlbiBqdXN0aWZ5aW5nIHRoZSBu ZWVkIGZvciBuZWdhdGl2ZSBNQUMgRmx1c2guIEV2ZW4gaW4NCj4gdGhlIFBFIGZhaWx1cmUgY2Fz ZSB0aGUgbmV4dCBob3AgdHJhY2tpbmcgaW4gSUdQIGNhbiBiZSBxdWl0ZSBmYXN0LCANCj4gbm90 IHRvIHNwZWFrIGFib3V0IE9BTSBDQ01zLiANCltMaXpob25nXSBJR1AgdHJhY2tpbmcgaXMgbm90 IGFsd2F5cyB0aGVyZSwgZXNwZWNpYWxseSBpbiBNUExTLVRQIG5ldHdvcmsgDQppbiBiYWNraGF1 bC4gVGFrZSB0aGUgc2NlbmFyaW8gaW4gDQpkcmFmdC1saXUtbDJ2cG4tdnBscy1pbnRlci1kb21h aW4tcmVkdW5kYW5jeSBmb3IgZXhhbXBsZSwgdXN1YWxseSBCRkQgd2lsbCANCmJlIGRlcGxveWVk IGJldHdlZW4gYWN0aXZlIGFuZCBzdGFuZGJ5IFBFLCBhbmQgc3RhbmRieSBQRSB3b3VsZCBzZW5z ZSB0aGUgDQpmYWlsdXJlIG9mIGFjdGl2ZSBQRSBtdWNoIGZhc3Rlci4gTW9yZW92ZXIsIHdoYXQg aWYgdGhlIG9yaWdpbmFsIGFjdGl2ZSBQRSANCmRvZXMgbm90IHN1cHBvcnQgbmVnYXRpdmUgY2Fw YWJpbGl0eSwgdGhlbiBsZXQgdGhlIG9yaWdpbmFsIHN0YW5kYnkgUEUgdG8gDQpzZW5kIG5lZ2F0 aXZlIE1BQyB3aXRoZHJhdyB3aXRoIFBFLUlEIFRMViB3b3VsZCBvcHRpbWl6ZSBNQUMgZmx1c2gu DQoNCj4gPiANCj4gPiANCj4gPiBIb3BlIHRvIHNlZSB5b3VyIGNvbW1lbnRzLiANCj4gPiANCj4g PiBUaGFua3MgDQo+ID4gTGl6aG9uZyANCj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4gDQo= --=_alternative 0025954F482579D9_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEZsb3Jpbiw8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNvcnJ5IGZvciB0aGUgbGF0ZSByZXBs eSwgcGxlYXNlIHNlZQ0KaW5saW5lLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+VGhhbmtzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5MaXpob25nPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+Jm5i c3A7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+JnF1b3Q7QmFsdXMsIEZsb3Jp biBTdGVsaWFuIChGbG9yaW4pJnF1b3Q7ICZsdDtmbG9yaW4uYmFsdXNAYWxjYXRlbC1sdWNlbnQu Y29tJmd0Ow0Kd3JvdGUgMjAxMi8wMi8xMSAwNTo0NzoyMjo8YnI+DQo8YnI+DQomZ3Q7IExpemhv bmcsPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZuYnNwOzwvdHQ+PC9m b250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBGcm9tOiBMaXpob25nIEppbiBbbWFpbHRv OmxpemhvbmcuamluQHp0ZS5jb20uY25dDQo8YnI+DQomZ3Q7IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1 YXJ5IDA3LCAyMDEyIDExOjUxIFBNPGJyPg0KJmd0OyBUbzogQmFsdXMsIEZsb3JpbiBTdGVsaWFu IChGbG9yaW4pPGJyPg0KJmd0OyBDYzogZ2VyYWxkaW5lLmNhbHZpZ25hY0BvcmFuZ2UtZnRncm91 cC5jb207IGwydnBuQGlldGYub3JnOyA8YnI+DQomZ3Q7IG9zdG9rZXNAZXh0cmVtZW5ldHdvcmtz LmNvbTsgRHV0dGEsIFByYW5qYWwgSyAoUHJhbmphbCk8YnI+DQomZ3Q7IFN1YmplY3Q6IFJFOiBD b21tZW50cyBvZiBkcmFmdC1pZXRmLWwydnBuLXZwbHMtbGRwLW1hYy1vcHQtMDU8L3R0PjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgPGJyPg0KJmd0OyBGbG9yaW4sIDxicj4NCiZn dDsgVGhhbmtzIGZvciB0aGUgcmVwbHksIHNlZSBpbmxpbmUgYmVsb3cuIDxicj4NCiZndDsgUmVn YXJkcyA8YnI+DQomZ3Q7IExpemhvbmcgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZxdW90O0JhbHVz LCBGbG9yaW4gU3RlbGlhbiAoRmxvcmluKSZxdW90OyAmbHQ7ZmxvcmluLmJhbHVzQGFsY2F0ZWwt bHVjZW50LmNvbSZndDsNCjxicj4NCiZndDsgd3JvdGUgMjAxMi8wMi8wNyAyMzo1MTo1NTo8YnI+ DQomZ3Q7ICZndDsgTGl6aG9uZywgPGJyPg0KJmd0OyAmZ3Q7IFNlZSBpbi1saW5loa0gPGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgRnJvbTogTGl6aG9uZyBKaW4gW21haWx0 bzpsaXpob25nLmppbkB6dGUuY29tLmNuXSA8YnI+DQomZ3Q7ICZndDsgU2VudDogVHVlc2RheSwg RmVicnVhcnkgMDcsIDIwMTIgMTI6NDUgQU08YnI+DQomZ3Q7ICZndDsgVG86IER1dHRhLCBQcmFu amFsIEsgKFByYW5qYWwpOyBCYWx1cywgRmxvcmluIFN0ZWxpYW4gKEZsb3Jpbik7DQo8YnI+DQom Z3Q7ICZndDsgZ2VyYWxkaW5lLmNhbHZpZ25hY0BvcmFuZ2UtZnRncm91cC5jb207IG9zdG9rZXNA ZXh0cmVtZW5ldHdvcmtzLmNvbTxicj4NCiZndDsgJmd0OyBDYzogbDJ2cG5AaWV0Zi5vcmc8YnI+ DQomZ3Q7ICZndDsgU3ViamVjdDogQ29tbWVudHMgb2YgZHJhZnQtaWV0Zi1sMnZwbi12cGxzLWxk cC1tYWMtb3B0LTA1IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyBIaSBhdXRob3JzLCA8YnI+DQomZ3Q7ICZndDsgU2luY2UgdjA0IG9mIHRoaXMg ZHJhZnQsIHRoZSBQRS1JRCBUTFYgaGFzIGJlZW4gcmVtb3ZlZCBhbmQgcmVwbGFjZWQ8YnI+DQom Z3Q7ICZndDsgYnkgTUFDIEZsdXNoIFBhcmFtZXRlcnMgVExWLiBJbiBzZWN0aW9uIDQuMS4xLCBp dCBzYXlzICZxdW90O1RoZQ0Kc291cmNlIDxicj4NCiZndDsgJmd0OyAobWluZS9tZSkgaXMgZGVm aW5lZCBlaXRoZXIgYXMgdGhlIFBXIGFzc29jaWF0ZWQgd2l0aCB0aGUgTERQDQo8YnI+DQomZ3Q7 ICZndDsgc2Vzc2lvbiBvbiB3aGljaCB0aGUgTERQIE1BQyBXaXRoZHJhdyB3YXMgcmVjZWl2ZWQg b3Igd2l0aCB0aGUNCjxicj4NCiZndDsgJmd0OyBCTUFDKHMpIGxpc3RlZCBpbiB0aGUgQk1BQyBT dWItVExWJnF1b3Q7LiA8YnI+DQomZ3Q7ICZndDsgVGhhdCBtZWFucyB0aGUgTUFDIGZsdXNoaW5n IGFzc29jaWF0ZWQgUFcgZW5kcG9pbnQgYWRkcmVzcyBpcw0KZml4ZWQgPGJyPg0KJmd0OyAmZ3Q7 IHdpdGggdGhlIHNlbmRpbmcgUEUuIDxicj4NCiZndDsgJmd0OyBJbiBzb21lIGNhc2VzLCBpdCBt YXkgYmUgdXNlZnVsIGZvciBhIFBFIHRvIHNlbmQgTUFDIHdpdGhkcmF3DQp3aXRoIDxicj4NCiZn dDsgJmd0OyBvdGhlciBzb3VyY2UgZW5kcG9pbnQgYWRkcmVzcyBvZiBvdGhlciBQVy4gRS5nLCBp biBhIGR1YWwtaG9tZWQNCjxicj4NCiZndDsgJmd0OyBzY2VuYXJpbyBpbiBmaWd1cmUgNSBvZiBS RkM0NzYyLCBpZiB0aGUgUEUxLXJzIHdpdGggcHJpbWFyeSBQVw0KaXMgPGJyPg0KJmd0OyAmZ3Q7 IGRvd24sIHRoZSBQRTMtcnMgd2l0aCBzZWNvbmRhcnkgUFcgY291bGQgc2VuZCBNQUMgd2l0aGRy YXcgd2l0aA0KUEUxLTxicj4NCiZndDsgJmd0OyBycyBhZGRyZXNzLCB0byB0ZWxsIG90aGVyIFBF LXJzIHRvIGZsdXNoIGFsbCBNQUMgYWRkcmVzcyBmcm9tDQpQRTEtcnMuIDxicj4NCiZndDsgJmd0 OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IEZCJmd0OyBJZiBQRTEtcnMgaXMgZG93biB0aGUgb3Ro ZXIgUEVzIGluIHRoZSBtZXNoIHdpbGwga25vdw0KYWJvdXQgaXQgPGJyPg0KJmd0OyAmZ3Q7IGlu IGEgbnVtYmVyIG9mIHdheXM6IHRoZWlyIHR1bm5lbC9QVyB0byBQRTEtcnMgd2lsbCBiZSBkb3du L25leHRob3ANCjxicj4NCiZndDsgJmd0OyB0cmFja2luZyAoSUdQKSB3aWxsIGluZGljYXRlIFBF MS1ycyBpcyBnb25lIGV0Y6GtIEFzIGEgcmVzdWx0DQo8YnI+DQomZ3Q7ICZndDsgZXZlcnlib2R5 IHdpbGwgZmx1c2ggdGhlaXIgTUFDIGFkZHJlc3NlcyBmcm9tIFBFMSBhbnlob3cuIElmDQphbm90 aGVyPGJyPg0KJmd0OyAmZ3Q7IFBFIHNlbmRzIHRoZSBNQUMgRmx1c2ggaXQgd2lsbCBpbmNyZWFz ZSB0aGUgZmxvb2RpbmcgdGltZSBieQ0KZG9pbmcgPGJyPg0KJmd0OyAmZ3Q7IGFuIHVubmVjZXNz YXJ5IHNlY29uZCBmbHVzaC4gPGJyPg0KJmd0OyBbTGl6aG9uZ10gVGhlIHByZWNvbmRpdGlvbiBp cyB0aGF0IHRoZXJlIGlzIE9BTSBydW5uaW5nIGJldHdlZW4gUEUxLTxicj4NCiZndDsgcnMgYW5k IG90aGVyIFBFcy4gSWYgdGhlcmUgaXMgbm8gT0FNLCBpdCBoYXMgdG8gcmVseSBvbiBMRFAgc2Vz c2lvbg0KPGJyPg0KJmd0OyB0aW1lb3V0IG9yIElHUCBjb252ZXJnZW5jZSB3aGljaCBtYXliZSBh IGJpdCBzbG93LiBJbiBtYW55IGNhc2VzLA0KPGJyPg0KJmd0OyBQRTMtcnMgd2lsbCBrbm93IHRo ZSBmYWlsdXJlIG9mIHByaW1hcnkgUFcgZmFzdGVyIHRoYW4gb3RoZXIgUEUtcnMuDQo8YnI+DQom Z3Q7IFdoYXQncyBtb3JlLCBpbiBSRkM0NzYyLCBQRTMtcnMgd2lsbCBhbHdheXMgc2VuZCBNQUMg d2l0aGRyYXcgd2l0aA0KPGJyPg0KJmd0OyBlbXB0eSBNQUMgbGlzdCB3aGF0ZXZlciBQRTEtcnMg aXMgZG93biBvciBub3QgKFBFMy1ycyB3aWxsIHNlbmQgPGJyPg0KJmd0OyB3aXRoZHJhdyB3aGVu IHNlY29uZCBQVyBmcm9tIHN0YW5kYnkgdG8gYWN0aXZlKSwgd2hpY2ggd29yc2UgdGhlIHNpdHVh dGlvbi4NCjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBGQiZndDtJIHRo aW5rIHlvdSBhcmUgc2F5aW5nIHRoYXQgdGhlcmUgd2lsbA0KYmUgcHJvYmxlbXMgaWYgYm90aCBN QUMgPGJyPg0KJmd0OyBXaXRoZHJhdyBiZWhhdmlvcnMgYXJlIGFjdGl2ZSB3aGljaCBpcyB0cnVl LiBEZWZpbml0ZWx5IG9ubHkgb25lIDxicj4NCiZndDsgdHlwZSBvZiBNQUMgV2l0aGRyYXcgc2hv dWxkIGJlIHVzZWQgZm9yIGEgY2VydGFpbiBNdWx0aS1ob21pbmcgPGJyPg0KJmd0OyByZWxhdGlv bi4gV2UgaGF2ZSB0aGUgcG9zaXRpdmUvbmVnYXRpdmUgZmxhZyBpbmRpY2F0aW9uIHRvIDxicj4N CiZndDsgZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIHRoZW0uIFRoZSBwcm9jZWR1cmUgaW4gUkZDIDQ3 NjIgaXMgdGhlIGRlZmF1bHQ8YnI+DQomZ3Q7IG9uZSwgdGhlIG5lZ2F0aXZlIE1BQyBGbHVzaCBj YW4gYmUgYWN0aXZhdGVkIGFzIGFuIGFsdGVybmF0aXZlLiA8L3R0PjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTI+PHR0PltMaXpob25nXSBkcmFmdC1pZXRmLWwydnBuLXZwbHMtbGRwLW1hYy1vcHQg ZG9lcyBub3QNCnNheSBhbnl0aGluZyBhYm91dCB0aGUgTUFDIHdpdGhkcmF3IGNhcGFiaWxpdHkg bmVnb3RpYXRpb24uIEluIENFIG11bHRpaG9taW5nDQpzY2VuYXJpbywgYm90aCBQRXMgd2lsbCBz ZW5kIE1BQyB3aXRoZHJhdyBtZXNzYWdlLiBkcmFmdC1saXUtbDJ2cG4tdnBscy1pbnRlci1kb21h aW4tcmVkdW5kYW5jeQ0KZGVmaW5lcyB0aGUgTUFDIHdpdGhkcmF3IGNhcGFiaWxpdHkgbmVnb3Rp YXRpb24gaW4gSUNDUCBjYXNlLiBPbmUgbW9yZQ0KYmVuZWZpdCBvZiBuZWdhdGl2ZSBNQUMgRmx1 c2ggd2l0aCBQRS1JRCBUTFYgaXMgd2hlbiBQRTEtcnMgZG9lcyBub3Qgc3VwcG9ydA0KbmVnYXRp dmUgY2FwYWJpbGl0eSwgdGhlbiBQRTMtcnMgY291bGQgc2VuZCBuZWdhdGl2ZSBNQUMgd2l0aGRy YXcgd2l0aA0KUEUxLXJzIElEIFRMViwgdG8gb3B0aW1pemUgTUFDIGZsdXNoLjwvdHQ+PC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyA8YnI+DQomZ3Q7IE9uZSBtb3JlIHVz ZWZ1bCBzY2VuYXJpbyBpcyBDRSBtdWx0aWhvbWluZyB3aXRoIElDQ1AgZGVwbG95ZWQsIHRoZQ0K PGJyPg0KJmd0OyBzdGFuZGJ5IFBFIHdvdWxkIGtub3cgdGhlIHByaW1hcnkgUEUgZmFpbHVyZSBm YXN0ZXIgdGhhbiBvdGhlciBQRSwNCjxicj4NCiZndDsgYW5kIGl0IHdvdWxkIGJlIGJldHRlciBm b3Igb3JpZ2luYWwgc3RhbmRieSBQRSB0byBzZW5kIE1BQyB3aXRoZHJhdw0KPGJyPg0KJmd0OyB3 aXRoIGZhaWxlZCBQRSBhZGRyZXNzLCBpbnN0ZWFkIG9mIE1BQyB3aXRoZHJhdyB3aXRoIGVtcHR5 IGxpc3QuIDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBGQiZndDsgV2hl dGhlciBpdCBpcyBmYXN0ZXIgb3Igbm90IGRlcGVuZHMgcmVhbGx5DQpvbiB3aGljaCBmYWlsdXJl IDxicj4NCiZndDsgc2NlbmFyaW9zIGFyZSBjb25zaWRlcmVkIHRoZSBtb3N0IGNvbW1vbi4gSWYg dGhlIGFjdGl2ZSBsaW5rIGZhaWxzDQo8YnI+DQomZ3Q7IHRoZSBQRSB0aGF0IG93bnMgdGhlIGZh aWxlZCBsaW5rIHdpbGwga25vdyByaWdodCBhd2F5IHNvIHRoZSBjdXJyZW50PGJyPg0KJmd0OyBw cm9jZWR1cmUgaW4gdGhlIGRyYWZ0IGlzIGZhc3Rlci4gVGhpcyB3YXMgb25lIG9mIHRoZSB1c2Ug Y2FzZXMgSQ0KPGJyPg0KJmd0OyBoZWFyZCBtb3JlIG9mdGVuIGp1c3RpZnlpbmcgdGhlIG5lZWQg Zm9yIG5lZ2F0aXZlIE1BQyBGbHVzaC4gRXZlbg0KaW48YnI+DQomZ3Q7IHRoZSBQRSBmYWlsdXJl IGNhc2UgdGhlIG5leHQgaG9wIHRyYWNraW5nIGluIElHUCBjYW4gYmUgcXVpdGUgZmFzdCwNCjxi cj4NCiZndDsgbm90IHRvIHNwZWFrIGFib3V0IE9BTSBDQ01zLiA8L3R0PjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTI+PHR0PltMaXpob25nXSBJR1AgdHJhY2tpbmcgaXMgbm90IGFsd2F5cyB0aGVy ZSwgZXNwZWNpYWxseQ0KaW4gTVBMUy1UUCBuZXR3b3JrIGluIGJhY2toYXVsLiBUYWtlIHRoZSBz Y2VuYXJpbyBpbiBkcmFmdC1saXUtbDJ2cG4tdnBscy1pbnRlci1kb21haW4tcmVkdW5kYW5jeQ0K Zm9yIGV4YW1wbGUsIHVzdWFsbHkgQkZEIHdpbGwgYmUgZGVwbG95ZWQgYmV0d2VlbiBhY3RpdmUg YW5kIHN0YW5kYnkgUEUsDQphbmQgc3RhbmRieSBQRSB3b3VsZCBzZW5zZSB0aGUgZmFpbHVyZSBv ZiBhY3RpdmUgUEUgbXVjaCBmYXN0ZXIuIE1vcmVvdmVyLA0Kd2hhdCBpZiB0aGUgb3JpZ2luYWwg YWN0aXZlIFBFIGRvZXMgbm90IHN1cHBvcnQgbmVnYXRpdmUgY2FwYWJpbGl0eSwgdGhlbg0KbGV0 IHRoZSBvcmlnaW5hbCBzdGFuZGJ5IFBFIHRvIHNlbmQgbmVnYXRpdmUgTUFDIHdpdGhkcmF3IHdp dGggUEUtSUQgVExWDQp3b3VsZCBvcHRpbWl6ZSBNQUMgZmx1c2guPC90dD48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yPjx0dD48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyBIb3BlIHRvIHNlZSB5b3VyIGNvbW1lbnRzLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7IFRoYW5rcyA8YnI+DQomZ3Q7ICZndDsgTGl6aG9uZyA8YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZu YnNwOyA8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7PC90dD48 L2ZvbnQ+DQo= --=_alternative 0025954F482579D9_=-- From Alexander.Vainshtein@ecitele.com Sat Apr 7 22:24:58 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A7D21F85A7 for ; Sat, 7 Apr 2012 22:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, 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 CiNzkogJI8nZ for ; Sat, 7 Apr 2012 22:24:58 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 2C90021F85C5 for ; Sat, 7 Apr 2012 22:24:56 -0700 (PDT) Received: from [85.158.139.83:29812] by server-7.bemta-5.messagelabs.com id 17/7C-16195-721218F4; Sun, 08 Apr 2012 05:24:55 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1333862695!22805223!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.7; banners=-,-,- Received: (qmail 6450 invoked from network); 8 Apr 2012 05:24:55 -0000 Received: from unknown (HELO fridlpvsb003.ecitele.com) (168.87.1.157) by server-15.tower-182.messagelabs.com with SMTP; 8 Apr 2012 05:24:55 -0000 X-AuditID: a8571403-b7f566d0000048f9-b2-4f8121215e6a Received: from FRIDWPPCH001.ecitele.com (fridwppch001.ecitele.com [10.1.16.52]) by fridlpvsb003.ecitele.com (Symantec Messaging Gateway) with SMTP id 50.04.18681.121218F4; Sun, 8 Apr 2012 07:24:49 +0200 (CEST) Received: from FRIDWPPMB002.ecitele.com ([169.254.4.167]) by FRIDWPPCH001.ecitele.com ([10.1.16.52]) with mapi id 14.01.0339.001; Sun, 8 Apr 2012 07:24:54 +0200 From: Alexander Vainshtein To: "l2vpn@ietf.org" Subject: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNFUfavCW4Idac1kehO7tUxP5nzA== Date: Sun, 8 Apr 2012 05:24:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.2] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA02031CCDFRIDWPPMB002ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3WTfUgTYRzHfXbzvJYX55ztcfRyXhllbcysNGj2IkH7QyYlWEHYuXvcjrbb 2k3RCJq0NKywqECFqNBMtFKsJOjNZlr5jxZGEb1o9oJWEhWaEtE9HJoQ3V/f5/f9/L73u7vf UYS+nzRRohREAYn3cKROqwNRJnNSUpnD+qE8PWNoLBKzAWypr5/Q5ICdIbCOlyRfkA8iVkCy 08blBMRi3lnKsaJg41I51u/hnciLpKCN4/1+JAlcpo7951qnYKLEIsnpE0TJZePs2xzmjIzV a82pXGauW5RZZPbyoof1IlnmXYhVKnhGSdh9hXCHOkZJf4ep5OHnIzEhcMhYCSgKMqtge1Ny JZilyLmw73ULWQl0lJ7pB7C7tQuoh3oAH5x5G4MpkrHBtuZXJG42MMnwZliHGYIZBPDmxQEC M/EKc6yuX4u1gdkEh1/UESpvgdfa47HUMovhs5PLMEEz2fDxy9sk1kCZYbznkgZrgjHCF+/O atTZGFh/q5dQdQIcHvodreqF8Or1oWiV98GBO2dJNTMOPqp5p1WZRHiv8bn2ODDUzoitndFS O6NFrVvg89OnSFUvhw3nPxGqNsPq3xHtzPo5ENMEYGFAFDz+YrnAak2zIKcYRB5kcfq8bUBZ jcY8A3ED/KiyRABDAS6WHrwRcuij+WK51BsBiZSGS6An55c59HMKfEKpm5fd+YEiD5IjAFIE Z6DfdCo4LfCl+1DAN2VtVt7hCcI02+nDHziYn2a1/v/AGemWrZkOPeNSVnAPQn4UmMqZR1Ec pAVWuX1cALlQSaHoCf61NdQsPEasMkY2ZmjZz3tl0aX6PSDRZKS92GCw4S6SpntHgFF52Hh6 BXZjlTWc7hpRAjVK4P6RAzhQ+S2mLVMI6Ea/Is+OnMvhws6lVZO3it7/yF2ZnpVXbd2+a6N9 TY3RMvCkSxq/800bl3ahd02YSjm8b0l7w6+PYl3+U4s9r69na8Kge/6XrEX7m1qTny4orw2X JR3+HB7N9kfNHax41VycMdbbXdF731FQcbBwr6XazpQtsE+sv3z38fDR7yVVPzmt7OZTU4iA zP8BXEa7WecDAAA= Cc: Mishael Wexler , Andrew Sergeev , Idan Kaspit , Vladimir Kleiner , Rotem Cohen X-BeenThere: l2vpn@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: Sun, 08 Apr 2012 05:24:58 -0000 --_000_F9336571731ADE42A5397FC831CEAA02031CCDFRIDWPPMB002ecite_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Hi all, Unfortunately I have not been able to attend the Paris IETF. However, looking up the L2VPN proceedings, I've found a short anonymous pres= entation called "E-Tree Update" (http://www.ietf.org/proceedings/83/slides/= slides-83-l2vpn-1.pptx). This presentation discusses the differences of the= E-Tree approaches based on dedicated VLANs (as in http://datatracker.ietf.o= rg/doc/draft-cao-l2vpn-vpls-etree/?include_text=3D1) and multiple PWs betwee= n the PEs (as in http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multi= ple-pw/?include_text=3D1) and completely ignores the solution based on usage= of the CW in the PWs connecting the PEs (as in http://datatracker.ietf.org/= doc/draft-key-l2vpn-vpls-etree/?include_text=3D1). The Minutes of the Paris L2VPN session are not yet available, but I wonder w= hether the WG has taken a decision to reject the approach based on the CW us= age? I do not remember any recent discussion of this topic on the WG mailing= list. Regards, and lots of thanks in advance, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA02031CCDFRIDWPPMB002ecite_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable

Hi all,

Unfortunately I have not been able to attend the Paris IETF.<= /p>

However, looking up the L2VPN proceedings, I've found a short anonymous p= resentation called "E-Tree Update"  (http://www.ietf.org/pro= ceedings/83/slides/slides-83-l2vpn-1.pptx). This presentation discusses the differences of the E-Tree approaches based= on dedicated VLANs (as in http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_text=3D1= ) and multiple PWs between the PEs (as in http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?include_t= ext=3D1) and completely ignores the solution based on usage of the CW in= the PWs connecting the PEs (as in http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_text=3D1= ).

 

The Minutes of the Paris L2VPN session are not yet available, but I= wonder whether the WG has taken a decision to reject the approach based on= the CW usage? I do not remember any recent discussion of this topic on the= WG mailing list.

 

Regards, and lots of thanks in advance,

Sasha

 

 

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA02031CCDFRIDWPPMB002ecite_-- From martin.pels@ams-ix.net Mon Apr 9 03:59:19 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B4E21F869E for ; Mon, 9 Apr 2012 03:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 QvM70hyRS-Oi for ; Mon, 9 Apr 2012 03:59:19 -0700 (PDT) Received: from deliverix.ams-ix.net (deliverix.ams-ix.net [IPv6:2001:67c:1a8:101::248]) by ietfa.amsl.com (Postfix) with ESMTP id D6AFA21F869D for ; Mon, 9 Apr 2012 03:59:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at ams-ix.net Received: from fizzix (nemix0.ipv6.ams-ix.net [IPv6:2001:67c:1a8:120::4]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by deliverix.ams-ix.net (Postfix) with ESMTPSA id 57C31542AA for ; Mon, 9 Apr 2012 12:59:11 +0200 (CEST) Date: Mon, 9 Apr 2012 12:59:09 +0200 From: Martin Pels To: l2vpn@ietf.org Subject: Some questions about draft-ietf-l2vpn-evpn-00 Message-ID: <20120409125909.5e36428b@fizzix> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.22.0; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: l2vpn@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, 09 Apr 2012 10:59:19 -0000 Hello, I've been reading the E-VPN draft, and a few questions came up in my head that the document does not seem to answer. 1) Forwarding packets to a "semi-local" CE Section 18 describes two load-balancing scenario's: Load-balancing from a MES to a remote CE, and load-balancing to a local CE. What is missing here is the situation of a "semi-local" CE. Consider a case where CE-A is connected to MES-1, and CE-B is multi-homed to MES-1 and MES-2. If CE-A sends to CE-B, would this traffic remain local to MES-1, or would it be load-balanced over the local and the remote path to CE-B? 2) Multi-homing vs. Mac move According to section 10.2.1, it is possible for a set of MESs to discover a multi-homed CE with no configuration. I understand this could be achieved by connecting the CE using LACP, causing both MESs to generate the same ESI (as specified in section 6, point 2). In this scenario, how would the requirement that a MES must be able to distinguish a MAC move from multi-homing (section 19) be satisfied? 3) Handling of more specific MAC Advertisements Section 11.2.1 describes a method to encode a MAC address as a prefix. If this is implemented, what should a MES-1 do if it receives a MAC Advertisement with a prefix from MES-2, and a more specific MAC Advertisement (a single MAC Address within the prefix) from MES-3? Kind regards, Martin From wim.henderickx@alcatel-lucent.com Mon Apr 9 06:37:06 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F1021F8704 for ; Mon, 9 Apr 2012 06:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 jZ0vBPSIKLZY for ; Mon, 9 Apr 2012 06:37:05 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id E2F2621F8701 for ; Mon, 9 Apr 2012 06:37:04 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q39Dax95024593 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 Apr 2012 15:36:59 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 9 Apr 2012 15:36:59 +0200 From: "Henderickx, Wim (Wim)" To: Martin Pels , "l2vpn@ietf.org" Date: Mon, 9 Apr 2012 15:36:56 +0200 Subject: RE: Some questions about draft-ietf-l2vpn-evpn-00 Thread-Topic: Some questions about draft-ietf-l2vpn-evpn-00 Thread-Index: Ac0WP9akcT98XTzwRzSoo8oV2nSK5AAFLmuQ Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D67E6570070@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <20120409125909.5e36428b@fizzix> In-Reply-To: <20120409125909.5e36428b@fizzix> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 X-BeenThere: l2vpn@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, 09 Apr 2012 13:37:06 -0000 Martin, in-line with WH> -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of M= artin Pels Sent: maandag 9 april 2012 12:59 To: l2vpn@ietf.org Subject: Some questions about draft-ietf-l2vpn-evpn-00 Hello, I've been reading the E-VPN draft, and a few questions came up in my head that the document does not seem to answer. 1) Forwarding packets to a "semi-local" CE Section 18 describes two load-balancing scenario's: Load-balancing from a MES to a remote CE, and load-balancing to a local CE. What is missing here is the situation of a "semi-local" CE. Consider a case where CE-A is connected to MES-1, and CE-B is multi-homed to MES-1 and MES-2. If CE-A sends to CE-B, would this traffic remain local to MES-1, or would it be load-balanced over the local and the remote path to CE-B? WH> it depends on the BGP Policy applied in the E-VPN. You can either avoid= load-balancing such that traffic from/to CE-A only goes via MES1 or allow = load-balancing like EIBGP load-balancing in IP-VPNs.=20 2) Multi-homing vs. Mac move According to section 10.2.1, it is possible for a set of MESs to discover a multi-homed CE with no configuration. I understand this could be achieved by connecting the CE using LACP, causing both MESs to generate the same ESI (as specified in section 6, point 2). In this scenario, how would the requirement that a MES must be able to distinguish a MAC move from multi-homing (section 19) be satisfied? WH> A MAC move means a MAC address is learned on a different ESI Ctxt, wher= eas multi-homing means a MAC is learned within an ESI Context. Hope this cl= arifies.=20 3) Handling of more specific MAC Advertisements Section 11.2.1 describes a method to encode a MAC address as a prefix. If this is implemented, what should a MES-1 do if it receives a MAC Advertisement with a prefix from MES-2, and a more specific MAC Advertisement (a single MAC Address within the prefix) from MES-3? WH> the FIB should implement a LPM function like an IP FIB. Kind regards, Martin From sajassi@cisco.com Mon Apr 9 10:23:25 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C4B21F87B5 for ; Mon, 9 Apr 2012 10:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.934 X-Spam-Level: X-Spam-Status: No, score=-9.934 tagged_above=-999 required=5 tests=[AWL=0.665, 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 XPveMci2ofTj for ; Mon, 9 Apr 2012 10:23:24 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBAF21F87AA for ; Mon, 9 Apr 2012 10:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sajassi@cisco.com; l=3041; q=dns/txt; s=iport; t=1333992204; x=1335201804; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=KnDwRvz8x28dhERc2a+AS3osYdVN6WH3Zw8d/G2m+A0=; b=eu6g3HFiFl4KtiDrEZbYIdH1hpH51/RzAzT4LQyRLP54ijpvOpnsS0uq DMk75f+EuXOFuWWM9fRTH86Iru4zO2cX1I8x8iCimBvATqSFO8m2Uxv08 Snutl6z08pLxQk/xFxx8wZxTVUL8EbtlmqtyBpVjauM0G63GII3XkmULE k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOQZg0+rRDoI/2dsb2JhbABEuSCBB4IJAQEBAwESAScCASgZBwYBCAkIBAEBKE0JCAEBBAESIodnBAGaBKACkFoEiFqFLIdmjk2BaYMH X-IronPort-AV: E=Sophos;i="4.75,393,1330905600"; d="scan'208";a="39713983" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 09 Apr 2012 17:23:24 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q39HNNjX026151; Mon, 9 Apr 2012 17:23:24 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Apr 2012 10:23:23 -0700 Received: from 10.128.2.28 ([10.128.2.28]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Mon, 9 Apr 2012 17:23:23 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 09 Apr 2012 10:23:22 -0700 Subject: Re: Some questions about draft-ietf-l2vpn-evpn-00 From: sajassi To: "Henderickx, Wim (Wim)" , Martin Pels , "l2vpn@ietf.org" Message-ID: Thread-Topic: Some questions about draft-ietf-l2vpn-evpn-00 Thread-Index: Ac0WP9akcT98XTzwRzSoo8oV2nSK5AAFLmuQAAg5kOc= In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D67E6570070@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Apr 2012 17:23:23.0771 (UTC) FILETIME=[77A21CB0:01CD1675] X-BeenThere: l2vpn@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, 09 Apr 2012 17:23:26 -0000 Martin, In addition to Wim's comments, please see comments below for some additional clarification ... On 4/9/12 6:36 AM, "Henderickx, Wim (Wim)" wrote: > Martin, in-line with WH> > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > Martin Pels > Sent: maandag 9 april 2012 12:59 > To: l2vpn@ietf.org > Subject: Some questions about draft-ietf-l2vpn-evpn-00 > > Hello, > > I've been reading the E-VPN draft, and a few questions came up in my > head that the document does not seem to answer. > > 1) Forwarding packets to a "semi-local" CE > > Section 18 describes two load-balancing scenario's: Load-balancing from > a MES to a remote CE, and load-balancing to a local CE. What is missing > here is the situation of a "semi-local" CE. > > Consider a case where CE-A is connected to MES-1, and CE-B is > multi-homed to MES-1 and MES-2. If CE-A sends to CE-B, would this > traffic remain local to MES-1, or would it be load-balanced over the > local and the remote path to CE-B? > > WH> it depends on the BGP Policy applied in the E-VPN. You can either avoid > load-balancing such that traffic from/to CE-A only goes via MES1 or allow > load-balancing like EIBGP load-balancing in IP-VPNs. > For unicast traffic, the MES-1 (by default) should load-balanced between local and remote; however, it can be overwritten so that traffic is only locally switched. For multicast traffic, it depends on the DF election. If the local port is selected as DF, then the traffic is locally switched; however, if the port on the MES-2 is selected as DF, then the traffic goes over the core. > 2) Multi-homing vs. Mac move > > According to section 10.2.1, it is possible for a set of MESs to > discover a multi-homed CE with no configuration. I understand this could > be achieved by connecting the CE using LACP, causing both MESs to > generate the same ESI (as specified in section 6, point 2). > > In this scenario, how would the requirement that a MES must be able to > distinguish a MAC move from multi-homing (section 19) be satisfied? > > WH> A MAC move means a MAC address is learned on a different ESI Ctxt, whereas > multi-homing means a MAC is learned within an ESI Context. Hope this > clarifies. And a PE knows that it is a different ESI context, because it learns the MAC locally from an ESI which is different from the advertised ESI . > > 3) Handling of more specific MAC Advertisements > > Section 11.2.1 describes a method to encode a MAC address as a prefix. > If this is implemented, what should a MES-1 do if it receives a MAC > Advertisement with a prefix from MES-2, and a more specific MAC > Advertisement (a single MAC Address within the prefix) from MES-3? > > WH> the FIB should implement a LPM function like an IP FIB. E.g., more specific address should take precedence over coarser one. Cheers, Ali > > Kind regards, > Martin From simon.delord@gmail.com Mon Apr 9 16:45:27 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B9C21F87C6 for ; Mon, 9 Apr 2012 16:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bp+T13ZBJ3J for ; Mon, 9 Apr 2012 16:45:27 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8D94021F87AA for ; Mon, 9 Apr 2012 16:45:26 -0700 (PDT) Received: by lbok13 with SMTP id k13so2360349lbo.31 for ; Mon, 09 Apr 2012 16:45:25 -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=/MPbzf/SuhWHyqoLGsaeycJT06nL54ESUUn0sb2CR+s=; b=L3291Y2vn7CoqXg1xAXHJ/MWS30jHJ1f6TW2An5uB/u4PA0jwpqYmG9+tgIBLPzmnm ZrFB9BwgaygKELD2uU/l6tKoLwy8M4X1ZS5BJtMTMe8v1DCvbLVXfO7MI7O7MGLmG7o/ DyqKrDpKe31RGpUvf+nLNjUpmS932dX2ZVndj2W/vsG9CsVTiGWysNgIz87e9JiEAlfE ZGTHK6cZBNIyBvuF/fRPpGsUtc8yqUWh1EYgC+WYsKQOMiekk7aCPETQ7gvdaKrYZjI2 kafPCb/I7aqVZPg32lSRRCoBkeCjGuHPdGrRGd0gMoF4DHVBRK6RLiz//1RrxFz3scPR hvlA== MIME-Version: 1.0 Received: by 10.152.146.234 with SMTP id tf10mr13273724lab.31.1334015125527; Mon, 09 Apr 2012 16:45:25 -0700 (PDT) Received: by 10.112.23.38 with HTTP; Mon, 9 Apr 2012 16:45:25 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 Apr 2012 09:45:25 +1000 Message-ID: Subject: Re: The status of the approaches to the E-Tree solution? From: Simon Delord To: Alexander Vainshtein Content-Type: multipart/alternative; boundary=e89a8f22c84fae9b4904bd479997 Cc: "l2vpn@ietf.org" , Vladimir Kleiner , Andrew Sergeev , Idan Kaspit , Mishael Wexler , Rotem Cohen X-BeenThere: l2vpn@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, 09 Apr 2012 23:45:28 -0000 --e89a8f22c84fae9b4904bd479997 Content-Type: text/plain; charset=ISO-8859-1 Hi Alexander, You are right, no discussion on the WG mailing list recently, but there have been substantial discussions among the authors of various solution drafts off the mailing list. As far as I know, no consensus yet before ietf83, not sure the progress in the Paris WG meeting. I think the CW approach has not been rejected by the WG yet, or the WG has not yet decided on which one to adopt. Simon 2012/4/8 Alexander Vainshtein > Hi all, > > Unfortunately I have not been able to attend the Paris IETF. > > However, looking up the L2VPN proceedings, I've found a short anonymous > presentation called "E-Tree Update" ( > http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). This > presentation discusses the differences of the E-Tree approaches based on > dedicated VLANs (as in > http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_text=1) > and multiple PWs between the PEs (as in > http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?include_text=1) > and completely ignores the solution based on usage of the CW in the PWs > connecting the PEs (as in > http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_text=1 > ). > > > > The Minutes of the Paris L2VPN session are not yet available, but I wonder > whether the WG has taken a decision to reject the approach based on the CW > usage? I do not remember any recent discussion of this topic on the WG > mailing list. > > > > Regards, and lots of thanks in advance, > > Sasha > > > > > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us > by e-mail, phone or fax, and then delete the original and all copies > thereof. > --e89a8f22c84fae9b4904bd479997 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alexander,

You are right, no discussion on the WG mailing list recently= , but there have been substantial discussions among the authors of various = solution drafts off the mailing list. As far as I know, no consensus yet be= fore ietf83, not sure the progress in the Paris WG meeting. I think the CW = approach has not been rejected by the WG yet, or the WG has not yet decided= on which one to adopt.

Simon

2012/4/8 Alexander Vainshtein = <A= lexander.Vainshtein@ecitele.com>

Hi all,

Unfortunately=A0I have not been able to attend the Paris IETF.

However, looking up the L2VPN proceedings, I've found a short anonym= ous presentation called "E-Tree Update"=A0 (h= ttp://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). This presentation discusses the differences of the E-Tree approaches based= on dedicated VLANs (as in http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_text=3D= 1) and multiple PWs between the PEs (as in http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?include_= text=3D1) and completely ignores the solution based on usage of the CW = in the PWs connecting the PEs (as in http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_text=3D= 1).

=A0

The=A0Minutes of the Paris L2VPN session are not yet available, but I wo= nder whether the WG has taken a decision to reject the approach based on th= e CW usage? I do not remember any recent discussion of this topic on the WG= mailing list.

=A0

Regards, and lots of thanks in advance,

Sasha

=A0

=A0

This e-mail message is intended for the recipient only and contains info= rmation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. = If you have received this transmission in error, please inform us by e-mail= , phone or fax, and then delete the original and all copies thereof.


--e89a8f22c84fae9b4904bd479997-- From ietf-ipr@ietf.org Fri Apr 6 06:12:11 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8121421F84F8; Fri, 6 Apr 2012 06:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, 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 bJ8ydRvypZ81; Fri, 6 Apr 2012 06:12:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E27721F84B3; Fri, 6 Apr 2012 06:12:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: hshah@ciena.com, giheron@cisco.com, vach.kompella@alcatel-lucent.com, erosen@cisco.com Subject: IPR Disclosure: Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn-arp-mediation-19 X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120406131211.23260.14085.idtracker@ietfa.amsl.com> Date: Fri, 06 Apr 2012 06:12:11 -0700 X-Mailman-Approved-At: Wed, 11 Apr 2012 02:11:18 -0700 Cc: l2vpn@ietf.org, giheron@cisco.com, ipr-announce@ietf.org, stbryant@cisco.com X-BeenThere: l2vpn@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, 06 Apr 2012 13:12:11 -0000 Dear Himanshu C. Shah, Giles Heron, Vach Kompella, Eric Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "ARP Media= tion for IP Interworking of Layer 2 VPN" (draft-ietf-l2vpn-arp-mediation) was submitted to the IETF Secretariat on 2012-03-29 and has been posted on the = "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1738/). The title of the IPR disclosure is "Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn-arp- mediation-19.""); The IETF Secretariat From agmalis@gmail.com Wed Apr 11 05:20:20 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFD721F8526; Wed, 11 Apr 2012 05:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsR5n8kbdDa0; Wed, 11 Apr 2012 05:20:19 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5834321F852E; Wed, 11 Apr 2012 05:20:19 -0700 (PDT) Received: by ggmi1 with SMTP id i1so414502ggm.31 for ; Wed, 11 Apr 2012 05:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=4DgviCOpaDCT8enNX081W4V9nqhtqxkbUXgtps9B53o=; b=hlnpQ9zbgDc8TlmZw+Pr0zhVH6g+MVU7JtAQW96uaZ4Uj8rITlssBIMMPFoGgTsZLB QWvx+TL+HC94U7kWfcxWV8VWzO9MUyGC8lFTxc5MvM0l9eAr/5FWggSgdEigDbMkZJvb l/82ITTTovN25b8z97X+JtmNCqgrq8hlsIK3obQ0Uavwiubk2B9WAQ0QjMQKqa8yn0XW AkWjMpX78G9mHfHsaClZx8p2bb3p9RPkSh8/xlMQa3nn7bKchnfwWClPZHy44UJog/G3 0CV9zJSnfRTAy6J8iQnbKCs9rnqme4Fy3fUqWppM2hydFIJOjSYZod9OhCkPNUuLPlPM Pq+g== Received: by 10.50.181.164 with SMTP id dx4mr1829270igc.1.1334146818773; Wed, 11 Apr 2012 05:20:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.184.231 with HTTP; Wed, 11 Apr 2012 05:19:58 -0700 (PDT) In-Reply-To: <20120406131211.23260.14085.idtracker@ietfa.amsl.com> References: <20120406131211.23260.14085.idtracker@ietfa.amsl.com> From: "Andrew G. Malis" Date: Wed, 11 Apr 2012 08:19:58 -0400 Message-ID: Subject: Re: IPR Disclosure: Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn-arp-mediation-19 To: IETF Secretariat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vach.kompella@alcatel-lucent.com, l2vpn@ietf.org, giheron@cisco.com, andrew.dolganow@alcatel-lucent.com, erosen@cisco.com, ipr-announce@ietf.org, stbryant@cisco.com X-BeenThere: l2vpn@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, 11 Apr 2012 12:20:20 -0000 IPv6 support for ARP mediation was added in draft-ietf-l2vpn-arp-mediation-08, dated July 2007. The text of the patent directly refers to revision -09 of the draft, and at least one of the authors is an IETF regular. The patent was filed in January 2009 and awarded in May 2011. Why is it just being disclosed now? Thanks, Andy On Fri, Apr 6, 2012 at 9:12 AM, IETF Secretariat wrote: > > Dear Himanshu C. Shah, Giles Heron, Vach Kompella, Eric Rosen: > > =A0An IPR disclosure that pertains to your Internet-Draft entitled "ARP M= ediation > for IP Interworking of Layer 2 VPN" (draft-ietf-l2vpn-arp-mediation) was > submitted to the IETF Secretariat on 2012-03-29 and has been posted on th= e "IETF > Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1738/). The title of the IPR disclosure= is > "Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn-arp- > mediation-19.""); > > The IETF Secretariat > From martin.pels@ams-ix.net Wed Apr 11 10:09:27 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F2E21F848F for ; Wed, 11 Apr 2012 10:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 osDDqglwCl5Z for ; Wed, 11 Apr 2012 10:09:27 -0700 (PDT) Received: from deliverix.ams-ix.net (deliverix.ams-ix.net [IPv6:2001:67c:1a8:101::248]) by ietfa.amsl.com (Postfix) with ESMTP id 107C221F84D1 for ; Wed, 11 Apr 2012 10:09:24 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at ams-ix.net Received: from fizzix (nemix0.ipv6.ams-ix.net [IPv6:2001:67c:1a8:120::4]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by deliverix.ams-ix.net (Postfix) with ESMTPSA id 1D3CB542AA; Wed, 11 Apr 2012 19:09:21 +0200 (CEST) Date: Wed, 11 Apr 2012 19:09:20 +0200 From: Martin Pels To: sajassi , "Henderickx, Wim (Wim)" Subject: Re: Some questions about draft-ietf-l2vpn-evpn-00 Message-ID: <20120411190920.05380198@fizzix> In-Reply-To: References: <14C7F4F06DB5814AB0DE29716C4F6D67E6570070@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.22.0; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 11 Apr 2012 17:09:27 -0000 Hi Wim, Ali, Thanks for your replies. On Mon, 09 Apr 2012 10:23:22 -0700 sajassi wrote: > > Martin, > > In addition to Wim's comments, please see comments below for some additional > clarification ... > > > On 4/9/12 6:36 AM, "Henderickx, Wim (Wim)" > wrote: > > > Martin, in-line with WH> > > > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > > Martin Pels > > Sent: maandag 9 april 2012 12:59 > > To: l2vpn@ietf.org > > Subject: Some questions about draft-ietf-l2vpn-evpn-00 > > > > Hello, > > > > I've been reading the E-VPN draft, and a few questions came up in my > > head that the document does not seem to answer. > > > > 1) Forwarding packets to a "semi-local" CE > > > > Section 18 describes two load-balancing scenario's: Load-balancing from > > a MES to a remote CE, and load-balancing to a local CE. What is missing > > here is the situation of a "semi-local" CE. > > > > Consider a case where CE-A is connected to MES-1, and CE-B is > > multi-homed to MES-1 and MES-2. If CE-A sends to CE-B, would this > > traffic remain local to MES-1, or would it be load-balanced over the > > local and the remote path to CE-B? > > > > WH> it depends on the BGP Policy applied in the E-VPN. You can either avoid > > load-balancing such that traffic from/to CE-A only goes via MES1 or allow > > load-balancing like EIBGP load-balancing in IP-VPNs. > > > > For unicast traffic, the MES-1 (by default) should load-balanced between > local and remote; however, it can be overwritten so that traffic is only > locally switched. That makes sense. It might be useful to clarify this in the draft. > For multicast traffic, it depends on the DF election. If the local port is > selected as DF, then the traffic is locally switched; > however, if the port on the MES-2 is selected as DF, then the traffic goes > over the core. Ack. > > 2) Multi-homing vs. Mac move > > > > According to section 10.2.1, it is possible for a set of MESs to > > discover a multi-homed CE with no configuration. I understand this could > > be achieved by connecting the CE using LACP, causing both MESs to > > generate the same ESI (as specified in section 6, point 2). > > > > In this scenario, how would the requirement that a MES must be able to > > distinguish a MAC move from multi-homing (section 19) be satisfied? > > > > WH> A MAC move means a MAC address is learned on a different ESI Ctxt, whereas > > multi-homing means a MAC is learned within an ESI Context. Hope this > > clarifies. > > And a PE knows that it is a different ESI context, because it learns the MAC > locally from an ESI which is different from the advertised ESI . I understand this would work with statically configured ESIs. But if the ESI is generated from the CE LACP System Identifier and CE Port key, it will always be the same, correct? So then when the CE appears behind a second MES it will always be seen as multi-homing, never as a MAC Move. > > > > 3) Handling of more specific MAC Advertisements > > > > Section 11.2.1 describes a method to encode a MAC address as a prefix. > > If this is implemented, what should a MES-1 do if it receives a MAC > > Advertisement with a prefix from MES-2, and a more specific MAC > > Advertisement (a single MAC Address within the prefix) from MES-3? > > > > WH> the FIB should implement a LPM function like an IP FIB. > > E.g., more specific address should take precedence over coarser one. Ok. I think this should also be clarified in the text. Kind regards, Martin From wim.henderickx@alcatel-lucent.com Wed Apr 11 10:48:59 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AFF21F8570 for ; Wed, 11 Apr 2012 10:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 JYNx7DGN4a34 for ; Wed, 11 Apr 2012 10:48:58 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id E7DF121F8564 for ; Wed, 11 Apr 2012 10:48:57 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3BHmsLY002278 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 11 Apr 2012 19:48:54 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 11 Apr 2012 19:48:54 +0200 From: "Henderickx, Wim (Wim)" To: Martin Pels , sajassi Date: Wed, 11 Apr 2012 19:48:41 +0200 Subject: RE: Some questions about draft-ietf-l2vpn-evpn-00 Thread-Topic: Some questions about draft-ietf-l2vpn-evpn-00 Thread-Index: Ac0YBdw+08f/MAG6SHKfM8k75SQpywAAMmgA Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D67E65707B1@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <14C7F4F06DB5814AB0DE29716C4F6D67E6570070@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <20120411190920.05380198@fizzix> In-Reply-To: <20120411190920.05380198@fizzix> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: hYk= CoNe FmaM MAVo Os+g Q/yp Sgc1 S0Qz UUn6 W7RO XyUK bL/0 dHn+ df4y egnP g6fZ; 3; bAAyAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAbQBhAHIAdABpAG4ALgBwAGUAbABzAEAAYQBtAHMALQBpAHgALgBuAGUAdAA7AHMAYQBqAGEAcwBzAGkAQABjAGkAcwBjAG8ALgBjAG8AbQA=; Sosha1_v1; 7; {BF802C67-819C-4CF6-B35F-6FC7FE951951}; dwBpAG0ALgBoAGUAbgBkAGUAcgBpAGMAawB4AEAAYQBsAGMAYQB0AGUAbAAtAGwAdQBjAGUAbgB0AC4AYwBvAG0A; Wed, 11 Apr 2012 17:48:41 GMT; UgBFADoAIABTAG8AbQBlACAAcQB1AGUAcwB0AGkAbwBuAHMAIABhAGIAbwB1AHQAIABkAHIAYQBmAHQALQBpAGUAdABmAC0AbAAyAHYAcABuAC0AZQB2AHAAbgAtADAAMAA= x-cr-puzzleid: {BF802C67-819C-4CF6-B35F-6FC7FE951951} acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 11 Apr 2012 17:48:59 -0000 Martin, in-line I agree we need to clarify some items. <> I understand this would work with statically configured ESIs. But if the ESI is generated from the CE LACP System Identifier and CE Port = key, it will always be the same, correct? So then when the CE appears behind a s= econd MES it will always be seen as multi-homing, never as a MAC Move. <> As long as the traffic comes from the same CE this is indeed multi-homing, = but I don't see an issue with this. If the traffic comes to another CE with= dynamic LACP we will do mac move -----Original Message----- From: Martin Pels [mailto:martin.pels@ams-ix.net]=20 Sent: woensdag 11 april 2012 19:09 To: sajassi; Henderickx, Wim (Wim) Cc: l2vpn@ietf.org Subject: Re: Some questions about draft-ietf-l2vpn-evpn-00 Hi Wim, Ali, Thanks for your replies. On Mon, 09 Apr 2012 10:23:22 -0700 sajassi wrote: >=20 > Martin, >=20 > In addition to Wim's comments, please see comments below for some additio= nal > clarification ... >=20 >=20 > On 4/9/12 6:36 AM, "Henderickx, Wim (Wim)" > wrote: >=20 > > Martin, in-line with WH> > >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of > > Martin Pels > > Sent: maandag 9 april 2012 12:59 > > To: l2vpn@ietf.org > > Subject: Some questions about draft-ietf-l2vpn-evpn-00 > >=20 > > Hello, > >=20 > > I've been reading the E-VPN draft, and a few questions came up in my > > head that the document does not seem to answer. > >=20 > > 1) Forwarding packets to a "semi-local" CE > >=20 > > Section 18 describes two load-balancing scenario's: Load-balancing from > > a MES to a remote CE, and load-balancing to a local CE. What is missing > > here is the situation of a "semi-local" CE. > >=20 > > Consider a case where CE-A is connected to MES-1, and CE-B is > > multi-homed to MES-1 and MES-2. If CE-A sends to CE-B, would this > > traffic remain local to MES-1, or would it be load-balanced over the > > local and the remote path to CE-B? > >=20 > > WH> it depends on the BGP Policy applied in the E-VPN. You can either a= void > > load-balancing such that traffic from/to CE-A only goes via MES1 or all= ow > > load-balancing like EIBGP load-balancing in IP-VPNs. > >=20 >=20 > For unicast traffic, the MES-1 (by default) should load-balanced between > local and remote; however, it can be overwritten so that traffic is only > locally switched. That makes sense. It might be useful to clarify this in the draft. > For multicast traffic, it depends on the DF election. If the local port i= s=20 > selected as DF, then the traffic is locally switched; > however, if the port on the MES-2 is selected as DF, then the traffic goe= s > over the core.=20 Ack. > > 2) Multi-homing vs. Mac move > >=20 > > According to section 10.2.1, it is possible for a set of MESs to > > discover a multi-homed CE with no configuration. I understand this coul= d > > be achieved by connecting the CE using LACP, causing both MESs to > > generate the same ESI (as specified in section 6, point 2). > >=20 > > In this scenario, how would the requirement that a MES must be able to > > distinguish a MAC move from multi-homing (section 19) be satisfied? > >=20 > > WH> A MAC move means a MAC address is learned on a different ESI Ctxt, = whereas > > multi-homing means a MAC is learned within an ESI Context. Hope this > > clarifies.=20 >=20 > And a PE knows that it is a different ESI context, because it learns the = MAC > locally from an ESI which is different from the advertised ESI . I understand this would work with statically configured ESIs. But if the ESI is generated from the CE LACP System Identifier and CE Port = key, it will always be the same, correct? So then when the CE appears behind a s= econd MES it will always be seen as multi-homing, never as a MAC Move. > >=20 > > 3) Handling of more specific MAC Advertisements > >=20 > > Section 11.2.1 describes a method to encode a MAC address as a prefix. > > If this is implemented, what should a MES-1 do if it receives a MAC > > Advertisement with a prefix from MES-2, and a more specific MAC > > Advertisement (a single MAC Address within the prefix) from MES-3? > >=20 > > WH> the FIB should implement a LPM function like an IP FIB. >=20 > E.g., more specific address should take precedence over coarser one. Ok. I think this should also be clarified in the text. Kind regards, Martin From giles.heron@gmail.com Wed Apr 11 23:22:39 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C5421F8494 for ; Wed, 11 Apr 2012 23:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJiGSReJQ7Eg for ; Wed, 11 Apr 2012 23:22:39 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 47A8411E8075 for ; Wed, 11 Apr 2012 23:22:38 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1092278wgb.13 for ; Wed, 11 Apr 2012 23:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:mime-version:content-type:content-transfer-encoding; bh=vg2qsUnK4eLjSOZ26nHq8hh2+Dv/AH51A9Rg/xVrM54=; b=GaQIpnOQN7cn3xAInQLaPJ/C2NVEA7Zt0/4lzQbmEcphjHiuWH9EV1sTjU+ZnXA/8i zm2dQ3WDbRFRge0cqL4kFkHHtbr/UkEFcA4r+VutZ95F4pX4BtC09mgAExJsmg6XBYHr ZjpE42tKPbQip4wBRVjP9FaP1Ovq3YTofYC8rrkzb5GiTkvKgctYmWgY2rdkLo8k9wCl zlb8re7thETmWJ1xr79sYHczAYfvbZJJ4tOEki/IB1Ti3t/SZ0vRY3sTNeVx5K/+3ZA3 9S3SoCobxGJavwuOWjU3SiiXuoemg8ktjqSmbkw+uMXfnDd5sofdVe7g8sYVAoULiZ74 qq/g== Received: by 10.216.131.24 with SMTP id l24mr695116wei.76.1334211752129; Wed, 11 Apr 2012 23:22:32 -0700 (PDT) Received: from [10.55.89.28] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fl2sm18100928wib.2.2012.04.11.23.22.26 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Apr 2012 23:22:30 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 12 Apr 2012 07:22:08 +0100 Subject: Re: The status of the approaches to the E-Tree solution? From: Giles Heron To: Simon Delord , Alexander Vainshtein Message-ID: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFdjZLWcpAE0uaMYACV/K6GQ== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "l2vpn@ietf.org" , Vladimir Kleiner , Andrew Sergeev , Idan Kaspit , Mishael Wexler , Rotem Cohen X-BeenThere: l2vpn@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, 12 Apr 2012 06:22:39 -0000 Sorry - the "anonymous presentation" was mine. I should possibly have put in a third column on the CW approach. And hopefully the minutes will be posted soon. We had various discussions, as Simon stated, and consensus seemed to be forming around the two alternatives of two PWEs or two VLANs. I believe three of the authors of the CW approach are also authors of the two VLAN approach and one is also an author of the two PWE approach. So perhaps it's best to let those four individuals say which approach they prefer and why? Giles On 10/04/2012 00:45, "Simon Delord" wrote: > Hi Alexander, > > You are right, no discussion on the WG mailing list recently, but there > have been substantial discussions among the authors of various solution > drafts off the mailing list. As far as I know, no consensus yet before > ietf83, not sure the progress in the Paris WG meeting. I think the CW > approach has not been rejected by the WG yet, or the WG has not yet decided > on which one to adopt. > > Simon > > 2012/4/8 Alexander Vainshtein > >> Hi all, >> >> Unfortunately I have not been able to attend the Paris IETF. >> >> However, looking up the L2VPN proceedings, I've found a short anonymous >> presentation called "E-Tree Update" ( >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). This >> presentation discusses the differences of the E-Tree approaches based on >> dedicated VLANs (as in >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_text=1) >> and multiple PWs between the PEs (as in >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?include_te >> xt=1) >> and completely ignores the solution based on usage of the CW in the PWs >> connecting the PEs (as in >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_text=1 >> ). >> >> >> >> The Minutes of the Paris L2VPN session are not yet available, but I wonder >> whether the WG has taken a decision to reject the approach based on the CW >> usage? I do not remember any recent discussion of this topic on the WG >> mailing list. >> >> >> >> Regards, and lots of thanks in advance, >> >> Sasha >> >> >> >> >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please inform us >> by e-mail, phone or fax, and then delete the original and all copies >> thereof. >> From wim.henderickx@alcatel-lucent.com Thu Apr 12 00:03:05 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186FA21F84DF for ; Thu, 12 Apr 2012 00:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, HS_INDEX_PARAM=0.001, 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 7gaec+Ho-b56 for ; Thu, 12 Apr 2012 00:03:04 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0828621F84E4 for ; Thu, 12 Apr 2012 00:03:03 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3C72r0r030515 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Apr 2012 09:02:59 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 12 Apr 2012 09:02:50 +0200 From: "Henderickx, Wim (Wim)" To: "'giles.heron@gmail.com'" , "'simon.delord@gmail.com'" , "'Alexander.Vainshtein@ecitele.com'" Date: Thu, 12 Apr 2012 09:02:49 +0200 Subject: Re: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFdjZLWcpAE0uaMYACV/K6GQABa612 Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D67E6673E75@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "'l2vpn@ietf.org'" , "'Vladimir.Kleiner@ecitele.com'" , "'Andrew.Sergeev@ecitele.com'" , "'Idan.Kaspit@ecitele.com'" , "'Mishael.Wexler@ecitele.com'" , "'Rotem.Cohen@ecitele.com'" X-BeenThere: l2vpn@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, 12 Apr 2012 07:03:05 -0000 The vlan approach is superior as it also works for eth only networks, etc. = On top some vendors indicate hw issues with the cw approach. As such we hav= e dropped more or less the cw approach. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Thursday, April 12, 2012 08:22 AM=0A= To: Simon Delord ; Alexander Vainshtein Cc: l2vpn@ietf.org ; Vladimir Kleiner ; Andrew Sergeev ; Idan Kaspit ; Mishael Wexler ; Rotem Cohe= n Subject: Re: The status of the approaches to the E-Tree solution? Sorry - the "anonymous presentation" was mine. I should possibly have put in a third column on the CW approach. And hopefully the minutes will be posted soon. We had various discussions, as Simon stated, and consensus seemed to be forming around the two alternatives of two PWEs or two VLANs. I believe three of the authors of the CW approach are also authors of the two VLAN approach and one is also an author of the two PWE approach. So perhaps it's best to let those four individuals say which approach they prefer and why? Giles On 10/04/2012 00:45, "Simon Delord" wrote: > Hi Alexander, >=20 > You are right, no discussion on the WG mailing list recently, but there > have been substantial discussions among the authors of various solution > drafts off the mailing list. As far as I know, no consensus yet before > ietf83, not sure the progress in the Paris WG meeting. I think the CW > approach has not been rejected by the WG yet, or the WG has not yet decid= ed > on which one to adopt. >=20 > Simon >=20 > 2012/4/8 Alexander Vainshtein >=20 >> Hi all, >>=20 >> Unfortunately I have not been able to attend the Paris IETF. >>=20 >> However, looking up the L2VPN proceedings, I've found a short anonymous >> presentation called "E-Tree Update" ( >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). This >> presentation discusses the differences of the E-Tree approaches based on >> dedicated VLANs (as in >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_text= =3D1) >> and multiple PWs between the PEs (as in >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?inclu= de_te >> xt=3D1) >> and completely ignores the solution based on usage of the CW in the PWs >> connecting the PEs (as in >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_text= =3D1 >> ). >>=20 >>=20 >>=20 >> The Minutes of the Paris L2VPN session are not yet available, but I wond= er >> whether the WG has taken a decision to reject the approach based on the = CW >> usage? I do not remember any recent discussion of this topic on the WG >> mailing list. >>=20 >>=20 >>=20 >> Regards, and lots of thanks in advance, >>=20 >> Sasha >>=20 >>=20 >>=20 >>=20 >>=20 >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please inform = us >> by e-mail, phone or fax, and then delete the original and all copies >> thereof. >>=20 From stbryant@cisco.com Thu Apr 12 10:57:23 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874A821F8577; Thu, 12 Apr 2012 10:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.578 X-Spam-Level: X-Spam-Status: No, score=-110.578 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 CT8pgwlYgR-w; Thu, 12 Apr 2012 10:57:22 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6958321F855F; Thu, 12 Apr 2012 10:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=5912; q=dns/txt; s=iport; t=1334253441; x=1335463041; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=cU6Df5Otm1U/OJuoatFWHBcSwbk+gr4sfEoj8rp9kQg=; b=V6WbFjDnlBlDPqnyDwHhbzYUIdIzL4aRGLCMhTXG365u6MGYYmPM95Ee Zy3Zf9ay8oX5K0GW4Ur7PuKzbdl72k+9nApXOyjRrU0/FV2jzEPrrkF1u e4eoeRu7ORvaYDU0fDFvrMpJEOFKXvC1QuWC5HgJnGtmBRgjmb7WCRqla 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKAWh0+Q/khR/2dsb2JhbABEuXWBB4IJAQEBBBIBAmMBDAQcAwECAQkWBAsJAwIBAgEPLAIIBg0BBQIBAR6HXgMLC5ocgz8Qkl8NiU8EijOHSwSVbIs5gxSBAmeCaA X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208,217";a="134991358" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 12 Apr 2012 17:57:20 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3CHvF8A001764; Thu, 12 Apr 2012 17:57:20 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q3CHvEN4028317; Thu, 12 Apr 2012 18:57:14 +0100 (BST) Message-ID: <4F871779.8050006@cisco.com> Date: Thu, 12 Apr 2012 18:57:13 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: IETF-IESG-Support via RT Subject: Fwd: Re: IPR Disclosure: Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn-arp-mediation-19 References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/alternative; boundary="------------080903030307010606080409" Cc: "l2vpn@ietf.org" , "l2vpn-chairs@tools.ietf.org" , draft-ietf-l2vpn-arp-mediation@tools.ietf.org, "iesg@ietf.org" , RFC Editor X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 17:57:23 -0000 This is a multi-part message in MIME format. --------------080903030307010606080409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IESG Secretary In view of this late IPR disclosure, please initiate a new IETF Last Call on this draft. RFC Editor Please hold publication until the Last Call completes and I indicate that there is IETF consensus to proceed. Thanks Stewart -------- Original Message -------- Subject: Re: IPR Disclosure: Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn-arp-mediation-19 Date: Wed, 11 Apr 2012 08:19:58 -0400 From: Andrew G. Malis To: IETF Secretariat CC: hshah@ciena.com, giheron@cisco.com, vach.kompella@alcatel-lucent.com, erosen@cisco.com, l2vpn@ietf.org, ipr-announce@ietf.org, stbryant@cisco.com, andrew.dolganow@alcatel-lucent.com IPv6 support for ARP mediation was added in draft-ietf-l2vpn-arp-mediation-08, dated July 2007. The text of the patent directly refers to revision -09 of the draft, and at least one of the authors is an IETF regular. The patent was filed in January 2009 and awarded in May 2011. Why is it just being disclosed now? Thanks, Andy On Fri, Apr 6, 2012 at 9:12 AM, IETF Secretariat wrote: > > Dear Himanshu C. Shah, Giles Heron, Vach Kompella, Eric Rosen: > > An IPR disclosure that pertains to your Internet-Draft entitled "ARP Mediation > for IP Interworking of Layer 2 VPN" (draft-ietf-l2vpn-arp-mediation) was > submitted to the IETF Secretariat on 2012-03-29 and has been posted on the "IETF > Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1738/). The title of the IPR disclosure is > "Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn-arp- > mediation-19.""); > > The IETF Secretariat > --------------080903030307010606080409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit IESG Secretary

In view of this late IPR disclosure, please initiate a new IETF Last Call
on this draft.

RFC Editor

Please hold publication until the Last Call completes
and I indicate that there is IETF consensus to proceed.

Thanks

Stewart


-------- Original Message --------
Subject: Re: IPR Disclosure: Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn-arp-mediation-19
Date: Wed, 11 Apr 2012 08:19:58 -0400
From: Andrew G. Malis <agmalis@gmail.com>
To: IETF Secretariat <ietf-ipr@ietf.org>
CC: hshah@ciena.com, giheron@cisco.com, vach.kompella@alcatel-lucent.com, erosen@cisco.com, l2vpn@ietf.org, ipr-announce@ietf.org, stbryant@cisco.com, andrew.dolganow@alcatel-lucent.com 


IPv6 support for ARP mediation was added in
draft-ietf-l2vpn-arp-mediation-08, dated July 2007. The text of the
patent directly refers to revision -09 of the draft, and at least one
of the authors is an IETF regular. The patent was filed in January
2009 and awarded in May 2011. Why is it just being disclosed now?

Thanks,
Andy

On Fri, Apr 6, 2012 at 9:12 AM, IETF Secretariat <ietf-ipr@ietf.org> wrote:
>
> Dear Himanshu C. Shah, Giles Heron, Vach Kompella, Eric Rosen:
>
>  An IPR disclosure that pertains to your Internet-Draft entitled "ARP Mediation
> for IP Interworking of Layer 2 VPN" (draft-ietf-l2vpn-arp-mediation) was
> submitted to the IETF Secretariat on 2012-03-29 and has been posted on the "IETF
> Page of Intellectual Property Rights Disclosures"
> (https://datatracker.ietf.org/ipr/1738/). The title of the IPR disclosure is
> "Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn-arp-
> mediation-19."");
>
> The IETF Secretariat
>
--------------080903030307010606080409-- From iesg-secretary@ietf.org Thu Apr 12 13:39:41 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4618421F870E; Thu, 12 Apr 2012 13:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, 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 pDWh5d2Djm+T; Thu, 12 Apr 2012 13:39:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B19A21F84FB; Thu, 12 Apr 2012 13:39:40 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (ARP Mediation for IP Interworking of Layer 2 VPN) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120412203940.23570.43972.idtracker@ietfa.amsl.com> Date: Thu, 12 Apr 2012 13:39:40 -0700 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 20:39:41 -0000 The IESG has received a request from the Layer 2 Virtual Private Networks WG (l2vpn) to consider the following document: - 'ARP Mediation for IP Interworking of Layer 2 VPN' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-04-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Virtual Private Wire Service (VPWS) [RFC4664] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet, both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "ARP Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-l2vpn-arp-mediation/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-l2vpn-arp-mediation/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1738/ From ietf-ipr@ietf.org Thu Apr 12 07:48:44 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D8821F8680; Thu, 12 Apr 2012 07:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.368 X-Spam-Level: X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, 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 JxtGE9YWe+DI; Thu, 12 Apr 2012 07:48:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAE221F857A; Thu, 12 Apr 2012 07:48:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: pranjal.dutta@alcatel-lucent.com, florin.balus@alcatel-lucent.com, ostokes@extremenetworks.com, geraldine.calvignac@orange-ftgroup.com Subject: IPR Disclosure: Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn-vpls-ldp-mac-opt-05 X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120412144837.24409.22177.idtracker@ietfa.amsl.com> Date: Thu, 12 Apr 2012 07:48:37 -0700 X-Mailman-Approved-At: Thu, 12 Apr 2012 15:04:36 -0700 Cc: l2vpn@ietf.org, giheron@cisco.com, ipr-announce@ietf.org, stbryant@cisco.com X-BeenThere: l2vpn@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, 12 Apr 2012 14:48:45 -0000 Dear Pranjal Dutta, Florin Balus, Olen Stokes, Geraldine Calvignac: An IPR disclosure that pertains to your Internet-Draft entitled "LDP Exten= sions for Optimized MAC Address Withdrawal in H-VPLS" (draft-ietf-l2vpn-vpls-ldp-= mac-opt) was submitted to the IETF Secretariat on 2012-04-11 and has been p= osted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1749/). The title of the IPR disclosure is "Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn-vpls-ldp-= mac- opt-05.""); The IETF Secretariat From ietf-ipr@ietf.org Thu Apr 12 07:53:07 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA9021F869A; Thu, 12 Apr 2012 07:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.369 X-Spam-Level: X-Spam-Status: No, score=-102.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, 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 rq4NCfLy6mGp; Thu, 12 Apr 2012 07:53:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A01121F8652; Thu, 12 Apr 2012 07:53:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: raggarwa_1@yahoo.com, sajassi@cisco.com, wim.henderickx@alcatel-lucent.com, nabil.n.bitar@verizon.com, rshekhar@juniper.net, jdrake@juniper.net Subject: IPR Disclosure: Juniper's Statement of IPR related to draft-ietf-l2vpn-evpn-00 X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120412145306.25301.31446.idtracker@ietfa.amsl.com> Date: Thu, 12 Apr 2012 07:53:06 -0700 X-Mailman-Approved-At: Thu, 12 Apr 2012 15:04:36 -0700 Cc: l2vpn@ietf.org, giheron@cisco.com, ipr-announce@ietf.org, stbryant@cisco.com X-BeenThere: l2vpn@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, 12 Apr 2012 14:53:07 -0000 Dear Rahul Aggarwal, Ali Sajassi, Wim Henderickx, Dr. Nabil N. Bitar, Ravi = Shekhar, John Drake: An IPR disclosure that pertains to your Internet-Draft entitled "BGP MPLS = Based Ethernet VPN" (draft-ietf-l2vpn-evpn) was submitted to the IETF Secretariat= on 2012-04-01 and has been posted on the "IETF Page of Intellectual Property R= ights Disclosures" (https://datatracker.ietf.org/ipr/1751/). The title of the IPR disclosure is "Juniper's Statement of IPR related to draft-ietf-l2vpn- evpn-00.""); The IETF Secretariat From davari@broadcom.com Thu Apr 12 10:16:37 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F38021F8684 for ; Thu, 12 Apr 2012 10:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 W1EHtsXW+lj4 for ; Thu, 12 Apr 2012 10:16:37 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5505921F86A6 for ; Thu, 12 Apr 2012 10:16:35 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Thu, 12 Apr 2012 10:26:05 -0700 X-Server-Uuid: B730DE51-FC43-4C83-941F-F1F78A914BDD Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.131]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Thu, 12 Apr 2012 10:16:21 -0700 From: "Shahram Davari" To: "Henderickx, Wim (Wim)" , "'giles.heron@gmail.com'" , "'simon.delord@gmail.com'" , "'Alexander.Vainshtein@ecitele.com'" Date: Thu, 12 Apr 2012 10:16:20 -0700 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFdjZLWcpAE0uaMYACV/K6GQABa612ABVhJNA= Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6BC12CB953A@SJEXCHCCR02.corp.ad.broadcom.com> References: <14C7F4F06DB5814AB0DE29716C4F6D67E6673E75@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D67E6673E75@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6399CFA63E017015011-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 12 Apr 2012 15:04:36 -0700 Cc: "'l2vpn@ietf.org'" , "'Vladimir.Kleiner@ecitele.com'" , "'Andrew.Sergeev@ecitele.com'" , "'Idan.Kaspit@ecitele.com'" , "'Mishael.Wexler@ecitele.com'" , "'Rotem.Cohen@ecitele.com'" X-BeenThere: l2vpn@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, 12 Apr 2012 17:16:37 -0000 Hi, Wim is correct. CW flag requires extensive hardware change. Many implementa= tion don't even support CW. Thx Shahram -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of H= enderickx, Wim (Wim) Sent: Thursday, April 12, 2012 12:03 AM To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtei= n@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecite= le.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Co= hen@ecitele.com' Subject: Re: The status of the approaches to the E-Tree solution? The vlan approach is superior as it also works for eth only networks, etc. = On top some vendors indicate hw issues with the cw approach. As such we hav= e dropped more or less the cw approach. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Thursday, April 12, 2012 08:22 AM To: Simon Delord ; Alexander Vainshtein Cc: l2vpn@ietf.org ; Vladimir Kleiner ; Andrew Sergeev ; Idan Kaspit ; Mishael Wexler ; Rotem Cohe= n Subject: Re: The status of the approaches to the E-Tree solution? Sorry - the "anonymous presentation" was mine. I should possibly have put in a third column on the CW approach. And hopefully the minutes will be posted soon. We had various discussions, as Simon stated, and consensus seemed to be forming around the two alternatives of two PWEs or two VLANs. I believe three of the authors of the CW approach are also authors of the two VLAN approach and one is also an author of the two PWE approach. So perhaps it's best to let those four individuals say which approach they prefer and why? Giles On 10/04/2012 00:45, "Simon Delord" wrote: > Hi Alexander, >=20 > You are right, no discussion on the WG mailing list recently, but there > have been substantial discussions among the authors of various solution > drafts off the mailing list. As far as I know, no consensus yet before > ietf83, not sure the progress in the Paris WG meeting. I think the CW > approach has not been rejected by the WG yet, or the WG has not yet decid= ed > on which one to adopt. >=20 > Simon >=20 > 2012/4/8 Alexander Vainshtein >=20 >> Hi all, >>=20 >> Unfortunately I have not been able to attend the Paris IETF. >>=20 >> However, looking up the L2VPN proceedings, I've found a short anonymous >> presentation called "E-Tree Update" ( >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). This >> presentation discusses the differences of the E-Tree approaches based on >> dedicated VLANs (as in >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_text= =3D1) >> and multiple PWs between the PEs (as in >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?inclu= de_te >> xt=3D1) >> and completely ignores the solution based on usage of the CW in the PWs >> connecting the PEs (as in >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_text= =3D1 >> ). >>=20 >>=20 >>=20 >> The Minutes of the Paris L2VPN session are not yet available, but I wond= er >> whether the WG has taken a decision to reject the approach based on the = CW >> usage? I do not remember any recent discussion of this topic on the WG >> mailing list. >>=20 >>=20 >>=20 >> Regards, and lots of thanks in advance, >>=20 >> Sasha >>=20 >>=20 >>=20 >>=20 >>=20 >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please inform = us >> by e-mail, phone or fax, and then delete the original and all copies >> thereof. >>=20 From internet-drafts@ietf.org Fri Apr 13 06:18:22 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A7321F865F; Fri, 13 Apr 2012 06:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, FUZZY_VLIUM=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 CEWSgcn6wK0P; Fri, 13 Apr 2012 06:18:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AD021F85F4; Fri, 13 Apr 2012 06:18:22 -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-l2vpn-etree-reqt-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120413131822.31665.78773.idtracker@ietfa.amsl.com> Date: Fri, 13 Apr 2012 06:18:22 -0700 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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, 13 Apr 2012 13:18:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 2 Virtual Private Networks Work= ing Group of the IETF. Title : Requirements for MEF E-Tree Support in VPLS Author(s) : Raymond Key Simon Delord Frederic Jounay Lu Huang Zhihua Liu Manuel Paul Ruediger Kunze Nick Del Regno Joshua Rogers Filename : draft-ietf-l2vpn-etree-reqt-01.txt Pages : 14 Date : 2012-04-13 This document provides functional requirements for Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) support in Virtual Private LAN Service (VPLS). It is intended that potential solutions will use these requirements as guidelines. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-etree-reqt-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-l2vpn-etree-reqt-01.txt From yuqun.cao@gmail.com Sun Apr 15 05:05:35 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A0521F8712 for ; Sun, 15 Apr 2012 05:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HGhYTcnwQ42 for ; Sun, 15 Apr 2012 05:05:34 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2D66321F86F9 for ; Sun, 15 Apr 2012 05:05:34 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so3278148pbb.31 for ; Sun, 15 Apr 2012 05:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :x-mimeole:in-reply-to; bh=iSdAVpKozqU4kjJ/EwHIcZpju8ZJiNyWoYKysPA78VU=; b=Oten6vqPlbp7KXNDbgkKQXP6jO1jnVoUuOzQkShLX8jsoAm41SAKuTsLez54cGgff/ o3QVnAPR0zmJUiroKk4OuOAJP4wHTn9Jhi931mP1hqoooVjWxOtDmdToBe1YFyg0s0Xy S0D85vG/9c0/Mkekq+Sc9G4KQcmZ2alVC97u6FpzT44CkNIcpflryY8MF7UXa6gpVZbP w6pbWkwIYC+NLecYK5KGFnE5ZH4qbScgO6FGwhG8HX3Tr+WfLkgAT4lBelxfTKJ82YvM SAscIWgUZsjF3HuuYVw49yFVxwil8mKC5GqKol8q/hYA9JMqAZxiM5XO9fBdfQe18sVn ZC+A== Received: by 10.68.218.198 with SMTP id pi6mr16831204pbc.121.1334491533279; Sun, 15 Apr 2012 05:05:33 -0700 (PDT) Received: from v2comsam ([175.42.35.87]) by mx.google.com with ESMTPS id st4sm14555385pbc.51.2012.04.15.05.05.26 (version=SSLv3 cipher=OTHER); Sun, 15 Apr 2012 05:05:32 -0700 (PDT) From: "Sam Cao" To: References: Subject: RE: L2vpn Digest, Vol 95, Issue 16 Date: Sun, 15 Apr 2012 20:05:18 +0800 Message-ID: <108FBD7F1B8A416F9B8A17BA54AD088F@v2comsam> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Ac0Y3n6i2LC54OipTtOKVLbetSY0IgCGVn5w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: X-BeenThere: l2vpn@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: Sun, 15 Apr 2012 12:05:35 -0000 Hi all, 1) Is there any update on global VLAN-ID allocation for Dual-VLAN? I can not find any update on this. 2) The highlight of Dual-VLAN is, it supports eth-only network (from Wim). But I can not find such requirement in MEF 22.1 and other documents. Is this real requirement from carriers? 3) Dual-VLAN should strip VLAN-ID out after decapsulation on egress PE, but multi-PW seems simpler. In addition, if thinking of backward compatibility (there is legacy PE in E-Tree domain), shall we need one patch in Dual-VLAN approach? I guess we have to. Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of l2vpn-request@ietf.org Sent: Friday, April 13, 2012 3:00 AM To: l2vpn@ietf.org Subject: L2vpn Digest, Vol 95, Issue 16 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/l2vpn Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send L2vpn mailing list submissions to l2vpn@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/l2vpn or, via email, send a message with subject or body 'help' to l2vpn-request@ietf.org You can reach the person managing the list at l2vpn-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of L2vpn digest..." Today's Topics: 1. Re: The status of the approaches to the E-Tree solution? (Giles Heron) 2. Re: The status of the approaches to the E-Tree solution? (Henderickx, Wim (Wim)) 3. Fwd: Re: IPR Disclosure: Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn-arp-mediation-19 (Stewart Bryant) ---------------------------------------------------------------------- Message: 1 Date: Thu, 12 Apr 2012 07:22:08 +0100 From: Giles Heron To: Simon Delord , Alexander Vainshtein Cc: "l2vpn@ietf.org" , Vladimir Kleiner , Andrew Sergeev , Idan Kaspit , Mishael Wexler , Rotem Cohen Subject: Re: The status of the approaches to the E-Tree solution? Message-ID: Content-Type: text/plain; charset="US-ASCII" Sorry - the "anonymous presentation" was mine. I should possibly have put in a third column on the CW approach. And hopefully the minutes will be posted soon. We had various discussions, as Simon stated, and consensus seemed to be forming around the two alternatives of two PWEs or two VLANs. I believe three of the authors of the CW approach are also authors of the two VLAN approach and one is also an author of the two PWE approach. So perhaps it's best to let those four individuals say which approach they prefer and why? Giles On 10/04/2012 00:45, "Simon Delord" wrote: > Hi Alexander, > > You are right, no discussion on the WG mailing list recently, but there > have been substantial discussions among the authors of various solution > drafts off the mailing list. As far as I know, no consensus yet before > ietf83, not sure the progress in the Paris WG meeting. I think the CW > approach has not been rejected by the WG yet, or the WG has not yet decided > on which one to adopt. > > Simon > > 2012/4/8 Alexander Vainshtein > >> Hi all, >> >> Unfortunately I have not been able to attend the Paris IETF. >> >> However, looking up the L2VPN proceedings, I've found a short anonymous >> presentation called "E-Tree Update" ( >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). This >> presentation discusses the differences of the E-Tree approaches based on >> dedicated VLANs (as in >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_text=1) >> and multiple PWs between the PEs (as in >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?include_t e >> xt=1) >> and completely ignores the solution based on usage of the CW in the PWs >> connecting the PEs (as in >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_text=1 >> ). >> >> >> >> The Minutes of the Paris L2VPN session are not yet available, but I wonder >> whether the WG has taken a decision to reject the approach based on the CW >> usage? I do not remember any recent discussion of this topic on the WG >> mailing list. >> >> >> >> Regards, and lots of thanks in advance, >> >> Sasha >> >> >> >> >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please inform us >> by e-mail, phone or fax, and then delete the original and all copies >> thereof. >> ------------------------------ Message: 2 Date: Thu, 12 Apr 2012 09:02:49 +0200 From: "Henderickx, Wim (Wim)" To: "'giles.heron@gmail.com'" , "'simon.delord@gmail.com'" , "'Alexander.Vainshtein@ecitele.com'" Cc: "'l2vpn@ietf.org'" , "'Vladimir.Kleiner@ecitele.com'" , "'Andrew.Sergeev@ecitele.com'" , "'Idan.Kaspit@ecitele.com'" , "'Mishael.Wexler@ecitele.com'" , "'Rotem.Cohen@ecitele.com'" Subject: Re: The status of the approaches to the E-Tree solution? Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D67E6673E75@FRMRSSXCHMBSB1.dc-m.alcatel-lucent .com> Content-Type: text/plain; charset="iso-8859-1" The vlan approach is superior as it also works for eth only networks, etc. On top some vendors indicate hw issues with the cw approach. As such we have dropped more or less the cw approach. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Thursday, April 12, 2012 08:22 AM To: Simon Delord ; Alexander Vainshtein Cc: l2vpn@ietf.org ; Vladimir Kleiner ; Andrew Sergeev ; Idan Kaspit ; Mishael Wexler ; Rotem Cohen Subject: Re: The status of the approaches to the E-Tree solution? Sorry - the "anonymous presentation" was mine. I should possibly have put in a third column on the CW approach. And hopefully the minutes will be posted soon. We had various discussions, as Simon stated, and consensus seemed to be forming around the two alternatives of two PWEs or two VLANs. I believe three of the authors of the CW approach are also authors of the two VLAN approach and one is also an author of the two PWE approach. So perhaps it's best to let those four individuals say which approach they prefer and why? Giles On 10/04/2012 00:45, "Simon Delord" wrote: > Hi Alexander, > > You are right, no discussion on the WG mailing list recently, but there > have been substantial discussions among the authors of various solution > drafts off the mailing list. As far as I know, no consensus yet before > ietf83, not sure the progress in the Paris WG meeting. I think the CW > approach has not been rejected by the WG yet, or the WG has not yet decided > on which one to adopt. > > Simon > > 2012/4/8 Alexander Vainshtein > >> Hi all, >> >> Unfortunately I have not been able to attend the Paris IETF. >> >> However, looking up the L2VPN proceedings, I've found a short anonymous >> presentation called "E-Tree Update" ( >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). This >> presentation discusses the differences of the E-Tree approaches based on >> dedicated VLANs (as in >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_text=1) >> and multiple PWs between the PEs (as in >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?include_t e >> xt=1) >> and completely ignores the solution based on usage of the CW in the PWs >> connecting the PEs (as in >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_text=1 >> ). >> >> >> >> The Minutes of the Paris L2VPN session are not yet available, but I wonder >> whether the WG has taken a decision to reject the approach based on the CW >> usage? I do not remember any recent discussion of this topic on the WG >> mailing list. >> >> >> >> Regards, and lots of thanks in advance, >> >> Sasha >> >> >> >> >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please inform us >> by e-mail, phone or fax, and then delete the original and all copies >> thereof. >> ------------------------------ Message: 3 Date: Thu, 12 Apr 2012 18:57:13 +0100 From: Stewart Bryant To: IETF-IESG-Support via RT Cc: "l2vpn@ietf.org" , "l2vpn-chairs@tools.ietf.org" , draft-ietf-l2vpn-arp-mediation@tools.ietf.org, "iesg@ietf.org" , RFC Editor Subject: Fwd: Re: IPR Disclosure: Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn-arp-mediation-19 Message-ID: <4F871779.8050006@cisco.com> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" IESG Secretary In view of this late IPR disclosure, please initiate a new IETF Last Call on this draft. RFC Editor Please hold publication until the Last Call completes and I indicate that there is IETF consensus to proceed. Thanks Stewart -------- Original Message -------- Subject: Re: IPR Disclosure: Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn-arp-mediation-19 Date: Wed, 11 Apr 2012 08:19:58 -0400 From: Andrew G. Malis To: IETF Secretariat CC: hshah@ciena.com, giheron@cisco.com, vach.kompella@alcatel-lucent.com, erosen@cisco.com, l2vpn@ietf.org, ipr-announce@ietf.org, stbryant@cisco.com, andrew.dolganow@alcatel-lucent.com IPv6 support for ARP mediation was added in draft-ietf-l2vpn-arp-mediation-08, dated July 2007. The text of the patent directly refers to revision -09 of the draft, and at least one of the authors is an IETF regular. The patent was filed in January 2009 and awarded in May 2011. Why is it just being disclosed now? Thanks, Andy On Fri, Apr 6, 2012 at 9:12 AM, IETF Secretariat wrote: > > Dear Himanshu C. Shah, Giles Heron, Vach Kompella, Eric Rosen: > > An IPR disclosure that pertains to your Internet-Draft entitled "ARP Mediation > for IP Interworking of Layer 2 VPN" (draft-ietf-l2vpn-arp-mediation) was > submitted to the IETF Secretariat on 2012-03-29 and has been posted on the "IETF > Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1738/). The title of the IPR disclosure is > "Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn-arp- > mediation-19.""); > > The IETF Secretariat > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 16 ************************************* From lucy.yong@huawei.com Fri Apr 13 15:49:24 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8EF11E8142 for ; Fri, 13 Apr 2012 15:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=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 OO9LnKUv1zMD for ; Fri, 13 Apr 2012 15:49:23 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3609611E8135 for ; Fri, 13 Apr 2012 15:49:23 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFF03531; Fri, 13 Apr 2012 18:49:23 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Apr 2012 15:48:55 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Fri, 13 Apr 2012 15:48:48 -0700 From: Lucy yong To: "Henderickx, Wim (Wim)" , "'giles.heron@gmail.com'" , "'simon.delord@gmail.com'" , "'Alexander.Vainshtein@ecitele.com'" Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFe/4Txq0Y50G6N17p5MncdwABa612AFMldrA= Date: Fri, 13 Apr 2012 22:48:48 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D32649D4D@dfweml505-mbx> References: <14C7F4F06DB5814AB0DE29716C4F6D67E6673E75@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D67E6673E75@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 16 Apr 2012 01:27:49 -0700 Cc: "'l2vpn@ietf.org'" , "'Vladimir.Kleiner@ecitele.com'" , "'Andrew.Sergeev@ecitele.com'" , "'Idan.Kaspit@ecitele.com'" , "'Mishael.Wexler@ecitele.com'" , "'Rotem.Cohen@ecitele.com'" X-BeenThere: l2vpn@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, 13 Apr 2012 22:49:24 -0000 Agree with Wim. VLAN approach is the best solution for E-Tree.=20 Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of H= enderickx, Wim (Wim) Sent: Thursday, April 12, 2012 2:03 AM To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtei= n@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecite= le.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Co= hen@ecitele.com' Subject: Re: The status of the approaches to the E-Tree solution? The vlan approach is superior as it also works for eth only networks, etc. = On top some vendors indicate hw issues with the cw approach. As such we hav= e dropped more or less the cw approach. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Thursday, April 12, 2012 08:22 AM To: Simon Delord ; Alexander Vainshtein Cc: l2vpn@ietf.org ; Vladimir Kleiner ; Andrew Sergeev ; Idan Kaspit ; Mishael Wexler ; Rotem Cohe= n Subject: Re: The status of the approaches to the E-Tree solution? Sorry - the "anonymous presentation" was mine. I should possibly have put in a third column on the CW approach. And hopefully the minutes will be posted soon. We had various discussions, as Simon stated, and consensus seemed to be forming around the two alternatives of two PWEs or two VLANs. I believe three of the authors of the CW approach are also authors of the two VLAN approach and one is also an author of the two PWE approach. So perhaps it's best to let those four individuals say which approach they prefer and why? Giles On 10/04/2012 00:45, "Simon Delord" wrote: > Hi Alexander, >=20 > You are right, no discussion on the WG mailing list recently, but there > have been substantial discussions among the authors of various solution > drafts off the mailing list. As far as I know, no consensus yet before > ietf83, not sure the progress in the Paris WG meeting. I think the CW > approach has not been rejected by the WG yet, or the WG has not yet decid= ed > on which one to adopt. >=20 > Simon >=20 > 2012/4/8 Alexander Vainshtein >=20 >> Hi all, >>=20 >> Unfortunately I have not been able to attend the Paris IETF. >>=20 >> However, looking up the L2VPN proceedings, I've found a short anonymous >> presentation called "E-Tree Update" ( >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). This >> presentation discusses the differences of the E-Tree approaches based on >> dedicated VLANs (as in >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_text= =3D1) >> and multiple PWs between the PEs (as in >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?inclu= de_te >> xt=3D1) >> and completely ignores the solution based on usage of the CW in the PWs >> connecting the PEs (as in >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_text= =3D1 >> ). >>=20 >>=20 >>=20 >> The Minutes of the Paris L2VPN session are not yet available, but I wond= er >> whether the WG has taken a decision to reject the approach based on the = CW >> usage? I do not remember any recent discussion of this topic on the WG >> mailing list. >>=20 >>=20 >>=20 >> Regards, and lots of thanks in advance, >>=20 >> Sasha >>=20 >>=20 >>=20 >>=20 >>=20 >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please inform = us >> by e-mail, phone or fax, and then delete the original and all copies >> thereof. >>=20 From josh.rogers@twcable.com Mon Apr 16 06:36:06 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F58321F86D5 for ; Mon, 16 Apr 2012 06:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.838 X-Spam-Level: X-Spam-Status: No, score=0.838 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HS_INDEX_PARAM=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 zIVjj3tzVZUt for ; Mon, 16 Apr 2012 06:36:06 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id B295B21F8690 for ; Mon, 16 Apr 2012 06:36:05 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,428,1330923600"; d="scan'208";a="351628796" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 16 Apr 2012 09:34:09 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Mon, 16 Apr 2012 09:35:04 -0400 From: "Rogers, Josh" To: Lucy yong , "Henderickx, Wim (Wim)" , "'giles.heron@gmail.com'" , "'simon.delord@gmail.com'" , "'Alexander.Vainshtein@ecitele.com'" Date: Mon, 16 Apr 2012 09:35:04 -0400 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFe/4Txq0Y50G6N17p5MncdwABa612AFMldrAAg7gO1w== Message-ID: 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-Mailman-Approved-At: Mon, 16 Apr 2012 06:37:06 -0700 Cc: "'l2vpn@ietf.org'" , "'Vladimir.Kleiner@ecitele.com'" , "'Andrew.Sergeev@ecitele.com'" , "'Idan.Kaspit@ecitele.com'" , "'Mishael.Wexler@ecitele.com'" , "'Rotem.Cohen@ecitele.com'" X-BeenThere: l2vpn@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, 16 Apr 2012 13:36:06 -0000 I believe the initial question was in regard to the CW method. Are you say= ing that you no longer are interested in that method in preference of the d= ual vlan method? Lucy yong wrote: Agree with Wim. VLAN approach is the best solution for E-Tree. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of H= enderickx, Wim (Wim) Sent: Thursday, April 12, 2012 2:03 AM To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtei= n@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecite= le.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Co= hen@ecitele.com' Subject: Re: The status of the approaches to the E-Tree solution? The vlan approach is superior as it also works for eth only networks, etc. = On top some vendors indicate hw issues with the cw approach. As such we hav= e dropped more or less the cw approach. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Thursday, April 12, 2012 08:22 AM To: Simon Delord ; Alexander Vainshtein Cc: l2vpn@ietf.org ; Vladimir Kleiner ; Andrew Sergeev ; Idan Kaspit ; Mishael Wexler ; Rotem Cohe= n Subject: Re: The status of the approaches to the E-Tree solution? Sorry - the "anonymous presentation" was mine. I should possibly have put in a third column on the CW approach. And hopefully the minutes will be posted soon. We had various discussions, as Simon stated, and consensus seemed to be forming around the two alternatives of two PWEs or two VLANs. I believe three of the authors of the CW approach are also authors of the two VLAN approach and one is also an author of the two PWE approach. So perhaps it's best to let those four individuals say which approach they prefer and why? Giles On 10/04/2012 00:45, "Simon Delord" wrote: > Hi Alexander, > > You are right, no discussion on the WG mailing list recently, but there > have been substantial discussions among the authors of various solution > drafts off the mailing list. As far as I know, no consensus yet before > ietf83, not sure the progress in the Paris WG meeting. I think the CW > approach has not been rejected by the WG yet, or the WG has not yet decid= ed > on which one to adopt. > > Simon > > 2012/4/8 Alexander Vainshtein > >> Hi all, >> >> Unfortunately I have not been able to attend the Paris IETF. >> >> However, looking up the L2VPN proceedings, I've found a short anonymous >> presentation called "E-Tree Update" ( >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). This >> presentation discusses the differences of the E-Tree approaches based on >> dedicated VLANs (as in >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_text= =3D1) >> and multiple PWs between the PEs (as in >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?inclu= de_te >> xt=3D1) >> and completely ignores the solution based on usage of the CW in the PWs >> connecting the PEs (as in >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_text= =3D1 >> ). >> >> >> >> The Minutes of the Paris L2VPN session are not yet available, but I wond= er >> whether the WG has taken a decision to reject the approach based on the = CW >> usage? I do not remember any recent discussion of this topic on the WG >> mailing list. >> >> >> >> Regards, and lots of thanks in advance, >> >> Sasha >> >> >> >> >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please inform = us >> by e-mail, phone or fax, and then delete the original and all copies >> thereof. >> This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From lucy.yong@huawei.com Mon Apr 16 08:08:04 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185B421F8690 for ; Mon, 16 Apr 2012 08:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=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 TjgCji9nLgpO for ; Mon, 16 Apr 2012 08:08:03 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 28F4E21F8694 for ; Mon, 16 Apr 2012 08:08:03 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEY54662; Mon, 16 Apr 2012 11:08:02 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Apr 2012 08:06:02 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Mon, 16 Apr 2012 08:05:13 -0700 From: Lucy yong To: "Rogers, Josh" , "Henderickx, Wim (Wim)" , "'giles.heron@gmail.com'" , "'simon.delord@gmail.com'" , "'Alexander.Vainshtein@ecitele.com'" Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFe/4Txq0Y50G6N17p5MncdwABa612AFMldrAAg7gO1wACovJQ Date: Mon, 16 Apr 2012 15:06:01 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D32649F44@dfweml505-mbx> 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.155.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 16 Apr 2012 09:24:13 -0700 Cc: "'l2vpn@ietf.org'" , "'Vladimir.Kleiner@ecitele.com'" , "'Andrew.Sergeev@ecitele.com'" , "'Idan.Kaspit@ecitele.com'" , "'Mishael.Wexler@ecitele.com'" , "'Rotem.Cohen@ecitele.com'" X-BeenThere: l2vpn@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, 16 Apr 2012 15:08:04 -0000 In my mind, the VLAN approach means dual vlan method. The main concern for CW approach is hardware support. Two PW approach can be complex too if the VPLS instance for E-Tree uses P2P= PW for unicast traffic and P2MP PW for broadcast and unknown unicast traff= ic, and some P2MP PWs for multicast traffic. It may double all of them. E-tree is an Ethernet service and there is already VLAN based solution in I= EEE, can we just utilize it without complicating VPLS transport constructio= n? This also makes interworking with Eth only network easier. Cheers, Lucy -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Monday, April 16, 2012 8:35 AM To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; 'simon.delor= d@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecite= le.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Co= hen@ecitele.com' Subject: RE: The status of the approaches to the E-Tree solution? I believe the initial question was in regard to the CW method. Are you say= ing that you no longer are interested in that method in preference of the d= ual vlan method? Lucy yong wrote: Agree with Wim. VLAN approach is the best solution for E-Tree. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of H= enderickx, Wim (Wim) Sent: Thursday, April 12, 2012 2:03 AM To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtei= n@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecite= le.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Co= hen@ecitele.com' Subject: Re: The status of the approaches to the E-Tree solution? The vlan approach is superior as it also works for eth only networks, etc. = On top some vendors indicate hw issues with the cw approach. As such we hav= e dropped more or less the cw approach. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Thursday, April 12, 2012 08:22 AM To: Simon Delord ; Alexander Vainshtein Cc: l2vpn@ietf.org ; Vladimir Kleiner ; Andrew Sergeev ; Idan Kaspit ; Mishael Wexler ; Rotem Cohe= n Subject: Re: The status of the approaches to the E-Tree solution? Sorry - the "anonymous presentation" was mine. I should possibly have put in a third column on the CW approach. And hopefully the minutes will be posted soon. We had various discussions, as Simon stated, and consensus seemed to be forming around the two alternatives of two PWEs or two VLANs. I believe three of the authors of the CW approach are also authors of the two VLAN approach and one is also an author of the two PWE approach. So perhaps it's best to let those four individuals say which approach they prefer and why? Giles On 10/04/2012 00:45, "Simon Delord" wrote: > Hi Alexander, > > You are right, no discussion on the WG mailing list recently, but there > have been substantial discussions among the authors of various solution > drafts off the mailing list. As far as I know, no consensus yet before > ietf83, not sure the progress in the Paris WG meeting. I think the CW > approach has not been rejected by the WG yet, or the WG has not yet decid= ed > on which one to adopt. > > Simon > > 2012/4/8 Alexander Vainshtein > >> Hi all, >> >> Unfortunately I have not been able to attend the Paris IETF. >> >> However, looking up the L2VPN proceedings, I've found a short anonymous >> presentation called "E-Tree Update" ( >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). This >> presentation discusses the differences of the E-Tree approaches based on >> dedicated VLANs (as in >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_text= =3D1) >> and multiple PWs between the PEs (as in >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?inclu= de_te >> xt=3D1) >> and completely ignores the solution based on usage of the CW in the PWs >> connecting the PEs (as in >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_text= =3D1 >> ). >> >> >> >> The Minutes of the Paris L2VPN session are not yet available, but I wond= er >> whether the WG has taken a decision to reject the approach based on the = CW >> usage? I do not remember any recent discussion of this topic on the WG >> mailing list. >> >> >> >> Regards, and lots of thanks in advance, >> >> Sasha >> >> >> >> >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please inform = us >> by e-mail, phone or fax, and then delete the original and all copies >> thereof. >> This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From david.i.allan@ericsson.com Mon Apr 16 10:19:30 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FD411E80A0 for ; Mon, 16 Apr 2012 10:19:30 -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=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 bkvRrL8xlIIC for ; Mon, 16 Apr 2012 10:19:29 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id BDB2011E809D for ; Mon, 16 Apr 2012 10:19:29 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q3GHJFML011714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Apr 2012 12:19:16 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 16 Apr 2012 13:19:15 -0400 From: David Allan I To: Lucy yong , "Henderickx, Wim (Wim)" , "'giles.heron@gmail.com'" , "'simon.delord@gmail.com'" , "'Alexander.Vainshtein@ecitele.com'" Date: Mon, 16 Apr 2012 13:19:13 -0400 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFe/4Txq0Y50G6N17p5MncdwABa612AFMldrAAi4ttAA== Message-ID: <60C093A41B5E45409A19D42CF7786DFD522ED58786@EUSAACMS0703.eamcs.ericsson.se> References: <14C7F4F06DB5814AB0DE29716C4F6D67E6673E75@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <2691CE0099834E4A9C5044EEC662BB9D32649D4D@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D32649D4D@dfweml505-mbx> 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-Mailman-Approved-At: Mon, 16 Apr 2012 11:09:26 -0700 Cc: "'l2vpn@ietf.org'" , "'Vladimir.Kleiner@ecitele.com'" , "'Andrew.Sergeev@ecitele.com'" , "'Idan.Kaspit@ecitele.com'" , "'Mishael.Wexler@ecitele.com'" , "'Rotem.Cohen@ecitele.com'" X-BeenThere: l2vpn@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, 16 Apr 2012 17:19:31 -0000 +1=20 -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of L= ucy yong Sent: Friday, April 13, 2012 3:49 PM To: Henderickx, Wim (Wim); 'giles.heron@gmail.com'; 'simon.delord@gmail.com= '; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecite= le.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Co= hen@ecitele.com' Subject: RE: The status of the approaches to the E-Tree solution? Agree with Wim. VLAN approach is the best solution for E-Tree.=20 Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of H= enderickx, Wim (Wim) Sent: Thursday, April 12, 2012 2:03 AM To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtei= n@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecite= le.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Co= hen@ecitele.com' Subject: Re: The status of the approaches to the E-Tree solution? The vlan approach is superior as it also works for eth only networks, etc. = On top some vendors indicate hw issues with the cw approach. As such we hav= e dropped more or less the cw approach. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Thursday, April 12, 2012 08:22 AM To: Simon Delord ; Alexander Vainshtein Cc: l2vpn@ietf.org ; Vladimir Kleiner ; Andrew Sergeev ; Idan Kaspit ; Mishael Wexler ; Rotem Cohe= n Subject: Re: The status of the approaches to the E-Tree solution? Sorry - the "anonymous presentation" was mine. I should possibly have put = in a third column on the CW approach. And hopefully the minutes will be po= sted soon. We had various discussions, as Simon stated, and consensus seemed to be for= ming around the two alternatives of two PWEs or two VLANs. I believe three= of the authors of the CW approach are also authors of the two VLAN approac= h and one is also an author of the two PWE approach. So perhaps it's best t= o let those four individuals say which approach they prefer and why? Giles On 10/04/2012 00:45, "Simon Delord" wrote: > Hi Alexander, >=20 > You are right, no discussion on the WG mailing list recently, but=20 > there have been substantial discussions among the authors of various=20 > solution drafts off the mailing list. As far as I know, no consensus=20 > yet before ietf83, not sure the progress in the Paris WG meeting. I=20 > think the CW approach has not been rejected by the WG yet, or the WG=20 > has not yet decided on which one to adopt. >=20 > Simon >=20 > 2012/4/8 Alexander Vainshtein >=20 >> Hi all, >>=20 >> Unfortunately I have not been able to attend the Paris IETF. >>=20 >> However, looking up the L2VPN proceedings, I've found a short=20 >> anonymous presentation called "E-Tree Update" (=20 >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx).=20 >> This presentation discusses the differences of the E-Tree approaches=20 >> based on dedicated VLANs (as in >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >> ext=3D1) and multiple PWs between the PEs (as in=20 >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >> clude_te >> xt=3D1) >> and completely ignores the solution based on usage of the CW in the=20 >> PWs connecting the PEs (as in >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >> ext=3D1 >> ). >>=20 >>=20 >>=20 >> The Minutes of the Paris L2VPN session are not yet available, but I=20 >> wonder whether the WG has taken a decision to reject the approach=20 >> based on the CW usage? I do not remember any recent discussion of=20 >> this topic on the WG mailing list. >>=20 >>=20 >>=20 >> Regards, and lots of thanks in advance, >>=20 >> Sasha >>=20 >>=20 >>=20 >>=20 >>=20 >> This e-mail message is intended for the recipient only and contains=20 >> information which is CONFIDENTIAL and which may be proprietary to ECI=20 >> Telecom. If you have received this transmission in error, please=20 >> inform us by e-mail, phone or fax, and then delete the original and=20 >> all copies thereof. >>=20 From jeff.tantsura@ericsson.com Mon Apr 16 11:54:56 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339FD21F85B6 for ; Mon, 16 Apr 2012 11:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 YZ25xmsvpdVC for ; Mon, 16 Apr 2012 11:54:55 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7959B21F8572 for ; Mon, 16 Apr 2012 11:54:55 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3GIsmBc007605; Mon, 16 Apr 2012 13:54:49 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.157]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 16 Apr 2012 14:54:41 -0400 From: Jeff Tantsura To: David Allan I Date: Mon, 16 Apr 2012 14:54:34 -0400 Subject: Re: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0cAmDULtTTm4jhTCWQHVHWxHxCsQ== Message-ID: References: <14C7F4F06DB5814AB0DE29716C4F6D67E6673E75@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <2691CE0099834E4A9C5044EEC662BB9D32649D4D@dfweml505-mbx> <60C093A41B5E45409A19D42CF7786DFD522ED58786@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD522ED58786@EUSAACMS0703.eamcs.ericsson.se> 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-Mailman-Approved-At: Tue, 17 Apr 2012 05:35:39 -0700 Cc: "l2vpn@ietf.org" , "Vladimir.Kleiner@ecitele.com" , "Andrew.Sergeev@ecitele.com" , "Idan.Kaspit@ecitele.com" , "Mishael.Wexler@ecitele.com" , "Rotem.Cohen@ecitele.com" X-BeenThere: l2vpn@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, 16 Apr 2012 18:54:56 -0000 +1 Regards, Jeff On Apr 16, 2012, at 11:09, "David Allan I" wro= te: > +1=20 >=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of= Lucy yong > Sent: Friday, April 13, 2012 3:49 PM > To: Henderickx, Wim (Wim); 'giles.heron@gmail.com'; 'simon.delord@gmail.c= om'; 'Alexander.Vainshtein@ecitele.com' > Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@eci= tele.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' > Subject: RE: The status of the approaches to the E-Tree solution? >=20 > Agree with Wim. VLAN approach is the best solution for E-Tree.=20 >=20 > Lucy >=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of= Henderickx, Wim (Wim) > Sent: Thursday, April 12, 2012 2:03 AM > To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainsht= ein@ecitele.com' > Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@eci= tele.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' > Subject: Re: The status of the approaches to the E-Tree solution? >=20 > The vlan approach is superior as it also works for eth only networks, etc= . On top some vendors indicate hw issues with the cw approach. As such we h= ave dropped more or less the cw approach. >=20 > Cheers, > Wim > _________________ > sent from blackberry >=20 > ----- Original Message ----- > From: Giles Heron [mailto:giles.heron@gmail.com] > Sent: Thursday, April 12, 2012 08:22 AM > To: Simon Delord ; Alexander Vainshtein > Cc: l2vpn@ietf.org ; Vladimir Kleiner ; Andrew Sergeev ; Idan Kaspit ; Mishael Wexler ; Rotem Co= hen > Subject: Re: The status of the approaches to the E-Tree solution? >=20 > Sorry - the "anonymous presentation" was mine. I should possibly have pu= t in a third column on the CW approach. And hopefully the minutes will be = posted soon. >=20 > We had various discussions, as Simon stated, and consensus seemed to be f= orming around the two alternatives of two PWEs or two VLANs. I believe thr= ee of the authors of the CW approach are also authors of the two VLAN appro= ach and one is also an author of the two PWE approach. So perhaps it's best= to let those four individuals say which approach they prefer and why? >=20 > Giles >=20 > On 10/04/2012 00:45, "Simon Delord" wrote: >=20 >> Hi Alexander, >>=20 >> You are right, no discussion on the WG mailing list recently, but=20 >> there have been substantial discussions among the authors of various=20 >> solution drafts off the mailing list. As far as I know, no consensus=20 >> yet before ietf83, not sure the progress in the Paris WG meeting. I=20 >> think the CW approach has not been rejected by the WG yet, or the WG=20 >> has not yet decided on which one to adopt. >>=20 >> Simon >>=20 >> 2012/4/8 Alexander Vainshtein >>=20 >>> Hi all, >>>=20 >>> Unfortunately I have not been able to attend the Paris IETF. >>>=20 >>> However, looking up the L2VPN proceedings, I've found a short=20 >>> anonymous presentation called "E-Tree Update" (=20 >>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx).=20 >>> This presentation discusses the differences of the E-Tree approaches=20 >>> based on dedicated VLANs (as in >>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>> ext=3D1) and multiple PWs between the PEs (as in=20 >>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>> clude_te >>> xt=3D1) >>> and completely ignores the solution based on usage of the CW in the=20 >>> PWs connecting the PEs (as in >>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>> ext=3D1 >>> ). >>>=20 >>>=20 >>>=20 >>> The Minutes of the Paris L2VPN session are not yet available, but I=20 >>> wonder whether the WG has taken a decision to reject the approach=20 >>> based on the CW usage? I do not remember any recent discussion of=20 >>> this topic on the WG mailing list. >>>=20 >>>=20 >>>=20 >>> Regards, and lots of thanks in advance, >>>=20 >>> Sasha >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> This e-mail message is intended for the recipient only and contains=20 >>> information which is CONFIDENTIAL and which may be proprietary to ECI=20 >>> Telecom. If you have received this transmission in error, please=20 >>> inform us by e-mail, phone or fax, and then delete the original and=20 >>> all copies thereof. >>>=20 >=20 >=20 >=20 >=20 From DanielC@orckit.com Mon Apr 16 14:08:11 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7554221F866D for ; Mon, 16 Apr 2012 14:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.377 X-Spam-Level: * X-Spam-Status: No, score=1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_ILLEGAL_IP=1.908, RCVD_NUMERIC_HELO=2.067] 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 fPR3IFz5wKXJ for ; Mon, 16 Apr 2012 14:08:10 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF5621F866A for ; Mon, 16 Apr 2012 14:08:09 -0700 (PDT) Received: from 1.1.40.5 ([1.1.40.5]) by tlvmail1.corrigent.com ([1.1.40.5]) with Microsoft Exchange Server HTTP-DAV ; Mon, 16 Apr 2012 21:10:23 +0000 Date: Tue, 17 Apr 2012 00:08:02 +0300 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <115801cd1c15$566895a6$05280101@corrigent.com> Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFe/4Txq0Y50G6N17p5MncdwABa612AFMldrAAg7gO1wACovJQAA1D5U0= X-MimeOLE: Produced By Microsoft Exchange V6.5 Importance: normal From: "Daniel Cohn" To: "Lucy yong" , "Rogers, Josh" , "Henderickx, Wim (Wim)" , , , MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 17 Apr 2012 05:35:38 -0700 Cc: l2vpn@ietf.org, Vladimir.Kleiner@ecitele.com, Andrew.Sergeev@ecitele.com, Idan.Kaspit@ecitele.com, Mishael.Wexler@ecitele.com, Rotem.Cohen@ecitele.com X-BeenThere: l2vpn@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, 16 Apr 2012 21:08:11 -0000 Hi lucy,=0A= =0A= As we discussed extensively in the list, and as reflected in giles = slide, 2 pws are only needed between pes with both root and leaf acs, = which will typically be a small minority.=0A= Also as per giles slide, dual vlan can have scalability issues due to = additional lookup and double use of vlans in internal emulated lan = interface. Also there are potential backward compatibility issues with = silicon that doesn't support vlan mapping.=0A= =0A= Regards,=0A= =0A= Daniel=0A= =0A= Thumb typed - please be tolerant=0A= =0A= Lucy yong wrote:=0A= =0A= In my mind, the VLAN approach means dual vlan method. The main concern for CW approach is hardware support. Two PW approach can be complex too if the VPLS instance for E-Tree uses = P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast = traffic, and some P2MP PWs for multicast traffic. It may double all of = them. E-tree is an Ethernet service and there is already VLAN based solution = in IEEE, can we just utilize it without complicating VPLS transport = construction? This also makes interworking with Eth only network easier. Cheers, Lucy -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Monday, April 16, 2012 8:35 AM To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; = 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; = 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; = 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' Subject: RE: The status of the approaches to the E-Tree solution? I believe the initial question was in regard to the CW method. Are you = saying that you no longer are interested in that method in preference of = the dual vlan method? Lucy yong wrote: Agree with Wim. VLAN approach is the best solution for E-Tree. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Henderickx, Wim (Wim) Sent: Thursday, April 12, 2012 2:03 AM To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; = 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; = 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; = 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' Subject: Re: The status of the approaches to the E-Tree solution? The vlan approach is superior as it also works for eth only networks, = etc. On top some vendors indicate hw issues with the cw approach. As = such we have dropped more or less the cw approach. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Thursday, April 12, 2012 08:22 AM To: Simon Delord ; Alexander Vainshtein = Cc: l2vpn@ietf.org ; Vladimir Kleiner = ; Andrew Sergeev = ; Idan Kaspit ; = Mishael Wexler ; Rotem Cohen = Subject: Re: The status of the approaches to the E-Tree solution? Sorry - the "anonymous presentation" was mine. I should possibly have = put in a third column on the CW approach. And hopefully the minutes will be posted soon. We had various discussions, as Simon stated, and consensus seemed to be forming around the two alternatives of two PWEs or two VLANs. I believe three of the authors of the CW approach are also authors of the two VLAN approach and one is also an author of the two PWE approach. So perhaps = it's best to let those four individuals say which approach they prefer and = why? Giles On 10/04/2012 00:45, "Simon Delord" wrote: > Hi Alexander, > > You are right, no discussion on the WG mailing list recently, but = there > have been substantial discussions among the authors of various = solution > drafts off the mailing list. As far as I know, no consensus yet before > ietf83, not sure the progress in the Paris WG meeting. I think the CW > approach has not been rejected by the WG yet, or the WG has not yet = decided > on which one to adopt. > > Simon > > 2012/4/8 Alexander Vainshtein > >> Hi all, >> >> Unfortunately I have not been able to attend the Paris IETF. >> >> However, looking up the L2VPN proceedings, I've found a short = anonymous >> presentation called "E-Tree Update" ( >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). = This >> presentation discusses the differences of the E-Tree approaches based = on >> dedicated VLANs (as in >> = http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_text=3D= 1) >> and multiple PWs between the PEs (as in >> = http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?includ= e_te >> xt=3D1) >> and completely ignores the solution based on usage of the CW in the = PWs >> connecting the PEs (as in >> = http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_text=3D= 1 >> ). >> >> >> >> The Minutes of the Paris L2VPN session are not yet available, but I = wonder >> whether the WG has taken a decision to reject the approach based on = the CW >> usage? I do not remember any recent discussion of this topic on the = WG >> mailing list. >> >> >> >> Regards, and lots of thanks in advance, >> >> Sasha >> >> >> >> >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please = inform us >> by e-mail, phone or fax, and then delete the original and all copies >> thereof. >> This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. From lucy.yong@huawei.com Mon Apr 16 14:40:52 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1493221F85B9 for ; Mon, 16 Apr 2012 14:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HS_INDEX_PARAM=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 ZJLxwE9TLh9U for ; Mon, 16 Apr 2012 14:40:51 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1833421F85B4 for ; Mon, 16 Apr 2012 14:40:51 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFG79104; Mon, 16 Apr 2012 17:40:50 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Apr 2012 14:38:49 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Mon, 16 Apr 2012 14:38:00 -0700 From: Lucy yong To: Daniel Cohn , "Rogers, Josh" , "Henderickx, Wim (Wim)" , "giles.heron@gmail.com" , "simon.delord@gmail.com" , "Alexander.Vainshtein@ecitele.com" Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFe/4Txq0Y50G6N17p5MncdwABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMA== Date: Mon, 16 Apr 2012 21:38:51 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264A1C0@dfweml505-mbx> References: <115801cd1c15$566895a6$05280101@corrigent.com> In-Reply-To: <115801cd1c15$566895a6$05280101@corrigent.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.231] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Tue, 17 Apr 2012 05:35:39 -0700 Cc: "l2vpn@ietf.org" , "Vladimir.Kleiner@ecitele.com" , "Andrew.Sergeev@ecitele.com" , "Idan.Kaspit@ecitele.com" , "Mishael.Wexler@ecitele.com" , "Rotem.Cohen@ecitele.com" X-BeenThere: l2vpn@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, 16 Apr 2012 21:40:52 -0000 DQpTbmlwcGVkLA0KDQpBcyB3ZSBkaXNjdXNzZWQgZXh0ZW5zaXZlbHkgaW4gdGhlIGxpc3QsIGFu ZCBhcyByZWZsZWN0ZWQgaW4gZ2lsZXMgc2xpZGUsIDIgcHdzIGFyZSBvbmx5IG5lZWRlZCBiZXR3 ZWVuIHBlcyB3aXRoIGJvdGggcm9vdCBhbmQgbGVhZiBhY3MsIHdoaWNoIHdpbGwgdHlwaWNhbGx5 IGJlIGEgc21hbGwgbWlub3JpdHkuDQpbW0xZXV0gRG9uJ3Qga25vdyBpZiB0aGUgYXNzdW1wdGlv biBpcyB0cnVlLiBFdmVuIGl0IGlzIHRoZSBjYXNlLCBib3RoIGFwcHJvYWNoZXMgY2FuIGJlbmVm aXQgZnJvbSBpdC4gSSB3YXMgb2ZmIGZvciBhIHdoaWxlIGFuZCBjYXB0dXJlcyBzb21lIGRpc2N1 c3Npb25zIG5vdy4gDQoNCkFsc28gYXMgcGVyIGdpbGVzIHNsaWRlLCBkdWFsIHZsYW4gY2FuIGhh dmUgc2NhbGFiaWxpdHkgaXNzdWVzIGR1ZSB0byBhZGRpdGlvbmFsIGxvb2t1cCBhbmQgZG91Ymxl IHVzZSBvZiB2bGFucyBpbiBpbnRlcm5hbCBlbXVsYXRlZCBsYW4gaW50ZXJmYWNlLiBBbHNvIHRo ZXJlIGFyZSBwb3RlbnRpYWwgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBpc3N1ZXMgd2l0aCBzaWxp Y29uIHRoYXQgZG9lc24ndCBzdXBwb3J0IHZsYW4gbWFwcGluZy4NCltbTFldXSBJIHdhcyBub3Qg aW4gSUVURjgzIG1lZXRpbmcgYW5kIHdhaXQgb24gdGhlIG1lZXRpbmcgbWludXRlcy4gSSBhbSBu b3QgY2xlYXIgb24gYWxsIHRoZSBpc3N1ZXMuIENvdWxkIHlvdSBiZSBtb3JlIHNwZWNpZmljPyBB cyBJIG1lbnRpb25lZCBpbiBiZWxvdywgdHdvIFBXIGFwcHJvYWNoIG1ha2VzIFZQTFMgdHJhbnNw b3J0IGNvbnN0cnVjdGlvbiBhbmQgcGFja2V0IGZvcndhcmRpbmcgbW9yZSBjb21wbGV4LCBJIGNh biBzZWUgcG90ZW50aWFsIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXNzdWVzIHdpdGggMiBQVyBz b2x1dGlvbi4gDQoNClJlZ2FyZHMsDQpMdWN5DQoNClJlZ2FyZHMsDQoNCkRhbmllbA0KDQpUaHVt YiB0eXBlZCAtIHBsZWFzZSBiZSB0b2xlcmFudA0KDQpMdWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3 ZWkuY29tPiB3cm90ZToNCg0KSW4gbXkgbWluZCwgdGhlIFZMQU4gYXBwcm9hY2ggbWVhbnMgZHVh bCB2bGFuIG1ldGhvZC4NCg0KVGhlIG1haW4gY29uY2VybiBmb3IgQ1cgYXBwcm9hY2ggaXMgaGFy ZHdhcmUgc3VwcG9ydC4NCg0KVHdvIFBXIGFwcHJvYWNoIGNhbiBiZSBjb21wbGV4IHRvbyBpZiB0 aGUgVlBMUyBpbnN0YW5jZSBmb3IgRS1UcmVlIHVzZXMgUDJQIFBXIGZvciB1bmljYXN0IHRyYWZm aWMgYW5kIFAyTVAgUFcgZm9yIGJyb2FkY2FzdCBhbmQgdW5rbm93biB1bmljYXN0IHRyYWZmaWMs IGFuZCBzb21lIFAyTVAgUFdzIGZvciBtdWx0aWNhc3QgdHJhZmZpYy4gSXQgbWF5IGRvdWJsZSBh bGwgb2YgdGhlbS4NCg0KRS10cmVlIGlzIGFuIEV0aGVybmV0IHNlcnZpY2UgYW5kIHRoZXJlIGlz IGFscmVhZHkgVkxBTiBiYXNlZCBzb2x1dGlvbiBpbiBJRUVFLCBjYW4gd2UganVzdCB1dGlsaXpl IGl0IHdpdGhvdXQgY29tcGxpY2F0aW5nIFZQTFMgdHJhbnNwb3J0IGNvbnN0cnVjdGlvbj8gVGhp cyBhbHNvIG1ha2VzIGludGVyd29ya2luZyB3aXRoIEV0aCBvbmx5IG5ldHdvcmsgZWFzaWVyLg0K DQpDaGVlcnMsDQpMdWN5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSb2dl cnMsIEpvc2ggW21haWx0bzpqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbV0gDQpTZW50OiBNb25kYXks IEFwcmlsIDE2LCAyMDEyIDg6MzUgQU0NClRvOiBMdWN5IHlvbmc7IEhlbmRlcmlja3gsIFdpbSAo V2ltKTsgJ2dpbGVzLmhlcm9uQGdtYWlsLmNvbSc7ICdzaW1vbi5kZWxvcmRAZ21haWwuY29tJzsg J0FsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tJw0KQ2M6ICdsMnZwbkBpZXRmLm9yZyc7 ICdWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tJzsgJ0FuZHJldy5TZXJnZWV2QGVjaXRlbGUu Y29tJzsgJ0lkYW4uS2FzcGl0QGVjaXRlbGUuY29tJzsgJ01pc2hhZWwuV2V4bGVyQGVjaXRlbGUu Y29tJzsgJ1JvdGVtLkNvaGVuQGVjaXRlbGUuY29tJw0KU3ViamVjdDogUkU6IFRoZSBzdGF0dXMg b2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCg0KSSBiZWxpZXZlIHRo ZSBpbml0aWFsIHF1ZXN0aW9uIHdhcyBpbiByZWdhcmQgdG8gdGhlIENXIG1ldGhvZC4gIEFyZSB5 b3Ugc2F5aW5nIHRoYXQgeW91IG5vIGxvbmdlciBhcmUgaW50ZXJlc3RlZCBpbiB0aGF0IG1ldGhv ZCBpbiBwcmVmZXJlbmNlIG9mIHRoZSBkdWFsIHZsYW4gbWV0aG9kPw0KDQoNCg0KTHVjeSB5b25n IDxsdWN5LnlvbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQoNCg0KQWdyZWUgd2l0aCBXaW0uIFZMQU4g YXBwcm9hY2ggaXMgdGhlIGJlc3Qgc29sdXRpb24gZm9yIEUtVHJlZS4NCg0KTHVjeQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIZW5kZXJpY2t4LCBXaW0g KFdpbSkNClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxMiwgMjAxMiAyOjAzIEFNDQpUbzogJ2dpbGVz Lmhlcm9uQGdtYWlsLmNvbSc7ICdzaW1vbi5kZWxvcmRAZ21haWwuY29tJzsgJ0FsZXhhbmRlci5W YWluc2h0ZWluQGVjaXRlbGUuY29tJw0KQ2M6ICdsMnZwbkBpZXRmLm9yZyc7ICdWbGFkaW1pci5L bGVpbmVyQGVjaXRlbGUuY29tJzsgJ0FuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tJzsgJ0lkYW4u S2FzcGl0QGVjaXRlbGUuY29tJzsgJ01pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tJzsgJ1JvdGVt LkNvaGVuQGVjaXRlbGUuY29tJw0KU3ViamVjdDogUmU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJv YWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCg0KVGhlIHZsYW4gYXBwcm9hY2ggaXMgc3Vw ZXJpb3IgYXMgaXQgYWxzbyB3b3JrcyBmb3IgZXRoIG9ubHkgbmV0d29ya3MsIGV0Yy4gT24gdG9w IHNvbWUgdmVuZG9ycyBpbmRpY2F0ZSBodyBpc3N1ZXMgd2l0aCB0aGUgY3cgYXBwcm9hY2guIEFz IHN1Y2ggd2UgaGF2ZSBkcm9wcGVkIG1vcmUgb3IgbGVzcyB0aGUgY3cgYXBwcm9hY2guDQoNCkNo ZWVycywNCldpbQ0KX19fX19fX19fX19fX19fX18NCnNlbnQgZnJvbSBibGFja2JlcnJ5DQoNCi0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IEdpbGVzIEhlcm9uIFttYWlsdG86Z2ls ZXMuaGVyb25AZ21haWwuY29tXQ0KU2VudDogVGh1cnNkYXksIEFwcmlsIDEyLCAyMDEyIDA4OjIy IEFNDQpUbzogU2ltb24gRGVsb3JkIDxzaW1vbi5kZWxvcmRAZ21haWwuY29tPjsgQWxleGFuZGVy IFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPg0KQ2M6IGwydnBu QGlldGYub3JnIDxsMnZwbkBpZXRmLm9yZz47IFZsYWRpbWlyIEtsZWluZXIgPFZsYWRpbWlyLkts ZWluZXJAZWNpdGVsZS5jb20+OyBBbmRyZXcgU2VyZ2VldiA8QW5kcmV3LlNlcmdlZXZAZWNpdGVs ZS5jb20+OyBJZGFuIEthc3BpdCA8SWRhbi5LYXNwaXRAZWNpdGVsZS5jb20+OyBNaXNoYWVsIFdl eGxlciA8TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb20+OyBSb3RlbSBDb2hlbiA8Um90ZW0uQ29o ZW5AZWNpdGVsZS5jb20+DQpTdWJqZWN0OiBSZTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hl cyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KDQpTb3JyeSAtIHRoZSAiYW5vbnltb3VzIHByZXNl bnRhdGlvbiIgd2FzIG1pbmUuICBJIHNob3VsZCBwb3NzaWJseSBoYXZlIHB1dA0KaW4gYSB0aGly ZCBjb2x1bW4gb24gdGhlIENXIGFwcHJvYWNoLiAgQW5kIGhvcGVmdWxseSB0aGUgbWludXRlcyB3 aWxsIGJlDQpwb3N0ZWQgc29vbi4NCg0KV2UgaGFkIHZhcmlvdXMgZGlzY3Vzc2lvbnMsIGFzIFNp bW9uIHN0YXRlZCwgYW5kIGNvbnNlbnN1cyBzZWVtZWQgdG8gYmUNCmZvcm1pbmcgYXJvdW5kIHRo ZSB0d28gYWx0ZXJuYXRpdmVzIG9mIHR3byBQV0VzIG9yIHR3byBWTEFOcy4gIEkgYmVsaWV2ZQ0K dGhyZWUgb2YgdGhlIGF1dGhvcnMgb2YgdGhlIENXIGFwcHJvYWNoIGFyZSBhbHNvIGF1dGhvcnMg b2YgdGhlIHR3byBWTEFODQphcHByb2FjaCBhbmQgb25lIGlzIGFsc28gYW4gYXV0aG9yIG9mIHRo ZSB0d28gUFdFIGFwcHJvYWNoLiBTbyBwZXJoYXBzIGl0J3MNCmJlc3QgdG8gbGV0IHRob3NlIGZv dXIgaW5kaXZpZHVhbHMgc2F5IHdoaWNoIGFwcHJvYWNoIHRoZXkgcHJlZmVyIGFuZCB3aHk/DQoN CkdpbGVzDQoNCk9uIDEwLzA0LzIwMTIgMDA6NDUsICJTaW1vbiBEZWxvcmQiIDxzaW1vbi5kZWxv cmRAZ21haWwuY29tPiB3cm90ZToNCg0KPiBIaSBBbGV4YW5kZXIsDQo+DQo+IFlvdSBhcmUgcmln aHQsIG5vIGRpc2N1c3Npb24gb24gdGhlIFdHIG1haWxpbmcgbGlzdCByZWNlbnRseSwgYnV0IHRo ZXJlDQo+IGhhdmUgYmVlbiBzdWJzdGFudGlhbCBkaXNjdXNzaW9ucyBhbW9uZyB0aGUgYXV0aG9y cyBvZiB2YXJpb3VzIHNvbHV0aW9uDQo+IGRyYWZ0cyBvZmYgdGhlIG1haWxpbmcgbGlzdC4gQXMg ZmFyIGFzIEkga25vdywgbm8gY29uc2Vuc3VzIHlldCBiZWZvcmUNCj4gaWV0ZjgzLCBub3Qgc3Vy ZSB0aGUgcHJvZ3Jlc3MgaW4gdGhlIFBhcmlzIFdHIG1lZXRpbmcuIEkgdGhpbmsgdGhlIENXDQo+ IGFwcHJvYWNoIGhhcyBub3QgYmVlbiByZWplY3RlZCBieSB0aGUgV0cgeWV0LCBvciB0aGUgV0cg aGFzIG5vdCB5ZXQgZGVjaWRlZA0KPiBvbiB3aGljaCBvbmUgdG8gYWRvcHQuDQo+DQo+IFNpbW9u DQo+DQo+IDIwMTIvNC84IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbT4NCj4NCj4+ICBIaSBhbGwsDQo+Pg0KPj4gVW5mb3J0dW5hdGVseSBJIGhh dmUgbm90IGJlZW4gYWJsZSB0byBhdHRlbmQgdGhlIFBhcmlzIElFVEYuDQo+Pg0KPj4gSG93ZXZl ciwgbG9va2luZyB1cCB0aGUgTDJWUE4gcHJvY2VlZGluZ3MsIEkndmUgZm91bmQgYSBzaG9ydCBh bm9ueW1vdXMNCj4+IHByZXNlbnRhdGlvbiBjYWxsZWQgIkUtVHJlZSBVcGRhdGUiICAoDQo+PiBo dHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzgzL3NsaWRlcy9zbGlkZXMtODMtbDJ2cG4t MS5wcHR4KS4gVGhpcw0KPj4gcHJlc2VudGF0aW9uIGRpc2N1c3NlcyB0aGUgZGlmZmVyZW5jZXMg b2YgdGhlIEUtVHJlZSBhcHByb2FjaGVzIGJhc2VkIG9uDQo+PiBkZWRpY2F0ZWQgVkxBTnMgKGFz IGluDQo+PiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNhby1sMnZwbi12 cGxzLWV0cmVlLz9pbmNsdWRlX3RleHQ9MSkNCj4+IGFuZCBtdWx0aXBsZSBQV3MgYmV0d2VlbiB0 aGUgUEVzIChhcyBpbg0KPj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1y YW0tbDJ2cG4tZXRyZWUtbXVsdGlwbGUtcHcvP2luY2x1ZGVfdGUNCj4+IHh0PTEpDQo+PiBhbmQg Y29tcGxldGVseSBpZ25vcmVzIHRoZSBzb2x1dGlvbiBiYXNlZCBvbiB1c2FnZSBvZiB0aGUgQ1cg aW4gdGhlIFBXcw0KPj4gY29ubmVjdGluZyB0aGUgUEVzIChhcyBpbg0KPj4gaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rZXktbDJ2cG4tdnBscy1ldHJlZS8/aW5jbHVkZV90 ZXh0PTENCj4+ICkuDQo+Pg0KPj4NCj4+DQo+PiBUaGUgTWludXRlcyBvZiB0aGUgUGFyaXMgTDJW UE4gc2Vzc2lvbiBhcmUgbm90IHlldCBhdmFpbGFibGUsIGJ1dCBJIHdvbmRlcg0KPj4gd2hldGhl ciB0aGUgV0cgaGFzIHRha2VuIGEgZGVjaXNpb24gdG8gcmVqZWN0IHRoZSBhcHByb2FjaCBiYXNl ZCBvbiB0aGUgQ1cNCj4+IHVzYWdlPyBJIGRvIG5vdCByZW1lbWJlciBhbnkgcmVjZW50IGRpc2N1 c3Npb24gb2YgdGhpcyB0b3BpYyBvbiB0aGUgV0cNCj4+IG1haWxpbmcgbGlzdC4NCj4+DQo+Pg0K Pj4NCj4+IFJlZ2FyZHMsIGFuZCBsb3RzIG9mIHRoYW5rcyBpbiBhZHZhbmNlLA0KPj4NCj4+IFNh c2hhDQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+IFRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5k ZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMNCj4+IGluZm9ybWF0aW9uIHdo aWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSQ0K Pj4gVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJy b3IsIHBsZWFzZSBpbmZvcm0gdXMNCj4+IGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhl biBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbGwgY29waWVzDQo+PiB0aGVyZW9mLg0KPj4NCg0K DQoNCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJp dmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcg dG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVz c2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWls LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmli dXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVu dHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFu ZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5k IGFueSBwcmludG91dC4NCg== From DanielC@orckit.com Tue Apr 17 01:54:27 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201EF21F856D for ; Tue, 17 Apr 2012 01:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=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 QAz2hRLjSGKq for ; Tue, 17 Apr 2012 01:54:22 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4461F21F857D for ; Tue, 17 Apr 2012 01:54:22 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Date: Tue, 17 Apr 2012 11:56:29 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081307510E14@tlvmail1> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D3264A1C0@dfweml505-mbx> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFe/4Txq0Y50G6N17p5MncdwABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlg References: <115801cd1c15$566895a6$05280101@corrigent.com> <2691CE0099834E4A9C5044EEC662BB9D3264A1C0@dfweml505-mbx> From: "Daniel Cohn" To: "Lucy yong" , "Rogers, Josh" , "Henderickx, Wim (Wim)" , , , , "Sam Cao" X-Mailman-Approved-At: Tue, 17 Apr 2012 05:35:39 -0700 Cc: l2vpn@ietf.org, Vladimir.Kleiner@ecitele.com, Andrew.Sergeev@ecitele.com, Idan.Kaspit@ecitele.com, Mishael.Wexler@ecitele.com, Rotem.Cohen@ecitele.com X-BeenThere: l2vpn@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, 17 Apr 2012 08:54:27 -0000 Adding Sam (as l2vpn@ is holding messages) DC=20 -----Original Message----- From: Lucy yong [mailto:lucy.yong@huawei.com]=20 Sent: Tuesday, April 17, 2012 12:39 AM To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); giles.heron@gmail.com; simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com Subject: RE: The status of the approaches to the E-Tree solution? Snipped, As we discussed extensively in the list, and as reflected in giles slide, 2 pws are only needed between pes with both root and leaf acs, which will typically be a small minority. [[LY]] Don't know if the assumption is true. Even it is the case, both approaches can benefit from it. I was off for a while and captures some discussions now.=20 Also as per giles slide, dual vlan can have scalability issues due to additional lookup and double use of vlans in internal emulated lan interface. Also there are potential backward compatibility issues with silicon that doesn't support vlan mapping. [[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am not clear on all the issues. Could you be more specific? As I mentioned in below, two PW approach makes VPLS transport construction and packet forwarding more complex, I can see potential backward compatibility issues with 2 PW solution.=20 Regards, Lucy Regards, Daniel Thumb typed - please be tolerant Lucy yong wrote: In my mind, the VLAN approach means dual vlan method. The main concern for CW approach is hardware support. Two PW approach can be complex too if the VPLS instance for E-Tree uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast traffic, and some P2MP PWs for multicast traffic. It may double all of them. E-tree is an Ethernet service and there is already VLAN based solution in IEEE, can we just utilize it without complicating VPLS transport construction? This also makes interworking with Eth only network easier. Cheers, Lucy -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Monday, April 16, 2012 8:35 AM To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' Subject: RE: The status of the approaches to the E-Tree solution? I believe the initial question was in regard to the CW method. Are you saying that you no longer are interested in that method in preference of the dual vlan method? Lucy yong wrote: Agree with Wim. VLAN approach is the best solution for E-Tree. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim) Sent: Thursday, April 12, 2012 2:03 AM To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' Subject: Re: The status of the approaches to the E-Tree solution? The vlan approach is superior as it also works for eth only networks, etc. On top some vendors indicate hw issues with the cw approach. As such we have dropped more or less the cw approach. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Thursday, April 12, 2012 08:22 AM To: Simon Delord ; Alexander Vainshtein Cc: l2vpn@ietf.org ; Vladimir Kleiner ; Andrew Sergeev ; Idan Kaspit ; Mishael Wexler ; Rotem Cohen Subject: Re: The status of the approaches to the E-Tree solution? Sorry - the "anonymous presentation" was mine. I should possibly have put in a third column on the CW approach. And hopefully the minutes will be posted soon. We had various discussions, as Simon stated, and consensus seemed to be forming around the two alternatives of two PWEs or two VLANs. I believe three of the authors of the CW approach are also authors of the two VLAN approach and one is also an author of the two PWE approach. So perhaps it's best to let those four individuals say which approach they prefer and why? Giles On 10/04/2012 00:45, "Simon Delord" wrote: > Hi Alexander, > > You are right, no discussion on the WG mailing list recently, but=20 > there have been substantial discussions among the authors of various=20 > solution drafts off the mailing list. As far as I know, no consensus=20 > yet before ietf83, not sure the progress in the Paris WG meeting. I=20 > think the CW approach has not been rejected by the WG yet, or the WG=20 > has not yet decided on which one to adopt. > > Simon > > 2012/4/8 Alexander Vainshtein > >> Hi all, >> >> Unfortunately I have not been able to attend the Paris IETF. >> >> However, looking up the L2VPN proceedings, I've found a short=20 >> anonymous presentation called "E-Tree Update" (=20 >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx).=20 >> This presentation discusses the differences of the E-Tree approaches=20 >> based on dedicated VLANs (as in >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >> ext=3D1) and multiple PWs between the PEs (as in=20 >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >> clude_te >> xt=3D1) >> and completely ignores the solution based on usage of the CW in the=20 >> PWs connecting the PEs (as in >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >> ext=3D1 >> ). >> >> >> >> The Minutes of the Paris L2VPN session are not yet available, but I=20 >> wonder whether the WG has taken a decision to reject the approach=20 >> based on the CW usage? I do not remember any recent discussion of=20 >> this topic on the WG mailing list. >> >> >> >> Regards, and lots of thanks in advance, >> >> Sasha >> >> >> >> >> >> This e-mail message is intended for the recipient only and contains=20 >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please=20 >> inform us by e-mail, phone or fax, and then delete the original and=20 >> all copies thereof. >> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From yuqun.cao@gmail.com Tue Apr 17 04:59:51 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FE921F8644 for ; Tue, 17 Apr 2012 04:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPptGaUgSw0X for ; Tue, 17 Apr 2012 04:59:47 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6370D21F863F for ; Tue, 17 Apr 2012 04:59:47 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so5516781pbb.31 for ; Tue, 17 Apr 2012 04:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:x-mimeole :thread-index:in-reply-to; bh=+sw3YH3MKjLdxJbdYt7689jP/5r1bpVHyXg4JBLP/Uo=; b=sR1XnxCUXUbQrVUHuklb+0LgGN8+J18xCQRw5TJE0cQt/9OudGBGwNT/sVGgWe6rv6 2rtM6TojNXqiQBetezdBCs4TnAlVxgfhC4BG1yVqAOkKVzmbwNjJgF7tcg93B5wJJLW3 4RguJBfdACSKpowWpxZ+AUleRBMAO7Q8p4QKapMI9kP5RTEC8KNu9U8K5hx5mt6V82Qz tFsTb5lzOAihfxkBsWH8yfjZGWTo3P4TP6rtGezGnjDziGQtLfeTcXn3YrvOawBwba4h A64C2vZtuTJvdHLl5qlOePKwMZ5Pzn/awulURxueJUhcn+rBupyilPlxH1oUlFxayTPK opow== Received: by 10.68.191.35 with SMTP id gv3mr3830511pbc.160.1334663986857; Tue, 17 Apr 2012 04:59:46 -0700 (PDT) Received: from v2comsam ([175.42.35.87]) by mx.google.com with ESMTPS id i1sm16022445pbv.49.2012.04.17.04.59.33 (version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 04:59:45 -0700 (PDT) From: "Sam Cao" To: "'Daniel Cohn'" , "'Lucy yong'" , "'Rogers, Josh'" , "'Henderickx, Wim \(Wim\)'" , , , References: <115801cd1c15$566895a6$05280101@corrigent.com> <2691CE0099834E4A9C5044EEC662BB9D3264A1C0@dfweml505-mbx> <44F4E579A764584EA9BDFD07D0CA081307510E14@tlvmail1> Subject: RE: The status of the approaches to the E-Tree solution? Date: Tue, 17 Apr 2012 19:59:42 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac0YdJZFe/4Txq0Y50G6N17p5MncdwABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAASsbCA= In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081307510E14@tlvmail1> X-Mailman-Approved-At: Tue, 17 Apr 2012 05:35:39 -0700 Cc: l2vpn@ietf.org, Vladimir.Kleiner@ecitele.com, Andrew.Sergeev@ecitele.com, Idan.Kaspit@ecitele.com, Mishael.Wexler@ecitele.com, Rotem.Cohen@ecitele.com X-BeenThere: l2vpn@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, 17 Apr 2012 11:59:51 -0000 [YL] two PW approach makes VPLS transport construction and packet forwarding more complex, I can see potential backward compatibility issues with 2 PW solution. [Sam] Dual-PW approach uses 2 PW labels to identify frames if need. After decapsulation (stripe PW label out), bridge will forward the frame to corresponding ACs with frame type [input, identified by PW label]; Dual-VLAN approach uses VLAN-ID to identify frames, so after decapsulation, bridge will stripe S-VLAN ID out then forward the frame to corresponding ACs (We should integrate S-VLAN ID pop operation into bridge, I think). Considering forwarding process, both work in similar way. The difference is, Dual-VLAN approach needs one more POP operation. So, I think Dual-VLAN is a little complex, maybe not much. In addition, Dual-PW approach has considered backward compatibility. Please let us know if we miss something. BTW, Dual-PW or Dual-VLAN is good solution if there is one or more Root-Leaf-Mixed PE in E-Tree domain. Mostly there are Root-only and Leaf-Only in an E-Tree domain, current solutions have supported, but configuration is complex. Dual-VLAN still uses traditional configuration, but Dual-PW approach does NOT setup PW between Leaf-only PEs, so Dual-PW approach breaks communication between Leaf-Only PEs natively, but Dual-VLAN can not. Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Tuesday, April 17, 2012 4:56 PM To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); giles.heron@gmail.com; simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com Subject: RE: The status of the approaches to the E-Tree solution? Adding Sam (as l2vpn@ is holding messages) DC -----Original Message----- From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Tuesday, April 17, 2012 12:39 AM To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); giles.heron@gmail.com; simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com Subject: RE: The status of the approaches to the E-Tree solution? Snipped, As we discussed extensively in the list, and as reflected in giles slide, 2 pws are only needed between pes with both root and leaf acs, which will typically be a small minority. [[LY]] Don't know if the assumption is true. Even it is the case, both approaches can benefit from it. I was off for a while and captures some discussions now. Also as per giles slide, dual vlan can have scalability issues due to additional lookup and double use of vlans in internal emulated lan interface. Also there are potential backward compatibility issues with silicon that doesn't support vlan mapping. [[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am not clear on all the issues. Could you be more specific? As I mentioned in below, two PW approach makes VPLS transport construction and packet forwarding more complex, I can see potential backward compatibility issues with 2 PW solution. Regards, Lucy Regards, Daniel Thumb typed - please be tolerant Lucy yong wrote: In my mind, the VLAN approach means dual vlan method. The main concern for CW approach is hardware support. Two PW approach can be complex too if the VPLS instance for E-Tree uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast traffic, and some P2MP PWs for multicast traffic. It may double all of them. E-tree is an Ethernet service and there is already VLAN based solution in IEEE, can we just utilize it without complicating VPLS transport construction? This also makes interworking with Eth only network easier. Cheers, Lucy -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Monday, April 16, 2012 8:35 AM To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' Subject: RE: The status of the approaches to the E-Tree solution? I believe the initial question was in regard to the CW method. Are you saying that you no longer are interested in that method in preference of the dual vlan method? Lucy yong wrote: Agree with Wim. VLAN approach is the best solution for E-Tree. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim) Sent: Thursday, April 12, 2012 2:03 AM To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' Subject: Re: The status of the approaches to the E-Tree solution? The vlan approach is superior as it also works for eth only networks, etc. On top some vendors indicate hw issues with the cw approach. As such we have dropped more or less the cw approach. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Thursday, April 12, 2012 08:22 AM To: Simon Delord ; Alexander Vainshtein Cc: l2vpn@ietf.org ; Vladimir Kleiner ; Andrew Sergeev ; Idan Kaspit ; Mishael Wexler ; Rotem Cohen Subject: Re: The status of the approaches to the E-Tree solution? Sorry - the "anonymous presentation" was mine. I should possibly have put in a third column on the CW approach. And hopefully the minutes will be posted soon. We had various discussions, as Simon stated, and consensus seemed to be forming around the two alternatives of two PWEs or two VLANs. I believe three of the authors of the CW approach are also authors of the two VLAN approach and one is also an author of the two PWE approach. So perhaps it's best to let those four individuals say which approach they prefer and why? Giles On 10/04/2012 00:45, "Simon Delord" wrote: > Hi Alexander, > > You are right, no discussion on the WG mailing list recently, but > there have been substantial discussions among the authors of various > solution drafts off the mailing list. As far as I know, no consensus > yet before ietf83, not sure the progress in the Paris WG meeting. I > think the CW approach has not been rejected by the WG yet, or the WG > has not yet decided on which one to adopt. > > Simon > > 2012/4/8 Alexander Vainshtein > >> Hi all, >> >> Unfortunately I have not been able to attend the Paris IETF. >> >> However, looking up the L2VPN proceedings, I've found a short >> anonymous presentation called "E-Tree Update" ( >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >> This presentation discusses the differences of the E-Tree approaches >> based on dedicated VLANs (as in >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >> ext=1) and multiple PWs between the PEs (as in >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >> clude_te >> xt=1) >> and completely ignores the solution based on usage of the CW in the >> PWs connecting the PEs (as in >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >> ext=1 >> ). >> >> >> >> The Minutes of the Paris L2VPN session are not yet available, but I >> wonder whether the WG has taken a decision to reject the approach >> based on the CW usage? I do not remember any recent discussion of >> this topic on the WG mailing list. >> >> >> >> Regards, and lots of thanks in advance, >> >> Sasha >> >> >> >> >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please >> inform us by e-mail, phone or fax, and then delete the original and >> all copies thereof. >> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From yuqun.cao@gmail.com Tue Apr 17 05:13:55 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C293F21F857F for ; Tue, 17 Apr 2012 05:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4b4r+GAOG4y for ; Tue, 17 Apr 2012 05:13:51 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 697A021F855A for ; Tue, 17 Apr 2012 05:13:51 -0700 (PDT) Received: by dady13 with SMTP id y13so11467934dad.27 for ; Tue, 17 Apr 2012 05:13:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:x-mimeole :thread-index:in-reply-to; bh=j/YP5UwKlWYYaDikCZJPS39mzB30G1Do3qGf0ZDQx2o=; b=MvmY/0ygWCWfL/gyZVgcC4ueRzeUgurgJyRwSZ1LuT7XnrNvmJMlVYqTV0ptgdjAYI FUAjE69hkuYgo0Xk6tYF2DCAZDKNelwac6kctrLTG/KU05+BodHx3n1ngcJnLh8SZUOR B+JI6ufIaIHDOGOGj7BsBhTfbezBvZGjWcgPGUkb+ofjxE+440VAkuFFFZbYFmf1qZEZ lKYjMWZGUa7JEfyWlAQZqI3V5XvV1FaVnyygzIRfviEbRl5I2K0bMur2RbqEOwEXKQ/P pPTw+O975pS1JYhcamHTjsTGfTFFMiXmUZpyLi299069hf2GnVh5UKcR7pRZqwkC2YE1 NMYA== Received: by 10.68.237.130 with SMTP id vc2mr30918459pbc.134.1334664830862; Tue, 17 Apr 2012 05:13:50 -0700 (PDT) Received: from v2comsam ([175.42.35.87]) by mx.google.com with ESMTPS id pg6sm7312161pbb.41.2012.04.17.05.13.41 (version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 05:13:49 -0700 (PDT) From: "Sam Cao" To: "'Daniel Cohn'" , "'Lucy yong'" , "'Rogers, Josh'" , "'Henderickx, Wim \(Wim\)'" , , , References: <115801cd1c15$566895a6$05280101@corrigent.com> <2691CE0099834E4A9C5044EEC662BB9D3264A1C0@dfweml505-mbx> <44F4E579A764584EA9BDFD07D0CA081307510E14@tlvmail1> Subject: RE: The status of the approaches to the E-Tree solution? Date: Tue, 17 Apr 2012 20:13:50 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac0YdJZFe/4Txq0Y50G6N17p5MncdwABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIA= In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081307510E14@tlvmail1> X-Mailman-Approved-At: Tue, 17 Apr 2012 05:35:39 -0700 Cc: l2vpn@ietf.org, Vladimir.Kleiner@ecitele.com, Andrew.Sergeev@ecitele.com, Idan.Kaspit@ecitele.com, Mishael.Wexler@ecitele.com, Rotem.Cohen@ecitele.com X-BeenThere: l2vpn@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, 17 Apr 2012 12:13:55 -0000 Yes, 2 pws are only needed between pes with both root and leaf acs after improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 P2MP PWs if need. There is no difference between P2MP or normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Tuesday, April 17, 2012 4:56 PM To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); giles.heron@gmail.com; simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com Subject: RE: The status of the approaches to the E-Tree solution? Adding Sam (as l2vpn@ is holding messages) DC -----Original Message----- From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Tuesday, April 17, 2012 12:39 AM To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); giles.heron@gmail.com; simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com Subject: RE: The status of the approaches to the E-Tree solution? Snipped, As we discussed extensively in the list, and as reflected in giles slide, 2 pws are only needed between pes with both root and leaf acs, which will typically be a small minority. [[LY]] Don't know if the assumption is true. Even it is the case, both approaches can benefit from it. I was off for a while and captures some discussions now. Also as per giles slide, dual vlan can have scalability issues due to additional lookup and double use of vlans in internal emulated lan interface. Also there are potential backward compatibility issues with silicon that doesn't support vlan mapping. [[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am not clear on all the issues. Could you be more specific? As I mentioned in below, two PW approach makes VPLS transport construction and packet forwarding more complex, I can see potential backward compatibility issues with 2 PW solution. Regards, Lucy Regards, Daniel Thumb typed - please be tolerant Lucy yong wrote: In my mind, the VLAN approach means dual vlan method. The main concern for CW approach is hardware support. Two PW approach can be complex too if the VPLS instance for E-Tree uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast traffic, and some P2MP PWs for multicast traffic. It may double all of them. E-tree is an Ethernet service and there is already VLAN based solution in IEEE, can we just utilize it without complicating VPLS transport construction? This also makes interworking with Eth only network easier. Cheers, Lucy -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Monday, April 16, 2012 8:35 AM To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' Subject: RE: The status of the approaches to the E-Tree solution? I believe the initial question was in regard to the CW method. Are you saying that you no longer are interested in that method in preference of the dual vlan method? Lucy yong wrote: Agree with Wim. VLAN approach is the best solution for E-Tree. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim) Sent: Thursday, April 12, 2012 2:03 AM To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' Subject: Re: The status of the approaches to the E-Tree solution? The vlan approach is superior as it also works for eth only networks, etc. On top some vendors indicate hw issues with the cw approach. As such we have dropped more or less the cw approach. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Thursday, April 12, 2012 08:22 AM To: Simon Delord ; Alexander Vainshtein Cc: l2vpn@ietf.org ; Vladimir Kleiner ; Andrew Sergeev ; Idan Kaspit ; Mishael Wexler ; Rotem Cohen Subject: Re: The status of the approaches to the E-Tree solution? Sorry - the "anonymous presentation" was mine. I should possibly have put in a third column on the CW approach. And hopefully the minutes will be posted soon. We had various discussions, as Simon stated, and consensus seemed to be forming around the two alternatives of two PWEs or two VLANs. I believe three of the authors of the CW approach are also authors of the two VLAN approach and one is also an author of the two PWE approach. So perhaps it's best to let those four individuals say which approach they prefer and why? Giles On 10/04/2012 00:45, "Simon Delord" wrote: > Hi Alexander, > > You are right, no discussion on the WG mailing list recently, but > there have been substantial discussions among the authors of various > solution drafts off the mailing list. As far as I know, no consensus > yet before ietf83, not sure the progress in the Paris WG meeting. I > think the CW approach has not been rejected by the WG yet, or the WG > has not yet decided on which one to adopt. > > Simon > > 2012/4/8 Alexander Vainshtein > >> Hi all, >> >> Unfortunately I have not been able to attend the Paris IETF. >> >> However, looking up the L2VPN proceedings, I've found a short >> anonymous presentation called "E-Tree Update" ( >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >> This presentation discusses the differences of the E-Tree approaches >> based on dedicated VLANs (as in >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >> ext=1) and multiple PWs between the PEs (as in >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >> clude_te >> xt=1) >> and completely ignores the solution based on usage of the CW in the >> PWs connecting the PEs (as in >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >> ext=1 >> ). >> >> >> >> The Minutes of the Paris L2VPN session are not yet available, but I >> wonder whether the WG has taken a decision to reject the approach >> based on the CW usage? I do not remember any recent discussion of >> this topic on the WG mailing list. >> >> >> >> Regards, and lots of thanks in advance, >> >> Sasha >> >> >> >> >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please >> inform us by e-mail, phone or fax, and then delete the original and >> all copies thereof. >> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From jiangyuanlong@huawei.com Tue Apr 17 10:41:17 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D30A21F8551 for ; Tue, 17 Apr 2012 10:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=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 m+zJhwVkiwNW for ; Tue, 17 Apr 2012 10:41:11 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1313A21F854C for ; Tue, 17 Apr 2012 10:41:11 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFH45538; Tue, 17 Apr 2012 13:41:10 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 17 Apr 2012 10:38:41 -0700 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 17 Apr 2012 10:38:43 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.137]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Wed, 18 Apr 2012 01:38:10 +0800 From: Jiangyuanlong To: Daniel Cohn Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNHL77xbisvEh3kk6CwsWQjlzY3w== Date: Tue, 17 Apr 2012 17:38:10 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E12E@SZXEML508-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: [172.24.1.69] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 17 Apr 2012 17:41:17 -0000 Hi Daniel, Please see my comments inline. Regards Yuanlong ------------------------------ Date: Tue, 17 Apr 2012 00:08:02 +0300 From: "Daniel Cohn" To: "Lucy yong" , "Rogers, Josh" , "Henderickx, Wim (Wim)" , , , Cc: l2vpn@ietf.org, Vladimir.Kleiner@ecitele.com, Andrew.Sergeev@ecitele.com, Idan.Kaspit@ecitele.com, Mishael.Wexler@ecitele.com, Rotem.Cohen@ecitele.com Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <115801cd1c15$566895a6$05280101@corrigent.com> Content-Type: text/plain; charset=3D"utf-8" Hi lucy, As we discussed extensively in the list, and as reflected in giles slide, 2= pws are only needed between pes with both root and leaf acs, which will ty= pically be a small minority. [YL] For a PE with only leaf ACs and a PE with both root and leaf ACs, do y= ou really think only 1 PW is needed? if so, should it be a root PW or a lea= f PW?=20 Also as per giles slide, dual vlan can have scalability issues due to addit= ional lookup and double use of vlans in internal emulated lan interface. Al= so there are potential backward compatibility issues with silicon that does= n't support vlan mapping. [YL] Dual VLAN may have scalability concerns only when the PE can only supp= ort a single global VLAN space, not sure a VLAN lookup at the port has any = scalability issue.=20 [YL] If VLAN mapping can not be supported by the PE, global VLAN may be use= d instead. Regards, Daniel Thumb typed - please be tolerant Lucy yong wrote: In my mind, the VLAN approach means dual vlan method. The main concern for CW approach is hardware support. Two PW approach can be complex too if the VPLS instance for E-Tree uses P2P= PW for unicast traffic and P2MP PW for broadcast and unknown unicast traff= ic, and some P2MP PWs for multicast traffic. It may double all of them. E-tree is an Ethernet service and there is already VLAN based solution in I= EEE, can we just utilize it without complicating VPLS transport constructio= n? This also makes interworking with Eth only network easier. Cheers, Lucy -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Monday, April 16, 2012 8:35 AM To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; 'simon.delor= d@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecite= le.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Co= hen@ecitele.com' Subject: RE: The status of the approaches to the E-Tree solution? I believe the initial question was in regard to the CW method. Are you say= ing that you no longer are interested in that method in preference of the d= ual vlan method? Lucy yong wrote: Agree with Wim. VLAN approach is the best solution for E-Tree. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of H= enderickx, Wim (Wim) Sent: Thursday, April 12, 2012 2:03 AM To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtei= n@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecite= le.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Co= hen@ecitele.com' Subject: Re: The status of the approaches to the E-Tree solution? The vlan approach is superior as it also works for eth only networks, etc. = On top some vendors indicate hw issues with the cw approach. As such we hav= e dropped more or less the cw approach. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Thursday, April 12, 2012 08:22 AM To: Simon Delord ; Alexander Vainshtein Cc: l2vpn@ietf.org ; Vladimir Kleiner ; Andrew Sergeev ; Idan Kaspit ; Mishael Wexler ; Rotem Cohe= n Subject: Re: The status of the approaches to the E-Tree solution? Sorry - the "anonymous presentation" was mine. I should possibly have put in a third column on the CW approach. And hopefully the minutes will be posted soon. We had various discussions, as Simon stated, and consensus seemed to be forming around the two alternatives of two PWEs or two VLANs. I believe three of the authors of the CW approach are also authors of the two VLAN approach and one is also an author of the two PWE approach. So perhaps it's best to let those four individuals say which approach they prefer and why? Giles On 10/04/2012 00:45, "Simon Delord" wrote: > Hi Alexander, > > You are right, no discussion on the WG mailing list recently, but there > have been substantial discussions among the authors of various solution > drafts off the mailing list. As far as I know, no consensus yet before > ietf83, not sure the progress in the Paris WG meeting. I think the CW > approach has not been rejected by the WG yet, or the WG has not yet decid= ed > on which one to adopt. > > Simon > > 2012/4/8 Alexander Vainshtein > >> Hi all, >> >> Unfortunately I have not been able to attend the Paris IETF. >> >> However, looking up the L2VPN proceedings, I've found a short anonymous >> presentation called "E-Tree Update" ( >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). This >> presentation discusses the differences of the E-Tree approaches based on >> dedicated VLANs (as in >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_text= =3D1) >> and multiple PWs between the PEs (as in >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?inclu= de_te >> xt=3D1) >> and completely ignores the solution based on usage of the CW in the PWs >> connecting the PEs (as in >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_text= =3D1 >> ). >> >> >> >> The Minutes of the Paris L2VPN session are not yet available, but I wond= er >> whether the WG has taken a decision to reject the approach based on the = CW >> usage? I do not remember any recent discussion of this topic on the WG >> mailing list. >> >> >> >> Regards, and lots of thanks in advance, >> >> Sasha >> >> >> >> >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please inform = us >> by e-mail, phone or fax, and then delete the original and all copies >> thereof. >> This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. ------------------------------ Message: 3 Date: Mon, 16 Apr 2012 21:38:51 +0000 From: Lucy yong To: Daniel Cohn , "Rogers, Josh" , "Henderickx, Wim (Wim)" , "giles.heron@gmail.com" , "simon.delord@gmail.com" , "Alexander.Vainshtein@ecitele.com" Cc: "l2vpn@ietf.org" , "Vladimir.Kleiner@ecitele.com" , "Andrew.Sergeev@ecitele.com" , "Idan.Kaspit@ecitele.com" , "Mishael.Wexler@ecitele.com" , "Rotem.Cohen@ecitele.com" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264A1C0@dfweml505-mbx> Content-Type: text/plain; charset=3D"utf-8" Snipped, As we discussed extensively in the list, and as reflected in giles slide, 2= pws are only needed between pes with both root and leaf acs, which will ty= pically be a small minority. [[LY]] Don't know if the assumption is true. Even it is the case, both appr= oaches can benefit from it. I was off for a while and captures some discuss= ions now. Also as per giles slide, dual vlan can have scalability issues due to addit= ional lookup and double use of vlans in internal emulated lan interface. Al= so there are potential backward compatibility issues with silicon that does= n't support vlan mapping. [[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am no= t clear on all the issues. Could you be more specific? As I mentioned in be= low, two PW approach makes VPLS transport construction and packet forwardin= g more complex, I can see potential backward compatibility issues with 2 PW= solution. Regards, Lucy Regards, Daniel Thumb typed - please be tolerant Lucy yong wrote: In my mind, the VLAN approach means dual vlan method. The main concern for CW approach is hardware support. Two PW approach can be complex too if the VPLS instance for E-Tree uses P2P= PW for unicast traffic and P2MP PW for broadcast and unknown unicast traff= ic, and some P2MP PWs for multicast traffic. It may double all of them. E-tree is an Ethernet service and there is already VLAN based solution in I= EEE, can we just utilize it without complicating VPLS transport constructio= n? This also makes interworking with Eth only network easier. Cheers, Lucy -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Monday, April 16, 2012 8:35 AM To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; 'simon.delor= d@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecite= le.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Co= hen@ecitele.com' Subject: RE: The status of the approaches to the E-Tree solution? I believe the initial question was in regard to the CW method. Are you say= ing that you no longer are interested in that method in preference of the d= ual vlan method? Lucy yong wrote: Agree with Wim. VLAN approach is the best solution for E-Tree. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of H= enderickx, Wim (Wim) Sent: Thursday, April 12, 2012 2:03 AM To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtei= n@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecite= le.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Co= hen@ecitele.com' Subject: Re: The status of the approaches to the E-Tree solution? The vlan approach is superior as it also works for eth only networks, etc. = On top some vendors indicate hw issues with the cw approach. As such we hav= e dropped more or less the cw approach. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Thursday, April 12, 2012 08:22 AM To: Simon Delord ; Alexander Vainshtein Cc: l2vpn@ietf.org ; Vladimir Kleiner ; Andrew Sergeev ; Idan Kaspit ; Mishael Wexler ; Rotem Cohe= n Subject: Re: The status of the approaches to the E-Tree solution? Sorry - the "anonymous presentation" was mine. I should possibly have put in a third column on the CW approach. And hopefully the minutes will be posted soon. We had various discussions, as Simon stated, and consensus seemed to be forming around the two alternatives of two PWEs or two VLANs. I believe three of the authors of the CW approach are also authors of the two VLAN approach and one is also an author of the two PWE approach. So perhaps it's best to let those four individuals say which approach they prefer and why? Giles On 10/04/2012 00:45, "Simon Delord" wrote: > Hi Alexander, > > You are right, no discussion on the WG mailing list recently, but there > have been substantial discussions among the authors of various solution > drafts off the mailing list. As far as I know, no consensus yet before > ietf83, not sure the progress in the Paris WG meeting. I think the CW > approach has not been rejected by the WG yet, or the WG has not yet decid= ed > on which one to adopt. > > Simon > > 2012/4/8 Alexander Vainshtein > >> Hi all, >> >> Unfortunately I have not been able to attend the Paris IETF. >> >> However, looking up the L2VPN proceedings, I've found a short anonymous >> presentation called "E-Tree Update" ( >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). This >> presentation discusses the differences of the E-Tree approaches based on >> dedicated VLANs (as in >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_text= =3D1) >> and multiple PWs between the PEs (as in >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?inclu= de_te >> xt=3D1) >> and completely ignores the solution based on usage of the CW in the PWs >> connecting the PEs (as in >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_text= =3D1 >> ). >> >> >> >> The Minutes of the Paris L2VPN session are not yet available, but I wond= er >> whether the WG has taken a decision to reject the approach based on the = CW >> usage? I do not remember any recent discussion of this topic on the WG >> mailing list. >> >> >> >> Regards, and lots of thanks in advance, >> >> Sasha >> >> >> >> >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please inform = us >> by e-mail, phone or fax, and then delete the original and all copies >> thereof. >> This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. ------------------------------ Message: 4 Date: Tue, 17 Apr 2012 11:56:29 +0300 From: "Daniel Cohn" To: "Lucy yong" , "Rogers, Josh" , "Henderickx, Wim (Wim)" , , , ,= "Sam Cao" Cc: l2vpn@ietf.org, Vladimir.Kleiner@ecitele.com, Andrew.Sergeev@ecitele.com, Idan.Kaspit@ecitele.com, Mishael.Wexler@ecitele.com, Rotem.Cohen@ecitele.com Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <44F4E579A764584EA9BDFD07D0CA081307510E14@tlvmail1> Content-Type: text/plain; charset=3D"us-ascii" Adding Sam (as l2vpn@ is holding messages) DC -----Original Message----- From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Tuesday, April 17, 2012 12:39 AM To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); giles.heron@gmail.com; simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com Subject: RE: The status of the approaches to the E-Tree solution? Snipped, As we discussed extensively in the list, and as reflected in giles slide, 2 pws are only needed between pes with both root and leaf acs, which will typically be a small minority. [[LY]] Don't know if the assumption is true. Even it is the case, both approaches can benefit from it. I was off for a while and captures some discussions now. Also as per giles slide, dual vlan can have scalability issues due to additional lookup and double use of vlans in internal emulated lan interface. Also there are potential backward compatibility issues with silicon that doesn't support vlan mapping. [[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am not clear on all the issues. Could you be more specific? As I mentioned in below, two PW approach makes VPLS transport construction and packet forwarding more complex, I can see potential backward compatibility issues with 2 PW solution. Regards, Lucy Regards, Daniel Thumb typed - please be tolerant Lucy yong wrote: In my mind, the VLAN approach means dual vlan method. The main concern for CW approach is hardware support. Two PW approach can be complex too if the VPLS instance for E-Tree uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast traffic, and some P2MP PWs for multicast traffic. It may double all of them. E-tree is an Ethernet service and there is already VLAN based solution in IEEE, can we just utilize it without complicating VPLS transport construction? This also makes interworking with Eth only network easier. Cheers, Lucy -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Monday, April 16, 2012 8:35 AM To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' Subject: RE: The status of the approaches to the E-Tree solution? I believe the initial question was in regard to the CW method. Are you saying that you no longer are interested in that method in preference of the dual vlan method? Lucy yong wrote: Agree with Wim. VLAN approach is the best solution for E-Tree. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim) Sent: Thursday, April 12, 2012 2:03 AM To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' Subject: Re: The status of the approaches to the E-Tree solution? The vlan approach is superior as it also works for eth only networks, etc. On top some vendors indicate hw issues with the cw approach. As such we have dropped more or less the cw approach. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Thursday, April 12, 2012 08:22 AM To: Simon Delord ; Alexander Vainshtein Cc: l2vpn@ietf.org ; Vladimir Kleiner ; Andrew Sergeev ; Idan Kaspit ; Mishael Wexler ; Rotem Cohen Subject: Re: The status of the approaches to the E-Tree solution? Sorry - the "anonymous presentation" was mine. I should possibly have put in a third column on the CW approach. And hopefully the minutes will be posted soon. We had various discussions, as Simon stated, and consensus seemed to be forming around the two alternatives of two PWEs or two VLANs. I believe three of the authors of the CW approach are also authors of the two VLAN approach and one is also an author of the two PWE approach. So perhaps it's best to let those four individuals say which approach they prefer and why? Giles On 10/04/2012 00:45, "Simon Delord" wrote: > Hi Alexander, > > You are right, no discussion on the WG mailing list recently, but > there have been substantial discussions among the authors of various > solution drafts off the mailing list. As far as I know, no consensus > yet before ietf83, not sure the progress in the Paris WG meeting. I > think the CW approach has not been rejected by the WG yet, or the WG > has not yet decided on which one to adopt. > > Simon > > 2012/4/8 Alexander Vainshtein > >> Hi all, >> >> Unfortunately I have not been able to attend the Paris IETF. >> >> However, looking up the L2VPN proceedings, I've found a short >> anonymous presentation called "E-Tree Update" ( >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >> This presentation discusses the differences of the E-Tree approaches >> based on dedicated VLANs (as in >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >> ext=3D1) and multiple PWs between the PEs (as in >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >> clude_te >> xt=3D1) >> and completely ignores the solution based on usage of the CW in the >> PWs connecting the PEs (as in >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >> ext=3D1 >> ). >> >> >> >> The Minutes of the Paris L2VPN session are not yet available, but I >> wonder whether the WG has taken a decision to reject the approach >> based on the CW usage? I do not remember any recent discussion of >> this topic on the WG mailing list. >> >> >> >> Regards, and lots of thanks in advance, >> >> Sasha >> >> >> >> >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please >> inform us by e-mail, phone or fax, and then delete the original and >> all copies thereof. >> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 20 *************************************= From yuqun.cao@gmail.com Tue Apr 17 19:51:17 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E91A21F858A for ; Tue, 17 Apr 2012 19:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKnabaWf3tPV for ; Tue, 17 Apr 2012 19:51:13 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 219E621F8584 for ; Tue, 17 Apr 2012 19:51:13 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so6312017pbb.31 for ; Tue, 17 Apr 2012 19:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :in-reply-to:x-mimeole; bh=/iE7saBVid36Q6XLJLQzwLC0bMHefVedgNhKc0Vlxok=; b=tKfcf6CxMGhRx+DDw2cn8wpbAOtTx9ZjJ8VkOM+uf42vzWVkAv2e0SE1kegk1y0u5b Fu5nPz3mKSKlGDU6cPLXB9ZIVIft1U7Obqxa1lGho5zVmjfJ1IcAyR7Qw6BI9asvkYL8 ff22u9uRtKgXKj4UqfmxFXD5mx+4rU/DIpQz1NRoAzrFpu58D1AzmRCWSE5IYB6dLvtL oJAVU9juyl0LgxvO43054nYXtf398rJWuC+zjbCy3AIWrAWib9G7l4pOdxt7Dcv5+jO8 PY6La8z2g/+STXIaHSfC+pJ9hFAtezry8dpmOZtmH2Nx8Sr7bCy693wb9SiqFfS2OC6+ BGag== Received: by 10.68.217.67 with SMTP id ow3mr2550826pbc.16.1334717472368; Tue, 17 Apr 2012 19:51:12 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id or6sm22378100pbc.43.2012.04.17.19.51.02 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Apr 2012 19:51:10 -0700 (PDT) From: "Sam Cao" To: References: Subject: RE: L2vpn Digest, Vol 95, Issue 21 Date: Wed, 18 Apr 2012 10:51:20 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac0cwVX1lVjXizjtQ4ysP690Vb6frQASc/8g In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: l2vpn@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, 18 Apr 2012 02:51:17 -0000 We discussed several rounds on this before. As I know, Dual-VLAN needs to confirm the following cases first, 1) Wait for confirmation or comments from chip vendors; 2) Use Global VLAN ID. If so, Yuanlong and other co-authors would better update draft first. For me, if support E-Tree in MPLS network, Multi-PW is better solution; if also support E-Tree in eth-only network, maybe Dual-VLAN is better. My question is, is "E-tree support in Eth-only network" real requirement from carrier? In addition, I also figured some disadvantages of Dual-VLAN out before. Till now I did not get positive responses from Yuanlong or other co-authors. Wish chairs push this forward and reach agreements soon ^_^. Sam -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of l2vpn-request@ietf.org Sent: Wednesday, April 18, 2012 1:41 AM To: l2vpn@ietf.org Subject: L2vpn Digest, Vol 95, Issue 21 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/l2vpn Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send L2vpn mailing list submissions to l2vpn@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/l2vpn or, via email, send a message with subject or body 'help' to l2vpn-request@ietf.org You can reach the person managing the list at l2vpn-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of L2vpn digest..." Today's Topics: 1. RE: The status of the approaches to the E-Tree solution? (Sam Cao) 2. RE: The status of the approaches to the E-Tree solution? (Sam Cao) 3. RE: The status of the approaches to the E-Tree solution? (Jiangyuanlong) ---------------------------------------------------------------------- Message: 1 Date: Tue, 17 Apr 2012 19:59:42 +0800 From: "Sam Cao" To: "'Daniel Cohn'" , "'Lucy yong'" , "'Rogers, Josh'" , "'Henderickx, Wim \(Wim\)'" , , , Cc: l2vpn@ietf.org, Vladimir.Kleiner@ecitele.com, Andrew.Sergeev@ecitele.com, Idan.Kaspit@ecitele.com, Mishael.Wexler@ecitele.com, Rotem.Cohen@ecitele.com Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: Content-Type: text/plain; charset="us-ascii" [YL] two PW approach makes VPLS transport construction and packet forwarding more complex, I can see potential backward compatibility issues with 2 PW solution. [Sam] Dual-PW approach uses 2 PW labels to identify frames if need. After decapsulation (stripe PW label out), bridge will forward the frame to corresponding ACs with frame type [input, identified by PW label]; Dual-VLAN approach uses VLAN-ID to identify frames, so after decapsulation, bridge will stripe S-VLAN ID out then forward the frame to corresponding ACs (We should integrate S-VLAN ID pop operation into bridge, I think). Considering forwarding process, both work in similar way. The difference is, Dual-VLAN approach needs one more POP operation. So, I think Dual-VLAN is a little complex, maybe not much. In addition, Dual-PW approach has considered backward compatibility. Please let us know if we miss something. BTW, Dual-PW or Dual-VLAN is good solution if there is one or more Root-Leaf-Mixed PE in E-Tree domain. Mostly there are Root-only and Leaf-Only in an E-Tree domain, current solutions have supported, but configuration is complex. Dual-VLAN still uses traditional configuration, but Dual-PW approach does NOT setup PW between Leaf-only PEs, so Dual-PW approach breaks communication between Leaf-Only PEs natively, but Dual-VLAN can not. Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Tuesday, April 17, 2012 4:56 PM To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); giles.heron@gmail.com; simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com Subject: RE: The status of the approaches to the E-Tree solution? Adding Sam (as l2vpn@ is holding messages) DC -----Original Message----- From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Tuesday, April 17, 2012 12:39 AM To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); giles.heron@gmail.com; simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com Subject: RE: The status of the approaches to the E-Tree solution? Snipped, As we discussed extensively in the list, and as reflected in giles slide, 2 pws are only needed between pes with both root and leaf acs, which will typically be a small minority. [[LY]] Don't know if the assumption is true. Even it is the case, both approaches can benefit from it. I was off for a while and captures some discussions now. Also as per giles slide, dual vlan can have scalability issues due to additional lookup and double use of vlans in internal emulated lan interface. Also there are potential backward compatibility issues with silicon that doesn't support vlan mapping. [[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am not clear on all the issues. Could you be more specific? As I mentioned in below, two PW approach makes VPLS transport construction and packet forwarding more complex, I can see potential backward compatibility issues with 2 PW solution. Regards, Lucy Regards, Daniel Thumb typed - please be tolerant Lucy yong wrote: In my mind, the VLAN approach means dual vlan method. The main concern for CW approach is hardware support. Two PW approach can be complex too if the VPLS instance for E-Tree uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast traffic, and some P2MP PWs for multicast traffic. It may double all of them. E-tree is an Ethernet service and there is already VLAN based solution in IEEE, can we just utilize it without complicating VPLS transport construction? This also makes interworking with Eth only network easier. Cheers, Lucy -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Monday, April 16, 2012 8:35 AM To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' Subject: RE: The status of the approaches to the E-Tree solution? I believe the initial question was in regard to the CW method. Are you saying that you no longer are interested in that method in preference of the dual vlan method? Lucy yong wrote: Agree with Wim. VLAN approach is the best solution for E-Tree. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim) Sent: Thursday, April 12, 2012 2:03 AM To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' Subject: Re: The status of the approaches to the E-Tree solution? The vlan approach is superior as it also works for eth only networks, etc. On top some vendors indicate hw issues with the cw approach. As such we have dropped more or less the cw approach. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Thursday, April 12, 2012 08:22 AM To: Simon Delord ; Alexander Vainshtein Cc: l2vpn@ietf.org ; Vladimir Kleiner ; Andrew Sergeev ; Idan Kaspit ; Mishael Wexler ; Rotem Cohen Subject: Re: The status of the approaches to the E-Tree solution? Sorry - the "anonymous presentation" was mine. I should possibly have put in a third column on the CW approach. And hopefully the minutes will be posted soon. We had various discussions, as Simon stated, and consensus seemed to be forming around the two alternatives of two PWEs or two VLANs. I believe three of the authors of the CW approach are also authors of the two VLAN approach and one is also an author of the two PWE approach. So perhaps it's best to let those four individuals say which approach they prefer and why? Giles On 10/04/2012 00:45, "Simon Delord" wrote: > Hi Alexander, > > You are right, no discussion on the WG mailing list recently, but > there have been substantial discussions among the authors of various > solution drafts off the mailing list. As far as I know, no consensus > yet before ietf83, not sure the progress in the Paris WG meeting. I > think the CW approach has not been rejected by the WG yet, or the WG > has not yet decided on which one to adopt. > > Simon > > 2012/4/8 Alexander Vainshtein > >> Hi all, >> >> Unfortunately I have not been able to attend the Paris IETF. >> >> However, looking up the L2VPN proceedings, I've found a short >> anonymous presentation called "E-Tree Update" ( >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >> This presentation discusses the differences of the E-Tree approaches >> based on dedicated VLANs (as in >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >> ext=1) and multiple PWs between the PEs (as in >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >> clude_te >> xt=1) >> and completely ignores the solution based on usage of the CW in the >> PWs connecting the PEs (as in >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >> ext=1 >> ). >> >> >> >> The Minutes of the Paris L2VPN session are not yet available, but I >> wonder whether the WG has taken a decision to reject the approach >> based on the CW usage? I do not remember any recent discussion of >> this topic on the WG mailing list. >> >> >> >> Regards, and lots of thanks in advance, >> >> Sasha >> >> >> >> >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please >> inform us by e-mail, phone or fax, and then delete the original and >> all copies thereof. >> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ------------------------------ Message: 2 Date: Tue, 17 Apr 2012 20:13:50 +0800 From: "Sam Cao" To: "'Daniel Cohn'" , "'Lucy yong'" , "'Rogers, Josh'" , "'Henderickx, Wim \(Wim\)'" , , , Cc: l2vpn@ietf.org, Vladimir.Kleiner@ecitele.com, Andrew.Sergeev@ecitele.com, Idan.Kaspit@ecitele.com, Mishael.Wexler@ecitele.com, Rotem.Cohen@ecitele.com Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: Content-Type: text/plain; charset="us-ascii" Yes, 2 pws are only needed between pes with both root and leaf acs after improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 P2MP PWs if need. There is no difference between P2MP or normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Tuesday, April 17, 2012 4:56 PM To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); giles.heron@gmail.com; simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com Subject: RE: The status of the approaches to the E-Tree solution? Adding Sam (as l2vpn@ is holding messages) DC -----Original Message----- From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Tuesday, April 17, 2012 12:39 AM To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); giles.heron@gmail.com; simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com Subject: RE: The status of the approaches to the E-Tree solution? Snipped, As we discussed extensively in the list, and as reflected in giles slide, 2 pws are only needed between pes with both root and leaf acs, which will typically be a small minority. [[LY]] Don't know if the assumption is true. Even it is the case, both approaches can benefit from it. I was off for a while and captures some discussions now. Also as per giles slide, dual vlan can have scalability issues due to additional lookup and double use of vlans in internal emulated lan interface. Also there are potential backward compatibility issues with silicon that doesn't support vlan mapping. [[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am not clear on all the issues. Could you be more specific? As I mentioned in below, two PW approach makes VPLS transport construction and packet forwarding more complex, I can see potential backward compatibility issues with 2 PW solution. Regards, Lucy Regards, Daniel Thumb typed - please be tolerant Lucy yong wrote: In my mind, the VLAN approach means dual vlan method. The main concern for CW approach is hardware support. Two PW approach can be complex too if the VPLS instance for E-Tree uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast traffic, and some P2MP PWs for multicast traffic. It may double all of them. E-tree is an Ethernet service and there is already VLAN based solution in IEEE, can we just utilize it without complicating VPLS transport construction? This also makes interworking with Eth only network easier. Cheers, Lucy -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Monday, April 16, 2012 8:35 AM To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' Subject: RE: The status of the approaches to the E-Tree solution? I believe the initial question was in regard to the CW method. Are you saying that you no longer are interested in that method in preference of the dual vlan method? Lucy yong wrote: Agree with Wim. VLAN approach is the best solution for E-Tree. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim) Sent: Thursday, April 12, 2012 2:03 AM To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' Subject: Re: The status of the approaches to the E-Tree solution? The vlan approach is superior as it also works for eth only networks, etc. On top some vendors indicate hw issues with the cw approach. As such we have dropped more or less the cw approach. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Thursday, April 12, 2012 08:22 AM To: Simon Delord ; Alexander Vainshtein Cc: l2vpn@ietf.org ; Vladimir Kleiner ; Andrew Sergeev ; Idan Kaspit ; Mishael Wexler ; Rotem Cohen Subject: Re: The status of the approaches to the E-Tree solution? Sorry - the "anonymous presentation" was mine. I should possibly have put in a third column on the CW approach. And hopefully the minutes will be posted soon. We had various discussions, as Simon stated, and consensus seemed to be forming around the two alternatives of two PWEs or two VLANs. I believe three of the authors of the CW approach are also authors of the two VLAN approach and one is also an author of the two PWE approach. So perhaps it's best to let those four individuals say which approach they prefer and why? Giles On 10/04/2012 00:45, "Simon Delord" wrote: > Hi Alexander, > > You are right, no discussion on the WG mailing list recently, but > there have been substantial discussions among the authors of various > solution drafts off the mailing list. As far as I know, no consensus > yet before ietf83, not sure the progress in the Paris WG meeting. I > think the CW approach has not been rejected by the WG yet, or the WG > has not yet decided on which one to adopt. > > Simon > > 2012/4/8 Alexander Vainshtein > >> Hi all, >> >> Unfortunately I have not been able to attend the Paris IETF. >> >> However, looking up the L2VPN proceedings, I've found a short >> anonymous presentation called "E-Tree Update" ( >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >> This presentation discusses the differences of the E-Tree approaches >> based on dedicated VLANs (as in >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >> ext=1) and multiple PWs between the PEs (as in >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >> clude_te >> xt=1) >> and completely ignores the solution based on usage of the CW in the >> PWs connecting the PEs (as in >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >> ext=1 >> ). >> >> >> >> The Minutes of the Paris L2VPN session are not yet available, but I >> wonder whether the WG has taken a decision to reject the approach >> based on the CW usage? I do not remember any recent discussion of >> this topic on the WG mailing list. >> >> >> >> Regards, and lots of thanks in advance, >> >> Sasha >> >> >> >> >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please >> inform us by e-mail, phone or fax, and then delete the original and >> all copies thereof. >> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ------------------------------ Message: 3 Date: Tue, 17 Apr 2012 17:38:10 +0000 From: Jiangyuanlong To: Daniel Cohn Cc: "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E12E@SZXEML508-MBS.china.huawei.com> Content-Type: text/plain; charset="iso-8859-1" Hi Daniel, Please see my comments inline. Regards Yuanlong ------------------------------ Date: Tue, 17 Apr 2012 00:08:02 +0300 From: "Daniel Cohn" To: "Lucy yong" , "Rogers, Josh" , "Henderickx, Wim (Wim)" , , , Cc: l2vpn@ietf.org, Vladimir.Kleiner@ecitele.com, Andrew.Sergeev@ecitele.com, Idan.Kaspit@ecitele.com, Mishael.Wexler@ecitele.com, Rotem.Cohen@ecitele.com Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <115801cd1c15$566895a6$05280101@corrigent.com> Content-Type: text/plain; charset="utf-8" Hi lucy, As we discussed extensively in the list, and as reflected in giles slide, 2 pws are only needed between pes with both root and leaf acs, which will typically be a small minority. [YL] For a PE with only leaf ACs and a PE with both root and leaf ACs, do you really think only 1 PW is needed? if so, should it be a root PW or a leaf PW? Also as per giles slide, dual vlan can have scalability issues due to additional lookup and double use of vlans in internal emulated lan interface. Also there are potential backward compatibility issues with silicon that doesn't support vlan mapping. [YL] Dual VLAN may have scalability concerns only when the PE can only support a single global VLAN space, not sure a VLAN lookup at the port has any scalability issue. [YL] If VLAN mapping can not be supported by the PE, global VLAN may be used instead. Regards, Daniel Thumb typed - please be tolerant Lucy yong wrote: In my mind, the VLAN approach means dual vlan method. The main concern for CW approach is hardware support. Two PW approach can be complex too if the VPLS instance for E-Tree uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast traffic, and some P2MP PWs for multicast traffic. It may double all of them. E-tree is an Ethernet service and there is already VLAN based solution in IEEE, can we just utilize it without complicating VPLS transport construction? This also makes interworking with Eth only network easier. Cheers, Lucy -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Monday, April 16, 2012 8:35 AM To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' Subject: RE: The status of the approaches to the E-Tree solution? I believe the initial question was in regard to the CW method. Are you saying that you no longer are interested in that method in preference of the dual vlan method? Lucy yong wrote: Agree with Wim. VLAN approach is the best solution for E-Tree. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim) Sent: Thursday, April 12, 2012 2:03 AM To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' Subject: Re: The status of the approaches to the E-Tree solution? The vlan approach is superior as it also works for eth only networks, etc. On top some vendors indicate hw issues with the cw approach. As such we have dropped more or less the cw approach. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Thursday, April 12, 2012 08:22 AM To: Simon Delord ; Alexander Vainshtein Cc: l2vpn@ietf.org ; Vladimir Kleiner ; Andrew Sergeev ; Idan Kaspit ; Mishael Wexler ; Rotem Cohen Subject: Re: The status of the approaches to the E-Tree solution? Sorry - the "anonymous presentation" was mine. I should possibly have put in a third column on the CW approach. And hopefully the minutes will be posted soon. We had various discussions, as Simon stated, and consensus seemed to be forming around the two alternatives of two PWEs or two VLANs. I believe three of the authors of the CW approach are also authors of the two VLAN approach and one is also an author of the two PWE approach. So perhaps it's best to let those four individuals say which approach they prefer and why? Giles On 10/04/2012 00:45, "Simon Delord" wrote: > Hi Alexander, > > You are right, no discussion on the WG mailing list recently, but there > have been substantial discussions among the authors of various solution > drafts off the mailing list. As far as I know, no consensus yet before > ietf83, not sure the progress in the Paris WG meeting. I think the CW > approach has not been rejected by the WG yet, or the WG has not yet decided > on which one to adopt. > > Simon > > 2012/4/8 Alexander Vainshtein > >> Hi all, >> >> Unfortunately I have not been able to attend the Paris IETF. >> >> However, looking up the L2VPN proceedings, I've found a short anonymous >> presentation called "E-Tree Update" ( >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). This >> presentation discusses the differences of the E-Tree approaches based on >> dedicated VLANs (as in >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_text=1) >> and multiple PWs between the PEs (as in >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?include_t e >> xt=1) >> and completely ignores the solution based on usage of the CW in the PWs >> connecting the PEs (as in >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_text=1 >> ). >> >> >> >> The Minutes of the Paris L2VPN session are not yet available, but I wonder >> whether the WG has taken a decision to reject the approach based on the CW >> usage? I do not remember any recent discussion of this topic on the WG >> mailing list. >> >> >> >> Regards, and lots of thanks in advance, >> >> Sasha >> >> >> >> >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please inform us >> by e-mail, phone or fax, and then delete the original and all copies >> thereof. >> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ------------------------------ Message: 3 Date: Mon, 16 Apr 2012 21:38:51 +0000 From: Lucy yong To: Daniel Cohn , "Rogers, Josh" , "Henderickx, Wim (Wim)" , "giles.heron@gmail.com" , "simon.delord@gmail.com" , "Alexander.Vainshtein@ecitele.com" Cc: "l2vpn@ietf.org" , "Vladimir.Kleiner@ecitele.com" , "Andrew.Sergeev@ecitele.com" , "Idan.Kaspit@ecitele.com" , "Mishael.Wexler@ecitele.com" , "Rotem.Cohen@ecitele.com" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264A1C0@dfweml505-mbx> Content-Type: text/plain; charset="utf-8" Snipped, As we discussed extensively in the list, and as reflected in giles slide, 2 pws are only needed between pes with both root and leaf acs, which will typically be a small minority. [[LY]] Don't know if the assumption is true. Even it is the case, both approaches can benefit from it. I was off for a while and captures some discussions now. Also as per giles slide, dual vlan can have scalability issues due to additional lookup and double use of vlans in internal emulated lan interface. Also there are potential backward compatibility issues with silicon that doesn't support vlan mapping. [[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am not clear on all the issues. Could you be more specific? As I mentioned in below, two PW approach makes VPLS transport construction and packet forwarding more complex, I can see potential backward compatibility issues with 2 PW solution. Regards, Lucy Regards, Daniel Thumb typed - please be tolerant Lucy yong wrote: In my mind, the VLAN approach means dual vlan method. The main concern for CW approach is hardware support. Two PW approach can be complex too if the VPLS instance for E-Tree uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast traffic, and some P2MP PWs for multicast traffic. It may double all of them. E-tree is an Ethernet service and there is already VLAN based solution in IEEE, can we just utilize it without complicating VPLS transport construction? This also makes interworking with Eth only network easier. Cheers, Lucy -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Monday, April 16, 2012 8:35 AM To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' Subject: RE: The status of the approaches to the E-Tree solution? I believe the initial question was in regard to the CW method. Are you saying that you no longer are interested in that method in preference of the dual vlan method? Lucy yong wrote: Agree with Wim. VLAN approach is the best solution for E-Tree. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim) Sent: Thursday, April 12, 2012 2:03 AM To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' Subject: Re: The status of the approaches to the E-Tree solution? The vlan approach is superior as it also works for eth only networks, etc. On top some vendors indicate hw issues with the cw approach. As such we have dropped more or less the cw approach. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Thursday, April 12, 2012 08:22 AM To: Simon Delord ; Alexander Vainshtein Cc: l2vpn@ietf.org ; Vladimir Kleiner ; Andrew Sergeev ; Idan Kaspit ; Mishael Wexler ; Rotem Cohen Subject: Re: The status of the approaches to the E-Tree solution? Sorry - the "anonymous presentation" was mine. I should possibly have put in a third column on the CW approach. And hopefully the minutes will be posted soon. We had various discussions, as Simon stated, and consensus seemed to be forming around the two alternatives of two PWEs or two VLANs. I believe three of the authors of the CW approach are also authors of the two VLAN approach and one is also an author of the two PWE approach. So perhaps it's best to let those four individuals say which approach they prefer and why? Giles On 10/04/2012 00:45, "Simon Delord" wrote: > Hi Alexander, > > You are right, no discussion on the WG mailing list recently, but there > have been substantial discussions among the authors of various solution > drafts off the mailing list. As far as I know, no consensus yet before > ietf83, not sure the progress in the Paris WG meeting. I think the CW > approach has not been rejected by the WG yet, or the WG has not yet decided > on which one to adopt. > > Simon > > 2012/4/8 Alexander Vainshtein > >> Hi all, >> >> Unfortunately I have not been able to attend the Paris IETF. >> >> However, looking up the L2VPN proceedings, I've found a short anonymous >> presentation called "E-Tree Update" ( >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). This >> presentation discusses the differences of the E-Tree approaches based on >> dedicated VLANs (as in >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_text=1) >> and multiple PWs between the PEs (as in >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?include_t e >> xt=1) >> and completely ignores the solution based on usage of the CW in the PWs >> connecting the PEs (as in >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_text=1 >> ). >> >> >> >> The Minutes of the Paris L2VPN session are not yet available, but I wonder >> whether the WG has taken a decision to reject the approach based on the CW >> usage? I do not remember any recent discussion of this topic on the WG >> mailing list. >> >> >> >> Regards, and lots of thanks in advance, >> >> Sasha >> >> >> >> >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please inform us >> by e-mail, phone or fax, and then delete the original and all copies >> thereof. >> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ------------------------------ Message: 4 Date: Tue, 17 Apr 2012 11:56:29 +0300 From: "Daniel Cohn" To: "Lucy yong" , "Rogers, Josh" , "Henderickx, Wim (Wim)" , , , , "Sam Cao" Cc: l2vpn@ietf.org, Vladimir.Kleiner@ecitele.com, Andrew.Sergeev@ecitele.com, Idan.Kaspit@ecitele.com, Mishael.Wexler@ecitele.com, Rotem.Cohen@ecitele.com Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <44F4E579A764584EA9BDFD07D0CA081307510E14@tlvmail1> Content-Type: text/plain; charset="us-ascii" Adding Sam (as l2vpn@ is holding messages) DC -----Original Message----- From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Tuesday, April 17, 2012 12:39 AM To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); giles.heron@gmail.com; simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com Subject: RE: The status of the approaches to the E-Tree solution? Snipped, As we discussed extensively in the list, and as reflected in giles slide, 2 pws are only needed between pes with both root and leaf acs, which will typically be a small minority. [[LY]] Don't know if the assumption is true. Even it is the case, both approaches can benefit from it. I was off for a while and captures some discussions now. Also as per giles slide, dual vlan can have scalability issues due to additional lookup and double use of vlans in internal emulated lan interface. Also there are potential backward compatibility issues with silicon that doesn't support vlan mapping. [[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am not clear on all the issues. Could you be more specific? As I mentioned in below, two PW approach makes VPLS transport construction and packet forwarding more complex, I can see potential backward compatibility issues with 2 PW solution. Regards, Lucy Regards, Daniel Thumb typed - please be tolerant Lucy yong wrote: In my mind, the VLAN approach means dual vlan method. The main concern for CW approach is hardware support. Two PW approach can be complex too if the VPLS instance for E-Tree uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast traffic, and some P2MP PWs for multicast traffic. It may double all of them. E-tree is an Ethernet service and there is already VLAN based solution in IEEE, can we just utilize it without complicating VPLS transport construction? This also makes interworking with Eth only network easier. Cheers, Lucy -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Monday, April 16, 2012 8:35 AM To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' Subject: RE: The status of the approaches to the E-Tree solution? I believe the initial question was in regard to the CW method. Are you saying that you no longer are interested in that method in preference of the dual vlan method? Lucy yong wrote: Agree with Wim. VLAN approach is the best solution for E-Tree. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim) Sent: Thursday, April 12, 2012 2:03 AM To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' Subject: Re: The status of the approaches to the E-Tree solution? The vlan approach is superior as it also works for eth only networks, etc. On top some vendors indicate hw issues with the cw approach. As such we have dropped more or less the cw approach. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Thursday, April 12, 2012 08:22 AM To: Simon Delord ; Alexander Vainshtein Cc: l2vpn@ietf.org ; Vladimir Kleiner ; Andrew Sergeev ; Idan Kaspit ; Mishael Wexler ; Rotem Cohen Subject: Re: The status of the approaches to the E-Tree solution? Sorry - the "anonymous presentation" was mine. I should possibly have put in a third column on the CW approach. And hopefully the minutes will be posted soon. We had various discussions, as Simon stated, and consensus seemed to be forming around the two alternatives of two PWEs or two VLANs. I believe three of the authors of the CW approach are also authors of the two VLAN approach and one is also an author of the two PWE approach. So perhaps it's best to let those four individuals say which approach they prefer and why? Giles On 10/04/2012 00:45, "Simon Delord" wrote: > Hi Alexander, > > You are right, no discussion on the WG mailing list recently, but > there have been substantial discussions among the authors of various > solution drafts off the mailing list. As far as I know, no consensus > yet before ietf83, not sure the progress in the Paris WG meeting. I > think the CW approach has not been rejected by the WG yet, or the WG > has not yet decided on which one to adopt. > > Simon > > 2012/4/8 Alexander Vainshtein > >> Hi all, >> >> Unfortunately I have not been able to attend the Paris IETF. >> >> However, looking up the L2VPN proceedings, I've found a short >> anonymous presentation called "E-Tree Update" ( >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >> This presentation discusses the differences of the E-Tree approaches >> based on dedicated VLANs (as in >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >> ext=1) and multiple PWs between the PEs (as in >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >> clude_te >> xt=1) >> and completely ignores the solution based on usage of the CW in the >> PWs connecting the PEs (as in >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >> ext=1 >> ). >> >> >> >> The Minutes of the Paris L2VPN session are not yet available, but I >> wonder whether the WG has taken a decision to reject the approach >> based on the CW usage? I do not remember any recent discussion of >> this topic on the WG mailing list. >> >> >> >> Regards, and lots of thanks in advance, >> >> Sasha >> >> >> >> >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please >> inform us by e-mail, phone or fax, and then delete the original and >> all copies thereof. >> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 20 ************************************* ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 21 ************************************* From lucy.yong@huawei.com Wed Apr 18 08:33:10 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E808721F84DA for ; Wed, 18 Apr 2012 08:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HS_INDEX_PARAM=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 BOOMaaStubFe for ; Wed, 18 Apr 2012 08:33:06 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5DB21F8573 for ; Wed, 18 Apr 2012 08:33:06 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFI20010; Wed, 18 Apr 2012 11:33:06 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Apr 2012 08:30:46 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Wed, 18 Apr 2012 08:30:44 -0700 From: Lucy yong To: Sam Cao , 'Daniel Cohn' Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFe/4Txq0Y50G6N17p5MncdwABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEA== Date: Wed, 18 Apr 2012 15:30:43 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264A626@dfweml505-mbx> References: <115801cd1c15$566895a6$05280101@corrigent.com> <2691CE0099834E4A9C5044EEC662BB9D3264A1C0@dfweml505-mbx> <44F4E579A764584EA9BDFD07D0CA081307510E14@tlvmail1> 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.134.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 18 Apr 2012 15:33:11 -0000 Please see inline. -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Tuesday, April 17, 2012 7:14 AM To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; gile= s.heron@gmail.com; simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; Andrew.Sergeev@ecitele.co= m; Idan.Kaspit@ecitele.com; Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele= .com Subject: RE: The status of the approaches to the E-Tree solution? Yes, 2 pws are only needed between pes with both root and leaf acs after improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 P2MP PWs if need. There is no difference between P2MP or normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW?=20 [[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both ro= ot and leaf ACs set up two or one P2MP PW to other PEs (some PE have both r= oot and leaf AC and some only have leaf ACs)?=20 Regards, Lucy Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Tuesday, April 17, 2012 4:56 PM To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); giles.heron@gmail.com; simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com Subject: RE: The status of the approaches to the E-Tree solution? Adding Sam (as l2vpn@ is holding messages) DC=20 -----Original Message----- From: Lucy yong [mailto:lucy.yong@huawei.com]=20 Sent: Tuesday, April 17, 2012 12:39 AM To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); giles.heron@gmail.com; simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com Subject: RE: The status of the approaches to the E-Tree solution? Snipped, As we discussed extensively in the list, and as reflected in giles slide, 2 pws are only needed between pes with both root and leaf acs, which will typically be a small minority. [[LY]] Don't know if the assumption is true. Even it is the case, both approaches can benefit from it. I was off for a while and captures some discussions now.=20 Also as per giles slide, dual vlan can have scalability issues due to additional lookup and double use of vlans in internal emulated lan interface. Also there are potential backward compatibility issues with silicon that doesn't support vlan mapping. [[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am not clear on all the issues. Could you be more specific? As I mentioned in below, two PW approach makes VPLS transport construction and packet forwarding more complex, I can see potential backward compatibility issues with 2 PW solution.=20 Regards, Lucy Regards, Daniel Thumb typed - please be tolerant Lucy yong wrote: In my mind, the VLAN approach means dual vlan method. The main concern for CW approach is hardware support. Two PW approach can be complex too if the VPLS instance for E-Tree uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast traffic, and some P2MP PWs for multicast traffic. It may double all of them. E-tree is an Ethernet service and there is already VLAN based solution in IEEE, can we just utilize it without complicating VPLS transport construction? This also makes interworking with Eth only network easier. Cheers, Lucy -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Monday, April 16, 2012 8:35 AM To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' Subject: RE: The status of the approaches to the E-Tree solution? I believe the initial question was in regard to the CW method. Are you saying that you no longer are interested in that method in preference of the dual vlan method? Lucy yong wrote: Agree with Wim. VLAN approach is the best solution for E-Tree. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim) Sent: Thursday, April 12, 2012 2:03 AM To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' Subject: Re: The status of the approaches to the E-Tree solution? The vlan approach is superior as it also works for eth only networks, etc. On top some vendors indicate hw issues with the cw approach. As such we have dropped more or less the cw approach. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Giles Heron [mailto:giles.heron@gmail.com] Sent: Thursday, April 12, 2012 08:22 AM To: Simon Delord ; Alexander Vainshtein Cc: l2vpn@ietf.org ; Vladimir Kleiner ; Andrew Sergeev ; Idan Kaspit ; Mishael Wexler ; Rotem Cohen Subject: Re: The status of the approaches to the E-Tree solution? Sorry - the "anonymous presentation" was mine. I should possibly have put in a third column on the CW approach. And hopefully the minutes will be posted soon. We had various discussions, as Simon stated, and consensus seemed to be forming around the two alternatives of two PWEs or two VLANs. I believe three of the authors of the CW approach are also authors of the two VLAN approach and one is also an author of the two PWE approach. So perhaps it's best to let those four individuals say which approach they prefer and why? Giles On 10/04/2012 00:45, "Simon Delord" wrote: > Hi Alexander, > > You are right, no discussion on the WG mailing list recently, but=20 > there have been substantial discussions among the authors of various=20 > solution drafts off the mailing list. As far as I know, no consensus=20 > yet before ietf83, not sure the progress in the Paris WG meeting. I=20 > think the CW approach has not been rejected by the WG yet, or the WG=20 > has not yet decided on which one to adopt. > > Simon > > 2012/4/8 Alexander Vainshtein > >> Hi all, >> >> Unfortunately I have not been able to attend the Paris IETF. >> >> However, looking up the L2VPN proceedings, I've found a short=20 >> anonymous presentation called "E-Tree Update" (=20 >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx).=20 >> This presentation discusses the differences of the E-Tree approaches=20 >> based on dedicated VLANs (as in >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >> ext=3D1) and multiple PWs between the PEs (as in=20 >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >> clude_te >> xt=3D1) >> and completely ignores the solution based on usage of the CW in the=20 >> PWs connecting the PEs (as in >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >> ext=3D1 >> ). >> >> >> >> The Minutes of the Paris L2VPN session are not yet available, but I=20 >> wonder whether the WG has taken a decision to reject the approach=20 >> based on the CW usage? I do not remember any recent discussion of=20 >> this topic on the WG mailing list. >> >> >> >> Regards, and lots of thanks in advance, >> >> Sasha >> >> >> >> >> >> This e-mail message is intended for the recipient only and contains=20 >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please=20 >> inform us by e-mail, phone or fax, and then delete the original and=20 >> all copies thereof. >> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From josh.rogers@twcable.com Wed Apr 18 09:10:11 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4181D21F8533 for ; Wed, 18 Apr 2012 09:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.188 X-Spam-Level: X-Spam-Status: No, score=0.188 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HS_INDEX_PARAM=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 XWWXvV+rYeN9 for ; Wed, 18 Apr 2012 09:10:07 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id D7DAA21F85F4 for ; Wed, 18 Apr 2012 09:10:06 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,442,1330923600"; d="scan'208";a="352832692" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 18 Apr 2012 12:07:05 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Wed, 18 Apr 2012 12:08:07 -0400 From: "Rogers, Josh" To: Lucy yong , Sam Cao , 'Daniel Cohn' Date: Wed, 18 Apr 2012 12:08:08 -0400 Subject: Re: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0dfXFuYKn+28YCSUyuvyDT2kpS+w== Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D3264A626@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 18 Apr 2012 16:10:11 -0000 Lucy, Allow me to think out loud here, as the interchange thus far as been overly terse, and has not helped me understand the issue better. I believe the answer is two. To me, this seems like a moot point, as both methods require the ingress traffic to be encapsulated uniquely based on the AC type (one applies a root or leaf S-Tag, and the other places the traffic into a PW purposed for root or leaf traffic). The defining difference when considering P2MP PW's, is the decision to forward is being made at the ingress PE, or the egress PE. 2VLAN - On ingress PE, all frames are forwarded onto P2MP PW on ingress PE, and at the egress PE a decision to forward out the receiving AC is made. Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for traffic coming from a root AC) I see how 2VLAN is simpler when P2MP PW's are involved, I think. I haven't had any first hand experience with P2MP PW's, however, so don't feel terribly strong about this objection. Is this a real problem for others (now or in the future), or is this objection in the weeds? I'm not sure the 'additional complexity' is notable, or even relevant. I encourage others to speak up if they disagree, as P2MP PW is only conceptual to me, and I am unfamiliar with real-life use cases for it. Thanks, Josh On 4/18/12 10:30 AM, "Lucy yong" wrote: >Please see inline. > >-----Original Message----- >From: Sam Cao [mailto:yuqun.cao@gmail.com] >Sent: Tuesday, April 17, 2012 7:14 AM >To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >giles.heron@gmail.com; simon.delord@gmail.com; >Alexander.Vainshtein@ecitele.com >Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >Subject: RE: The status of the approaches to the E-Tree solution? > >Yes, 2 pws are only needed between pes with both root and leaf acs after >improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >P2MP >PWs if need. There is no difference between P2MP or normal PW setup. But, >can Leaf-ACs be bound to Root PE of P2MP PW? > >[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >both root and leaf AC and some only have leaf ACs)? >Regards, >Lucy > >Regards, > >Yuqun (Sam) Cao >E-mail: Yuqun.cao@gmail.com > > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Tuesday, April 17, 2012 4:56 PM >To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); giles.heron@gmail.com; >simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >Subject: RE: The status of the approaches to the E-Tree solution? > >Adding Sam (as l2vpn@ is holding messages) > >DC > >-----Original Message----- >From: Lucy yong [mailto:lucy.yong@huawei.com] >Sent: Tuesday, April 17, 2012 12:39 AM >To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >giles.heron@gmail.com; simon.delord@gmail.com; >Alexander.Vainshtein@ecitele.com >Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >Subject: RE: The status of the approaches to the E-Tree solution? > > >Snipped, > >As we discussed extensively in the list, and as reflected in giles >slide, 2 pws are only needed between pes with both root and leaf acs, >which will typically be a small minority. >[[LY]] Don't know if the assumption is true. Even it is the case, both >approaches can benefit from it. I was off for a while and captures some >discussions now. > >Also as per giles slide, dual vlan can have scalability issues due to >additional lookup and double use of vlans in internal emulated lan >interface. Also there are potential backward compatibility issues with >silicon that doesn't support vlan mapping. >[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >not clear on all the issues. Could you be more specific? As I mentioned >in below, two PW approach makes VPLS transport construction and packet >forwarding more complex, I can see potential backward compatibility >issues with 2 PW solution. > >Regards, >Lucy > >Regards, > >Daniel > >Thumb typed - please be tolerant > >Lucy yong wrote: > >In my mind, the VLAN approach means dual vlan method. > >The main concern for CW approach is hardware support. > >Two PW approach can be complex too if the VPLS instance for E-Tree uses >P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >traffic, and some P2MP PWs for multicast traffic. It may double all of >them. > >E-tree is an Ethernet service and there is already VLAN based solution >in IEEE, can we just utilize it without complicating VPLS transport >construction? This also makes interworking with Eth only network easier. > >Cheers, >Lucy > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Monday, April 16, 2012 8:35 AM >To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >Subject: RE: The status of the approaches to the E-Tree solution? > >I believe the initial question was in regard to the CW method. Are you >saying that you no longer are interested in that method in preference of >the dual vlan method? > > > >Lucy yong wrote: > > >Agree with Wim. VLAN approach is the best solution for E-Tree. > >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >Of Henderickx, Wim (Wim) >Sent: Thursday, April 12, 2012 2:03 AM >To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >'Alexander.Vainshtein@ecitele.com' >Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >Subject: Re: The status of the approaches to the E-Tree solution? > >The vlan approach is superior as it also works for eth only networks, >etc. On top some vendors indicate hw issues with the cw approach. As >such we have dropped more or less the cw approach. > >Cheers, >Wim >_________________ >sent from blackberry > >----- Original Message ----- >From: Giles Heron [mailto:giles.heron@gmail.com] >Sent: Thursday, April 12, 2012 08:22 AM >To: Simon Delord ; Alexander Vainshtein > >Cc: l2vpn@ietf.org ; Vladimir Kleiner >; Andrew Sergeev >; Idan Kaspit ; >Mishael Wexler ; Rotem Cohen > >Subject: Re: The status of the approaches to the E-Tree solution? > >Sorry - the "anonymous presentation" was mine. I should possibly have >put in a third column on the CW approach. And hopefully the minutes >will be posted soon. > >We had various discussions, as Simon stated, and consensus seemed to be >forming around the two alternatives of two PWEs or two VLANs. I believe >three of the authors of the CW approach are also authors of the two VLAN >approach and one is also an author of the two PWE approach. So perhaps >it's best to let those four individuals say which approach they prefer >and why? > >Giles > >On 10/04/2012 00:45, "Simon Delord" wrote: > >> Hi Alexander, >> >> You are right, no discussion on the WG mailing list recently, but >> there have been substantial discussions among the authors of various >> solution drafts off the mailing list. As far as I know, no consensus >> yet before ietf83, not sure the progress in the Paris WG meeting. I >> think the CW approach has not been rejected by the WG yet, or the WG >> has not yet decided on which one to adopt. >> >> Simon >> >> 2012/4/8 Alexander Vainshtein >> >>> Hi all, >>> >>> Unfortunately I have not been able to attend the Paris IETF. >>> >>> However, looking up the L2VPN proceedings, I've found a short >>> anonymous presentation called "E-Tree Update" ( >>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>> This presentation discusses the differences of the E-Tree approaches >>> based on dedicated VLANs (as in >>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>> ext=3D1) and multiple PWs between the PEs (as in >>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>> clude_te >>> xt=3D1) >>> and completely ignores the solution based on usage of the CW in the >>> PWs connecting the PEs (as in >>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>> ext=3D1 >>> ). >>> >>> >>> >>> The Minutes of the Paris L2VPN session are not yet available, but I >>> wonder whether the WG has taken a decision to reject the approach >>> based on the CW usage? I do not remember any recent discussion of >>> this topic on the WG mailing list. >>> >>> >>> >>> Regards, and lots of thanks in advance, >>> >>> Sasha >>> >>> >>> >>> >>> >>> This e-mail message is intended for the recipient only and contains >>> information which is CONFIDENTIAL and which may be proprietary to ECI > >>> Telecom. If you have received this transmission in error, please >>> inform us by e-mail, phone or fax, and then delete the original and >>> all copies thereof. >>> > > > > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject >to copyright belonging to Time Warner Cable. This E-mail is intended >solely for the use of the individual or entity to which it is addressed. >If you are not the intended recipient of this E-mail, you are hereby >notified that any dissemination, distribution, copying, or action taken >in relation to the contents of and attachments to this E-mail is >strictly prohibited and may be unlawful. If you have received this >E-mail in error, please notify the sender immediately and permanently >delete the original and any copy of this E-mail and any printout. > This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From lucy.yong@huawei.com Wed Apr 18 09:32:29 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF5C21F857A for ; Wed, 18 Apr 2012 09:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HS_INDEX_PARAM=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 NOqJnO3wFtz1 for ; Wed, 18 Apr 2012 09:32:24 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C364C21F8572 for ; Wed, 18 Apr 2012 09:32:24 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFI23712; Wed, 18 Apr 2012 12:32:24 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Apr 2012 09:29:56 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Wed, 18 Apr 2012 09:29:00 -0700 From: Lucy yong To: "Rogers, Josh" , Sam Cao , 'Daniel Cohn' Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFe/4Txq0Y50G6N17p5MncdwABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxA= Date: Wed, 18 Apr 2012 16:29:56 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264A69F@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D3264A626@dfweml505-mbx> 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.134.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 18 Apr 2012 16:32:29 -0000 Snipped.. Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for traffic coming from a root AC) [[LY]] Not that simple. You construct either two P2MP PWs to all other PEs = and let egress PE performing filtering, or construct one P2MP PW to leaf-on= ly PEs and two P2MP PWs to root and leaf PEs and let ingress PE perform for= warding and filtering. Both make node process complex. [[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for deliv= ering the frames to remote PEs. We should utilize them with the minimized c= hanges. Dual VLAN solution is simpler than Dual PW. Regards, Lucy I see how 2VLAN is simpler when P2MP PW's are involved, I think. I haven't had any first hand experience with P2MP PW's, however, so don't feel terribly strong about this objection. Is this a real problem for others (now or in the future), or is this objection in the weeds? I'm not sure the 'additional complexity' is notable, or even relevant. I encourage others to speak up if they disagree, as P2MP PW is only conceptual to me, and I am unfamiliar with real-life use cases for it. Thanks, Josh On 4/18/12 10:30 AM, "Lucy yong" wrote: >Please see inline. > >-----Original Message----- >From: Sam Cao [mailto:yuqun.cao@gmail.com] >Sent: Tuesday, April 17, 2012 7:14 AM >To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >giles.heron@gmail.com; simon.delord@gmail.com; >Alexander.Vainshtein@ecitele.com >Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >Subject: RE: The status of the approaches to the E-Tree solution? > >Yes, 2 pws are only needed between pes with both root and leaf acs after >improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >P2MP >PWs if need. There is no difference between P2MP or normal PW setup. But, >can Leaf-ACs be bound to Root PE of P2MP PW? > >[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >both root and leaf AC and some only have leaf ACs)? >Regards, >Lucy > >Regards, > >Yuqun (Sam) Cao >E-mail: Yuqun.cao@gmail.com > > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Tuesday, April 17, 2012 4:56 PM >To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); giles.heron@gmail.com; >simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >Subject: RE: The status of the approaches to the E-Tree solution? > >Adding Sam (as l2vpn@ is holding messages) > >DC > >-----Original Message----- >From: Lucy yong [mailto:lucy.yong@huawei.com] >Sent: Tuesday, April 17, 2012 12:39 AM >To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >giles.heron@gmail.com; simon.delord@gmail.com; >Alexander.Vainshtein@ecitele.com >Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >Subject: RE: The status of the approaches to the E-Tree solution? > > >Snipped, > >As we discussed extensively in the list, and as reflected in giles >slide, 2 pws are only needed between pes with both root and leaf acs, >which will typically be a small minority. >[[LY]] Don't know if the assumption is true. Even it is the case, both >approaches can benefit from it. I was off for a while and captures some >discussions now. > >Also as per giles slide, dual vlan can have scalability issues due to >additional lookup and double use of vlans in internal emulated lan >interface. Also there are potential backward compatibility issues with >silicon that doesn't support vlan mapping. >[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >not clear on all the issues. Could you be more specific? As I mentioned >in below, two PW approach makes VPLS transport construction and packet >forwarding more complex, I can see potential backward compatibility >issues with 2 PW solution. > >Regards, >Lucy > >Regards, > >Daniel > >Thumb typed - please be tolerant > >Lucy yong wrote: > >In my mind, the VLAN approach means dual vlan method. > >The main concern for CW approach is hardware support. > >Two PW approach can be complex too if the VPLS instance for E-Tree uses >P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >traffic, and some P2MP PWs for multicast traffic. It may double all of >them. > >E-tree is an Ethernet service and there is already VLAN based solution >in IEEE, can we just utilize it without complicating VPLS transport >construction? This also makes interworking with Eth only network easier. > >Cheers, >Lucy > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Monday, April 16, 2012 8:35 AM >To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >Subject: RE: The status of the approaches to the E-Tree solution? > >I believe the initial question was in regard to the CW method. Are you >saying that you no longer are interested in that method in preference of >the dual vlan method? > > > >Lucy yong wrote: > > >Agree with Wim. VLAN approach is the best solution for E-Tree. > >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >Of Henderickx, Wim (Wim) >Sent: Thursday, April 12, 2012 2:03 AM >To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >'Alexander.Vainshtein@ecitele.com' >Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >Subject: Re: The status of the approaches to the E-Tree solution? > >The vlan approach is superior as it also works for eth only networks, >etc. On top some vendors indicate hw issues with the cw approach. As >such we have dropped more or less the cw approach. > >Cheers, >Wim >_________________ >sent from blackberry > >----- Original Message ----- >From: Giles Heron [mailto:giles.heron@gmail.com] >Sent: Thursday, April 12, 2012 08:22 AM >To: Simon Delord ; Alexander Vainshtein > >Cc: l2vpn@ietf.org ; Vladimir Kleiner >; Andrew Sergeev >; Idan Kaspit ; >Mishael Wexler ; Rotem Cohen > >Subject: Re: The status of the approaches to the E-Tree solution? > >Sorry - the "anonymous presentation" was mine. I should possibly have >put in a third column on the CW approach. And hopefully the minutes >will be posted soon. > >We had various discussions, as Simon stated, and consensus seemed to be >forming around the two alternatives of two PWEs or two VLANs. I believe >three of the authors of the CW approach are also authors of the two VLAN >approach and one is also an author of the two PWE approach. So perhaps >it's best to let those four individuals say which approach they prefer >and why? > >Giles > >On 10/04/2012 00:45, "Simon Delord" wrote: > >> Hi Alexander, >> >> You are right, no discussion on the WG mailing list recently, but >> there have been substantial discussions among the authors of various >> solution drafts off the mailing list. As far as I know, no consensus >> yet before ietf83, not sure the progress in the Paris WG meeting. I >> think the CW approach has not been rejected by the WG yet, or the WG >> has not yet decided on which one to adopt. >> >> Simon >> >> 2012/4/8 Alexander Vainshtein >> >>> Hi all, >>> >>> Unfortunately I have not been able to attend the Paris IETF. >>> >>> However, looking up the L2VPN proceedings, I've found a short >>> anonymous presentation called "E-Tree Update" ( >>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>> This presentation discusses the differences of the E-Tree approaches >>> based on dedicated VLANs (as in >>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>> ext=3D1) and multiple PWs between the PEs (as in >>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>> clude_te >>> xt=3D1) >>> and completely ignores the solution based on usage of the CW in the >>> PWs connecting the PEs (as in >>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>> ext=3D1 >>> ). >>> >>> >>> >>> The Minutes of the Paris L2VPN session are not yet available, but I >>> wonder whether the WG has taken a decision to reject the approach >>> based on the CW usage? I do not remember any recent discussion of >>> this topic on the WG mailing list. >>> >>> >>> >>> Regards, and lots of thanks in advance, >>> >>> Sasha >>> >>> >>> >>> >>> >>> This e-mail message is intended for the recipient only and contains >>> information which is CONFIDENTIAL and which may be proprietary to ECI > >>> Telecom. If you have received this transmission in error, please >>> inform us by e-mail, phone or fax, and then delete the original and >>> all copies thereof. >>> > > > > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject >to copyright belonging to Time Warner Cable. This E-mail is intended >solely for the use of the individual or entity to which it is addressed. >If you are not the intended recipient of this E-mail, you are hereby >notified that any dissemination, distribution, copying, or action taken >in relation to the contents of and attachments to this E-mail is >strictly prohibited and may be unlawful. If you have received this >E-mail in error, please notify the sender immediately and permanently >delete the original and any copy of this E-mail and any printout. > This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From DanielC@orckit.com Wed Apr 18 11:42:02 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C48711E8093 for ; Wed, 18 Apr 2012 11:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.377 X-Spam-Level: * X-Spam-Status: No, score=1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_ILLEGAL_IP=1.908, RCVD_NUMERIC_HELO=2.067] 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 lb9J7FXK+fLw for ; Wed, 18 Apr 2012 11:41:58 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9B26121F84E6 for ; Wed, 18 Apr 2012 11:41:57 -0700 (PDT) Received: from 1.1.40.5 ([1.1.40.5]) by tlvmail1.corrigent.com ([1.1.40.5]) with Microsoft Exchange Server HTTP-DAV ; Wed, 18 Apr 2012 18:44:09 +0000 Date: Wed, 18 Apr 2012 21:41:50 +0300 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <12b701cd1d93$3dbbe37d$05280101@corrigent.com> Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFe/4Txq0Y50G6N17p5MncdwABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jA== X-MimeOLE: Produced By Microsoft Exchange V6.5 Importance: normal From: "Daniel Cohn" To: "Lucy yong" , "Rogers, Josh" , "Sam Cao" MIME-Version: 1.0 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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, 18 Apr 2012 18:42:02 -0000 I think the first option its the natural way to go. How is the = processing in this case more complex?=0A= =0A= Thumb typed - please be tolerant=0A= =0A= Lucy yong wrote:=0A= =0A= Snipped.. Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP = PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for traffic coming from a root AC) [[LY]] Not that simple. You construct either two P2MP PWs to all other = PEs and let egress PE performing filtering, or construct one P2MP PW to = leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE = perform forwarding and filtering. Both make node process complex. [[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for = delivering the frames to remote PEs. We should utilize them with the = minimized changes. Dual VLAN solution is simpler than Dual PW. Regards, Lucy I see how 2VLAN is simpler when P2MP PW's are involved, I think. I haven't had any first hand experience with P2MP PW's, however, so don't feel terribly strong about this objection. Is this a real problem for others (now or in the future), or is this objection in the weeds? I'm not sure the 'additional complexity' is notable, or even relevant. = I encourage others to speak up if they disagree, as P2MP PW is only conceptual to me, and I am unfamiliar with real-life use cases for it. Thanks, Josh On 4/18/12 10:30 AM, "Lucy yong" wrote: >Please see inline. > >-----Original Message----- >From: Sam Cao [mailto:yuqun.cao@gmail.com] >Sent: Tuesday, April 17, 2012 7:14 AM >To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >giles.heron@gmail.com; simon.delord@gmail.com; >Alexander.Vainshtein@ecitele.com >Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >Subject: RE: The status of the approaches to the E-Tree solution? > >Yes, 2 pws are only needed between pes with both root and leaf acs = after >improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >P2MP >PWs if need. There is no difference between P2MP or normal PW setup. = But, >can Leaf-ACs be bound to Root PE of P2MP PW? > >[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with = both >root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >both root and leaf AC and some only have leaf ACs)? >Regards, >Lucy > >Regards, > >Yuqun (Sam) Cao >E-mail: Yuqun.cao@gmail.com > > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Tuesday, April 17, 2012 4:56 PM >To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); = giles.heron@gmail.com; >simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >Subject: RE: The status of the approaches to the E-Tree solution? > >Adding Sam (as l2vpn@ is holding messages) > >DC > >-----Original Message----- >From: Lucy yong [mailto:lucy.yong@huawei.com] >Sent: Tuesday, April 17, 2012 12:39 AM >To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >giles.heron@gmail.com; simon.delord@gmail.com; >Alexander.Vainshtein@ecitele.com >Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >Subject: RE: The status of the approaches to the E-Tree solution? > > >Snipped, > >As we discussed extensively in the list, and as reflected in giles >slide, 2 pws are only needed between pes with both root and leaf acs, >which will typically be a small minority. >[[LY]] Don't know if the assumption is true. Even it is the case, both >approaches can benefit from it. I was off for a while and captures some >discussions now. > >Also as per giles slide, dual vlan can have scalability issues due to >additional lookup and double use of vlans in internal emulated lan >interface. Also there are potential backward compatibility issues with >silicon that doesn't support vlan mapping. >[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I = am >not clear on all the issues. Could you be more specific? As I mentioned >in below, two PW approach makes VPLS transport construction and packet >forwarding more complex, I can see potential backward compatibility >issues with 2 PW solution. > >Regards, >Lucy > >Regards, > >Daniel > >Thumb typed - please be tolerant > >Lucy yong wrote: > >In my mind, the VLAN approach means dual vlan method. > >The main concern for CW approach is hardware support. > >Two PW approach can be complex too if the VPLS instance for E-Tree uses >P2P PW for unicast traffic and P2MP PW for broadcast and unknown = unicast >traffic, and some P2MP PWs for multicast traffic. It may double all of >them. > >E-tree is an Ethernet service and there is already VLAN based solution >in IEEE, can we just utilize it without complicating VPLS transport >construction? This also makes interworking with Eth only network = easier. > >Cheers, >Lucy > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Monday, April 16, 2012 8:35 AM >To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >Subject: RE: The status of the approaches to the E-Tree solution? > >I believe the initial question was in regard to the CW method. Are you >saying that you no longer are interested in that method in preference = of >the dual vlan method? > > > >Lucy yong wrote: > > >Agree with Wim. VLAN approach is the best solution for E-Tree. > >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >Of Henderickx, Wim (Wim) >Sent: Thursday, April 12, 2012 2:03 AM >To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >'Alexander.Vainshtein@ecitele.com' >Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >Subject: Re: The status of the approaches to the E-Tree solution? > >The vlan approach is superior as it also works for eth only networks, >etc. On top some vendors indicate hw issues with the cw approach. As >such we have dropped more or less the cw approach. > >Cheers, >Wim >_________________ >sent from blackberry > >----- Original Message ----- >From: Giles Heron [mailto:giles.heron@gmail.com] >Sent: Thursday, April 12, 2012 08:22 AM >To: Simon Delord ; Alexander Vainshtein > >Cc: l2vpn@ietf.org ; Vladimir Kleiner >; Andrew Sergeev >; Idan Kaspit ; >Mishael Wexler ; Rotem Cohen > >Subject: Re: The status of the approaches to the E-Tree solution? > >Sorry - the "anonymous presentation" was mine. I should possibly have >put in a third column on the CW approach. And hopefully the minutes >will be posted soon. > >We had various discussions, as Simon stated, and consensus seemed to be >forming around the two alternatives of two PWEs or two VLANs. I = believe >three of the authors of the CW approach are also authors of the two = VLAN >approach and one is also an author of the two PWE approach. So perhaps >it's best to let those four individuals say which approach they prefer >and why? > >Giles > >On 10/04/2012 00:45, "Simon Delord" wrote: > >> Hi Alexander, >> >> You are right, no discussion on the WG mailing list recently, but >> there have been substantial discussions among the authors of various >> solution drafts off the mailing list. As far as I know, no consensus >> yet before ietf83, not sure the progress in the Paris WG meeting. I >> think the CW approach has not been rejected by the WG yet, or the WG >> has not yet decided on which one to adopt. >> >> Simon >> >> 2012/4/8 Alexander Vainshtein >> >>> Hi all, >>> >>> Unfortunately I have not been able to attend the Paris IETF. >>> >>> However, looking up the L2VPN proceedings, I've found a short >>> anonymous presentation called "E-Tree Update" ( >>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>> This presentation discusses the differences of the E-Tree approaches >>> based on dedicated VLANs (as in >>> = http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>> ext=3D1) and multiple PWs between the PEs (as in >>> = http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>> clude_te >>> xt=3D1) >>> and completely ignores the solution based on usage of the CW in the >>> PWs connecting the PEs (as in >>> = http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>> ext=3D1 >>> ). >>> >>> >>> >>> The Minutes of the Paris L2VPN session are not yet available, but I >>> wonder whether the WG has taken a decision to reject the approach >>> based on the CW usage? I do not remember any recent discussion of >>> this topic on the WG mailing list. >>> >>> >>> >>> Regards, and lots of thanks in advance, >>> >>> Sasha >>> >>> >>> >>> >>> >>> This e-mail message is intended for the recipient only and contains >>> information which is CONFIDENTIAL and which may be proprietary to = ECI > >>> Telecom. If you have received this transmission in error, please >>> inform us by e-mail, phone or fax, and then delete the original and >>> all copies thereof. >>> > > > > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject >to copyright belonging to Time Warner Cable. This E-mail is intended >solely for the use of the individual or entity to which it is = addressed. >If you are not the intended recipient of this E-mail, you are hereby >notified that any dissemination, distribution, copying, or action taken >in relation to the contents of and attachments to this E-mail is >strictly prohibited and may be unlawful. If you have received this >E-mail in error, please notify the sender immediately and permanently >delete the original and any copy of this E-mail and any printout. > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. From lucy.yong@huawei.com Wed Apr 18 11:56:48 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67D111E8073 for ; Wed, 18 Apr 2012 11:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HS_INDEX_PARAM=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 M+vHmO4Nf0xp for ; Wed, 18 Apr 2012 11:56:44 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 78FCE21F845D for ; Wed, 18 Apr 2012 11:56:44 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFA30261; Wed, 18 Apr 2012 14:56:44 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Apr 2012 11:53:25 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Wed, 18 Apr 2012 11:53:15 -0700 From: Lucy yong To: Daniel Cohn , "Rogers, Josh" , Sam Cao Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFe/4Txq0Y50G6N17p5MncdwABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jAAu/59A Date: Wed, 18 Apr 2012 18:53:15 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx> References: <12b701cd1d93$3dbbe37d$05280101@corrigent.com> In-Reply-To: <12b701cd1d93$3dbbe37d$05280101@corrigent.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.134.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 18 Apr 2012 18:56:49 -0000 U2VuZCB0aGlzIGFnYWluLg0KDQpUd28gUFcgYXBwcm9hY2ggY2FuIGJlIGNvbXBsZXggdG9vIGlm IHRoZSBWUExTIGluc3RhbmNlIGZvciBFLVRyZWUgdXNlcyANClAyUCBQVyBmb3IgdW5pY2FzdCB0 cmFmZmljIGFuZCBQMk1QIFBXIGZvciBicm9hZGNhc3QgYW5kIHVua25vd24gDQp1bmljYXN0IHRy YWZmaWMsIGFuZCBzb21lIFAyTVAgUFdzIGZvciBtdWx0aWNhc3QgdHJhZmZpYy4gSXQgbWF5IGRv dWJsZSANCmFsbCBvZiB0aGVtLg0KDQpMdWN5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBEYW5pZWwgQ29obiBbbWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbV0gDQpTZW50OiBX ZWRuZXNkYXksIEFwcmlsIDE4LCAyMDEyIDE6NDIgUE0NClRvOiBMdWN5IHlvbmc7IFJvZ2Vycywg Sm9zaDsgU2FtIENhbw0KQ2M6IGwydnBuQGlldGYub3JnDQpTdWJqZWN0OiBSRTogVGhlIHN0YXR1 cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KDQpJIHRoaW5rIHRo ZSBmaXJzdCBvcHRpb24gaXRzIHRoZSBuYXR1cmFsIHdheSB0byBnby4gSG93IGlzIHRoZSBwcm9j ZXNzaW5nIGluIHRoaXMgY2FzZSBtb3JlIGNvbXBsZXg/DQoNClRodW1iIHR5cGVkIC0gcGxlYXNl IGJlIHRvbGVyYW50DQoNCkx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb20+IHdyb3RlOg0K DQoNCg0KU25pcHBlZC4uDQoNCk11bHRpLVBXIC0gT24gaW5ncmVzcyBQRSwgZnJhbWUgaXMgcGxh Y2VkIG9udG8gZWl0aGVyIGEgTGVhZi1vbmx5IFAyTVAgUFcNCihmb3IgdHJhZmZpYyBjb21pbmcg ZnJvbSBhIGxlYWYgQUMpLCBvciBvbnRvIGEgUm9vdC9MZWFmIFAyTVAgUFcgKGZvcg0KdHJhZmZp YyBjb21pbmcgZnJvbSBhIHJvb3QgQUMpDQpbW0xZXV0gTm90IHRoYXQgc2ltcGxlLiBZb3UgY29u c3RydWN0IGVpdGhlciB0d28gUDJNUCBQV3MgdG8gYWxsIG90aGVyIFBFcyBhbmQgbGV0IGVncmVz cyBQRSBwZXJmb3JtaW5nIGZpbHRlcmluZywgb3IgY29uc3RydWN0IG9uZSBQMk1QIFBXIHRvIGxl YWYtb25seSBQRXMgYW5kIHR3byBQMk1QIFBXcyB0byByb290IGFuZCBsZWFmIFBFcyBhbmQgbGV0 IGluZ3Jlc3MgUEUgcGVyZm9ybSBmb3J3YXJkaW5nIGFuZCBmaWx0ZXJpbmcuIEJvdGggbWFrZSBu b2RlIHByb2Nlc3MgY29tcGxleC4NCg0KW1tMWV1dIFZQTFMgaXMgYnVpbHQgd2l0aCB0aGUgbWVj aGFuaXNtIHV0aWxpemluZyBQMlAgYW5kIFAyTVAgUFcgZm9yIGRlbGl2ZXJpbmcgdGhlIGZyYW1l cyB0byByZW1vdGUgUEVzLiBXZSBzaG91bGQgdXRpbGl6ZSB0aGVtIHdpdGggdGhlIG1pbmltaXpl ZCBjaGFuZ2VzLiBEdWFsIFZMQU4gc29sdXRpb24gaXMgc2ltcGxlciB0aGFuIER1YWwgUFcuDQoN ClJlZ2FyZHMsDQpMdWN5DQoNCg0KSSBzZWUgaG93IDJWTEFOIGlzIHNpbXBsZXIgd2hlbiBQMk1Q IFBXJ3MgYXJlIGludm9sdmVkLCBJIHRoaW5rLiAgSQ0KaGF2ZW4ndCBoYWQgYW55IGZpcnN0IGhh bmQgZXhwZXJpZW5jZSB3aXRoIFAyTVAgUFcncywgaG93ZXZlciwgc28gZG9uJ3QNCmZlZWwgdGVy cmlibHkgc3Ryb25nIGFib3V0IHRoaXMgb2JqZWN0aW9uLiAgSXMgdGhpcyBhIHJlYWwgcHJvYmxl bSBmb3INCm90aGVycyAobm93IG9yIGluIHRoZSBmdXR1cmUpLCBvciBpcyB0aGlzIG9iamVjdGlv biBpbiB0aGUgd2VlZHM/DQoNCkknbSBub3Qgc3VyZSB0aGUgJ2FkZGl0aW9uYWwgY29tcGxleGl0 eScgaXMgbm90YWJsZSwgb3IgZXZlbiByZWxldmFudC4gIEkNCmVuY291cmFnZSBvdGhlcnMgdG8g c3BlYWsgdXAgaWYgdGhleSBkaXNhZ3JlZSwgYXMgUDJNUCBQVyBpcyBvbmx5DQpjb25jZXB0dWFs IHRvIG1lLCBhbmQgSSBhbSB1bmZhbWlsaWFyIHdpdGggcmVhbC1saWZlIHVzZSBjYXNlcyBmb3Ig aXQuDQoNClRoYW5rcywNCkpvc2gNCg0KDQoNCk9uIDQvMTgvMTIgMTA6MzAgQU0sICJMdWN5IHlv bmciIDxsdWN5LnlvbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQoNCj5QbGVhc2Ugc2VlIGlubGluZS4N Cj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IFNhbSBDYW8gW21haWx0bzp5 dXF1bi5jYW9AZ21haWwuY29tXQ0KPlNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE3LCAyMDEyIDc6MTQg QU0NCj5UbzogJ0RhbmllbCBDb2huJzsgTHVjeSB5b25nOyAnUm9nZXJzLCBKb3NoJzsgJ0hlbmRl cmlja3gsIFdpbSAoV2ltKSc7DQo+Z2lsZXMuaGVyb25AZ21haWwuY29tOyBzaW1vbi5kZWxvcmRA Z21haWwuY29tOw0KPkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQo+Q2M6IGwydnBu QGlldGYub3JnOyBWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tOw0KPkFuZHJldy5TZXJnZWV2 QGVjaXRlbGUuY29tOyBJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbTsNCj5NaXNoYWVsLldleGxlckBl Y2l0ZWxlLmNvbTsgUm90ZW0uQ29oZW5AZWNpdGVsZS5jb20NCj5TdWJqZWN0OiBSRTogVGhlIHN0 YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPg0KPlllcywg MiBwd3MgYXJlIG9ubHkgbmVlZGVkIGJldHdlZW4gcGVzIHdpdGggYm90aCByb290IGFuZCBsZWFm IGFjcyBhZnRlcg0KPmltcHJvdmluZyBEdWFsLVBXIGFwcHJvYWNoLiBJZiBjb25zaWRlciBQMk1Q LCBEdWFsLVBXIGFwcHJvYWNoIHNldHVwIDINCj5QMk1QDQo+UFdzIGlmIG5lZWQuIFRoZXJlIGlz IG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBQMk1QIG9yIG5vcm1hbCBQVyBzZXR1cC4gQnV0LA0KPmNh biBMZWFmLUFDcyBiZSBib3VuZCB0byBSb290IFBFIG9mIFAyTVAgUFc/DQo+DQo+W1tMWV1dIE5v LCBpdCBtYWtlcyBjb21wbGV4IGluIHNldHRpbmcgdXAgUDJNUCBQVy4gU2hvdWxkIGEgUEUgd2l0 aCBib3RoDQo+cm9vdCBhbmQgbGVhZiBBQ3Mgc2V0IHVwIHR3byBvciBvbmUgUDJNUCBQVyB0byBv dGhlciBQRXMgKHNvbWUgUEUgaGF2ZQ0KPmJvdGggcm9vdCBhbmQgbGVhZiBBQyBhbmQgc29tZSBv bmx5IGhhdmUgbGVhZiBBQ3MpPw0KPlJlZ2FyZHMsDQo+THVjeQ0KPg0KPlJlZ2FyZHMsDQo+DQo+ WXVxdW4gKFNhbSkgQ2FvDQo+RS1tYWlsOiBZdXF1bi5jYW9AZ21haWwuY29tDQo+DQo+DQo+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBEYW5pZWwgQ29obiBbbWFpbHRvOkRhbmll bENAb3Jja2l0LmNvbV0NCj5TZW50OiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiA0OjU2IFBNDQo+ VG86IEx1Y3kgeW9uZzsgUm9nZXJzLCBKb3NoOyBIZW5kZXJpY2t4LCBXaW0gKFdpbSk7IGdpbGVz Lmhlcm9uQGdtYWlsLmNvbTsNCj5zaW1vbi5kZWxvcmRAZ21haWwuY29tOyBBbGV4YW5kZXIuVmFp bnNodGVpbkBlY2l0ZWxlLmNvbTsgU2FtIENhbw0KPkNjOiBsMnZwbkBpZXRmLm9yZzsgVmxhZGlt aXIuS2xlaW5lckBlY2l0ZWxlLmNvbTsNCj5BbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTsgSWRh bi5LYXNwaXRAZWNpdGVsZS5jb207DQo+TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb207IFJvdGVt LkNvaGVuQGVjaXRlbGUuY29tDQo+U3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJv YWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4NCj5BZGRpbmcgU2FtIChhcyBsMnZwbkAg aXMgaG9sZGluZyBtZXNzYWdlcykNCj4NCj5EQw0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+RnJvbTogTHVjeSB5b25nIFttYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb21dDQo+U2Vu dDogVHVlc2RheSwgQXByaWwgMTcsIDIwMTIgMTI6MzkgQU0NCj5UbzogRGFuaWVsIENvaG47IFJv Z2VycywgSm9zaDsgSGVuZGVyaWNreCwgV2ltIChXaW0pOw0KPmdpbGVzLmhlcm9uQGdtYWlsLmNv bTsgc2ltb24uZGVsb3JkQGdtYWlsLmNvbTsNCj5BbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbQ0KPkNjOiBsMnZwbkBpZXRmLm9yZzsgVmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbTsN Cj5BbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTsgSWRhbi5LYXNwaXRAZWNpdGVsZS5jb207DQo+ TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb207IFJvdGVtLkNvaGVuQGVjaXRlbGUuY29tDQo+U3Vi amVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1 dGlvbj8NCj4NCj4NCj5TbmlwcGVkLA0KPg0KPkFzIHdlIGRpc2N1c3NlZCBleHRlbnNpdmVseSBp biB0aGUgbGlzdCwgYW5kIGFzIHJlZmxlY3RlZCBpbiBnaWxlcw0KPnNsaWRlLCAyIHB3cyBhcmUg b25seSBuZWVkZWQgYmV0d2VlbiBwZXMgd2l0aCBib3RoIHJvb3QgYW5kIGxlYWYgYWNzLA0KPndo aWNoIHdpbGwgdHlwaWNhbGx5IGJlIGEgc21hbGwgbWlub3JpdHkuDQo+W1tMWV1dIERvbid0IGtu b3cgaWYgdGhlIGFzc3VtcHRpb24gaXMgdHJ1ZS4gRXZlbiBpdCBpcyB0aGUgY2FzZSwgYm90aA0K PmFwcHJvYWNoZXMgY2FuIGJlbmVmaXQgZnJvbSBpdC4gSSB3YXMgb2ZmIGZvciBhIHdoaWxlIGFu ZCBjYXB0dXJlcyBzb21lDQo+ZGlzY3Vzc2lvbnMgbm93Lg0KPg0KPkFsc28gYXMgcGVyIGdpbGVz IHNsaWRlLCBkdWFsIHZsYW4gY2FuIGhhdmUgc2NhbGFiaWxpdHkgaXNzdWVzIGR1ZSB0bw0KPmFk ZGl0aW9uYWwgbG9va3VwIGFuZCBkb3VibGUgdXNlIG9mIHZsYW5zIGluIGludGVybmFsIGVtdWxh dGVkIGxhbg0KPmludGVyZmFjZS4gQWxzbyB0aGVyZSBhcmUgcG90ZW50aWFsIGJhY2t3YXJkIGNv bXBhdGliaWxpdHkgaXNzdWVzIHdpdGgNCj5zaWxpY29uIHRoYXQgZG9lc24ndCBzdXBwb3J0IHZs YW4gbWFwcGluZy4NCj5bW0xZXV0gSSB3YXMgbm90IGluIElFVEY4MyBtZWV0aW5nIGFuZCB3YWl0 IG9uIHRoZSBtZWV0aW5nIG1pbnV0ZXMuIEkgYW0NCj5ub3QgY2xlYXIgb24gYWxsIHRoZSBpc3N1 ZXMuIENvdWxkIHlvdSBiZSBtb3JlIHNwZWNpZmljPyBBcyBJIG1lbnRpb25lZA0KPmluIGJlbG93 LCB0d28gUFcgYXBwcm9hY2ggbWFrZXMgVlBMUyB0cmFuc3BvcnQgY29uc3RydWN0aW9uIGFuZCBw YWNrZXQNCj5mb3J3YXJkaW5nIG1vcmUgY29tcGxleCwgSSBjYW4gc2VlIHBvdGVudGlhbCBiYWNr d2FyZCBjb21wYXRpYmlsaXR5DQo+aXNzdWVzIHdpdGggMiBQVyBzb2x1dGlvbi4NCj4NCj5SZWdh cmRzLA0KPkx1Y3kNCj4NCj5SZWdhcmRzLA0KPg0KPkRhbmllbA0KPg0KPlRodW1iIHR5cGVkIC0g cGxlYXNlIGJlIHRvbGVyYW50DQo+DQo+THVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbT4g d3JvdGU6DQo+DQo+SW4gbXkgbWluZCwgdGhlIFZMQU4gYXBwcm9hY2ggbWVhbnMgZHVhbCB2bGFu IG1ldGhvZC4NCj4NCj5UaGUgbWFpbiBjb25jZXJuIGZvciBDVyBhcHByb2FjaCBpcyBoYXJkd2Fy ZSBzdXBwb3J0Lg0KPg0KPlR3byBQVyBhcHByb2FjaCBjYW4gYmUgY29tcGxleCB0b28gaWYgdGhl IFZQTFMgaW5zdGFuY2UgZm9yIEUtVHJlZSB1c2VzDQo+UDJQIFBXIGZvciB1bmljYXN0IHRyYWZm aWMgYW5kIFAyTVAgUFcgZm9yIGJyb2FkY2FzdCBhbmQgdW5rbm93biB1bmljYXN0DQo+dHJhZmZp YywgYW5kIHNvbWUgUDJNUCBQV3MgZm9yIG11bHRpY2FzdCB0cmFmZmljLiBJdCBtYXkgZG91Ymxl IGFsbCBvZg0KPnRoZW0uDQo+DQo+RS10cmVlIGlzIGFuIEV0aGVybmV0IHNlcnZpY2UgYW5kIHRo ZXJlIGlzIGFscmVhZHkgVkxBTiBiYXNlZCBzb2x1dGlvbg0KPmluIElFRUUsIGNhbiB3ZSBqdXN0 IHV0aWxpemUgaXQgd2l0aG91dCBjb21wbGljYXRpbmcgVlBMUyB0cmFuc3BvcnQNCj5jb25zdHJ1 Y3Rpb24/IFRoaXMgYWxzbyBtYWtlcyBpbnRlcndvcmtpbmcgd2l0aCBFdGggb25seSBuZXR3b3Jr IGVhc2llci4NCj4NCj5DaGVlcnMsDQo+THVjeQ0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+RnJvbTogUm9nZXJzLCBKb3NoIFttYWlsdG86am9zaC5yb2dlcnNAdHdjYWJsZS5jb21d DQo+U2VudDogTW9uZGF5LCBBcHJpbCAxNiwgMjAxMiA4OjM1IEFNDQo+VG86IEx1Y3kgeW9uZzsg SGVuZGVyaWNreCwgV2ltIChXaW0pOyAnZ2lsZXMuaGVyb25AZ21haWwuY29tJzsNCj4nc2ltb24u ZGVsb3JkQGdtYWlsLmNvbSc7ICdBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbScNCj5D YzogJ2wydnBuQGlldGYub3JnJzsgJ1ZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb20nOw0KPidB bmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbSc7ICdJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbSc7DQo+ J01pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tJzsgJ1JvdGVtLkNvaGVuQGVjaXRlbGUuY29tJw0K PlN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUg c29sdXRpb24/DQo+DQo+SSBiZWxpZXZlIHRoZSBpbml0aWFsIHF1ZXN0aW9uIHdhcyBpbiByZWdh cmQgdG8gdGhlIENXIG1ldGhvZC4gIEFyZSB5b3UNCj5zYXlpbmcgdGhhdCB5b3Ugbm8gbG9uZ2Vy IGFyZSBpbnRlcmVzdGVkIGluIHRoYXQgbWV0aG9kIGluIHByZWZlcmVuY2Ugb2YNCj50aGUgZHVh bCB2bGFuIG1ldGhvZD8NCj4NCj4NCj4NCj5MdWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3ZWkuY29t PiB3cm90ZToNCj4NCj4NCj5BZ3JlZSB3aXRoIFdpbS4gVkxBTiBhcHByb2FjaCBpcyB0aGUgYmVz dCBzb2x1dGlvbiBmb3IgRS1UcmVlLg0KPg0KPkx1Y3kNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPkZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj5PZiBIZW5kZXJpY2t4LCBXaW0gKFdpbSkNCj5TZW50 OiBUaHVyc2RheSwgQXByaWwgMTIsIDIwMTIgMjowMyBBTQ0KPlRvOiAnZ2lsZXMuaGVyb25AZ21h aWwuY29tJzsgJ3NpbW9uLmRlbG9yZEBnbWFpbC5jb20nOw0KPidBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbScNCj5DYzogJ2wydnBuQGlldGYub3JnJzsgJ1ZsYWRpbWlyLktsZWluZXJA ZWNpdGVsZS5jb20nOw0KPidBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbSc7ICdJZGFuLkthc3Bp dEBlY2l0ZWxlLmNvbSc7DQo+J01pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tJzsgJ1JvdGVtLkNv aGVuQGVjaXRlbGUuY29tJw0KPlN1YmplY3Q6IFJlOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2Fj aGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+DQo+VGhlIHZsYW4gYXBwcm9hY2ggaXMgc3Vw ZXJpb3IgYXMgaXQgYWxzbyB3b3JrcyBmb3IgZXRoIG9ubHkgbmV0d29ya3MsDQo+ZXRjLiBPbiB0 b3Agc29tZSB2ZW5kb3JzIGluZGljYXRlIGh3IGlzc3VlcyB3aXRoIHRoZSBjdyBhcHByb2FjaC4g QXMNCj5zdWNoIHdlIGhhdmUgZHJvcHBlZCBtb3JlIG9yIGxlc3MgdGhlIGN3IGFwcHJvYWNoLg0K Pg0KPkNoZWVycywNCj5XaW0NCj5fX19fX19fX19fX19fX19fXw0KPnNlbnQgZnJvbSBibGFja2Jl cnJ5DQo+DQo+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPkZyb206IEdpbGVzIEhlcm9u IFttYWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tXQ0KPlNlbnQ6IFRodXJzZGF5LCBBcHJpbCAx MiwgMjAxMiAwODoyMiBBTQ0KPlRvOiBTaW1vbiBEZWxvcmQgPHNpbW9uLmRlbG9yZEBnbWFpbC5j b20+OyBBbGV4YW5kZXIgVmFpbnNodGVpbg0KPjxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbT4NCj5DYzogbDJ2cG5AaWV0Zi5vcmcgPGwydnBuQGlldGYub3JnPjsgVmxhZGltaXIgS2xl aW5lcg0KPjxWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPjsgQW5kcmV3IFNlcmdlZXYNCj48 QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb20+OyBJZGFuIEthc3BpdCA8SWRhbi5LYXNwaXRAZWNp dGVsZS5jb20+Ow0KPk1pc2hhZWwgV2V4bGVyIDxNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT47 IFJvdGVtIENvaGVuDQo+PFJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPg0KPlN1YmplY3Q6IFJlOiBU aGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+DQo+ U29ycnkgLSB0aGUgImFub255bW91cyBwcmVzZW50YXRpb24iIHdhcyBtaW5lLiAgSSBzaG91bGQg cG9zc2libHkgaGF2ZQ0KPnB1dCBpbiBhIHRoaXJkIGNvbHVtbiBvbiB0aGUgQ1cgYXBwcm9hY2gu ICBBbmQgaG9wZWZ1bGx5IHRoZSBtaW51dGVzDQo+d2lsbCBiZSBwb3N0ZWQgc29vbi4NCj4NCj5X ZSBoYWQgdmFyaW91cyBkaXNjdXNzaW9ucywgYXMgU2ltb24gc3RhdGVkLCBhbmQgY29uc2Vuc3Vz IHNlZW1lZCB0byBiZQ0KPmZvcm1pbmcgYXJvdW5kIHRoZSB0d28gYWx0ZXJuYXRpdmVzIG9mIHR3 byBQV0VzIG9yIHR3byBWTEFOcy4gIEkgYmVsaWV2ZQ0KPnRocmVlIG9mIHRoZSBhdXRob3JzIG9m IHRoZSBDVyBhcHByb2FjaCBhcmUgYWxzbyBhdXRob3JzIG9mIHRoZSB0d28gVkxBTg0KPmFwcHJv YWNoIGFuZCBvbmUgaXMgYWxzbyBhbiBhdXRob3Igb2YgdGhlIHR3byBQV0UgYXBwcm9hY2guIFNv IHBlcmhhcHMNCj5pdCdzIGJlc3QgdG8gbGV0IHRob3NlIGZvdXIgaW5kaXZpZHVhbHMgc2F5IHdo aWNoIGFwcHJvYWNoIHRoZXkgcHJlZmVyDQo+YW5kIHdoeT8NCj4NCj5HaWxlcw0KPg0KPk9uIDEw LzA0LzIwMTIgMDA6NDUsICJTaW1vbiBEZWxvcmQiIDxzaW1vbi5kZWxvcmRAZ21haWwuY29tPiB3 cm90ZToNCj4NCj4+IEhpIEFsZXhhbmRlciwNCj4+DQo+PiBZb3UgYXJlIHJpZ2h0LCBubyBkaXNj dXNzaW9uIG9uIHRoZSBXRyBtYWlsaW5nIGxpc3QgcmVjZW50bHksIGJ1dA0KPj4gdGhlcmUgaGF2 ZSBiZWVuIHN1YnN0YW50aWFsIGRpc2N1c3Npb25zIGFtb25nIHRoZSBhdXRob3JzIG9mIHZhcmlv dXMNCj4+IHNvbHV0aW9uIGRyYWZ0cyBvZmYgdGhlIG1haWxpbmcgbGlzdC4gQXMgZmFyIGFzIEkg a25vdywgbm8gY29uc2Vuc3VzDQo+PiB5ZXQgYmVmb3JlIGlldGY4Mywgbm90IHN1cmUgdGhlIHBy b2dyZXNzIGluIHRoZSBQYXJpcyBXRyBtZWV0aW5nLiBJDQo+PiB0aGluayB0aGUgQ1cgYXBwcm9h Y2ggaGFzIG5vdCBiZWVuIHJlamVjdGVkIGJ5IHRoZSBXRyB5ZXQsIG9yIHRoZSBXRw0KPj4gaGFz IG5vdCB5ZXQgZGVjaWRlZCBvbiB3aGljaCBvbmUgdG8gYWRvcHQuDQo+Pg0KPj4gU2ltb24NCj4+ DQo+PiAyMDEyLzQvOCBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb20+DQo+Pg0KPj4+ICBIaSBhbGwsDQo+Pj4NCj4+PiBVbmZvcnR1bmF0ZWx5IEkg aGF2ZSBub3QgYmVlbiBhYmxlIHRvIGF0dGVuZCB0aGUgUGFyaXMgSUVURi4NCj4+Pg0KPj4+IEhv d2V2ZXIsIGxvb2tpbmcgdXAgdGhlIEwyVlBOIHByb2NlZWRpbmdzLCBJJ3ZlIGZvdW5kIGEgc2hv cnQNCj4+PiBhbm9ueW1vdXMgcHJlc2VudGF0aW9uIGNhbGxlZCAiRS1UcmVlIFVwZGF0ZSIgICgN Cj4+PiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzgzL3NsaWRlcy9zbGlkZXMtODMt bDJ2cG4tMS5wcHR4KS4NCj4+PiBUaGlzIHByZXNlbnRhdGlvbiBkaXNjdXNzZXMgdGhlIGRpZmZl cmVuY2VzIG9mIHRoZSBFLVRyZWUgYXBwcm9hY2hlcw0KPj4+IGJhc2VkIG9uIGRlZGljYXRlZCBW TEFOcyAoYXMgaW4NCj4+PiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNh by1sMnZwbi12cGxzLWV0cmVlLz9pbmNsdWRlX3QNCj4+PiBleHQ9MSkgYW5kIG11bHRpcGxlIFBX cyBiZXR3ZWVuIHRoZSBQRXMgKGFzIGluDQo+Pj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1yYW0tbDJ2cG4tZXRyZWUtbXVsdGlwbGUtcHcvP2luDQo+Pj4gY2x1ZGVfdGUN Cj4+PiB4dD0xKQ0KPj4+IGFuZCBjb21wbGV0ZWx5IGlnbm9yZXMgdGhlIHNvbHV0aW9uIGJhc2Vk IG9uIHVzYWdlIG9mIHRoZSBDVyBpbiB0aGUNCj4+PiBQV3MgY29ubmVjdGluZyB0aGUgUEVzIChh cyBpbg0KPj4+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta2V5LWwydnBu LXZwbHMtZXRyZWUvP2luY2x1ZGVfdA0KPj4+IGV4dD0xDQo+Pj4gKS4NCj4+Pg0KPj4+DQo+Pj4N Cj4+PiBUaGUgTWludXRlcyBvZiB0aGUgUGFyaXMgTDJWUE4gc2Vzc2lvbiBhcmUgbm90IHlldCBh dmFpbGFibGUsIGJ1dCBJDQo+Pj4gd29uZGVyIHdoZXRoZXIgdGhlIFdHIGhhcyB0YWtlbiBhIGRl Y2lzaW9uIHRvIHJlamVjdCB0aGUgYXBwcm9hY2gNCj4+PiBiYXNlZCBvbiB0aGUgQ1cgdXNhZ2U/ IEkgZG8gbm90IHJlbWVtYmVyIGFueSByZWNlbnQgZGlzY3Vzc2lvbiBvZg0KPj4+IHRoaXMgdG9w aWMgb24gdGhlIFdHIG1haWxpbmcgbGlzdC4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBSZWdhcmRzLCBh bmQgbG90cyBvZiB0aGFua3MgaW4gYWR2YW5jZSwNCj4+Pg0KPj4+IFNhc2hhDQo+Pj4NCj4+Pg0K Pj4+DQo+Pj4NCj4+Pg0KPj4+IFRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRo ZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMNCj4+PiBpbmZvcm1hdGlvbiB3aGljaCBpcyBD T05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kNCj4NCj4+PiBU ZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwg cGxlYXNlDQo+Pj4gaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBk ZWxldGUgdGhlIG9yaWdpbmFsIGFuZA0KPj4+IGFsbCBjb3BpZXMgdGhlcmVvZi4NCj4+Pg0KPg0K Pg0KPg0KPg0KPg0KPlRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBj b250YWluIFRpbWUgV2FybmVyIENhYmxlDQo+cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNo IGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdA0KPnRvIGNvcHlyaWdodCBi ZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkDQo+ c29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBp dCBpcyBhZGRyZXNzZWQuDQo+SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBv ZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkNCj5ub3RpZmllZCB0aGF0IGFueSBkaXNzZW1p bmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbg0KPmluIHJlbGF0 aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMN Cj5zdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMNCj5FLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBp bW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkNCj5kZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkg Y29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0KPg0KDQoNClRoaXMgRS1tYWls IGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxl IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRp YWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJs ZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRp dmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5v dGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3Ig YWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVu dHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3 ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9y aWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K From josh.rogers@twcable.com Wed Apr 18 12:57:21 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C01B11E80A2 for ; Wed, 18 Apr 2012 12:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.529 X-Spam-Level: X-Spam-Status: No, score=-0.529 tagged_above=-999 required=5 tests=[AWL=0.933, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8CnNh16jtKO for ; Wed, 18 Apr 2012 12:57:17 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 0814E11E8095 for ; Wed, 18 Apr 2012 12:57:16 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,443,1330923600"; d="scan'208";a="369499520" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 18 Apr 2012 15:56:27 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Wed, 18 Apr 2012 15:57:11 -0400 From: "Rogers, Josh" To: Lucy yong , Daniel Cohn , Sam Cao Date: Wed, 18 Apr 2012 15:57:09 -0400 Subject: Re: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0dnXD9UVUxLczlQcuCg6PfIJz+Aw== Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 18 Apr 2012 19:57:21 -0000 Again, the P2MP situation throws me. Is this something that is used commonly? I'm under the impression that adding P2MP to any model results in a more complex model. Wether outside s-tag is used to differentiate, or dedicated pw's are used for the same purpose, it seems both become more complex. Gile's comparison slide still concisely captures the differences between these methods, in my opinion. I haven't seen any new ideas or thoughts brought to the group in the past week or two on the subject. I would hate for both proposed methods to die on the vine because we couldn't decide between two methods that have nothing inherently wrong with either. -Josh On 4/18/12 1:53 PM, "Lucy yong" wrote: >Send this again. > >Two PW approach can be complex too if the VPLS instance for E-Tree uses >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >unicast traffic, and some P2MP PWs for multicast traffic. It may double >all of them. > >Lucy > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, April 18, 2012 1:42 PM >To: Lucy yong; Rogers, Josh; Sam Cao >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >I think the first option its the natural way to go. How is the processing >in this case more complex? > >Thumb typed - please be tolerant > >Lucy yong wrote: > > > >Snipped.. > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >traffic coming from a root AC) >[[LY]] Not that simple. You construct either two P2MP PWs to all other >PEs and let egress PE performing filtering, or construct one P2MP PW to >leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >perform forwarding and filtering. Both make node process complex. > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >delivering the frames to remote PEs. We should utilize them with the >minimized changes. Dual VLAN solution is simpler than Dual PW. > >Regards, >Lucy > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >haven't had any first hand experience with P2MP PW's, however, so don't >feel terribly strong about this objection. Is this a real problem for >others (now or in the future), or is this objection in the weeds? > >I'm not sure the 'additional complexity' is notable, or even relevant. I >encourage others to speak up if they disagree, as P2MP PW is only >conceptual to me, and I am unfamiliar with real-life use cases for it. > >Thanks, >Josh > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > >>Please see inline. >> >>-----Original Message----- >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>Sent: Tuesday, April 17, 2012 7:14 AM >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Yes, 2 pws are only needed between pes with both root and leaf acs after >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>P2MP >>PWs if need. There is no difference between P2MP or normal PW setup. But, >>can Leaf-ACs be bound to Root PE of P2MP PW? >> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>both root and leaf AC and some only have leaf ACs)? >>Regards, >>Lucy >> >>Regards, >> >>Yuqun (Sam) Cao >>E-mail: Yuqun.cao@gmail.com >> >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Tuesday, April 17, 2012 4:56 PM >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; >>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Adding Sam (as l2vpn@ is holding messages) >> >>DC >> >>-----Original Message----- >>From: Lucy yong [mailto:lucy.yong@huawei.com] >>Sent: Tuesday, April 17, 2012 12:39 AM >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >>Snipped, >> >>As we discussed extensively in the list, and as reflected in giles >>slide, 2 pws are only needed between pes with both root and leaf acs, >>which will typically be a small minority. >>[[LY]] Don't know if the assumption is true. Even it is the case, both >>approaches can benefit from it. I was off for a while and captures some >>discussions now. >> >>Also as per giles slide, dual vlan can have scalability issues due to >>additional lookup and double use of vlans in internal emulated lan >>interface. Also there are potential backward compatibility issues with >>silicon that doesn't support vlan mapping. >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>not clear on all the issues. Could you be more specific? As I mentioned >>in below, two PW approach makes VPLS transport construction and packet >>forwarding more complex, I can see potential backward compatibility >>issues with 2 PW solution. >> >>Regards, >>Lucy >> >>Regards, >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>In my mind, the VLAN approach means dual vlan method. >> >>The main concern for CW approach is hardware support. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>traffic, and some P2MP PWs for multicast traffic. It may double all of >>them. >> >>E-tree is an Ethernet service and there is already VLAN based solution >>in IEEE, can we just utilize it without complicating VPLS transport >>construction? This also makes interworking with Eth only network easier. >> >>Cheers, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Monday, April 16, 2012 8:35 AM >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I believe the initial question was in regard to the CW method. Are you >>saying that you no longer are interested in that method in preference of >>the dual vlan method? >> >> >> >>Lucy yong wrote: >> >> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >> >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Henderickx, Wim (Wim) >>Sent: Thursday, April 12, 2012 2:03 AM >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>The vlan approach is superior as it also works for eth only networks, >>etc. On top some vendors indicate hw issues with the cw approach. As >>such we have dropped more or less the cw approach. >> >>Cheers, >>Wim >>_________________ >>sent from blackberry >> >>----- Original Message ----- >>From: Giles Heron [mailto:giles.heron@gmail.com] >>Sent: Thursday, April 12, 2012 08:22 AM >>To: Simon Delord ; Alexander Vainshtein >> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>; Andrew Sergeev >>; Idan Kaspit ; >>Mishael Wexler ; Rotem Cohen >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Sorry - the "anonymous presentation" was mine. I should possibly have >>put in a third column on the CW approach. And hopefully the minutes >>will be posted soon. >> >>We had various discussions, as Simon stated, and consensus seemed to be >>forming around the two alternatives of two PWEs or two VLANs. I believe >>three of the authors of the CW approach are also authors of the two VLAN >>approach and one is also an author of the two PWE approach. So perhaps >>it's best to let those four individuals say which approach they prefer >>and why? >> >>Giles >> >>On 10/04/2012 00:45, "Simon Delord" wrote: >> >>> Hi Alexander, >>> >>> You are right, no discussion on the WG mailing list recently, but >>> there have been substantial discussions among the authors of various >>> solution drafts off the mailing list. As far as I know, no consensus >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>> think the CW approach has not been rejected by the WG yet, or the WG >>> has not yet decided on which one to adopt. >>> >>> Simon >>> >>> 2012/4/8 Alexander Vainshtein >>> >>>> Hi all, >>>> >>>> Unfortunately I have not been able to attend the Paris IETF. >>>> >>>> However, looking up the L2VPN proceedings, I've found a short >>>> anonymous presentation called "E-Tree Update" ( >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>> This presentation discusses the differences of the E-Tree approaches >>>> based on dedicated VLANs (as in >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>> ext=3D1) and multiple PWs between the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>> clude_te >>>> xt=3D1) >>>> and completely ignores the solution based on usage of the CW in the >>>> PWs connecting the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>> ext=3D1 >>>> ). >>>> >>>> >>>> >>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>> wonder whether the WG has taken a decision to reject the approach >>>> based on the CW usage? I do not remember any recent discussion of >>>> this topic on the WG mailing list. >>>> >>>> >>>> >>>> Regards, and lots of thanks in advance, >>>> >>>> Sasha >>>> >>>> >>>> >>>> >>>> >>>> This e-mail message is intended for the recipient only and contains >>>> information which is CONFIDENTIAL and which may be proprietary to ECI >> >>>> Telecom. If you have received this transmission in error, please >>>> inform us by e-mail, phone or fax, and then delete the original and >>>> all copies thereof. >>>> >> >> >> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is addressed. >>If you are not the intended recipient of this E-mail, you are hereby >>notified that any dissemination, distribution, copying, or action taken >>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this >>E-mail in error, please notify the sender immediately and permanently >>delete the original and any copy of this E-mail and any printout. >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From Alexander.Vainshtein@ecitele.com Wed Apr 18 21:38:55 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724E721F845F for ; Wed, 18 Apr 2012 21:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.951 X-Spam-Level: X-Spam-Status: No, score=-2.951 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, 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 0TzWHJ87aztG for ; Wed, 18 Apr 2012 21:38:51 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4C58821F8463 for ; Wed, 18 Apr 2012 21:38:40 -0700 (PDT) Received: from [85.158.143.35:31215] by server-2.bemta-4.messagelabs.com id B4/83-17550-EC69F8F4; Thu, 19 Apr 2012 04:38:38 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1334810318!13913177!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.7; banners=-,-,- Received: (qmail 21452 invoked from network); 19 Apr 2012 04:38:38 -0000 Received: from unknown (HELO fridlpvsb005.ecitele.com) (168.87.1.157) by server-8.tower-21.messagelabs.com with SMTP; 19 Apr 2012 04:38:38 -0000 X-AuditID: a8571406-b7fe86d0000037a2-c5-4f8f96c81008 Received: from FRGRWPVCH001.ecitele.com (frgrwpvch001.ecitele.com [10.1.18.35]) by fridlpvsb005.ecitele.com (Symantec Messaging Gateway) with SMTP id D4.98.14242.8C69F8F4; Thu, 19 Apr 2012 06:38:32 +0200 (CEST) Received: from FRIDWPPMB002.ecitele.com ([169.254.4.167]) by FRGRWPVCH001.ecitele.com ([10.1.18.35]) with mapi id 14.01.0339.001; Thu, 19 Apr 2012 06:38:37 +0200 From: Alexander Vainshtein To: "Rogers, Josh" , Lucy yong , Daniel Cohn , Sam Cao Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdg== Date: Thu, 19 Apr 2012 04:38:36 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.1] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHJsWRmVeSWpSXmKPExsXCxcggpXtiWr+/wfy/2hYNlxYzWcxd/IfF 4vG3Q+wWG38tYrOY23yWzYHVY+esu+weLUfesnosWfKTyaN7w2Rmj9VrXrEEsEY1MNok5uXl lySWpCqkpBYn2yoFFGWWJSZXKilkptgqGSopFOQkJqfmpuaV2ColFhSk5qUo2XEpYAAboLLM PIXUvOT8lMy8dFslz2B/XQsLU0tdQyW7kIzMYoVU3dzEzByF3NTi4sT0VAWgCMgveSkJ65gz dm34w1ywrKxiXttZ5gbGM4ldjBwcEgImEsduGXYxcgKZYhIX7q1n62Lk4hASuMIosfHJdWYI ZymjxLl7/cwgVWwCthKbVt8FqxIRmMwocff2T3aQBLOAqkTLpn2MILawgKNE74suMFtEwEni 5a3FzBANkxgl5v0/BJZgAWqY3vUYrJlXwFdidsNbJpCThASyJb6e1AMJcwoYS/ydvhmsnBHo vO+n1jBB7BKXuPVkPhPE2QISS/acZ4awRSVePv7HCmHLS1z88ACqXkdiwe5PbBC2tsSyha+Z IdYKSpyc+YQFol5S4uCKGywTGMVnIVkxC0n7LCTts5C0L2BkWcUokVaUmZJTUFacZGBgqpea nFmSmpOql5yfu4kRmIpWhIuw7WBsmKB3iFGAg1GJh3fGlT5/IdbEsuLK3EOMkhxMSqK8f6f0 +wvxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4T1pA5TjTUmsrEotyodJWQDDcCKzFHdyPiiOS+KN DQxQOErivOuD7PyFBNKBCS87NbUgtQimVYaDQ0mCd/NUoKmCRanpqRVpmTklCGkmDk6QzTxA m6+D1PAWFyTmFmemQ+RPMapy/N928gqjEEtefl6qlDjvb5AiAZCijNI8uDmvGMWBfhXmvQmS 5QEmRLgJr4CGMwENV5ToAxkOzBhwKakGxjDBKQujtvyxkc5cbbI9v1W2RK8tb9PZpE6FBLMt rq63i5+ZzfI2L69aL/Vi4yUmyT7Vxs2lMmvtPJ/N9bc+o3wje3Lng4MOq1W+WiUs3HLY557k y+BVklOP9IgpBz+xKrJhLepabZYikqautOOtxrxELoZthsk9uyOqJd4YMTGe9Nu/uIpDiaU4 I9FQi7moOBEA1B9eqREEAAA= Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 19 Apr 2012 04:38:55 -0000 Hi all, I fully understand that that what I am going to say is not very popular, but= : IMO one of the advantages of the CW-based solution is that it is orthogonal= to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in= a more generic way, localization of effects of changes in the PE configurat= ion. In particular, adding a Leaf AC to a PE that previously has been only suppor= ting Root ACs (or vice versa), removal of the last Leaf or last Root AC from= a PE that previously has been supporting a mix etc. affect only the PE wher= e this operation happens and not the rest of the PEs. As for the need for HW changes that have been mentioned as a main disadvanta= ge of the CW-based approach - I believe it strongly depends on specific impl= ementations. And some changes in the forwarding process are required in any= solution. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, J= osh [josh.rogers@twcable.com] Sent: Wednesday, April 18, 2012 9:57 PM To: Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Again, the P2MP situation throws me. Is this something that is used commonly? I'm under the impression that adding P2MP to any model results in a more complex model. Wether outside s-tag is used to differentiate, or dedicated pw's are used for the same purpose, it seems both become more complex. Gile's comparison slide still concisely captures the differences between these methods, in my opinion. I haven't seen any new ideas or thoughts brought to the group in the past week or two on the subject. I would hate for both proposed methods to die on the vine because we couldn't decide between two methods that have nothing inherently wrong with either. -Josh On 4/18/12 1:53 PM, "Lucy yong" wrote: >Send this again. > >Two PW approach can be complex too if the VPLS instance for E-Tree uses >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >unicast traffic, and some P2MP PWs for multicast traffic. It may double >all of them. > >Lucy > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, April 18, 2012 1:42 PM >To: Lucy yong; Rogers, Josh; Sam Cao >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >I think the first option its the natural way to go. How is the processing >in this case more complex? > >Thumb typed - please be tolerant > >Lucy yong wrote: > > > >Snipped.. > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >traffic coming from a root AC) >[[LY]] Not that simple. You construct either two P2MP PWs to all other >PEs and let egress PE performing filtering, or construct one P2MP PW to >leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >perform forwarding and filtering. Both make node process complex. > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >delivering the frames to remote PEs. We should utilize them with the >minimized changes. Dual VLAN solution is simpler than Dual PW. > >Regards, >Lucy > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >haven't had any first hand experience with P2MP PW's, however, so don't >feel terribly strong about this objection. Is this a real problem for >others (now or in the future), or is this objection in the weeds? > >I'm not sure the 'additional complexity' is notable, or even relevant. I >encourage others to speak up if they disagree, as P2MP PW is only >conceptual to me, and I am unfamiliar with real-life use cases for it. > >Thanks, >Josh > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > >>Please see inline. >> >>-----Original Message----- >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>Sent: Tuesday, April 17, 2012 7:14 AM >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Yes, 2 pws are only needed between pes with both root and leaf acs after >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>P2MP >>PWs if need. There is no difference between P2MP or normal PW setup. But, >>can Leaf-ACs be bound to Root PE of P2MP PW? >> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>both root and leaf AC and some only have leaf ACs)? >>Regards, >>Lucy >> >>Regards, >> >>Yuqun (Sam) Cao >>E-mail: Yuqun.cao@gmail.com >> >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Tuesday, April 17, 2012 4:56 PM >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; >>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Adding Sam (as l2vpn@ is holding messages) >> >>DC >> >>-----Original Message----- >>From: Lucy yong [mailto:lucy.yong@huawei.com] >>Sent: Tuesday, April 17, 2012 12:39 AM >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >>Snipped, >> >>As we discussed extensively in the list, and as reflected in giles >>slide, 2 pws are only needed between pes with both root and leaf acs, >>which will typically be a small minority. >>[[LY]] Don't know if the assumption is true. Even it is the case, both >>approaches can benefit from it. I was off for a while and captures some >>discussions now. >> >>Also as per giles slide, dual vlan can have scalability issues due to >>additional lookup and double use of vlans in internal emulated lan >>interface. Also there are potential backward compatibility issues with >>silicon that doesn't support vlan mapping. >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>not clear on all the issues. Could you be more specific? As I mentioned >>in below, two PW approach makes VPLS transport construction and packet >>forwarding more complex, I can see potential backward compatibility >>issues with 2 PW solution. >> >>Regards, >>Lucy >> >>Regards, >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>In my mind, the VLAN approach means dual vlan method. >> >>The main concern for CW approach is hardware support. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>traffic, and some P2MP PWs for multicast traffic. It may double all of >>them. >> >>E-tree is an Ethernet service and there is already VLAN based solution >>in IEEE, can we just utilize it without complicating VPLS transport >>construction? This also makes interworking with Eth only network easier. >> >>Cheers, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Monday, April 16, 2012 8:35 AM >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I believe the initial question was in regard to the CW method. Are you >>saying that you no longer are interested in that method in preference of >>the dual vlan method? >> >> >> >>Lucy yong wrote: >> >> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >> >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Henderickx, Wim (Wim) >>Sent: Thursday, April 12, 2012 2:03 AM >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>The vlan approach is superior as it also works for eth only networks, >>etc. On top some vendors indicate hw issues with the cw approach. As >>such we have dropped more or less the cw approach. >> >>Cheers, >>Wim >>_________________ >>sent from blackberry >> >>----- Original Message ----- >>From: Giles Heron [mailto:giles.heron@gmail.com] >>Sent: Thursday, April 12, 2012 08:22 AM >>To: Simon Delord ; Alexander Vainshtein >> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>; Andrew Sergeev >>; Idan Kaspit ; >>Mishael Wexler ; Rotem Cohen >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Sorry - the "anonymous presentation" was mine. I should possibly have >>put in a third column on the CW approach. And hopefully the minutes >>will be posted soon. >> >>We had various discussions, as Simon stated, and consensus seemed to be >>forming around the two alternatives of two PWEs or two VLANs. I believe >>three of the authors of the CW approach are also authors of the two VLAN >>approach and one is also an author of the two PWE approach. So perhaps >>it's best to let those four individuals say which approach they prefer >>and why? >> >>Giles >> >>On 10/04/2012 00:45, "Simon Delord" wrote: >> >>> Hi Alexander, >>> >>> You are right, no discussion on the WG mailing list recently, but >>> there have been substantial discussions among the authors of various >>> solution drafts off the mailing list. As far as I know, no consensus >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>> think the CW approach has not been rejected by the WG yet, or the WG >>> has not yet decided on which one to adopt. >>> >>> Simon >>> >>> 2012/4/8 Alexander Vainshtein >>> >>>> Hi all, >>>> >>>> Unfortunately I have not been able to attend the Paris IETF. >>>> >>>> However, looking up the L2VPN proceedings, I've found a short >>>> anonymous presentation called "E-Tree Update" ( >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>> This presentation discusses the differences of the E-Tree approaches >>>> based on dedicated VLANs (as in >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>> ext=3D1) and multiple PWs between the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>> clude_te >>>> xt=3D1) >>>> and completely ignores the solution based on usage of the CW in the >>>> PWs connecting the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>> ext=3D1 >>>> ). >>>> >>>> >>>> >>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>> wonder whether the WG has taken a decision to reject the approach >>>> based on the CW usage? I do not remember any recent discussion of >>>> this topic on the WG mailing list. >>>> >>>> >>>> >>>> Regards, and lots of thanks in advance, >>>> >>>> Sasha >>>> >>>> >>>> >>>> >>>> >>>> This e-mail message is intended for the recipient only and contains >>>> information which is CONFIDENTIAL and which may be proprietary to ECI >> >>>> Telecom. If you have received this transmission in error, please >>>> inform us by e-mail, phone or fax, and then delete the original and >>>> all copies thereof. >>>> >> >> >> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is addressed. >>If you are not the intended recipient of this E-mail, you are hereby >>notified that any dissemination, distribution, copying, or action taken >>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this >>E-mail in error, please notify the sender immediately and permanently >>delete the original and any copy of this E-mail and any printout. >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable proprie= tary information, which is privileged, confidential, or subject to copyright= belonging to Time Warner Cable. This E-mail is intended solely for the use= of the individual or entity to which it is addressed. If you are not the in= tended recipient of this E-mail, you are hereby notified that any disseminat= ion, distribution, copying, or action taken in relation to the contents of a= nd attachments to this E-mail is strictly prohibited and may be unlawful. If= you have received this E-mail in error, please notify the sender immediatel= y and permanently delete the original and any copy of this E-mail and any pr= intout. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From wim.henderickx@alcatel-lucent.com Wed Apr 18 22:03:39 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF5021F84E4 for ; Wed, 18 Apr 2012 22:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HS_INDEX_PARAM=0.001, 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 theXlL5Ja5jX for ; Wed, 18 Apr 2012 22:03:34 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9D01E21F84E2 for ; Wed, 18 Apr 2012 22:03:34 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3J53HgA030349 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 19 Apr 2012 07:03:19 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 19 Apr 2012 07:03:18 +0200 From: "Henderickx, Wim (Wim)" To: "Rogers, Josh" , Lucy yong , Daniel Cohn , Sam Cao Date: Thu, 19 Apr 2012 07:03:18 +0200 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0dnXD9UVUxLczlQcuCg6PfIJz+AwAS5//w Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D670129623CA0@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 19 Apr 2012 05:03:39 -0000 -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of R= ogers, Josh Sent: woensdag 18 april 2012 21:57 To: Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Again, the P2MP situation throws me. Is this something that is used commonly? WH> we have a number of customers using it, which also want to deploy ETREE= with it. They use it mainly to Optimize BUM and multicast traffic. I'm under the impression that adding P2MP to any model results in a more complex model. Wether outside s-tag is used to differentiate, or dedicated pw's are used for the same purpose, it seems both become more complex. Gile's comparison slide still concisely captures the differences between these methods, in my opinion. I haven't seen any new ideas or thoughts brought to the group in the past week or two on the subject. I would hate for both proposed methods to die on the vine because we couldn't decide between two methods that have nothing inherently wrong with either. WH> I don't think we want to kill both but the idea is to come to 1 solutio= n. As I expressed before the VLAN approach is naturally supporting P2P or P= 2MP LSPs since it is independent of the PW construction since the ETREE dec= ision is taken outside the PW. -Josh On 4/18/12 1:53 PM, "Lucy yong" wrote: >Send this again. > >Two PW approach can be complex too if the VPLS instance for E-Tree uses >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >unicast traffic, and some P2MP PWs for multicast traffic. It may double >all of them. > >Lucy > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, April 18, 2012 1:42 PM >To: Lucy yong; Rogers, Josh; Sam Cao >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >I think the first option its the natural way to go. How is the processing >in this case more complex? > >Thumb typed - please be tolerant > >Lucy yong wrote: > > > >Snipped.. > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >traffic coming from a root AC) >[[LY]] Not that simple. You construct either two P2MP PWs to all other >PEs and let egress PE performing filtering, or construct one P2MP PW to >leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >perform forwarding and filtering. Both make node process complex. > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >delivering the frames to remote PEs. We should utilize them with the >minimized changes. Dual VLAN solution is simpler than Dual PW. > >Regards, >Lucy > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >haven't had any first hand experience with P2MP PW's, however, so don't >feel terribly strong about this objection. Is this a real problem for >others (now or in the future), or is this objection in the weeds? > >I'm not sure the 'additional complexity' is notable, or even relevant. I >encourage others to speak up if they disagree, as P2MP PW is only >conceptual to me, and I am unfamiliar with real-life use cases for it. > >Thanks, >Josh > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > >>Please see inline. >> >>-----Original Message----- >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>Sent: Tuesday, April 17, 2012 7:14 AM >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Yes, 2 pws are only needed between pes with both root and leaf acs after >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>P2MP >>PWs if need. There is no difference between P2MP or normal PW setup. But, >>can Leaf-ACs be bound to Root PE of P2MP PW? >> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>both root and leaf AC and some only have leaf ACs)? >>Regards, >>Lucy >> >>Regards, >> >>Yuqun (Sam) Cao >>E-mail: Yuqun.cao@gmail.com >> >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Tuesday, April 17, 2012 4:56 PM >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; >>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Adding Sam (as l2vpn@ is holding messages) >> >>DC >> >>-----Original Message----- >>From: Lucy yong [mailto:lucy.yong@huawei.com] >>Sent: Tuesday, April 17, 2012 12:39 AM >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >>Snipped, >> >>As we discussed extensively in the list, and as reflected in giles >>slide, 2 pws are only needed between pes with both root and leaf acs, >>which will typically be a small minority. >>[[LY]] Don't know if the assumption is true. Even it is the case, both >>approaches can benefit from it. I was off for a while and captures some >>discussions now. >> >>Also as per giles slide, dual vlan can have scalability issues due to >>additional lookup and double use of vlans in internal emulated lan >>interface. Also there are potential backward compatibility issues with >>silicon that doesn't support vlan mapping. >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>not clear on all the issues. Could you be more specific? As I mentioned >>in below, two PW approach makes VPLS transport construction and packet >>forwarding more complex, I can see potential backward compatibility >>issues with 2 PW solution. >> >>Regards, >>Lucy >> >>Regards, >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>In my mind, the VLAN approach means dual vlan method. >> >>The main concern for CW approach is hardware support. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>traffic, and some P2MP PWs for multicast traffic. It may double all of >>them. >> >>E-tree is an Ethernet service and there is already VLAN based solution >>in IEEE, can we just utilize it without complicating VPLS transport >>construction? This also makes interworking with Eth only network easier. >> >>Cheers, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Monday, April 16, 2012 8:35 AM >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I believe the initial question was in regard to the CW method. Are you >>saying that you no longer are interested in that method in preference of >>the dual vlan method? >> >> >> >>Lucy yong wrote: >> >> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >> >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Henderickx, Wim (Wim) >>Sent: Thursday, April 12, 2012 2:03 AM >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>The vlan approach is superior as it also works for eth only networks, >>etc. On top some vendors indicate hw issues with the cw approach. As >>such we have dropped more or less the cw approach. >> >>Cheers, >>Wim >>_________________ >>sent from blackberry >> >>----- Original Message ----- >>From: Giles Heron [mailto:giles.heron@gmail.com] >>Sent: Thursday, April 12, 2012 08:22 AM >>To: Simon Delord ; Alexander Vainshtein >> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>; Andrew Sergeev >>; Idan Kaspit ; >>Mishael Wexler ; Rotem Cohen >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Sorry - the "anonymous presentation" was mine. I should possibly have >>put in a third column on the CW approach. And hopefully the minutes >>will be posted soon. >> >>We had various discussions, as Simon stated, and consensus seemed to be >>forming around the two alternatives of two PWEs or two VLANs. I believe >>three of the authors of the CW approach are also authors of the two VLAN >>approach and one is also an author of the two PWE approach. So perhaps >>it's best to let those four individuals say which approach they prefer >>and why? >> >>Giles >> >>On 10/04/2012 00:45, "Simon Delord" wrote: >> >>> Hi Alexander, >>> >>> You are right, no discussion on the WG mailing list recently, but >>> there have been substantial discussions among the authors of various >>> solution drafts off the mailing list. As far as I know, no consensus >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>> think the CW approach has not been rejected by the WG yet, or the WG >>> has not yet decided on which one to adopt. >>> >>> Simon >>> >>> 2012/4/8 Alexander Vainshtein >>> >>>> Hi all, >>>> >>>> Unfortunately I have not been able to attend the Paris IETF. >>>> >>>> However, looking up the L2VPN proceedings, I've found a short >>>> anonymous presentation called "E-Tree Update" ( >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>> This presentation discusses the differences of the E-Tree approaches >>>> based on dedicated VLANs (as in >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>> ext=3D1) and multiple PWs between the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>> clude_te >>>> xt=3D1) >>>> and completely ignores the solution based on usage of the CW in the >>>> PWs connecting the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>> ext=3D1 >>>> ). >>>> >>>> >>>> >>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>> wonder whether the WG has taken a decision to reject the approach >>>> based on the CW usage? I do not remember any recent discussion of >>>> this topic on the WG mailing list. >>>> >>>> >>>> >>>> Regards, and lots of thanks in advance, >>>> >>>> Sasha >>>> >>>> >>>> >>>> >>>> >>>> This e-mail message is intended for the recipient only and contains >>>> information which is CONFIDENTIAL and which may be proprietary to ECI >> >>>> Telecom. If you have received this transmission in error, please >>>> inform us by e-mail, phone or fax, and then delete the original and >>>> all copies thereof. >>>> >> >> >> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is addressed. >>If you are not the intended recipient of this E-mail, you are hereby >>notified that any dissemination, distribution, copying, or action taken >>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this >>E-mail in error, please notify the sender immediately and permanently >>delete the original and any copy of this E-mail and any printout. >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wim.henderickx@alcatel-lucent.com Wed Apr 18 22:22:02 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C49B21F8532 for ; Wed, 18 Apr 2012 22:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HS_INDEX_PARAM=0.001, 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 On79BiZwM3gx for ; Wed, 18 Apr 2012 22:21:58 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id D305321F847A for ; Wed, 18 Apr 2012 22:21:57 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3J5LptI015209 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 19 Apr 2012 07:21:51 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 19 Apr 2012 07:21:51 +0200 From: "Henderickx, Wim (Wim)" To: Alexander Vainshtein , "Rogers, Josh" , Lucy yong , Daniel Cohn , Sam Cao Date: Thu, 19 Apr 2012 07:21:51 +0200 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1A Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 19 Apr 2012 05:22:02 -0000 Sasha, the VLAN approach allows for a similar operation as the CW does. It = is orthogonal to the underlying PW deployment of VPLS. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of A= lexander Vainshtein Sent: donderdag 19 april 2012 6:39 To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi all, I fully understand that that what I am going to say is not very popular, bu= t: IMO one of the advantages of the CW-based solution is that it is orthogonal= to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, i= n a more generic way, localization of effects of changes in the PE configur= ation. In particular, adding a Leaf AC to a PE that previously has been only suppo= rting Root ACs (or vice versa), removal of the last Leaf or last Root AC fr= om a PE that previously has been supporting a mix etc. affect only the PE w= here this operation happens and not the rest of the PEs. As for the need for HW changes that have been mentioned as a main disadvant= age of the CW-based approach - I believe it strongly depends on specific im= plementations. And some changes in the forwarding process are required in a= ny solution. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, = Josh [josh.rogers@twcable.com] Sent: Wednesday, April 18, 2012 9:57 PM To: Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Again, the P2MP situation throws me. Is this something that is used commonly? I'm under the impression that adding P2MP to any model results in a more complex model. Wether outside s-tag is used to differentiate, or dedicated pw's are used for the same purpose, it seems both become more complex. Gile's comparison slide still concisely captures the differences between these methods, in my opinion. I haven't seen any new ideas or thoughts brought to the group in the past week or two on the subject. I would hate for both proposed methods to die on the vine because we couldn't decide between two methods that have nothing inherently wrong with either. -Josh On 4/18/12 1:53 PM, "Lucy yong" wrote: >Send this again. > >Two PW approach can be complex too if the VPLS instance for E-Tree uses >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >unicast traffic, and some P2MP PWs for multicast traffic. It may double >all of them. > >Lucy > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, April 18, 2012 1:42 PM >To: Lucy yong; Rogers, Josh; Sam Cao >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >I think the first option its the natural way to go. How is the processing >in this case more complex? > >Thumb typed - please be tolerant > >Lucy yong wrote: > > > >Snipped.. > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >traffic coming from a root AC) >[[LY]] Not that simple. You construct either two P2MP PWs to all other >PEs and let egress PE performing filtering, or construct one P2MP PW to >leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >perform forwarding and filtering. Both make node process complex. > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >delivering the frames to remote PEs. We should utilize them with the >minimized changes. Dual VLAN solution is simpler than Dual PW. > >Regards, >Lucy > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >haven't had any first hand experience with P2MP PW's, however, so don't >feel terribly strong about this objection. Is this a real problem for >others (now or in the future), or is this objection in the weeds? > >I'm not sure the 'additional complexity' is notable, or even relevant. I >encourage others to speak up if they disagree, as P2MP PW is only >conceptual to me, and I am unfamiliar with real-life use cases for it. > >Thanks, >Josh > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > >>Please see inline. >> >>-----Original Message----- >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>Sent: Tuesday, April 17, 2012 7:14 AM >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Yes, 2 pws are only needed between pes with both root and leaf acs after >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>P2MP >>PWs if need. There is no difference between P2MP or normal PW setup. But, >>can Leaf-ACs be bound to Root PE of P2MP PW? >> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>both root and leaf AC and some only have leaf ACs)? >>Regards, >>Lucy >> >>Regards, >> >>Yuqun (Sam) Cao >>E-mail: Yuqun.cao@gmail.com >> >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Tuesday, April 17, 2012 4:56 PM >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; >>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Adding Sam (as l2vpn@ is holding messages) >> >>DC >> >>-----Original Message----- >>From: Lucy yong [mailto:lucy.yong@huawei.com] >>Sent: Tuesday, April 17, 2012 12:39 AM >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >>Snipped, >> >>As we discussed extensively in the list, and as reflected in giles >>slide, 2 pws are only needed between pes with both root and leaf acs, >>which will typically be a small minority. >>[[LY]] Don't know if the assumption is true. Even it is the case, both >>approaches can benefit from it. I was off for a while and captures some >>discussions now. >> >>Also as per giles slide, dual vlan can have scalability issues due to >>additional lookup and double use of vlans in internal emulated lan >>interface. Also there are potential backward compatibility issues with >>silicon that doesn't support vlan mapping. >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>not clear on all the issues. Could you be more specific? As I mentioned >>in below, two PW approach makes VPLS transport construction and packet >>forwarding more complex, I can see potential backward compatibility >>issues with 2 PW solution. >> >>Regards, >>Lucy >> >>Regards, >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>In my mind, the VLAN approach means dual vlan method. >> >>The main concern for CW approach is hardware support. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>traffic, and some P2MP PWs for multicast traffic. It may double all of >>them. >> >>E-tree is an Ethernet service and there is already VLAN based solution >>in IEEE, can we just utilize it without complicating VPLS transport >>construction? This also makes interworking with Eth only network easier. >> >>Cheers, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Monday, April 16, 2012 8:35 AM >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I believe the initial question was in regard to the CW method. Are you >>saying that you no longer are interested in that method in preference of >>the dual vlan method? >> >> >> >>Lucy yong wrote: >> >> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >> >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Henderickx, Wim (Wim) >>Sent: Thursday, April 12, 2012 2:03 AM >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>The vlan approach is superior as it also works for eth only networks, >>etc. On top some vendors indicate hw issues with the cw approach. As >>such we have dropped more or less the cw approach. >> >>Cheers, >>Wim >>_________________ >>sent from blackberry >> >>----- Original Message ----- >>From: Giles Heron [mailto:giles.heron@gmail.com] >>Sent: Thursday, April 12, 2012 08:22 AM >>To: Simon Delord ; Alexander Vainshtein >> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>; Andrew Sergeev >>; Idan Kaspit ; >>Mishael Wexler ; Rotem Cohen >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Sorry - the "anonymous presentation" was mine. I should possibly have >>put in a third column on the CW approach. And hopefully the minutes >>will be posted soon. >> >>We had various discussions, as Simon stated, and consensus seemed to be >>forming around the two alternatives of two PWEs or two VLANs. I believe >>three of the authors of the CW approach are also authors of the two VLAN >>approach and one is also an author of the two PWE approach. So perhaps >>it's best to let those four individuals say which approach they prefer >>and why? >> >>Giles >> >>On 10/04/2012 00:45, "Simon Delord" wrote: >> >>> Hi Alexander, >>> >>> You are right, no discussion on the WG mailing list recently, but >>> there have been substantial discussions among the authors of various >>> solution drafts off the mailing list. As far as I know, no consensus >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>> think the CW approach has not been rejected by the WG yet, or the WG >>> has not yet decided on which one to adopt. >>> >>> Simon >>> >>> 2012/4/8 Alexander Vainshtein >>> >>>> Hi all, >>>> >>>> Unfortunately I have not been able to attend the Paris IETF. >>>> >>>> However, looking up the L2VPN proceedings, I've found a short >>>> anonymous presentation called "E-Tree Update" ( >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>> This presentation discusses the differences of the E-Tree approaches >>>> based on dedicated VLANs (as in >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>> ext=3D1) and multiple PWs between the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>> clude_te >>>> xt=3D1) >>>> and completely ignores the solution based on usage of the CW in the >>>> PWs connecting the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>> ext=3D1 >>>> ). >>>> >>>> >>>> >>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>> wonder whether the WG has taken a decision to reject the approach >>>> based on the CW usage? I do not remember any recent discussion of >>>> this topic on the WG mailing list. >>>> >>>> >>>> >>>> Regards, and lots of thanks in advance, >>>> >>>> Sasha >>>> >>>> >>>> >>>> >>>> >>>> This e-mail message is intended for the recipient only and contains >>>> information which is CONFIDENTIAL and which may be proprietary to ECI >> >>>> Telecom. If you have received this transmission in error, please >>>> inform us by e-mail, phone or fax, and then delete the original and >>>> all copies thereof. >>>> >> >> >> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is addressed. >>If you are not the intended recipient of this E-mail, you are hereby >>notified that any dissemination, distribution, copying, or action taken >>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this >>E-mail in error, please notify the sender immediately and permanently >>delete the original and any copy of this E-mail and any printout. >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. From Alexander.Vainshtein@ecitele.com Wed Apr 18 22:31:17 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2601521F8533 for ; Wed, 18 Apr 2012 22:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, 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 JssMKN8SbrRX for ; Wed, 18 Apr 2012 22:31:13 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9BD21F8537 for ; Wed, 18 Apr 2012 22:31:12 -0700 (PDT) Received: from [85.158.143.35:49605] by server-2.bemta-4.messagelabs.com id AA/8D-17550-F13AF8F4; Thu, 19 Apr 2012 05:31:11 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1334813470!7739812!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.7; banners=-,-,- Received: (qmail 27344 invoked from network); 19 Apr 2012 05:31:11 -0000 Received: from unknown (HELO fridlppsb001.ecitele.com) (168.87.1.157) by server-4.tower-21.messagelabs.com with SMTP; 19 Apr 2012 05:31:11 -0000 X-AuditID: a8571401-b7f186d000005261-92-4f8fa3652fdc Received: from FRGRWPVCH001.ecitele.com (frgrwpvch001.ecitele.com [10.1.18.35]) by fridlppsb001.ecitele.com (Symantec Messaging Gateway) with SMTP id 76.28.21089.563AF8F4; Thu, 19 Apr 2012 07:32:22 +0200 (CEST) Received: from FRIDWPPMB002.ecitele.com ([169.254.4.167]) by FRGRWPVCH001.ecitele.com ([10.1.18.35]) with mapi id 14.01.0339.001; Thu, 19 Apr 2012 07:31:10 +0200 From: Alexander Vainshtein To: "Henderickx, Wim (Wim)" , "Rogers, Josh" , Lucy yong , Daniel Cohn , Sam Cao Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdios= Date: Thu, 19 Apr 2012 05:31:08 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, , <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.1] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTbUwTZxznubseB+ttZ0XvoTFbfRJnooO08SVHRsk296FLNMW3mLgPerZP 29P22vQKUj91gjOgwKaJiUUULTijiFISgu+xmMWSGN1ojJL4ElHUii/xw8T5gnc9RYz36fc8 v7fnufsfQ5rq882MJEdwWBb9iC6kCkGeucSTaHZaL/fxQuzfBCG0Jl5TwvB/qXyh+/8DtNAy PEYLrbWX6B9ox5aRMwbHifiNfEfdhccGR3v7S8Kx7fhO0nGkM0tV0qtjoFyU5WBEjGCLGysu O6oMS9WiK4osktuObMgS8osuHMByxI7EUAjLblRRaPnsKVdlkmzBsivolmSvHf2y3FkiCAvK SmyoYoVPUiy4JCBKfksAK4roxRZ1R7uV7F7bRfq2diXp0K5aUPPX9kUxUOtvAAwDufnwcHp5 AyhQ4XR45eYxugEUMiYuA2Cmp5fSFx0AnkvtAZqK5uwweeRGTlXEXQHw6d6jhEaQ3CxYlzyb E03lfoSNDxpyuIj7CT4cSpC6YS+A6W0vcgSlGvZ3nzNomOWWwM5MC6HX/U7A0bGuHFHArYU9 9aOkhoF6wBcDne/beDh0dx+hH5yD7acvkzqeBh8OvzXo+Bv4z7Pb7/XfwbZTz2kdz4UH9z8i 9eIpML37LqXri+H5Q9eoPwAfn1QRn2SPT7LHJ9nbAHUY8J6w5A6FlHVWq60Uu6QI9uNSVzCQ BOpAHVpVBPrAncbSFOAYgIzss6tNTpNBrFaigRQoZgg0jf2trdlp+nJd0B31iYpvTbjKj5UU gAyJith0ucqxbjG6CYeDHyhBfYl/kuYvXEHtI0fWzLNaP1kgnj22rMJp4rzq5G3AOITDH6wz GAZBdt8BNXVKGHtxjUfyRz7SBFOgNRvVZkbTsEpIDCiSV+cHwCxmvDedASZKDsrYzLPfayJO E/mq5ImcLODVu05lnRprVCdxIiGrhhNq+EzYpIWrf8YEZY4BeLZnkIMdi8czF/Pqmk56TvBL PX+jU6PJV4vW72ixX/wKzZj3OM/TXOMsG+nrP82PrBzcnunr3pG9U7ar94ktu9sxsODnV8Yt T9lfN1cS97eufrPw5WD57GjxtavGg3zi3rdD6y/VU9P7sxtb+6+Pt3R8vWS8utHJxdqqTt4a w0erEKX4RNscMqyI7wBgnGAVHAQAAA== Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 19 Apr 2012 05:31:17 -0000 Wim, Lots of thanks for a prompt response. I think that operational aspects of the VLAN approach (e.g., how is the Glob= al VID selected and distributed) should be examined in more detail. At the same time it seems that the double PW approach carries with it too ma= ny operational problems. E.g., no PWs are set up between Leaf-only PEs, but once one of these becomes= a Mix PE, all the Leaf-only PEs must now recognize it as a valid peer. And= if a Mix PE reverts to a Leaf only one, all its Leaf-only peers must drop i= t and shut down the relevant PWs... My 2c, Sasha ________________________________________ From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] Sent: Thursday, April 19, 2012 7:21 AM To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Sasha, the VLAN approach allows for a similar operation as the CW does. It i= s orthogonal to the underlying PW deployment of VPLS. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Al= exander Vainshtein Sent: donderdag 19 april 2012 6:39 To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi all, I fully understand that that what I am going to say is not very popular, but= : IMO one of the advantages of the CW-based solution is that it is orthogonal= to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in= a more generic way, localization of effects of changes in the PE configurat= ion. In particular, adding a Leaf AC to a PE that previously has been only suppor= ting Root ACs (or vice versa), removal of the last Leaf or last Root AC from= a PE that previously has been supporting a mix etc. affect only the PE wher= e this operation happens and not the rest of the PEs. As for the need for HW changes that have been mentioned as a main disadvanta= ge of the CW-based approach - I believe it strongly depends on specific impl= ementations. And some changes in the forwarding process are required in any= solution. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, J= osh [josh.rogers@twcable.com] Sent: Wednesday, April 18, 2012 9:57 PM To: Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Again, the P2MP situation throws me. Is this something that is used commonly? I'm under the impression that adding P2MP to any model results in a more complex model. Wether outside s-tag is used to differentiate, or dedicated pw's are used for the same purpose, it seems both become more complex. Gile's comparison slide still concisely captures the differences between these methods, in my opinion. I haven't seen any new ideas or thoughts brought to the group in the past week or two on the subject. I would hate for both proposed methods to die on the vine because we couldn't decide between two methods that have nothing inherently wrong with either. -Josh On 4/18/12 1:53 PM, "Lucy yong" wrote: >Send this again. > >Two PW approach can be complex too if the VPLS instance for E-Tree uses >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >unicast traffic, and some P2MP PWs for multicast traffic. It may double >all of them. > >Lucy > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, April 18, 2012 1:42 PM >To: Lucy yong; Rogers, Josh; Sam Cao >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >I think the first option its the natural way to go. How is the processing >in this case more complex? > >Thumb typed - please be tolerant > >Lucy yong wrote: > > > >Snipped.. > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >traffic coming from a root AC) >[[LY]] Not that simple. You construct either two P2MP PWs to all other >PEs and let egress PE performing filtering, or construct one P2MP PW to >leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >perform forwarding and filtering. Both make node process complex. > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >delivering the frames to remote PEs. We should utilize them with the >minimized changes. Dual VLAN solution is simpler than Dual PW. > >Regards, >Lucy > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >haven't had any first hand experience with P2MP PW's, however, so don't >feel terribly strong about this objection. Is this a real problem for >others (now or in the future), or is this objection in the weeds? > >I'm not sure the 'additional complexity' is notable, or even relevant. I >encourage others to speak up if they disagree, as P2MP PW is only >conceptual to me, and I am unfamiliar with real-life use cases for it. > >Thanks, >Josh > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > >>Please see inline. >> >>-----Original Message----- >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>Sent: Tuesday, April 17, 2012 7:14 AM >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Yes, 2 pws are only needed between pes with both root and leaf acs after >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>P2MP >>PWs if need. There is no difference between P2MP or normal PW setup. But, >>can Leaf-ACs be bound to Root PE of P2MP PW? >> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>both root and leaf AC and some only have leaf ACs)? >>Regards, >>Lucy >> >>Regards, >> >>Yuqun (Sam) Cao >>E-mail: Yuqun.cao@gmail.com >> >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Tuesday, April 17, 2012 4:56 PM >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; >>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Adding Sam (as l2vpn@ is holding messages) >> >>DC >> >>-----Original Message----- >>From: Lucy yong [mailto:lucy.yong@huawei.com] >>Sent: Tuesday, April 17, 2012 12:39 AM >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >>Snipped, >> >>As we discussed extensively in the list, and as reflected in giles >>slide, 2 pws are only needed between pes with both root and leaf acs, >>which will typically be a small minority. >>[[LY]] Don't know if the assumption is true. Even it is the case, both >>approaches can benefit from it. I was off for a while and captures some >>discussions now. >> >>Also as per giles slide, dual vlan can have scalability issues due to >>additional lookup and double use of vlans in internal emulated lan >>interface. Also there are potential backward compatibility issues with >>silicon that doesn't support vlan mapping. >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>not clear on all the issues. Could you be more specific? As I mentioned >>in below, two PW approach makes VPLS transport construction and packet >>forwarding more complex, I can see potential backward compatibility >>issues with 2 PW solution. >> >>Regards, >>Lucy >> >>Regards, >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>In my mind, the VLAN approach means dual vlan method. >> >>The main concern for CW approach is hardware support. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>traffic, and some P2MP PWs for multicast traffic. It may double all of >>them. >> >>E-tree is an Ethernet service and there is already VLAN based solution >>in IEEE, can we just utilize it without complicating VPLS transport >>construction? This also makes interworking with Eth only network easier. >> >>Cheers, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Monday, April 16, 2012 8:35 AM >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I believe the initial question was in regard to the CW method. Are you >>saying that you no longer are interested in that method in preference of >>the dual vlan method? >> >> >> >>Lucy yong wrote: >> >> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >> >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Henderickx, Wim (Wim) >>Sent: Thursday, April 12, 2012 2:03 AM >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>The vlan approach is superior as it also works for eth only networks, >>etc. On top some vendors indicate hw issues with the cw approach. As >>such we have dropped more or less the cw approach. >> >>Cheers, >>Wim >>_________________ >>sent from blackberry >> >>----- Original Message ----- >>From: Giles Heron [mailto:giles.heron@gmail.com] >>Sent: Thursday, April 12, 2012 08:22 AM >>To: Simon Delord ; Alexander Vainshtein >> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>; Andrew Sergeev >>; Idan Kaspit ; >>Mishael Wexler ; Rotem Cohen >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Sorry - the "anonymous presentation" was mine. I should possibly have >>put in a third column on the CW approach. And hopefully the minutes >>will be posted soon. >> >>We had various discussions, as Simon stated, and consensus seemed to be >>forming around the two alternatives of two PWEs or two VLANs. I believe >>three of the authors of the CW approach are also authors of the two VLAN >>approach and one is also an author of the two PWE approach. So perhaps >>it's best to let those four individuals say which approach they prefer >>and why? >> >>Giles >> >>On 10/04/2012 00:45, "Simon Delord" wrote: >> >>> Hi Alexander, >>> >>> You are right, no discussion on the WG mailing list recently, but >>> there have been substantial discussions among the authors of various >>> solution drafts off the mailing list. As far as I know, no consensus >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>> think the CW approach has not been rejected by the WG yet, or the WG >>> has not yet decided on which one to adopt. >>> >>> Simon >>> >>> 2012/4/8 Alexander Vainshtein >>> >>>> Hi all, >>>> >>>> Unfortunately I have not been able to attend the Paris IETF. >>>> >>>> However, looking up the L2VPN proceedings, I've found a short >>>> anonymous presentation called "E-Tree Update" ( >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>> This presentation discusses the differences of the E-Tree approaches >>>> based on dedicated VLANs (as in >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>> ext=3D1) and multiple PWs between the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>> clude_te >>>> xt=3D1) >>>> and completely ignores the solution based on usage of the CW in the >>>> PWs connecting the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>> ext=3D1 >>>> ). >>>> >>>> >>>> >>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>> wonder whether the WG has taken a decision to reject the approach >>>> based on the CW usage? I do not remember any recent discussion of >>>> this topic on the WG mailing list. >>>> >>>> >>>> >>>> Regards, and lots of thanks in advance, >>>> >>>> Sasha >>>> >>>> >>>> >>>> >>>> >>>> This e-mail message is intended for the recipient only and contains >>>> information which is CONFIDENTIAL and which may be proprietary to ECI >> >>>> Telecom. If you have received this transmission in error, please >>>> inform us by e-mail, phone or fax, and then delete the original and >>>> all copies thereof. >>>> >> >> >> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is addressed. >>If you are not the intended recipient of this E-mail, you are hereby >>notified that any dissemination, distribution, copying, or action taken >>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this >>E-mail in error, please notify the sender immediately and permanently >>delete the original and any copy of this E-mail and any printout. >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable proprie= tary information, which is privileged, confidential, or subject to copyright= belonging to Time Warner Cable. This E-mail is intended solely for the use= of the individual or entity to which it is addressed. If you are not the in= tended recipient of this E-mail, you are hereby notified that any disseminat= ion, distribution, copying, or action taken in relation to the contents of a= nd attachments to this E-mail is strictly prohibited and may be unlawful. If= you have received this E-mail in error, please notify the sender immediatel= y and permanently delete the original and any copy of this E-mail and any pr= intout. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From wim.henderickx@alcatel-lucent.com Wed Apr 18 22:33:55 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D529D21F84A7 for ; Wed, 18 Apr 2012 22:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.248 X-Spam-Level: X-Spam-Status: No, score=-8.248 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HS_INDEX_PARAM=0.001, 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 0QwYerJCmc1j for ; Wed, 18 Apr 2012 22:33:51 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD6A21F8537 for ; Wed, 18 Apr 2012 22:33:51 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3J5XhYl010114 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 19 Apr 2012 07:33:43 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 19 Apr 2012 07:33:43 +0200 From: "Henderickx, Wim (Wim)" To: Alexander Vainshtein , "Rogers, Josh" , Lucy yong , Daniel Cohn , Sam Cao Date: Thu, 19 Apr 2012 07:33:43 +0200 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdiov///3RsA== Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D670129623CAF@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, , <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 19 Apr 2012 05:33:56 -0000 Sasha, agreed. We will clarify the operational aspects of the VLAN approach= in more detail in the draft. -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: donderdag 19 april 2012 7:31 To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Wim, Lots of thanks for a prompt response. I think that operational aspects of the VLAN approach (e.g., how is the Glo= bal VID selected and distributed) should be examined in more detail. At the same time it seems that the double PW approach carries with it too m= any operational problems. E.g., no PWs are set up between Leaf-only PEs, but once one of these become= s a Mix PE, all the Leaf-only PEs must now recognize it as a valid peer. An= d if a Mix PE reverts to a Leaf only one, all its Leaf-only peers must drop= it and shut down the relevant PWs... My 2c, Sasha ________________________________________ From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] Sent: Thursday, April 19, 2012 7:21 AM To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Sasha, the VLAN approach allows for a similar operation as the CW does. It = is orthogonal to the underlying PW deployment of VPLS. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of A= lexander Vainshtein Sent: donderdag 19 april 2012 6:39 To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi all, I fully understand that that what I am going to say is not very popular, bu= t: IMO one of the advantages of the CW-based solution is that it is orthogonal= to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, i= n a more generic way, localization of effects of changes in the PE configur= ation. In particular, adding a Leaf AC to a PE that previously has been only suppo= rting Root ACs (or vice versa), removal of the last Leaf or last Root AC fr= om a PE that previously has been supporting a mix etc. affect only the PE w= here this operation happens and not the rest of the PEs. As for the need for HW changes that have been mentioned as a main disadvant= age of the CW-based approach - I believe it strongly depends on specific im= plementations. And some changes in the forwarding process are required in a= ny solution. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, = Josh [josh.rogers@twcable.com] Sent: Wednesday, April 18, 2012 9:57 PM To: Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Again, the P2MP situation throws me. Is this something that is used commonly? I'm under the impression that adding P2MP to any model results in a more complex model. Wether outside s-tag is used to differentiate, or dedicated pw's are used for the same purpose, it seems both become more complex. Gile's comparison slide still concisely captures the differences between these methods, in my opinion. I haven't seen any new ideas or thoughts brought to the group in the past week or two on the subject. I would hate for both proposed methods to die on the vine because we couldn't decide between two methods that have nothing inherently wrong with either. -Josh On 4/18/12 1:53 PM, "Lucy yong" wrote: >Send this again. > >Two PW approach can be complex too if the VPLS instance for E-Tree uses >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >unicast traffic, and some P2MP PWs for multicast traffic. It may double >all of them. > >Lucy > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, April 18, 2012 1:42 PM >To: Lucy yong; Rogers, Josh; Sam Cao >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >I think the first option its the natural way to go. How is the processing >in this case more complex? > >Thumb typed - please be tolerant > >Lucy yong wrote: > > > >Snipped.. > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >traffic coming from a root AC) >[[LY]] Not that simple. You construct either two P2MP PWs to all other >PEs and let egress PE performing filtering, or construct one P2MP PW to >leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >perform forwarding and filtering. Both make node process complex. > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >delivering the frames to remote PEs. We should utilize them with the >minimized changes. Dual VLAN solution is simpler than Dual PW. > >Regards, >Lucy > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >haven't had any first hand experience with P2MP PW's, however, so don't >feel terribly strong about this objection. Is this a real problem for >others (now or in the future), or is this objection in the weeds? > >I'm not sure the 'additional complexity' is notable, or even relevant. I >encourage others to speak up if they disagree, as P2MP PW is only >conceptual to me, and I am unfamiliar with real-life use cases for it. > >Thanks, >Josh > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > >>Please see inline. >> >>-----Original Message----- >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>Sent: Tuesday, April 17, 2012 7:14 AM >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Yes, 2 pws are only needed between pes with both root and leaf acs after >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>P2MP >>PWs if need. There is no difference between P2MP or normal PW setup. But, >>can Leaf-ACs be bound to Root PE of P2MP PW? >> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>both root and leaf AC and some only have leaf ACs)? >>Regards, >>Lucy >> >>Regards, >> >>Yuqun (Sam) Cao >>E-mail: Yuqun.cao@gmail.com >> >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Tuesday, April 17, 2012 4:56 PM >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; >>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Adding Sam (as l2vpn@ is holding messages) >> >>DC >> >>-----Original Message----- >>From: Lucy yong [mailto:lucy.yong@huawei.com] >>Sent: Tuesday, April 17, 2012 12:39 AM >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >>Snipped, >> >>As we discussed extensively in the list, and as reflected in giles >>slide, 2 pws are only needed between pes with both root and leaf acs, >>which will typically be a small minority. >>[[LY]] Don't know if the assumption is true. Even it is the case, both >>approaches can benefit from it. I was off for a while and captures some >>discussions now. >> >>Also as per giles slide, dual vlan can have scalability issues due to >>additional lookup and double use of vlans in internal emulated lan >>interface. Also there are potential backward compatibility issues with >>silicon that doesn't support vlan mapping. >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>not clear on all the issues. Could you be more specific? As I mentioned >>in below, two PW approach makes VPLS transport construction and packet >>forwarding more complex, I can see potential backward compatibility >>issues with 2 PW solution. >> >>Regards, >>Lucy >> >>Regards, >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>In my mind, the VLAN approach means dual vlan method. >> >>The main concern for CW approach is hardware support. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>traffic, and some P2MP PWs for multicast traffic. It may double all of >>them. >> >>E-tree is an Ethernet service and there is already VLAN based solution >>in IEEE, can we just utilize it without complicating VPLS transport >>construction? This also makes interworking with Eth only network easier. >> >>Cheers, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Monday, April 16, 2012 8:35 AM >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I believe the initial question was in regard to the CW method. Are you >>saying that you no longer are interested in that method in preference of >>the dual vlan method? >> >> >> >>Lucy yong wrote: >> >> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >> >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Henderickx, Wim (Wim) >>Sent: Thursday, April 12, 2012 2:03 AM >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>The vlan approach is superior as it also works for eth only networks, >>etc. On top some vendors indicate hw issues with the cw approach. As >>such we have dropped more or less the cw approach. >> >>Cheers, >>Wim >>_________________ >>sent from blackberry >> >>----- Original Message ----- >>From: Giles Heron [mailto:giles.heron@gmail.com] >>Sent: Thursday, April 12, 2012 08:22 AM >>To: Simon Delord ; Alexander Vainshtein >> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>; Andrew Sergeev >>; Idan Kaspit ; >>Mishael Wexler ; Rotem Cohen >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Sorry - the "anonymous presentation" was mine. I should possibly have >>put in a third column on the CW approach. And hopefully the minutes >>will be posted soon. >> >>We had various discussions, as Simon stated, and consensus seemed to be >>forming around the two alternatives of two PWEs or two VLANs. I believe >>three of the authors of the CW approach are also authors of the two VLAN >>approach and one is also an author of the two PWE approach. So perhaps >>it's best to let those four individuals say which approach they prefer >>and why? >> >>Giles >> >>On 10/04/2012 00:45, "Simon Delord" wrote: >> >>> Hi Alexander, >>> >>> You are right, no discussion on the WG mailing list recently, but >>> there have been substantial discussions among the authors of various >>> solution drafts off the mailing list. As far as I know, no consensus >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>> think the CW approach has not been rejected by the WG yet, or the WG >>> has not yet decided on which one to adopt. >>> >>> Simon >>> >>> 2012/4/8 Alexander Vainshtein >>> >>>> Hi all, >>>> >>>> Unfortunately I have not been able to attend the Paris IETF. >>>> >>>> However, looking up the L2VPN proceedings, I've found a short >>>> anonymous presentation called "E-Tree Update" ( >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>> This presentation discusses the differences of the E-Tree approaches >>>> based on dedicated VLANs (as in >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>> ext=3D1) and multiple PWs between the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>> clude_te >>>> xt=3D1) >>>> and completely ignores the solution based on usage of the CW in the >>>> PWs connecting the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>> ext=3D1 >>>> ). >>>> >>>> >>>> >>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>> wonder whether the WG has taken a decision to reject the approach >>>> based on the CW usage? I do not remember any recent discussion of >>>> this topic on the WG mailing list. >>>> >>>> >>>> >>>> Regards, and lots of thanks in advance, >>>> >>>> Sasha >>>> >>>> >>>> >>>> >>>> >>>> This e-mail message is intended for the recipient only and contains >>>> information which is CONFIDENTIAL and which may be proprietary to ECI >> >>>> Telecom. If you have received this transmission in error, please >>>> inform us by e-mail, phone or fax, and then delete the original and >>>> all copies thereof. >>>> >> >> >> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is addressed. >>If you are not the intended recipient of this E-mail, you are hereby >>notified that any dissemination, distribution, copying, or action taken >>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this >>E-mail in error, please notify the sender immediately and permanently >>delete the original and any copy of this E-mail and any printout. >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. From DanielC@orckit.com Wed Apr 18 23:16:35 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B4E21F851D for ; Wed, 18 Apr 2012 23:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=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 vLNLof8ZHcel for ; Wed, 18 Apr 2012 23:16:31 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8F711E8076 for ; Wed, 18 Apr 2012 23:16:29 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Date: Thu, 19 Apr 2012 09:16:29 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130777C1D5@tlvmail1> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdiov///PycA== References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, , <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> From: "Daniel Cohn" To: "Alexander Vainshtein" , "Henderickx, Wim (Wim)" , "Rogers, Josh" , "Lucy yong" , "Sam Cao" Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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, 19 Apr 2012 06:16:35 -0000 Hi Sasha and all, You have exactly the same "problem" in the 2-VLAN approach - quoting from the draft: 6. LDP Extensions for E-Tree Support P is a Leaf-only bit, it is set to 1 to indicate that the PE is attached with only leaves, and set to 0 otherwise. If the P bit is set, then: { If the PE is a leaf-only node itself, then a label release message with the error code "Leaf to Leaf PW error" is sent to the peer PE and exit the process; So all that you wrote about a leaf-only PE becoming mixed and viceversa applies to both solutions. Regards, Daniel -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Thursday, April 19, 2012 8:31 AM To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Wim, Lots of thanks for a prompt response. I think that operational aspects of the VLAN approach (e.g., how is the Global VID selected and distributed) should be examined in more detail. At the same time it seems that the double PW approach carries with it too many operational problems. E.g., no PWs are set up between Leaf-only PEs, but once one of these becomes a Mix PE, all the Leaf-only PEs must now recognize it as a valid peer. And if a Mix PE reverts to a Leaf only one, all its Leaf-only peers must drop it and shut down the relevant PWs... My 2c, Sasha ________________________________________ From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] Sent: Thursday, April 19, 2012 7:21 AM To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Sasha, the VLAN approach allows for a similar operation as the CW does. It is orthogonal to the underlying PW deployment of VPLS. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: donderdag 19 april 2012 6:39 To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi all, I fully understand that that what I am going to say is not very popular, but: IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes in the PE configuration. In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root AC from a PE that previously has been supporting a mix etc. affect only the PE where this operation happens and not the rest of the PEs. As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] Sent: Wednesday, April 18, 2012 9:57 PM To: Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Again, the P2MP situation throws me. Is this something that is used commonly? I'm under the impression that adding P2MP to any model results in a more complex model. Wether outside s-tag is used to differentiate, or dedicated pw's are used for the same purpose, it seems both become more complex. Gile's comparison slide still concisely captures the differences between these methods, in my opinion. I haven't seen any new ideas or thoughts brought to the group in the past week or two on the subject. I would hate for both proposed methods to die on the vine because we couldn't decide between two methods that have nothing inherently wrong with either. -Josh On 4/18/12 1:53 PM, "Lucy yong" wrote: >Send this again. > >Two PW approach can be complex too if the VPLS instance for E-Tree uses >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >unicast traffic, and some P2MP PWs for multicast traffic. It may double >all of them. > >Lucy > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, April 18, 2012 1:42 PM >To: Lucy yong; Rogers, Josh; Sam Cao >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >I think the first option its the natural way to go. How is the processing >in this case more complex? > >Thumb typed - please be tolerant > >Lucy yong wrote: > > > >Snipped.. > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >traffic coming from a root AC) >[[LY]] Not that simple. You construct either two P2MP PWs to all other >PEs and let egress PE performing filtering, or construct one P2MP PW to >leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >perform forwarding and filtering. Both make node process complex. > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >delivering the frames to remote PEs. We should utilize them with the >minimized changes. Dual VLAN solution is simpler than Dual PW. > >Regards, >Lucy > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >haven't had any first hand experience with P2MP PW's, however, so don't >feel terribly strong about this objection. Is this a real problem for >others (now or in the future), or is this objection in the weeds? > >I'm not sure the 'additional complexity' is notable, or even relevant. I >encourage others to speak up if they disagree, as P2MP PW is only >conceptual to me, and I am unfamiliar with real-life use cases for it. > >Thanks, >Josh > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > >>Please see inline. >> >>-----Original Message----- >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>Sent: Tuesday, April 17, 2012 7:14 AM >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Yes, 2 pws are only needed between pes with both root and leaf acs after >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>P2MP >>PWs if need. There is no difference between P2MP or normal PW setup. But, >>can Leaf-ACs be bound to Root PE of P2MP PW? >> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>both root and leaf AC and some only have leaf ACs)? >>Regards, >>Lucy >> >>Regards, >> >>Yuqun (Sam) Cao >>E-mail: Yuqun.cao@gmail.com >> >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Tuesday, April 17, 2012 4:56 PM >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; >>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Adding Sam (as l2vpn@ is holding messages) >> >>DC >> >>-----Original Message----- >>From: Lucy yong [mailto:lucy.yong@huawei.com] >>Sent: Tuesday, April 17, 2012 12:39 AM >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >>Snipped, >> >>As we discussed extensively in the list, and as reflected in giles >>slide, 2 pws are only needed between pes with both root and leaf acs, >>which will typically be a small minority. >>[[LY]] Don't know if the assumption is true. Even it is the case, both >>approaches can benefit from it. I was off for a while and captures some >>discussions now. >> >>Also as per giles slide, dual vlan can have scalability issues due to >>additional lookup and double use of vlans in internal emulated lan >>interface. Also there are potential backward compatibility issues with >>silicon that doesn't support vlan mapping. >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>not clear on all the issues. Could you be more specific? As I mentioned >>in below, two PW approach makes VPLS transport construction and packet >>forwarding more complex, I can see potential backward compatibility >>issues with 2 PW solution. >> >>Regards, >>Lucy >> >>Regards, >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>In my mind, the VLAN approach means dual vlan method. >> >>The main concern for CW approach is hardware support. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>traffic, and some P2MP PWs for multicast traffic. It may double all of >>them. >> >>E-tree is an Ethernet service and there is already VLAN based solution >>in IEEE, can we just utilize it without complicating VPLS transport >>construction? This also makes interworking with Eth only network easier. >> >>Cheers, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Monday, April 16, 2012 8:35 AM >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I believe the initial question was in regard to the CW method. Are you >>saying that you no longer are interested in that method in preference of >>the dual vlan method? >> >> >> >>Lucy yong wrote: >> >> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >> >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Henderickx, Wim (Wim) >>Sent: Thursday, April 12, 2012 2:03 AM >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>The vlan approach is superior as it also works for eth only networks, >>etc. On top some vendors indicate hw issues with the cw approach. As >>such we have dropped more or less the cw approach. >> >>Cheers, >>Wim >>_________________ >>sent from blackberry >> >>----- Original Message ----- >>From: Giles Heron [mailto:giles.heron@gmail.com] >>Sent: Thursday, April 12, 2012 08:22 AM >>To: Simon Delord ; Alexander Vainshtein >> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>; Andrew Sergeev >>; Idan Kaspit ; >>Mishael Wexler ; Rotem Cohen >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Sorry - the "anonymous presentation" was mine. I should possibly have >>put in a third column on the CW approach. And hopefully the minutes >>will be posted soon. >> >>We had various discussions, as Simon stated, and consensus seemed to be >>forming around the two alternatives of two PWEs or two VLANs. I believe >>three of the authors of the CW approach are also authors of the two VLAN >>approach and one is also an author of the two PWE approach. So perhaps >>it's best to let those four individuals say which approach they prefer >>and why? >> >>Giles >> >>On 10/04/2012 00:45, "Simon Delord" wrote: >> >>> Hi Alexander, >>> >>> You are right, no discussion on the WG mailing list recently, but >>> there have been substantial discussions among the authors of various >>> solution drafts off the mailing list. As far as I know, no consensus >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>> think the CW approach has not been rejected by the WG yet, or the WG >>> has not yet decided on which one to adopt. >>> >>> Simon >>> >>> 2012/4/8 Alexander Vainshtein >>> >>>> Hi all, >>>> >>>> Unfortunately I have not been able to attend the Paris IETF. >>>> >>>> However, looking up the L2VPN proceedings, I've found a short >>>> anonymous presentation called "E-Tree Update" ( >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>> This presentation discusses the differences of the E-Tree approaches >>>> based on dedicated VLANs (as in >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>> ext=3D1) and multiple PWs between the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>> clude_te >>>> xt=3D1) >>>> and completely ignores the solution based on usage of the CW in the >>>> PWs connecting the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>> ext=3D1 >>>> ). >>>> >>>> >>>> >>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>> wonder whether the WG has taken a decision to reject the approach >>>> based on the CW usage? I do not remember any recent discussion of >>>> this topic on the WG mailing list. >>>> >>>> >>>> >>>> Regards, and lots of thanks in advance, >>>> >>>> Sasha >>>> >>>> >>>> >>>> >>>> >>>> This e-mail message is intended for the recipient only and contains >>>> information which is CONFIDENTIAL and which may be proprietary to ECI >> >>>> Telecom. If you have received this transmission in error, please >>>> inform us by e-mail, phone or fax, and then delete the original and >>>> all copies thereof. >>>> >> >> >> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is addressed. >>If you are not the intended recipient of this E-mail, you are hereby >>notified that any dissemination, distribution, copying, or action taken >>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this >>E-mail in error, please notify the sender immediately and permanently >>delete the original and any copy of this E-mail and any printout. >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. From wim.henderickx@alcatel-lucent.com Wed Apr 18 23:34:16 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8885D21F852D for ; Wed, 18 Apr 2012 23:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_FR=0.35, HS_INDEX_PARAM=0.001, 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 f3LM75HjhQSx for ; Wed, 18 Apr 2012 23:34:12 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 157C421F852E for ; Wed, 18 Apr 2012 23:34:11 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3J6Y5XV029535 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 19 Apr 2012 08:34:06 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 19 Apr 2012 08:34:06 +0200 From: "Henderickx, Wim (Wim)" To: Daniel Cohn , Alexander Vainshtein , "Rogers, Josh" , Lucy yong , Sam Cao Date: Thu, 19 Apr 2012 08:34:03 +0200 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdiov///PycP//4qvA Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D670129623CD2@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, , <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130777C1D5@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130777C1D5@tlvmail1> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 19 Apr 2012 06:34:16 -0000 Daniel, we should discuss this as this is not absolutely required to tear d= own PW. You can also have an indication in the E-TREE fwd to indicate that = the endpoint has no leaf and as such avoid sending traffic down but allow t= he PW to be setup. As such we have some flexibility such that operators can= select the proper approach they would like to have/implement. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: donderdag 19 april 2012 8:16 To: Alexander Vainshtein; Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; S= am Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Sasha and all, You have exactly the same "problem" in the 2-VLAN approach - quoting from the draft: 6. LDP Extensions for E-Tree Support P is a Leaf-only bit, it is set to 1 to indicate that the PE is attached with only leaves, and set to 0 otherwise. If the P bit is set, then: { If the PE is a leaf-only node itself, then a label release message with the error code "Leaf to Leaf PW error" is sent to the peer PE and exit the process; So all that you wrote about a leaf-only PE becoming mixed and viceversa applies to both solutions. Regards, Daniel -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Thursday, April 19, 2012 8:31 AM To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Wim, Lots of thanks for a prompt response. I think that operational aspects of the VLAN approach (e.g., how is the Global VID selected and distributed) should be examined in more detail. At the same time it seems that the double PW approach carries with it too many operational problems. E.g., no PWs are set up between Leaf-only PEs, but once one of these becomes a Mix PE, all the Leaf-only PEs must now recognize it as a valid peer. And if a Mix PE reverts to a Leaf only one, all its Leaf-only peers must drop it and shut down the relevant PWs... My 2c, Sasha ________________________________________ From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] Sent: Thursday, April 19, 2012 7:21 AM To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Sasha, the VLAN approach allows for a similar operation as the CW does. It is orthogonal to the underlying PW deployment of VPLS. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: donderdag 19 april 2012 6:39 To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi all, I fully understand that that what I am going to say is not very popular, but: IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes in the PE configuration. In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root AC from a PE that previously has been supporting a mix etc. affect only the PE where this operation happens and not the rest of the PEs. As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] Sent: Wednesday, April 18, 2012 9:57 PM To: Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Again, the P2MP situation throws me. Is this something that is used commonly? I'm under the impression that adding P2MP to any model results in a more complex model. Wether outside s-tag is used to differentiate, or dedicated pw's are used for the same purpose, it seems both become more complex. Gile's comparison slide still concisely captures the differences between these methods, in my opinion. I haven't seen any new ideas or thoughts brought to the group in the past week or two on the subject. I would hate for both proposed methods to die on the vine because we couldn't decide between two methods that have nothing inherently wrong with either. -Josh On 4/18/12 1:53 PM, "Lucy yong" wrote: >Send this again. > >Two PW approach can be complex too if the VPLS instance for E-Tree uses >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >unicast traffic, and some P2MP PWs for multicast traffic. It may double >all of them. > >Lucy > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, April 18, 2012 1:42 PM >To: Lucy yong; Rogers, Josh; Sam Cao >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >I think the first option its the natural way to go. How is the processing >in this case more complex? > >Thumb typed - please be tolerant > >Lucy yong wrote: > > > >Snipped.. > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >traffic coming from a root AC) >[[LY]] Not that simple. You construct either two P2MP PWs to all other >PEs and let egress PE performing filtering, or construct one P2MP PW to >leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >perform forwarding and filtering. Both make node process complex. > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >delivering the frames to remote PEs. We should utilize them with the >minimized changes. Dual VLAN solution is simpler than Dual PW. > >Regards, >Lucy > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >haven't had any first hand experience with P2MP PW's, however, so don't >feel terribly strong about this objection. Is this a real problem for >others (now or in the future), or is this objection in the weeds? > >I'm not sure the 'additional complexity' is notable, or even relevant. I >encourage others to speak up if they disagree, as P2MP PW is only >conceptual to me, and I am unfamiliar with real-life use cases for it. > >Thanks, >Josh > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > >>Please see inline. >> >>-----Original Message----- >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>Sent: Tuesday, April 17, 2012 7:14 AM >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Yes, 2 pws are only needed between pes with both root and leaf acs after >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>P2MP >>PWs if need. There is no difference between P2MP or normal PW setup. But, >>can Leaf-ACs be bound to Root PE of P2MP PW? >> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>both root and leaf AC and some only have leaf ACs)? >>Regards, >>Lucy >> >>Regards, >> >>Yuqun (Sam) Cao >>E-mail: Yuqun.cao@gmail.com >> >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Tuesday, April 17, 2012 4:56 PM >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; >>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Adding Sam (as l2vpn@ is holding messages) >> >>DC >> >>-----Original Message----- >>From: Lucy yong [mailto:lucy.yong@huawei.com] >>Sent: Tuesday, April 17, 2012 12:39 AM >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >>Snipped, >> >>As we discussed extensively in the list, and as reflected in giles >>slide, 2 pws are only needed between pes with both root and leaf acs, >>which will typically be a small minority. >>[[LY]] Don't know if the assumption is true. Even it is the case, both >>approaches can benefit from it. I was off for a while and captures some >>discussions now. >> >>Also as per giles slide, dual vlan can have scalability issues due to >>additional lookup and double use of vlans in internal emulated lan >>interface. Also there are potential backward compatibility issues with >>silicon that doesn't support vlan mapping. >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>not clear on all the issues. Could you be more specific? As I mentioned >>in below, two PW approach makes VPLS transport construction and packet >>forwarding more complex, I can see potential backward compatibility >>issues with 2 PW solution. >> >>Regards, >>Lucy >> >>Regards, >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>In my mind, the VLAN approach means dual vlan method. >> >>The main concern for CW approach is hardware support. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>traffic, and some P2MP PWs for multicast traffic. It may double all of >>them. >> >>E-tree is an Ethernet service and there is already VLAN based solution >>in IEEE, can we just utilize it without complicating VPLS transport >>construction? This also makes interworking with Eth only network easier. >> >>Cheers, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Monday, April 16, 2012 8:35 AM >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I believe the initial question was in regard to the CW method. Are you >>saying that you no longer are interested in that method in preference of >>the dual vlan method? >> >> >> >>Lucy yong wrote: >> >> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >> >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Henderickx, Wim (Wim) >>Sent: Thursday, April 12, 2012 2:03 AM >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>The vlan approach is superior as it also works for eth only networks, >>etc. On top some vendors indicate hw issues with the cw approach. As >>such we have dropped more or less the cw approach. >> >>Cheers, >>Wim >>_________________ >>sent from blackberry >> >>----- Original Message ----- >>From: Giles Heron [mailto:giles.heron@gmail.com] >>Sent: Thursday, April 12, 2012 08:22 AM >>To: Simon Delord ; Alexander Vainshtein >> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>; Andrew Sergeev >>; Idan Kaspit ; >>Mishael Wexler ; Rotem Cohen >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Sorry - the "anonymous presentation" was mine. I should possibly have >>put in a third column on the CW approach. And hopefully the minutes >>will be posted soon. >> >>We had various discussions, as Simon stated, and consensus seemed to be >>forming around the two alternatives of two PWEs or two VLANs. I believe >>three of the authors of the CW approach are also authors of the two VLAN >>approach and one is also an author of the two PWE approach. So perhaps >>it's best to let those four individuals say which approach they prefer >>and why? >> >>Giles >> >>On 10/04/2012 00:45, "Simon Delord" wrote: >> >>> Hi Alexander, >>> >>> You are right, no discussion on the WG mailing list recently, but >>> there have been substantial discussions among the authors of various >>> solution drafts off the mailing list. As far as I know, no consensus >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>> think the CW approach has not been rejected by the WG yet, or the WG >>> has not yet decided on which one to adopt. >>> >>> Simon >>> >>> 2012/4/8 Alexander Vainshtein >>> >>>> Hi all, >>>> >>>> Unfortunately I have not been able to attend the Paris IETF. >>>> >>>> However, looking up the L2VPN proceedings, I've found a short >>>> anonymous presentation called "E-Tree Update" ( >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>> This presentation discusses the differences of the E-Tree approaches >>>> based on dedicated VLANs (as in >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>> ext=3D1) and multiple PWs between the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>> clude_te >>>> xt=3D1) >>>> and completely ignores the solution based on usage of the CW in the >>>> PWs connecting the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>> ext=3D1 >>>> ). >>>> >>>> >>>> >>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>> wonder whether the WG has taken a decision to reject the approach >>>> based on the CW usage? I do not remember any recent discussion of >>>> this topic on the WG mailing list. >>>> >>>> >>>> >>>> Regards, and lots of thanks in advance, >>>> >>>> Sasha >>>> >>>> >>>> >>>> >>>> >>>> This e-mail message is intended for the recipient only and contains >>>> information which is CONFIDENTIAL and which may be proprietary to ECI >> >>>> Telecom. If you have received this transmission in error, please >>>> inform us by e-mail, phone or fax, and then delete the original and >>>> all copies thereof. >>>> >> >> >> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is addressed. >>If you are not the intended recipient of this E-mail, you are hereby >>notified that any dissemination, distribution, copying, or action taken >>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this >>E-mail in error, please notify the sender immediately and permanently >>delete the original and any copy of this E-mail and any printout. >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. From chen.ran@zte.com.cn Thu Apr 19 00:21:23 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C4911E809A; Thu, 19 Apr 2012 00:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.789 X-Spam-Level: X-Spam-Status: No, score=-92.789 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 Gxux+ayxhUEs; Thu, 19 Apr 2012 00:21:19 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id CE8D011E8076; Thu, 19 Apr 2012 00:21:17 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 286202397131170; Thu, 19 Apr 2012 14:42:04 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 96035.6351547758; Thu, 19 Apr 2012 15:21:09 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q3J7L05P077578; Thu, 19 Apr 2012 15:21:00 +0800 (GMT-8) (envelope-from chen.ran@zte.com.cn) In-Reply-To: To: Alexander Vainshtein Subject: =?GB2312?B?tPC4tDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhl?= =?GB2312?B?IEUtVHJlZSBzb2x1dGlvbj8=?= MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Ran Chen Date: Thu, 19 Apr 2012 15:20:50 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-19 15:21:02, Serialize complete at 2012-04-19 15:21:02 Content-Type: multipart/alternative; boundary="=_alternative 00285D25482579E5_=" X-MAIL: mse02.zte.com.cn q3J7L05P077578 Cc: "l2vpn@ietf.org" , l2vpn-bounces@ietf.org, Sam Cao X-BeenThere: l2vpn@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, 19 Apr 2012 07:21:23 -0000 This is a multipart message in MIME format. --=_alternative 00285D25482579E5_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgU2FzaGEsDQpQbGVzZSBzZWUgaW5saW5lLCB0aGFua3MNCg0KDQoNCkFsZXhhbmRlciBWYWlu c2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4gDQq3orz+yMs6ICBsMnZw bi1ib3VuY2VzQGlldGYub3JnDQoyMDEyLzA0LzE5IDEzOjMxDQoNCsrVvP7Iyw0KIkhlbmRlcmlj a3gsIFdpbSAoV2ltKSIgPHdpbS5oZW5kZXJpY2t4QGFsY2F0ZWwtbHVjZW50LmNvbT4sICJSb2dl cnMsIA0KSm9zaCIgPGpvc2gucm9nZXJzQHR3Y2FibGUuY29tPiwgTHVjeSB5b25nIDxsdWN5Lnlv bmdAaHVhd2VpLmNvbT4sIERhbmllbCANCkNvaG4gPERhbmllbENAb3Jja2l0LmNvbT4sIFNhbSBD YW8gPHl1cXVuLmNhb0BnbWFpbC5jb20+DQqzrcvNDQoibDJ2cG5AaWV0Zi5vcmciIDxsMnZwbkBp ZXRmLm9yZz4NCtb3zOINClJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBF LVRyZWUgc29sdXRpb24/DQoNCg0KDQoNCg0KDQpXaW0sDQpMb3RzIG9mIHRoYW5rcyBmb3IgYSBw cm9tcHQgcmVzcG9uc2UuDQoNCkkgdGhpbmsgdGhhdCBvcGVyYXRpb25hbCBhc3BlY3RzIG9mIHRo ZSBWTEFOIGFwcHJvYWNoIChlLmcuLCBob3cgaXMgdGhlIA0KR2xvYmFsIFZJRCBzZWxlY3RlZCBh bmQgZGlzdHJpYnV0ZWQpIHNob3VsZCBiZSBleGFtaW5lZCBpbiBtb3JlIGRldGFpbC4NCltSYW5d IEFncmVlLCBhbmQgdGhlcmUgaGF2ZSBhbHJlYWR5IGJlZW4gc3VjaCBkcmFmdCB0aGF0IGRlc2Ny aWJlICJob3cgaXMgDQp0aGUgR2xvYWJhbCBWSUQgc2VsZWN0ZWQgYW5kIGRpc3RyaWJ1dGVkIiBp biBMMlZQTiBXRywgdGhlIGxpbmsgaXM6DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1jaGVuLWwydnBuLXZwbHMtZXRyZWUtdmxhbi0wMS4gDQoNCkF0IHRoZSBzYW1lIHRpbWUgaXQg c2VlbXMgdGhhdCB0aGUgZG91YmxlIFBXIGFwcHJvYWNoIGNhcnJpZXMgd2l0aCBpdCB0b28gDQpt YW55IG9wZXJhdGlvbmFsIHByb2JsZW1zLg0KRS5nLiwgbm8gUFdzIGFyZSBzZXQgdXAgYmV0d2Vl biBMZWFmLW9ubHkgUEVzLCBidXQgb25jZSBvbmUgb2YgdGhlc2UgDQpiZWNvbWVzIGEgTWl4IFBF LCBhbGwgdGhlIExlYWYtb25seSBQRXMgbXVzdCBub3cgcmVjb2duaXplIGl0IGFzIGEgdmFsaWQg DQpwZWVyLiBBbmQgaWYgYSBNaXggUEUgcmV2ZXJ0cyB0byBhIExlYWYgb25seSBvbmUsIGFsbCBp dHMgTGVhZi1vbmx5IHBlZXJzIA0KbXVzdCBkcm9wIGl0IGFuZCBzaHV0IGRvd24gdGhlIHJlbGV2 YW50IFBXcy4uLg0KDQpNeSAyYywNCiAgICAgU2FzaGENCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRnJvbTogSGVuZGVyaWNreCwgV2ltIChXaW0pIFt3aW0uaGVu ZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5jb21dDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMTksIDIw MTIgNzoyMSBBTQ0KVG86IEFsZXhhbmRlciBWYWluc2h0ZWluOyBSb2dlcnMsIEpvc2g7IEx1Y3kg eW9uZzsgRGFuaWVsIENvaG47IFNhbSBDYW8NCkNjOiBsMnZwbkBpZXRmLm9yZw0KU3ViamVjdDog UkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8N Cg0KU2FzaGEsIHRoZSBWTEFOIGFwcHJvYWNoIGFsbG93cyBmb3IgYSBzaW1pbGFyIG9wZXJhdGlv biBhcyB0aGUgQ1cgZG9lcy4gSXQgDQppcyBvcnRob2dvbmFsIHRvIHRoZSB1bmRlcmx5aW5nIFBX IGRlcGxveW1lbnQgb2YgVlBMUy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgDQpBbGV4YW5kZXIgVmFpbnNodGVpbg0KU2VudDogZG9uZGVyZGFnIDE5IGFw cmlsIDIwMTIgNjozOQ0KVG86IFJvZ2VycywgSm9zaDsgTHVjeSB5b25nOyBEYW5pZWwgQ29objsg U2FtIENhbw0KQ2M6IGwydnBuQGlldGYub3JnDQpTdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0 aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KDQpIaSBhbGwsDQpJIGZ1bGx5 IHVuZGVyc3RhbmQgdGhhdCB0aGF0IHdoYXQgSSBhbSBnb2luZyB0byBzYXkgaXMgbm90IHZlcnkg cG9wdWxhciwgDQpidXQ6DQoNCklNTyBvbmUgb2YgdGhlIGFkdmFudGFnZXMgb2YgdGhlIENXLWJh c2VkIHNvbHV0aW9uIGlzIHRoYXQgaXQgaXMgDQpvcnRob2dvbmFsIHRvIHVzYWdlIChvciBub24t dXNhZ2UpIG9mIFAyTVAgUFdzIGZvciBlZmZlY3RpdmUgZGVsaXZlcnkgb2YgDQpCVU4gdHJhZmZp Yy4NCg0KQW5vdGhlciBhZHZhbnRhZ2UgaXMgcHJlc2VydmF0aW9uIG9mIGZ1bGwgbWVzaCBvZiBQ MlAgUFdzIGluIGEgVlBMUywgYW5kLCANCmluIGEgbW9yZSBnZW5lcmljIHdheSwgbG9jYWxpemF0 aW9uIG9mIGVmZmVjdHMgb2YgY2hhbmdlcyBpbiB0aGUgUEUgDQpjb25maWd1cmF0aW9uLg0KDQpJ biBwYXJ0aWN1bGFyLCBhZGRpbmcgYSBMZWFmIEFDIHRvIGEgUEUgdGhhdCBwcmV2aW91c2x5IGhh cyBiZWVuIG9ubHkgDQpzdXBwb3J0aW5nIFJvb3QgQUNzIChvciB2aWNlIHZlcnNhKSwgcmVtb3Zh bCBvZiB0aGUgbGFzdCBMZWFmIG9yIGxhc3QgUm9vdCANCkFDIGZyb20gYSBQRSB0aGF0IHByZXZp b3VzbHkgaGFzIGJlZW4gc3VwcG9ydGluZyBhIG1peCBldGMuIGFmZmVjdCBvbmx5IA0KdGhlIFBF IHdoZXJlIHRoaXMgb3BlcmF0aW9uIGhhcHBlbnMgYW5kIG5vdCB0aGUgcmVzdCBvZiB0aGUgUEVz Lg0KDQpBcyBmb3IgdGhlIG5lZWQgZm9yIEhXIGNoYW5nZXMgdGhhdCBoYXZlIGJlZW4gbWVudGlv bmVkIGFzIGEgbWFpbiANCmRpc2FkdmFudGFnZSBvZiB0aGUgQ1ctYmFzZWQgYXBwcm9hY2ggLSBJ IGJlbGlldmUgaXQgc3Ryb25nbHkgZGVwZW5kcyBvbiANCnNwZWNpZmljIGltcGxlbWVudGF0aW9u cy4gQW5kIHNvbWUgY2hhbmdlcyBpbiB0aGUgZm9yd2FyZGluZyBwcm9jZXNzIGFyZSANCnJlcXVp cmVkIGluIGFueSBzb2x1dGlvbi4NCg0KTXkgMmMsDQogICAgIFNhc2hhDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBsMnZwbi1ib3VuY2VzQGll dGYub3JnIFtsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YgUm9nZXJzLCANCkpv c2ggW2pvc2gucm9nZXJzQHR3Y2FibGUuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxOCwg MjAxMiA5OjU3IFBNDQpUbzogTHVjeSB5b25nOyBEYW5pZWwgQ29objsgU2FtIENhbw0KQ2M6IGwy dnBuQGlldGYub3JnDQpTdWJqZWN0OiBSZTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0 byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KDQpBZ2FpbiwgdGhlIFAyTVAgc2l0dWF0aW9uIHRocm93 cyBtZS4gIElzIHRoaXMgc29tZXRoaW5nIHRoYXQgaXMgdXNlZA0KY29tbW9ubHk/DQoNCkknbSB1 bmRlciB0aGUgaW1wcmVzc2lvbiB0aGF0IGFkZGluZyBQMk1QIHRvIGFueSBtb2RlbCByZXN1bHRz IGluIGEgbW9yZQ0KY29tcGxleCBtb2RlbC4gIFdldGhlciBvdXRzaWRlIHMtdGFnIGlzIHVzZWQg dG8gZGlmZmVyZW50aWF0ZSwgb3INCmRlZGljYXRlZCBwdydzIGFyZSB1c2VkIGZvciB0aGUgc2Ft ZSBwdXJwb3NlLCBpdCBzZWVtcyBib3RoIGJlY29tZSBtb3JlDQpjb21wbGV4Lg0KDQpHaWxlJ3Mg Y29tcGFyaXNvbiBzbGlkZSBzdGlsbCBjb25jaXNlbHkgY2FwdHVyZXMgdGhlIGRpZmZlcmVuY2Vz IGJldHdlZW4NCnRoZXNlIG1ldGhvZHMsIGluIG15IG9waW5pb24uICBJIGhhdmVuJ3Qgc2VlbiBh bnkgbmV3IGlkZWFzIG9yIHRob3VnaHRzDQpicm91Z2h0IHRvIHRoZSBncm91cCBpbiB0aGUgcGFz dCB3ZWVrIG9yIHR3byBvbiB0aGUgc3ViamVjdC4gIEkgd291bGQgaGF0ZQ0KZm9yIGJvdGggcHJv cG9zZWQgbWV0aG9kcyB0byBkaWUgb24gdGhlIHZpbmUgYmVjYXVzZSB3ZSBjb3VsZG4ndCBkZWNp ZGUNCmJldHdlZW4gdHdvIG1ldGhvZHMgdGhhdCBoYXZlIG5vdGhpbmcgaW5oZXJlbnRseSB3cm9u ZyB3aXRoIGVpdGhlci4NCg0KLUpvc2gNCg0KDQpPbiA0LzE4LzEyIDE6NTMgUE0sICJMdWN5IHlv bmciIDxsdWN5LnlvbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQoNCj5TZW5kIHRoaXMgYWdhaW4uDQo+ DQo+VHdvIFBXIGFwcHJvYWNoIGNhbiBiZSBjb21wbGV4IHRvbyBpZiB0aGUgVlBMUyBpbnN0YW5j ZSBmb3IgRS1UcmVlIHVzZXMNCj5QMlAgUFcgZm9yIHVuaWNhc3QgdHJhZmZpYyBhbmQgUDJNUCBQ VyBmb3IgYnJvYWRjYXN0IGFuZCB1bmtub3duDQo+dW5pY2FzdCB0cmFmZmljLCBhbmQgc29tZSBQ Mk1QIFBXcyBmb3IgbXVsdGljYXN0IHRyYWZmaWMuIEl0IG1heSBkb3VibGUNCj5hbGwgb2YgdGhl bS4NCj4NCj5MdWN5DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBEYW5p ZWwgQ29obiBbbWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbV0NCj5TZW50OiBXZWRuZXNkYXksIEFw cmlsIDE4LCAyMDEyIDE6NDIgUE0NCj5UbzogTHVjeSB5b25nOyBSb2dlcnMsIEpvc2g7IFNhbSBD YW8NCj5DYzogbDJ2cG5AaWV0Zi5vcmcNCj5TdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUg YXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPg0KPkkgdGhpbmsgdGhlIGZpcnN0 IG9wdGlvbiBpdHMgdGhlIG5hdHVyYWwgd2F5IHRvIGdvLiBIb3cgaXMgdGhlIHByb2Nlc3NpbmcN Cj5pbiB0aGlzIGNhc2UgbW9yZSBjb21wbGV4Pw0KPg0KPlRodW1iIHR5cGVkIC0gcGxlYXNlIGJl IHRvbGVyYW50DQo+DQo+THVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ DQo+DQo+DQo+U25pcHBlZC4uDQo+DQo+TXVsdGktUFcgLSBPbiBpbmdyZXNzIFBFLCBmcmFtZSBp cyBwbGFjZWQgb250byBlaXRoZXIgYSBMZWFmLW9ubHkgUDJNUCBQVw0KPihmb3IgdHJhZmZpYyBj b21pbmcgZnJvbSBhIGxlYWYgQUMpLCBvciBvbnRvIGEgUm9vdC9MZWFmIFAyTVAgUFcgKGZvcg0K PnRyYWZmaWMgY29taW5nIGZyb20gYSByb290IEFDKQ0KPltbTFldXSBOb3QgdGhhdCBzaW1wbGUu IFlvdSBjb25zdHJ1Y3QgZWl0aGVyIHR3byBQMk1QIFBXcyB0byBhbGwgb3RoZXINCj5QRXMgYW5k IGxldCBlZ3Jlc3MgUEUgcGVyZm9ybWluZyBmaWx0ZXJpbmcsIG9yIGNvbnN0cnVjdCBvbmUgUDJN UCBQVyB0bw0KPmxlYWYtb25seSBQRXMgYW5kIHR3byBQMk1QIFBXcyB0byByb290IGFuZCBsZWFm IFBFcyBhbmQgbGV0IGluZ3Jlc3MgUEUNCj5wZXJmb3JtIGZvcndhcmRpbmcgYW5kIGZpbHRlcmlu Zy4gQm90aCBtYWtlIG5vZGUgcHJvY2VzcyBjb21wbGV4Lg0KPg0KPltbTFldXSBWUExTIGlzIGJ1 aWx0IHdpdGggdGhlIG1lY2hhbmlzbSB1dGlsaXppbmcgUDJQIGFuZCBQMk1QIFBXIGZvcg0KPmRl bGl2ZXJpbmcgdGhlIGZyYW1lcyB0byByZW1vdGUgUEVzLiBXZSBzaG91bGQgdXRpbGl6ZSB0aGVt IHdpdGggdGhlDQo+bWluaW1pemVkIGNoYW5nZXMuIER1YWwgVkxBTiBzb2x1dGlvbiBpcyBzaW1w bGVyIHRoYW4gRHVhbCBQVy4NCj4NCj5SZWdhcmRzLA0KPkx1Y3kNCj4NCj4NCj5JIHNlZSBob3cg MlZMQU4gaXMgc2ltcGxlciB3aGVuIFAyTVAgUFcncyBhcmUgaW52b2x2ZWQsIEkgdGhpbmsuICBJ DQo+aGF2ZW4ndCBoYWQgYW55IGZpcnN0IGhhbmQgZXhwZXJpZW5jZSB3aXRoIFAyTVAgUFcncywg aG93ZXZlciwgc28gZG9uJ3QNCj5mZWVsIHRlcnJpYmx5IHN0cm9uZyBhYm91dCB0aGlzIG9iamVj dGlvbi4gIElzIHRoaXMgYSByZWFsIHByb2JsZW0gZm9yDQo+b3RoZXJzIChub3cgb3IgaW4gdGhl IGZ1dHVyZSksIG9yIGlzIHRoaXMgb2JqZWN0aW9uIGluIHRoZSB3ZWVkcz8NCj4NCj5JJ20gbm90 IHN1cmUgdGhlICdhZGRpdGlvbmFsIGNvbXBsZXhpdHknIGlzIG5vdGFibGUsIG9yIGV2ZW4gcmVs ZXZhbnQuICBJDQo+ZW5jb3VyYWdlIG90aGVycyB0byBzcGVhayB1cCBpZiB0aGV5IGRpc2FncmVl LCBhcyBQMk1QIFBXIGlzIG9ubHkNCj5jb25jZXB0dWFsIHRvIG1lLCBhbmQgSSBhbSB1bmZhbWls aWFyIHdpdGggcmVhbC1saWZlIHVzZSBjYXNlcyBmb3IgaXQuDQo+DQo+VGhhbmtzLA0KPkpvc2gN Cj4NCj4NCj4NCj5PbiA0LzE4LzEyIDEwOjMwIEFNLCAiTHVjeSB5b25nIiA8bHVjeS55b25nQGh1 YXdlaS5jb20+IHdyb3RlOg0KPg0KPj5QbGVhc2Ugc2VlIGlubGluZS4NCj4+DQo+Pi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IFNhbSBDYW8gW21haWx0bzp5dXF1bi5jYW9AZ21h aWwuY29tXQ0KPj5TZW50OiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiA3OjE0IEFNDQo+PlRvOiAn RGFuaWVsIENvaG4nOyBMdWN5IHlvbmc7ICdSb2dlcnMsIEpvc2gnOyAnSGVuZGVyaWNreCwgV2lt IChXaW0pJzsNCj4+Z2lsZXMuaGVyb25AZ21haWwuY29tOyBzaW1vbi5kZWxvcmRAZ21haWwuY29t Ow0KPj5BbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KPj5DYzogbDJ2cG5AaWV0Zi5v cmc7IFZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb207DQo+PkFuZHJldy5TZXJnZWV2QGVjaXRl bGUuY29tOyBJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbTsNCj4+TWlzaGFlbC5XZXhsZXJAZWNpdGVs ZS5jb207IFJvdGVtLkNvaGVuQGVjaXRlbGUuY29tDQo+PlN1YmplY3Q6IFJFOiBUaGUgc3RhdHVz IG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pg0KPj5ZZXMsIDIg cHdzIGFyZSBvbmx5IG5lZWRlZCBiZXR3ZWVuIHBlcyB3aXRoIGJvdGggcm9vdCBhbmQgbGVhZiBh Y3MgYWZ0ZXINCj4+aW1wcm92aW5nIER1YWwtUFcgYXBwcm9hY2guIElmIGNvbnNpZGVyIFAyTVAs IER1YWwtUFcgYXBwcm9hY2ggc2V0dXAgMg0KPj5QMk1QDQo+PlBXcyBpZiBuZWVkLiBUaGVyZSBp cyBubyBkaWZmZXJlbmNlIGJldHdlZW4gUDJNUCBvciBub3JtYWwgUFcgc2V0dXAuIA0KQnV0LA0K Pj5jYW4gTGVhZi1BQ3MgYmUgYm91bmQgdG8gUm9vdCBQRSBvZiBQMk1QIFBXPw0KPj4NCj4+W1tM WV1dIE5vLCBpdCBtYWtlcyBjb21wbGV4IGluIHNldHRpbmcgdXAgUDJNUCBQVy4gU2hvdWxkIGEg UEUgd2l0aCBib3RoDQo+PnJvb3QgYW5kIGxlYWYgQUNzIHNldCB1cCB0d28gb3Igb25lIFAyTVAg UFcgdG8gb3RoZXIgUEVzIChzb21lIFBFIGhhdmUNCj4+Ym90aCByb290IGFuZCBsZWFmIEFDIGFu ZCBzb21lIG9ubHkgaGF2ZSBsZWFmIEFDcyk/DQo+PlJlZ2FyZHMsDQo+Pkx1Y3kNCj4+DQo+PlJl Z2FyZHMsDQo+Pg0KPj5ZdXF1biAoU2FtKSBDYW8NCj4+RS1tYWlsOiBZdXF1bi5jYW9AZ21haWwu Y29tDQo+Pg0KPj4NCj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogRGFuaWVs IENvaG4gW21haWx0bzpEYW5pZWxDQG9yY2tpdC5jb21dDQo+PlNlbnQ6IFR1ZXNkYXksIEFwcmls IDE3LCAyMDEyIDQ6NTYgUE0NCj4+VG86IEx1Y3kgeW9uZzsgUm9nZXJzLCBKb3NoOyBIZW5kZXJp Y2t4LCBXaW0gKFdpbSk7DQo+PmdpbGVzLmhlcm9uQGdtYWlsLmNvbTsNCj4+c2ltb24uZGVsb3Jk QGdtYWlsLmNvbTsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207IFNhbSBDYW8NCj4+ Q2M6IGwydnBuQGlldGYub3JnOyBWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tOw0KPj5BbmRy ZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTsgSWRhbi5LYXNwaXRAZWNpdGVsZS5jb207DQo+Pk1pc2hh ZWwuV2V4bGVyQGVjaXRlbGUuY29tOyBSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbQ0KPj5TdWJqZWN0 OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9u Pw0KPj4NCj4+QWRkaW5nIFNhbSAoYXMgbDJ2cG5AIGlzIGhvbGRpbmcgbWVzc2FnZXMpDQo+Pg0K Pj5EQw0KPj4NCj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogTHVjeSB5b25n IFttYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb21dDQo+PlNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE3 LCAyMDEyIDEyOjM5IEFNDQo+PlRvOiBEYW5pZWwgQ29objsgUm9nZXJzLCBKb3NoOyBIZW5kZXJp Y2t4LCBXaW0gKFdpbSk7DQo+PmdpbGVzLmhlcm9uQGdtYWlsLmNvbTsgc2ltb24uZGVsb3JkQGdt YWlsLmNvbTsNCj4+QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20NCj4+Q2M6IGwydnBu QGlldGYub3JnOyBWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tOw0KPj5BbmRyZXcuU2VyZ2Vl dkBlY2l0ZWxlLmNvbTsgSWRhbi5LYXNwaXRAZWNpdGVsZS5jb207DQo+Pk1pc2hhZWwuV2V4bGVy QGVjaXRlbGUuY29tOyBSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbQ0KPj5TdWJqZWN0OiBSRTogVGhl IHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4NCj4+ DQo+PlNuaXBwZWQsDQo+Pg0KPj5BcyB3ZSBkaXNjdXNzZWQgZXh0ZW5zaXZlbHkgaW4gdGhlIGxp c3QsIGFuZCBhcyByZWZsZWN0ZWQgaW4gZ2lsZXMNCj4+c2xpZGUsIDIgcHdzIGFyZSBvbmx5IG5l ZWRlZCBiZXR3ZWVuIHBlcyB3aXRoIGJvdGggcm9vdCBhbmQgbGVhZiBhY3MsDQo+PndoaWNoIHdp bGwgdHlwaWNhbGx5IGJlIGEgc21hbGwgbWlub3JpdHkuDQo+PltbTFldXSBEb24ndCBrbm93IGlm IHRoZSBhc3N1bXB0aW9uIGlzIHRydWUuIEV2ZW4gaXQgaXMgdGhlIGNhc2UsIGJvdGgNCj4+YXBw cm9hY2hlcyBjYW4gYmVuZWZpdCBmcm9tIGl0LiBJIHdhcyBvZmYgZm9yIGEgd2hpbGUgYW5kIGNh cHR1cmVzIHNvbWUNCj4+ZGlzY3Vzc2lvbnMgbm93Lg0KPj4NCj4+QWxzbyBhcyBwZXIgZ2lsZXMg c2xpZGUsIGR1YWwgdmxhbiBjYW4gaGF2ZSBzY2FsYWJpbGl0eSBpc3N1ZXMgZHVlIHRvDQo+PmFk ZGl0aW9uYWwgbG9va3VwIGFuZCBkb3VibGUgdXNlIG9mIHZsYW5zIGluIGludGVybmFsIGVtdWxh dGVkIGxhbg0KPj5pbnRlcmZhY2UuIEFsc28gdGhlcmUgYXJlIHBvdGVudGlhbCBiYWNrd2FyZCBj b21wYXRpYmlsaXR5IGlzc3VlcyB3aXRoDQo+PnNpbGljb24gdGhhdCBkb2Vzbid0IHN1cHBvcnQg dmxhbiBtYXBwaW5nLg0KPj5bW0xZXV0gSSB3YXMgbm90IGluIElFVEY4MyBtZWV0aW5nIGFuZCB3 YWl0IG9uIHRoZSBtZWV0aW5nIG1pbnV0ZXMuIEkgYW0NCj4+bm90IGNsZWFyIG9uIGFsbCB0aGUg aXNzdWVzLiBDb3VsZCB5b3UgYmUgbW9yZSBzcGVjaWZpYz8gQXMgSSBtZW50aW9uZWQNCj4+aW4g YmVsb3csIHR3byBQVyBhcHByb2FjaCBtYWtlcyBWUExTIHRyYW5zcG9ydCBjb25zdHJ1Y3Rpb24g YW5kIHBhY2tldA0KPj5mb3J3YXJkaW5nIG1vcmUgY29tcGxleCwgSSBjYW4gc2VlIHBvdGVudGlh bCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5DQo+Pmlzc3VlcyB3aXRoIDIgUFcgc29sdXRpb24uDQo+ Pg0KPj5SZWdhcmRzLA0KPj5MdWN5DQo+Pg0KPj5SZWdhcmRzLA0KPj4NCj4+RGFuaWVsDQo+Pg0K Pj5UaHVtYiB0eXBlZCAtIHBsZWFzZSBiZSB0b2xlcmFudA0KPj4NCj4+THVjeSB5b25nIDxsdWN5 LnlvbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQo+Pg0KPj5JbiBteSBtaW5kLCB0aGUgVkxBTiBhcHBy b2FjaCBtZWFucyBkdWFsIHZsYW4gbWV0aG9kLg0KPj4NCj4+VGhlIG1haW4gY29uY2VybiBmb3Ig Q1cgYXBwcm9hY2ggaXMgaGFyZHdhcmUgc3VwcG9ydC4NCj4+DQo+PlR3byBQVyBhcHByb2FjaCBj YW4gYmUgY29tcGxleCB0b28gaWYgdGhlIFZQTFMgaW5zdGFuY2UgZm9yIEUtVHJlZSB1c2VzDQo+ PlAyUCBQVyBmb3IgdW5pY2FzdCB0cmFmZmljIGFuZCBQMk1QIFBXIGZvciBicm9hZGNhc3QgYW5k IHVua25vd24gdW5pY2FzdA0KPj50cmFmZmljLCBhbmQgc29tZSBQMk1QIFBXcyBmb3IgbXVsdGlj YXN0IHRyYWZmaWMuIEl0IG1heSBkb3VibGUgYWxsIG9mDQo+PnRoZW0uDQo+Pg0KPj5FLXRyZWUg aXMgYW4gRXRoZXJuZXQgc2VydmljZSBhbmQgdGhlcmUgaXMgYWxyZWFkeSBWTEFOIGJhc2VkIHNv bHV0aW9uDQo+PmluIElFRUUsIGNhbiB3ZSBqdXN0IHV0aWxpemUgaXQgd2l0aG91dCBjb21wbGlj YXRpbmcgVlBMUyB0cmFuc3BvcnQNCj4+Y29uc3RydWN0aW9uPyBUaGlzIGFsc28gbWFrZXMgaW50 ZXJ3b3JraW5nIHdpdGggRXRoIG9ubHkgbmV0d29yayBlYXNpZXIuDQo+Pg0KPj5DaGVlcnMsDQo+ Pkx1Y3kNCj4+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IFJvZ2Vycywg Sm9zaCBbbWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29tXQ0KPj5TZW50OiBNb25kYXksIEFw cmlsIDE2LCAyMDEyIDg6MzUgQU0NCj4+VG86IEx1Y3kgeW9uZzsgSGVuZGVyaWNreCwgV2ltIChX aW0pOyAnZ2lsZXMuaGVyb25AZ21haWwuY29tJzsNCj4+J3NpbW9uLmRlbG9yZEBnbWFpbC5jb20n OyAnQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20nDQo+PkNjOiAnbDJ2cG5AaWV0Zi5v cmcnOyAnVmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbSc7DQo+PidBbmRyZXcuU2VyZ2VldkBl Y2l0ZWxlLmNvbSc7ICdJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbSc7DQo+PidNaXNoYWVsLldleGxl ckBlY2l0ZWxlLmNvbSc7ICdSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbScNCj4+U3ViamVjdDogUkU6 IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4+ DQo+PkkgYmVsaWV2ZSB0aGUgaW5pdGlhbCBxdWVzdGlvbiB3YXMgaW4gcmVnYXJkIHRvIHRoZSBD VyBtZXRob2QuICBBcmUgeW91DQo+PnNheWluZyB0aGF0IHlvdSBubyBsb25nZXIgYXJlIGludGVy ZXN0ZWQgaW4gdGhhdCBtZXRob2QgaW4gcHJlZmVyZW5jZSBvZg0KPj50aGUgZHVhbCB2bGFuIG1l dGhvZD8NCj4+DQo+Pg0KPj4NCj4+THVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbT4gd3Jv dGU6DQo+Pg0KPj4NCj4+QWdyZWUgd2l0aCBXaW0uIFZMQU4gYXBwcm9hY2ggaXMgdGhlIGJlc3Qg c29sdXRpb24gZm9yIEUtVHJlZS4NCj4+DQo+Pkx1Y3kNCj4+DQo+Pi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+PkZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4+T2YgSGVuZGVyaWNreCwgV2ltIChXaW0pDQo+ PlNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxMiwgMjAxMiAyOjAzIEFNDQo+PlRvOiAnZ2lsZXMuaGVy b25AZ21haWwuY29tJzsgJ3NpbW9uLmRlbG9yZEBnbWFpbC5jb20nOw0KPj4nQWxleGFuZGVyLlZh aW5zaHRlaW5AZWNpdGVsZS5jb20nDQo+PkNjOiAnbDJ2cG5AaWV0Zi5vcmcnOyAnVmxhZGltaXIu S2xlaW5lckBlY2l0ZWxlLmNvbSc7DQo+PidBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbSc7ICdJ ZGFuLkthc3BpdEBlY2l0ZWxlLmNvbSc7DQo+PidNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbSc7 ICdSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbScNCj4+U3ViamVjdDogUmU6IFRoZSBzdGF0dXMgb2Yg dGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4+DQo+PlRoZSB2bGFuIGFw cHJvYWNoIGlzIHN1cGVyaW9yIGFzIGl0IGFsc28gd29ya3MgZm9yIGV0aCBvbmx5IG5ldHdvcmtz LA0KPj5ldGMuIE9uIHRvcCBzb21lIHZlbmRvcnMgaW5kaWNhdGUgaHcgaXNzdWVzIHdpdGggdGhl IGN3IGFwcHJvYWNoLiBBcw0KPj5zdWNoIHdlIGhhdmUgZHJvcHBlZCBtb3JlIG9yIGxlc3MgdGhl IGN3IGFwcHJvYWNoLg0KPj4NCj4+Q2hlZXJzLA0KPj5XaW0NCj4+X19fX19fX19fX19fX19fX18N Cj4+c2VudCBmcm9tIGJsYWNrYmVycnkNCj4+DQo+Pi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0NCj4+RnJvbTogR2lsZXMgSGVyb24gW21haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb21dDQo+ PlNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxMiwgMjAxMiAwODoyMiBBTQ0KPj5UbzogU2ltb24gRGVs b3JkIDxzaW1vbi5kZWxvcmRAZ21haWwuY29tPjsgQWxleGFuZGVyIFZhaW5zaHRlaW4NCj4+PEFs ZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPg0KPj5DYzogbDJ2cG5AaWV0Zi5vcmcgPGwy dnBuQGlldGYub3JnPjsgVmxhZGltaXIgS2xlaW5lcg0KPj48VmxhZGltaXIuS2xlaW5lckBlY2l0 ZWxlLmNvbT47IEFuZHJldyBTZXJnZWV2DQo+PjxBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbT47 IElkYW4gS2FzcGl0IDxJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbT47DQo+Pk1pc2hhZWwgV2V4bGVy IDxNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT47IFJvdGVtIENvaGVuDQo+PjxSb3RlbS5Db2hl bkBlY2l0ZWxlLmNvbT4NCj4+U3ViamVjdDogUmU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNo ZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4+DQo+PlNvcnJ5IC0gdGhlICJhbm9ueW1vdXMg cHJlc2VudGF0aW9uIiB3YXMgbWluZS4gIEkgc2hvdWxkIHBvc3NpYmx5IGhhdmUNCj4+cHV0IGlu IGEgdGhpcmQgY29sdW1uIG9uIHRoZSBDVyBhcHByb2FjaC4gIEFuZCBob3BlZnVsbHkgdGhlIG1p bnV0ZXMNCj4+d2lsbCBiZSBwb3N0ZWQgc29vbi4NCj4+DQo+PldlIGhhZCB2YXJpb3VzIGRpc2N1 c3Npb25zLCBhcyBTaW1vbiBzdGF0ZWQsIGFuZCBjb25zZW5zdXMgc2VlbWVkIHRvIGJlDQo+PmZv cm1pbmcgYXJvdW5kIHRoZSB0d28gYWx0ZXJuYXRpdmVzIG9mIHR3byBQV0VzIG9yIHR3byBWTEFO cy4gIEkgYmVsaWV2ZQ0KPj50aHJlZSBvZiB0aGUgYXV0aG9ycyBvZiB0aGUgQ1cgYXBwcm9hY2gg YXJlIGFsc28gYXV0aG9ycyBvZiB0aGUgdHdvIFZMQU4NCj4+YXBwcm9hY2ggYW5kIG9uZSBpcyBh bHNvIGFuIGF1dGhvciBvZiB0aGUgdHdvIFBXRSBhcHByb2FjaC4gU28gcGVyaGFwcw0KPj5pdCdz IGJlc3QgdG8gbGV0IHRob3NlIGZvdXIgaW5kaXZpZHVhbHMgc2F5IHdoaWNoIGFwcHJvYWNoIHRo ZXkgcHJlZmVyDQo+PmFuZCB3aHk/DQo+Pg0KPj5HaWxlcw0KPj4NCj4+T24gMTAvMDQvMjAxMiAw MDo0NSwgIlNpbW9uIERlbG9yZCIgPHNpbW9uLmRlbG9yZEBnbWFpbC5jb20+IHdyb3RlOg0KPj4N Cj4+PiBIaSBBbGV4YW5kZXIsDQo+Pj4NCj4+PiBZb3UgYXJlIHJpZ2h0LCBubyBkaXNjdXNzaW9u IG9uIHRoZSBXRyBtYWlsaW5nIGxpc3QgcmVjZW50bHksIGJ1dA0KPj4+IHRoZXJlIGhhdmUgYmVl biBzdWJzdGFudGlhbCBkaXNjdXNzaW9ucyBhbW9uZyB0aGUgYXV0aG9ycyBvZiB2YXJpb3VzDQo+ Pj4gc29sdXRpb24gZHJhZnRzIG9mZiB0aGUgbWFpbGluZyBsaXN0LiBBcyBmYXIgYXMgSSBrbm93 LCBubyBjb25zZW5zdXMNCj4+PiB5ZXQgYmVmb3JlIGlldGY4Mywgbm90IHN1cmUgdGhlIHByb2dy ZXNzIGluIHRoZSBQYXJpcyBXRyBtZWV0aW5nLiBJDQo+Pj4gdGhpbmsgdGhlIENXIGFwcHJvYWNo IGhhcyBub3QgYmVlbiByZWplY3RlZCBieSB0aGUgV0cgeWV0LCBvciB0aGUgV0cNCj4+PiBoYXMg bm90IHlldCBkZWNpZGVkIG9uIHdoaWNoIG9uZSB0byBhZG9wdC4NCj4+Pg0KPj4+IFNpbW9uDQo+ Pj4NCj4+PiAyMDEyLzQvOCBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRl aW5AZWNpdGVsZS5jb20+DQo+Pj4NCj4+Pj4gIEhpIGFsbCwNCj4+Pj4NCj4+Pj4gVW5mb3J0dW5h dGVseSBJIGhhdmUgbm90IGJlZW4gYWJsZSB0byBhdHRlbmQgdGhlIFBhcmlzIElFVEYuDQo+Pj4+ DQo+Pj4+IEhvd2V2ZXIsIGxvb2tpbmcgdXAgdGhlIEwyVlBOIHByb2NlZWRpbmdzLCBJJ3ZlIGZv dW5kIGEgc2hvcnQNCj4+Pj4gYW5vbnltb3VzIHByZXNlbnRhdGlvbiBjYWxsZWQgIkUtVHJlZSBV cGRhdGUiICAoDQo+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODMvc2xpZGVz L3NsaWRlcy04My1sMnZwbi0xLnBwdHgpLg0KPj4+PiBUaGlzIHByZXNlbnRhdGlvbiBkaXNjdXNz ZXMgdGhlIGRpZmZlcmVuY2VzIG9mIHRoZSBFLVRyZWUgYXBwcm9hY2hlcw0KPj4+PiBiYXNlZCBv biBkZWRpY2F0ZWQgVkxBTnMgKGFzIGluDQo+Pj4+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtY2FvLWwydnBuLXZwbHMtZXRyZWUvP2luY2x1ZGVfdA0KPj4+PiBleHQ9MSkg YW5kIG11bHRpcGxlIFBXcyBiZXR3ZWVuIHRoZSBQRXMgKGFzIGluDQo+Pj4+IGh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmFtLWwydnBuLWV0cmVlLW11bHRpcGxlLXB3Lz9p bg0KPj4+PiBjbHVkZV90ZQ0KPj4+PiB4dD0xKQ0KPj4+PiBhbmQgY29tcGxldGVseSBpZ25vcmVz IHRoZSBzb2x1dGlvbiBiYXNlZCBvbiB1c2FnZSBvZiB0aGUgQ1cgaW4gdGhlDQo+Pj4+IFBXcyBj b25uZWN0aW5nIHRoZSBQRXMgKGFzIGluDQo+Pj4+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQta2V5LWwydnBuLXZwbHMtZXRyZWUvP2luY2x1ZGVfdA0KPj4+PiBleHQ9MQ0K Pj4+PiApLg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBUaGUgTWludXRlcyBvZiB0aGUgUGFyaXMg TDJWUE4gc2Vzc2lvbiBhcmUgbm90IHlldCBhdmFpbGFibGUsIGJ1dCBJDQo+Pj4+IHdvbmRlciB3 aGV0aGVyIHRoZSBXRyBoYXMgdGFrZW4gYSBkZWNpc2lvbiB0byByZWplY3QgdGhlIGFwcHJvYWNo DQo+Pj4+IGJhc2VkIG9uIHRoZSBDVyB1c2FnZT8gSSBkbyBub3QgcmVtZW1iZXIgYW55IHJlY2Vu dCBkaXNjdXNzaW9uIG9mDQo+Pj4+IHRoaXMgdG9waWMgb24gdGhlIFdHIG1haWxpbmcgbGlzdC4N Cj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gUmVnYXJkcywgYW5kIGxvdHMgb2YgdGhhbmtzIGluIGFk dmFuY2UsDQo+Pj4+DQo+Pj4+IFNhc2hhDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+ Pj4+IFRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25s eSBhbmQgY29udGFpbnMNCj4+Pj4gaW5mb3JtYXRpb24gd2hpY2ggaXMgQ09ORklERU5USUFMIGFu ZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJDQo+Pg0KPj4+PiBUZWxlY29tLiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlDQo+Pj4+ IGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBv cmlnaW5hbCBhbmQNCj4+Pj4gYWxsIGNvcGllcyB0aGVyZW9mLg0KPj4+Pg0KPj4NCj4+DQo+Pg0K Pj4NCj4+DQo+PlRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIFRpbWUgV2FybmVyIENhYmxlDQo+PnByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBp cyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QNCj4+dG8gY29weXJpZ2h0IGJl bG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQNCj4+ c29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBp dCBpcyBhZGRyZXNzZWQuDQo+PklmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQg b2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5DQo+Pm5vdGlmaWVkIHRoYXQgYW55IGRpc3Nl bWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuDQo+PmluIHJl bGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwg aXMNCj4+c3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzDQo+PkUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseQ0KPj5kZWxldGUgdGhlIG9yaWdpbmFsIGFu ZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0KPj4NCj4NCj4NCj5U aGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdh cm5lciBDYWJsZQ0KPnByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2Vk LCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8NCj5jb3B5cmlnaHQgYmVsb25naW5nIHRvIFRp bWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkNCj5mb3IgdGhl IHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2Vk LiBJZiB5b3UNCj5hcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWws IHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkDQo+dGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJp YnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4NCj5yZWxhdGlvbiB0byB0aGUgY29u dGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5DQo+cHJv aGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUt bWFpbCBpbg0KPmVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5k IHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUNCj5vcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBF LW1haWwgYW5kIGFueSBwcmludG91dC4NCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSANCnByb3ByaWV0YXJ5IGlu Zm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3Qg dG8gDQpjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFp bCBpcyBpbnRlbmRlZCBzb2xlbHkgDQpmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBl bnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgDQphcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIA0K dGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24g dGFrZW4gaW4gcmVsYXRpb24gDQp0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRv IHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgDQphbmQgbWF5IGJlIHVubGF3ZnVs LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIA0Kbm90 aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3Jp Z2luYWwgYW5kIGFueSANCmNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NClRo aXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQg Y29udGFpbnMgDQppbmZvcm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1h eSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgDQpUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyANCmJ5IGUtbWFpbCwg cGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbGwgY29waWVz IA0KdGhlcmVvZi4NClRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNp cGllbnQgb25seSBhbmQgY29udGFpbnMgDQppbmZvcm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJ QUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgDQpUZWxlY29tLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1 cyANCmJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFs IGFuZCBhbGwgY29waWVzIA0KdGhlcmVvZi4NCg0KDQoNCg0K --=_alternative 00285D25482579E5_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFNhc2hhLDwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+UGxlc2Ugc2VlIGlubGluZSwgdGhhbmtz PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkFs ZXhhbmRlciBWYWluc2h0ZWluICZsdDtBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbSZn dDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7I yzogJm5ic3A7bDJ2cG4tYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj4yMDEyLzA0LzE5IDEzOjMxPC9mb250Pg0KPHRkIHdpZHRoPTY0JT4N Cjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8 dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O0hlbmRlcmlja3gsIFdpbSAo V2ltKSZxdW90OyAmbHQ7d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29tJmd0OywNCiZx dW90O1JvZ2VycywgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Sm9zaCZxdW90OyAmbHQ7am9z aC5yb2dlcnNAdHdjYWJsZS5jb20mZ3Q7LA0KTHVjeSB5b25nICZsdDtsdWN5LnlvbmdAaHVhd2Vp LmNvbSZndDssIERhbmllbCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDb2huDQombHQ7RGFu aWVsQ0BvcmNraXQuY29tJmd0OywgU2FtIENhbyAmbHQ7eXVxdW4uY2FvQGdtYWlsLmNvbSZndDs8 L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O2wydnBuQGlldGYub3JnJnF1b3Q7ICZsdDtsMnZwbkBp ZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHBy b2FjaGVzIHRvDQp0aGUgRS1UcmVlIHNvbHV0aW9uPzwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRh YmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0K PGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+V2ltLDxicj4NCkxvdHMgb2YgdGhhbmtz IGZvciBhIHByb21wdCByZXNwb25zZS48YnI+DQo8YnI+DQpJIHRoaW5rIHRoYXQgb3BlcmF0aW9u YWwgYXNwZWN0cyBvZiB0aGUgVkxBTiBhcHByb2FjaCAoZS5nLiwgaG93IGlzIHRoZQ0KR2xvYmFs IFZJRCBzZWxlY3RlZCBhbmQgZGlzdHJpYnV0ZWQpIHNob3VsZCBiZSBleGFtaW5lZCBpbiBtb3Jl IGRldGFpbC48YnI+DQpbUmFuXSBBZ3JlZSwgYW5kIHRoZXJlIGhhdmUgYWxyZWFkeSBiZWVuIHN1 Y2ggZHJhZnQgdGhhdCBkZXNjcmliZSAmcXVvdDtob3cNCmlzIHRoZSBHbG9hYmFsIFZJRCBzZWxl Y3RlZCBhbmQgZGlzdHJpYnV0ZWQmcXVvdDsgaW4gTDJWUE4gV0csIHRoZSBsaW5rDQppczpodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGVuLWwydnBuLXZwbHMtZXRyZWUtdmxhbi0w MS4gPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD48YnI+DQpBdCB0aGUgc2FtZSB0 aW1lIGl0IHNlZW1zIHRoYXQgdGhlIGRvdWJsZSBQVyBhcHByb2FjaCBjYXJyaWVzIHdpdGggaXQg dG9vDQptYW55IG9wZXJhdGlvbmFsIHByb2JsZW1zLjxicj4NCkUuZy4sIG5vIFBXcyBhcmUgc2V0 IHVwIGJldHdlZW4gTGVhZi1vbmx5IFBFcywgYnV0IG9uY2Ugb25lIG9mIHRoZXNlIGJlY29tZXMN CmEgTWl4IFBFLCBhbGwgdGhlIExlYWYtb25seSBQRXMgbXVzdCBub3cgcmVjb2duaXplIGl0IGFz IGEgdmFsaWQgcGVlci4NCkFuZCBpZiBhIE1peCBQRSByZXZlcnRzIHRvIGEgTGVhZiBvbmx5IG9u ZSwgYWxsIGl0cyBMZWFmLW9ubHkgcGVlcnMgbXVzdA0KZHJvcCBpdCBhbmQgc2h1dCBkb3duIHRo ZSByZWxldmFudCBQV3MuLi48YnI+DQo8YnI+DQpNeSAyYyw8YnI+DQogJm5ic3A7ICZuYnNwOyBT YXNoYTxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpGcm9tOiBIZW5kZXJpY2t4LCBXaW0gKFdpbSkgW3dpbS5oZW5kZXJpY2t4QGFsY2F0ZWwt bHVjZW50LmNvbV08YnI+DQpTZW50OiBUaHVyc2RheSwgQXByaWwgMTksIDIwMTIgNzoyMSBBTTxi cj4NClRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgUm9nZXJzLCBKb3NoOyBMdWN5IHlvbmc7IERh bmllbCBDb2huOyBTYW0gQ2FvPGJyPg0KQ2M6IGwydnBuQGlldGYub3JnPGJyPg0KU3ViamVjdDog UkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj88 YnI+DQo8YnI+DQpTYXNoYSwgdGhlIFZMQU4gYXBwcm9hY2ggYWxsb3dzIGZvciBhIHNpbWlsYXIg b3BlcmF0aW9uIGFzIHRoZSBDVyBkb2VzLg0KSXQgaXMgb3J0aG9nb25hbCB0byB0aGUgdW5kZXJs eWluZyBQVyBkZXBsb3ltZW50IG9mIFZQTFMuPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQpGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4t Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQpPZiBBbGV4YW5kZXIgVmFpbnNodGVpbjxicj4N ClNlbnQ6IGRvbmRlcmRhZyAxOSBhcHJpbCAyMDEyIDY6Mzk8YnI+DQpUbzogUm9nZXJzLCBKb3No OyBMdWN5IHlvbmc7IERhbmllbCBDb2huOyBTYW0gQ2FvPGJyPg0KQ2M6IGwydnBuQGlldGYub3Jn PGJyPg0KU3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUt VHJlZSBzb2x1dGlvbj88YnI+DQo8YnI+DQpIaSBhbGwsPGJyPg0KSSBmdWxseSB1bmRlcnN0YW5k IHRoYXQgdGhhdCB3aGF0IEkgYW0gZ29pbmcgdG8gc2F5IGlzIG5vdCB2ZXJ5IHBvcHVsYXIsDQpi dXQ6PGJyPg0KPGJyPg0KSU1PIG9uZSBvZiB0aGUgYWR2YW50YWdlcyBvZiB0aGUgQ1ctYmFzZWQg c29sdXRpb24gaXMgdGhhdCBpdCBpcyBvcnRob2dvbmFsDQp0byB1c2FnZSAob3Igbm9uLXVzYWdl KSBvZiBQMk1QIFBXcyBmb3IgZWZmZWN0aXZlIGRlbGl2ZXJ5IG9mIEJVTiB0cmFmZmljLjxicj4N Cjxicj4NCkFub3RoZXIgYWR2YW50YWdlIGlzIHByZXNlcnZhdGlvbiBvZiBmdWxsIG1lc2ggb2Yg UDJQIFBXcyBpbiBhIFZQTFMsIGFuZCwNCmluIGEgbW9yZSBnZW5lcmljIHdheSwgbG9jYWxpemF0 aW9uIG9mIGVmZmVjdHMgb2YgY2hhbmdlcyBpbiB0aGUgUEUgY29uZmlndXJhdGlvbi48YnI+DQo8 YnI+DQpJbiBwYXJ0aWN1bGFyLCBhZGRpbmcgYSBMZWFmIEFDIHRvIGEgUEUgdGhhdCBwcmV2aW91 c2x5IGhhcyBiZWVuIG9ubHkgc3VwcG9ydGluZw0KUm9vdCBBQ3MgKG9yIHZpY2UgdmVyc2EpLCBy ZW1vdmFsIG9mIHRoZSBsYXN0IExlYWYgb3IgbGFzdCBSb290IEFDIGZyb20NCmEgUEUgdGhhdCBw cmV2aW91c2x5IGhhcyBiZWVuIHN1cHBvcnRpbmcgYSBtaXggZXRjLiBhZmZlY3Qgb25seSB0aGUg UEUNCndoZXJlIHRoaXMgb3BlcmF0aW9uIGhhcHBlbnMgYW5kIG5vdCB0aGUgcmVzdCBvZiB0aGUg UEVzLjxicj4NCjxicj4NCkFzIGZvciB0aGUgbmVlZCBmb3IgSFcgY2hhbmdlcyB0aGF0IGhhdmUg YmVlbiBtZW50aW9uZWQgYXMgYSBtYWluIGRpc2FkdmFudGFnZQ0Kb2YgdGhlIENXLWJhc2VkIGFw cHJvYWNoIC0gSSBiZWxpZXZlIGl0IHN0cm9uZ2x5IGRlcGVuZHMgb24gc3BlY2lmaWMgaW1wbGVt ZW50YXRpb25zLg0KQW5kIHNvbWUgY2hhbmdlcyBpbiB0aGUgZm9yd2FyZGluZyBwcm9jZXNzIGFy ZSByZXF1aXJlZCBpbiBhbnkgc29sdXRpb24uPGJyPg0KPGJyPg0KTXkgMmMsPGJyPg0KICZuYnNw OyAmbmJzcDsgU2FzaGE8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBb bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxmIG9mIFJvZ2VycywNCkpvc2ggW2pvc2gu cm9nZXJzQHR3Y2FibGUuY29tXTxicj4NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTgsIDIwMTIg OTo1NyBQTTxicj4NClRvOiBMdWN5IHlvbmc7IERhbmllbCBDb2huOyBTYW0gQ2FvPGJyPg0KQ2M6 IGwydnBuQGlldGYub3JnPGJyPg0KU3ViamVjdDogUmU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJv YWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj88YnI+DQo8YnI+DQpBZ2FpbiwgdGhlIFAyTVAg c2l0dWF0aW9uIHRocm93cyBtZS4gJm5ic3A7SXMgdGhpcyBzb21ldGhpbmcgdGhhdCBpcyB1c2Vk PGJyPg0KY29tbW9ubHk/PGJyPg0KPGJyPg0KSSdtIHVuZGVyIHRoZSBpbXByZXNzaW9uIHRoYXQg YWRkaW5nIFAyTVAgdG8gYW55IG1vZGVsIHJlc3VsdHMgaW4gYSBtb3JlPGJyPg0KY29tcGxleCBt b2RlbC4gJm5ic3A7V2V0aGVyIG91dHNpZGUgcy10YWcgaXMgdXNlZCB0byBkaWZmZXJlbnRpYXRl LCBvcjxicj4NCmRlZGljYXRlZCBwdydzIGFyZSB1c2VkIGZvciB0aGUgc2FtZSBwdXJwb3NlLCBp dCBzZWVtcyBib3RoIGJlY29tZSBtb3JlPGJyPg0KY29tcGxleC48YnI+DQo8YnI+DQpHaWxlJ3Mg Y29tcGFyaXNvbiBzbGlkZSBzdGlsbCBjb25jaXNlbHkgY2FwdHVyZXMgdGhlIGRpZmZlcmVuY2Vz IGJldHdlZW48YnI+DQp0aGVzZSBtZXRob2RzLCBpbiBteSBvcGluaW9uLiAmbmJzcDtJIGhhdmVu J3Qgc2VlbiBhbnkgbmV3IGlkZWFzIG9yIHRob3VnaHRzPGJyPg0KYnJvdWdodCB0byB0aGUgZ3Jv dXAgaW4gdGhlIHBhc3Qgd2VlayBvciB0d28gb24gdGhlIHN1YmplY3QuICZuYnNwO0kgd291bGQN CmhhdGU8YnI+DQpmb3IgYm90aCBwcm9wb3NlZCBtZXRob2RzIHRvIGRpZSBvbiB0aGUgdmluZSBi ZWNhdXNlIHdlIGNvdWxkbid0IGRlY2lkZTxicj4NCmJldHdlZW4gdHdvIG1ldGhvZHMgdGhhdCBo YXZlIG5vdGhpbmcgaW5oZXJlbnRseSB3cm9uZyB3aXRoIGVpdGhlci48YnI+DQo8YnI+DQotSm9z aDxicj4NCjxicj4NCjxicj4NCk9uIDQvMTgvMTIgMTo1MyBQTSwgJnF1b3Q7THVjeSB5b25nJnF1 b3Q7ICZsdDtsdWN5LnlvbmdAaHVhd2VpLmNvbSZndDsNCndyb3RlOjxicj4NCjxicj4NCiZndDtT ZW5kIHRoaXMgYWdhaW4uPGJyPg0KJmd0Ozxicj4NCiZndDtUd28gUFcgYXBwcm9hY2ggY2FuIGJl IGNvbXBsZXggdG9vIGlmIHRoZSBWUExTIGluc3RhbmNlIGZvciBFLVRyZWUNCnVzZXM8YnI+DQom Z3Q7UDJQIFBXIGZvciB1bmljYXN0IHRyYWZmaWMgYW5kIFAyTVAgUFcgZm9yIGJyb2FkY2FzdCBh bmQgdW5rbm93bjxicj4NCiZndDt1bmljYXN0IHRyYWZmaWMsIGFuZCBzb21lIFAyTVAgUFdzIGZv ciBtdWx0aWNhc3QgdHJhZmZpYy4gSXQgbWF5IGRvdWJsZTxicj4NCiZndDthbGwgb2YgdGhlbS48 YnI+DQomZ3Q7PGJyPg0KJmd0O0x1Y3k8YnI+DQomZ3Q7PGJyPg0KJmd0Oy0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPGJyPg0KJmd0O0Zyb206IERhbmllbCBDb2huIFttYWlsdG86RGFuaWVsQ0Bv cmNraXQuY29tXTxicj4NCiZndDtTZW50OiBXZWRuZXNkYXksIEFwcmlsIDE4LCAyMDEyIDE6NDIg UE08YnI+DQomZ3Q7VG86IEx1Y3kgeW9uZzsgUm9nZXJzLCBKb3NoOyBTYW0gQ2FvPGJyPg0KJmd0 O0NjOiBsMnZwbkBpZXRmLm9yZzxicj4NCiZndDtTdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0 aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPzxicj4NCiZndDs8YnI+DQomZ3Q7 SSB0aGluayB0aGUgZmlyc3Qgb3B0aW9uIGl0cyB0aGUgbmF0dXJhbCB3YXkgdG8gZ28uIEhvdyBp cyB0aGUgcHJvY2Vzc2luZzxicj4NCiZndDtpbiB0aGlzIGNhc2UgbW9yZSBjb21wbGV4Pzxicj4N CiZndDs8YnI+DQomZ3Q7VGh1bWIgdHlwZWQgLSBwbGVhc2UgYmUgdG9sZXJhbnQ8YnI+DQomZ3Q7 PGJyPg0KJmd0O0x1Y3kgeW9uZyAmbHQ7bHVjeS55b25nQGh1YXdlaS5jb20mZ3Q7IHdyb3RlOjxi cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDtTbmlwcGVkLi48YnI+DQomZ3Q7 PGJyPg0KJmd0O011bHRpLVBXIC0gT24gaW5ncmVzcyBQRSwgZnJhbWUgaXMgcGxhY2VkIG9udG8g ZWl0aGVyIGEgTGVhZi1vbmx5IFAyTVANClBXPGJyPg0KJmd0Oyhmb3IgdHJhZmZpYyBjb21pbmcg ZnJvbSBhIGxlYWYgQUMpLCBvciBvbnRvIGEgUm9vdC9MZWFmIFAyTVAgUFcgKGZvcjxicj4NCiZn dDt0cmFmZmljIGNvbWluZyBmcm9tIGEgcm9vdCBBQyk8YnI+DQomZ3Q7W1tMWV1dIE5vdCB0aGF0 IHNpbXBsZS4gWW91IGNvbnN0cnVjdCBlaXRoZXIgdHdvIFAyTVAgUFdzIHRvIGFsbCBvdGhlcjxi cj4NCiZndDtQRXMgYW5kIGxldCBlZ3Jlc3MgUEUgcGVyZm9ybWluZyBmaWx0ZXJpbmcsIG9yIGNv bnN0cnVjdCBvbmUgUDJNUCBQVw0KdG88YnI+DQomZ3Q7bGVhZi1vbmx5IFBFcyBhbmQgdHdvIFAy TVAgUFdzIHRvIHJvb3QgYW5kIGxlYWYgUEVzIGFuZCBsZXQgaW5ncmVzcw0KUEU8YnI+DQomZ3Q7 cGVyZm9ybSBmb3J3YXJkaW5nIGFuZCBmaWx0ZXJpbmcuIEJvdGggbWFrZSBub2RlIHByb2Nlc3Mg Y29tcGxleC48YnI+DQomZ3Q7PGJyPg0KJmd0O1tbTFldXSBWUExTIGlzIGJ1aWx0IHdpdGggdGhl IG1lY2hhbmlzbSB1dGlsaXppbmcgUDJQIGFuZCBQMk1QIFBXIGZvcjxicj4NCiZndDtkZWxpdmVy aW5nIHRoZSBmcmFtZXMgdG8gcmVtb3RlIFBFcy4gV2Ugc2hvdWxkIHV0aWxpemUgdGhlbSB3aXRo IHRoZTxicj4NCiZndDttaW5pbWl6ZWQgY2hhbmdlcy4gRHVhbCBWTEFOIHNvbHV0aW9uIGlzIHNp bXBsZXIgdGhhbiBEdWFsIFBXLjxicj4NCiZndDs8YnI+DQomZ3Q7UmVnYXJkcyw8YnI+DQomZ3Q7 THVjeTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0O0kgc2VlIGhvdyAyVkxBTiBpcyBzaW1w bGVyIHdoZW4gUDJNUCBQVydzIGFyZSBpbnZvbHZlZCwgSSB0aGluay4gJm5ic3A7STxicj4NCiZn dDtoYXZlbid0IGhhZCBhbnkgZmlyc3QgaGFuZCBleHBlcmllbmNlIHdpdGggUDJNUCBQVydzLCBo b3dldmVyLCBzbyBkb24ndDxicj4NCiZndDtmZWVsIHRlcnJpYmx5IHN0cm9uZyBhYm91dCB0aGlz IG9iamVjdGlvbi4gJm5ic3A7SXMgdGhpcyBhIHJlYWwgcHJvYmxlbQ0KZm9yPGJyPg0KJmd0O290 aGVycyAobm93IG9yIGluIHRoZSBmdXR1cmUpLCBvciBpcyB0aGlzIG9iamVjdGlvbiBpbiB0aGUg d2VlZHM/PGJyPg0KJmd0Ozxicj4NCiZndDtJJ20gbm90IHN1cmUgdGhlICdhZGRpdGlvbmFsIGNv bXBsZXhpdHknIGlzIG5vdGFibGUsIG9yIGV2ZW4gcmVsZXZhbnQuDQombmJzcDtJPGJyPg0KJmd0 O2VuY291cmFnZSBvdGhlcnMgdG8gc3BlYWsgdXAgaWYgdGhleSBkaXNhZ3JlZSwgYXMgUDJNUCBQ VyBpcyBvbmx5PGJyPg0KJmd0O2NvbmNlcHR1YWwgdG8gbWUsIGFuZCBJIGFtIHVuZmFtaWxpYXIg d2l0aCByZWFsLWxpZmUgdXNlIGNhc2VzIGZvcg0KaXQuPGJyPg0KJmd0Ozxicj4NCiZndDtUaGFu a3MsPGJyPg0KJmd0O0pvc2g8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 T24gNC8xOC8xMiAxMDozMCBBTSwgJnF1b3Q7THVjeSB5b25nJnF1b3Q7ICZsdDtsdWN5LnlvbmdA aHVhd2VpLmNvbSZndDsNCndyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0O1BsZWFzZSBzZWUg aW5saW5lLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDstLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj4NCiZndDsmZ3Q7RnJvbTogU2FtIENhbyBbbWFpbHRvOnl1cXVuLmNhb0BnbWFpbC5j b21dPGJyPg0KJmd0OyZndDtTZW50OiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiA3OjE0IEFNPGJy Pg0KJmd0OyZndDtUbzogJ0RhbmllbCBDb2huJzsgTHVjeSB5b25nOyAnUm9nZXJzLCBKb3NoJzsg J0hlbmRlcmlja3gsIFdpbQ0KKFdpbSknOzxicj4NCiZndDsmZ3Q7Z2lsZXMuaGVyb25AZ21haWwu Y29tOyBzaW1vbi5kZWxvcmRAZ21haWwuY29tOzxicj4NCiZndDsmZ3Q7QWxleGFuZGVyLlZhaW5z aHRlaW5AZWNpdGVsZS5jb208YnI+DQomZ3Q7Jmd0O0NjOiBsMnZwbkBpZXRmLm9yZzsgVmxhZGlt aXIuS2xlaW5lckBlY2l0ZWxlLmNvbTs8YnI+DQomZ3Q7Jmd0O0FuZHJldy5TZXJnZWV2QGVjaXRl bGUuY29tOyBJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbTs8YnI+DQomZ3Q7Jmd0O01pc2hhZWwuV2V4 bGVyQGVjaXRlbGUuY29tOyBSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbTxicj4NCiZndDsmZ3Q7U3Vi amVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1 dGlvbj88YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7WWVzLCAyIHB3cyBhcmUgb25seSBuZWVk ZWQgYmV0d2VlbiBwZXMgd2l0aCBib3RoIHJvb3QgYW5kIGxlYWYNCmFjcyBhZnRlcjxicj4NCiZn dDsmZ3Q7aW1wcm92aW5nIER1YWwtUFcgYXBwcm9hY2guIElmIGNvbnNpZGVyIFAyTVAsIER1YWwt UFcgYXBwcm9hY2gNCnNldHVwIDI8YnI+DQomZ3Q7Jmd0O1AyTVA8YnI+DQomZ3Q7Jmd0O1BXcyBp ZiBuZWVkLiBUaGVyZSBpcyBubyBkaWZmZXJlbmNlIGJldHdlZW4gUDJNUCBvciBub3JtYWwgUFcg c2V0dXAuDQpCdXQsPGJyPg0KJmd0OyZndDtjYW4gTGVhZi1BQ3MgYmUgYm91bmQgdG8gUm9vdCBQ RSBvZiBQMk1QIFBXPzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtbW0xZXV0gTm8sIGl0IG1h a2VzIGNvbXBsZXggaW4gc2V0dGluZyB1cCBQMk1QIFBXLiBTaG91bGQgYSBQRQ0Kd2l0aCBib3Ro PGJyPg0KJmd0OyZndDtyb290IGFuZCBsZWFmIEFDcyBzZXQgdXAgdHdvIG9yIG9uZSBQMk1QIFBX IHRvIG90aGVyIFBFcyAoc29tZQ0KUEUgaGF2ZTxicj4NCiZndDsmZ3Q7Ym90aCByb290IGFuZCBs ZWFmIEFDIGFuZCBzb21lIG9ubHkgaGF2ZSBsZWFmIEFDcyk/PGJyPg0KJmd0OyZndDtSZWdhcmRz LDxicj4NCiZndDsmZ3Q7THVjeTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtSZWdhcmRzLDxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtZdXF1biAoU2FtKSBDYW88YnI+DQomZ3Q7Jmd0O0Ut bWFpbDogWXVxdW4uY2FvQGdtYWlsLmNvbTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0Oy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDtGcm9tOiBE YW5pZWwgQ29obiBbbWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbV08YnI+DQomZ3Q7Jmd0O1NlbnQ6 IFR1ZXNkYXksIEFwcmlsIDE3LCAyMDEyIDQ6NTYgUE08YnI+DQomZ3Q7Jmd0O1RvOiBMdWN5IHlv bmc7IFJvZ2VycywgSm9zaDsgSGVuZGVyaWNreCwgV2ltIChXaW0pOzxicj4NCiZndDsmZ3Q7Z2ls ZXMuaGVyb25AZ21haWwuY29tOzxicj4NCiZndDsmZ3Q7c2ltb24uZGVsb3JkQGdtYWlsLmNvbTsg QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb207IFNhbSBDYW88YnI+DQomZ3Q7Jmd0O0Nj OiBsMnZwbkBpZXRmLm9yZzsgVmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbTs8YnI+DQomZ3Q7 Jmd0O0FuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tOyBJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbTs8 YnI+DQomZ3Q7Jmd0O01pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tOyBSb3RlbS5Db2hlbkBlY2l0 ZWxlLmNvbTxicj4NCiZndDsmZ3Q7U3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJv YWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj88YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 QWRkaW5nIFNhbSAoYXMgbDJ2cG5AIGlzIGhvbGRpbmcgbWVzc2FnZXMpPGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0O0RDPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Oy0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDtGcm9tOiBMdWN5IHlvbmcgW21haWx0bzpsdWN5Lnlv bmdAaHVhd2VpLmNvbV08YnI+DQomZ3Q7Jmd0O1NlbnQ6IFR1ZXNkYXksIEFwcmlsIDE3LCAyMDEy IDEyOjM5IEFNPGJyPg0KJmd0OyZndDtUbzogRGFuaWVsIENvaG47IFJvZ2VycywgSm9zaDsgSGVu ZGVyaWNreCwgV2ltIChXaW0pOzxicj4NCiZndDsmZ3Q7Z2lsZXMuaGVyb25AZ21haWwuY29tOyBz aW1vbi5kZWxvcmRAZ21haWwuY29tOzxicj4NCiZndDsmZ3Q7QWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb208YnI+DQomZ3Q7Jmd0O0NjOiBsMnZwbkBpZXRmLm9yZzsgVmxhZGltaXIuS2xl aW5lckBlY2l0ZWxlLmNvbTs8YnI+DQomZ3Q7Jmd0O0FuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29t OyBJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbTs8YnI+DQomZ3Q7Jmd0O01pc2hhZWwuV2V4bGVyQGVj aXRlbGUuY29tOyBSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbTxicj4NCiZndDsmZ3Q7U3ViamVjdDog UkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj88 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtTbmlwcGVkLDxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDtBcyB3ZSBkaXNjdXNzZWQgZXh0ZW5zaXZlbHkgaW4gdGhlIGxp c3QsIGFuZCBhcyByZWZsZWN0ZWQgaW4gZ2lsZXM8YnI+DQomZ3Q7Jmd0O3NsaWRlLCAyIHB3cyBh cmUgb25seSBuZWVkZWQgYmV0d2VlbiBwZXMgd2l0aCBib3RoIHJvb3QgYW5kIGxlYWYNCmFjcyw8 YnI+DQomZ3Q7Jmd0O3doaWNoIHdpbGwgdHlwaWNhbGx5IGJlIGEgc21hbGwgbWlub3JpdHkuPGJy Pg0KJmd0OyZndDtbW0xZXV0gRG9uJ3Qga25vdyBpZiB0aGUgYXNzdW1wdGlvbiBpcyB0cnVlLiBF dmVuIGl0IGlzIHRoZSBjYXNlLA0KYm90aDxicj4NCiZndDsmZ3Q7YXBwcm9hY2hlcyBjYW4gYmVu ZWZpdCBmcm9tIGl0LiBJIHdhcyBvZmYgZm9yIGEgd2hpbGUgYW5kIGNhcHR1cmVzDQpzb21lPGJy Pg0KJmd0OyZndDtkaXNjdXNzaW9ucyBub3cuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0O0Fs c28gYXMgcGVyIGdpbGVzIHNsaWRlLCBkdWFsIHZsYW4gY2FuIGhhdmUgc2NhbGFiaWxpdHkgaXNz dWVzDQpkdWUgdG88YnI+DQomZ3Q7Jmd0O2FkZGl0aW9uYWwgbG9va3VwIGFuZCBkb3VibGUgdXNl IG9mIHZsYW5zIGluIGludGVybmFsIGVtdWxhdGVkDQpsYW48YnI+DQomZ3Q7Jmd0O2ludGVyZmFj ZS4gQWxzbyB0aGVyZSBhcmUgcG90ZW50aWFsIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXNzdWVz DQp3aXRoPGJyPg0KJmd0OyZndDtzaWxpY29uIHRoYXQgZG9lc24ndCBzdXBwb3J0IHZsYW4gbWFw cGluZy48YnI+DQomZ3Q7Jmd0O1tbTFldXSBJIHdhcyBub3QgaW4gSUVURjgzIG1lZXRpbmcgYW5k IHdhaXQgb24gdGhlIG1lZXRpbmcgbWludXRlcy4NCkkgYW08YnI+DQomZ3Q7Jmd0O25vdCBjbGVh ciBvbiBhbGwgdGhlIGlzc3Vlcy4gQ291bGQgeW91IGJlIG1vcmUgc3BlY2lmaWM/IEFzIEkgbWVu dGlvbmVkPGJyPg0KJmd0OyZndDtpbiBiZWxvdywgdHdvIFBXIGFwcHJvYWNoIG1ha2VzIFZQTFMg dHJhbnNwb3J0IGNvbnN0cnVjdGlvbiBhbmQNCnBhY2tldDxicj4NCiZndDsmZ3Q7Zm9yd2FyZGlu ZyBtb3JlIGNvbXBsZXgsIEkgY2FuIHNlZSBwb3RlbnRpYWwgYmFja3dhcmQgY29tcGF0aWJpbGl0 eTxicj4NCiZndDsmZ3Q7aXNzdWVzIHdpdGggMiBQVyBzb2x1dGlvbi48YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7UmVnYXJkcyw8YnI+DQomZ3Q7Jmd0O0x1Y3k8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7UmVnYXJkcyw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7RGFuaWVsPGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0O1RodW1iIHR5cGVkIC0gcGxlYXNlIGJlIHRvbGVyYW50PGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0O0x1Y3kgeW9uZyAmbHQ7bHVjeS55b25nQGh1YXdlaS5j b20mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtJbiBteSBtaW5kLCB0aGUg VkxBTiBhcHByb2FjaCBtZWFucyBkdWFsIHZsYW4gbWV0aG9kLjxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDtUaGUgbWFpbiBjb25jZXJuIGZvciBDVyBhcHByb2FjaCBpcyBoYXJkd2FyZSBzdXBw b3J0Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtUd28gUFcgYXBwcm9hY2ggY2FuIGJlIGNv bXBsZXggdG9vIGlmIHRoZSBWUExTIGluc3RhbmNlIGZvciBFLVRyZWUNCnVzZXM8YnI+DQomZ3Q7 Jmd0O1AyUCBQVyBmb3IgdW5pY2FzdCB0cmFmZmljIGFuZCBQMk1QIFBXIGZvciBicm9hZGNhc3Qg YW5kIHVua25vd24NCnVuaWNhc3Q8YnI+DQomZ3Q7Jmd0O3RyYWZmaWMsIGFuZCBzb21lIFAyTVAg UFdzIGZvciBtdWx0aWNhc3QgdHJhZmZpYy4gSXQgbWF5IGRvdWJsZQ0KYWxsIG9mPGJyPg0KJmd0 OyZndDt0aGVtLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtFLXRyZWUgaXMgYW4gRXRoZXJu ZXQgc2VydmljZSBhbmQgdGhlcmUgaXMgYWxyZWFkeSBWTEFOIGJhc2VkIHNvbHV0aW9uPGJyPg0K Jmd0OyZndDtpbiBJRUVFLCBjYW4gd2UganVzdCB1dGlsaXplIGl0IHdpdGhvdXQgY29tcGxpY2F0 aW5nIFZQTFMgdHJhbnNwb3J0PGJyPg0KJmd0OyZndDtjb25zdHJ1Y3Rpb24/IFRoaXMgYWxzbyBt YWtlcyBpbnRlcndvcmtpbmcgd2l0aCBFdGggb25seSBuZXR3b3JrDQplYXNpZXIuPGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0O0NoZWVycyw8YnI+DQomZ3Q7Jmd0O0x1Y3k8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0O0Zy b206IFJvZ2VycywgSm9zaCBbbWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29tXTxicj4NCiZn dDsmZ3Q7U2VudDogTW9uZGF5LCBBcHJpbCAxNiwgMjAxMiA4OjM1IEFNPGJyPg0KJmd0OyZndDtU bzogTHVjeSB5b25nOyBIZW5kZXJpY2t4LCBXaW0gKFdpbSk7ICdnaWxlcy5oZXJvbkBnbWFpbC5j b20nOzxicj4NCiZndDsmZ3Q7J3NpbW9uLmRlbG9yZEBnbWFpbC5jb20nOyAnQWxleGFuZGVyLlZh aW5zaHRlaW5AZWNpdGVsZS5jb20nPGJyPg0KJmd0OyZndDtDYzogJ2wydnBuQGlldGYub3JnJzsg J1ZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb20nOzxicj4NCiZndDsmZ3Q7J0FuZHJldy5TZXJn ZWV2QGVjaXRlbGUuY29tJzsgJ0lkYW4uS2FzcGl0QGVjaXRlbGUuY29tJzs8YnI+DQomZ3Q7Jmd0 OydNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbSc7ICdSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbSc8 YnI+DQomZ3Q7Jmd0O1N1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRv IHRoZSBFLVRyZWUgc29sdXRpb24/PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0O0kgYmVsaWV2 ZSB0aGUgaW5pdGlhbCBxdWVzdGlvbiB3YXMgaW4gcmVnYXJkIHRvIHRoZSBDVyBtZXRob2QuDQom bmJzcDtBcmUgeW91PGJyPg0KJmd0OyZndDtzYXlpbmcgdGhhdCB5b3Ugbm8gbG9uZ2VyIGFyZSBp bnRlcmVzdGVkIGluIHRoYXQgbWV0aG9kIGluIHByZWZlcmVuY2UNCm9mPGJyPg0KJmd0OyZndDt0 aGUgZHVhbCB2bGFuIG1ldGhvZD88YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0O0x1Y3kgeW9uZyAmbHQ7bHVjeS55b25nQGh1YXdlaS5jb20mZ3Q7 IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0O0FncmVlIHdp dGggV2ltLiBWTEFOIGFwcHJvYWNoIGlzIHRoZSBiZXN0IHNvbHV0aW9uIGZvciBFLVRyZWUuPGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0O0x1Y3k8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0O0Zyb206IGwydnBuLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbg0KQmVoYWxmPGJy Pg0KJmd0OyZndDtPZiBIZW5kZXJpY2t4LCBXaW0gKFdpbSk8YnI+DQomZ3Q7Jmd0O1NlbnQ6IFRo dXJzZGF5LCBBcHJpbCAxMiwgMjAxMiAyOjAzIEFNPGJyPg0KJmd0OyZndDtUbzogJ2dpbGVzLmhl cm9uQGdtYWlsLmNvbSc7ICdzaW1vbi5kZWxvcmRAZ21haWwuY29tJzs8YnI+DQomZ3Q7Jmd0OydB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbSc8YnI+DQomZ3Q7Jmd0O0NjOiAnbDJ2cG5A aWV0Zi5vcmcnOyAnVmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbSc7PGJyPg0KJmd0OyZndDsn QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb20nOyAnSWRhbi5LYXNwaXRAZWNpdGVsZS5jb20nOzxi cj4NCiZndDsmZ3Q7J01pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tJzsgJ1JvdGVtLkNvaGVuQGVj aXRlbGUuY29tJzxicj4NCiZndDsmZ3Q7U3ViamVjdDogUmU6IFRoZSBzdGF0dXMgb2YgdGhlIGFw cHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj88YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7VGhlIHZsYW4gYXBwcm9hY2ggaXMgc3VwZXJpb3IgYXMgaXQgYWxzbyB3b3JrcyBmb3IgZXRo IG9ubHkgbmV0d29ya3MsPGJyPg0KJmd0OyZndDtldGMuIE9uIHRvcCBzb21lIHZlbmRvcnMgaW5k aWNhdGUgaHcgaXNzdWVzIHdpdGggdGhlIGN3IGFwcHJvYWNoLg0KQXM8YnI+DQomZ3Q7Jmd0O3N1 Y2ggd2UgaGF2ZSBkcm9wcGVkIG1vcmUgb3IgbGVzcyB0aGUgY3cgYXBwcm9hY2guPGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0O0NoZWVycyw8YnI+DQomZ3Q7Jmd0O1dpbTxicj4NCiZndDsmZ3Q7 X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0O3NlbnQgZnJvbSBibGFja2JlcnJ5PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Oy0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08YnI+DQom Z3Q7Jmd0O0Zyb206IEdpbGVzIEhlcm9uIFttYWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tXTxi cj4NCiZndDsmZ3Q7U2VudDogVGh1cnNkYXksIEFwcmlsIDEyLCAyMDEyIDA4OjIyIEFNPGJyPg0K Jmd0OyZndDtUbzogU2ltb24gRGVsb3JkICZsdDtzaW1vbi5kZWxvcmRAZ21haWwuY29tJmd0Ozsg QWxleGFuZGVyIFZhaW5zaHRlaW48YnI+DQomZ3Q7Jmd0OyZsdDtBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbSZndDs8YnI+DQomZ3Q7Jmd0O0NjOiBsMnZwbkBpZXRmLm9yZyAmbHQ7bDJ2 cG5AaWV0Zi5vcmcmZ3Q7OyBWbGFkaW1pciBLbGVpbmVyPGJyPg0KJmd0OyZndDsmbHQ7VmxhZGlt aXIuS2xlaW5lckBlY2l0ZWxlLmNvbSZndDs7IEFuZHJldyBTZXJnZWV2PGJyPg0KJmd0OyZndDsm bHQ7QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb20mZ3Q7OyBJZGFuIEthc3BpdCAmbHQ7SWRhbi5L YXNwaXRAZWNpdGVsZS5jb20mZ3Q7Ozxicj4NCiZndDsmZ3Q7TWlzaGFlbCBXZXhsZXIgJmx0O01p c2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tJmd0OzsgUm90ZW0gQ29oZW48YnI+DQomZ3Q7Jmd0OyZs dDtSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbSZndDs8YnI+DQomZ3Q7Jmd0O1N1YmplY3Q6IFJlOiBU aGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0O1NvcnJ5IC0gdGhlICZxdW90O2Fub255bW91cyBwcmVzZW50 YXRpb24mcXVvdDsgd2FzIG1pbmUuICZuYnNwO0kNCnNob3VsZCBwb3NzaWJseSBoYXZlPGJyPg0K Jmd0OyZndDtwdXQgaW4gYSB0aGlyZCBjb2x1bW4gb24gdGhlIENXIGFwcHJvYWNoLiAmbmJzcDtB bmQgaG9wZWZ1bGx5IHRoZQ0KbWludXRlczxicj4NCiZndDsmZ3Q7d2lsbCBiZSBwb3N0ZWQgc29v bi48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7V2UgaGFkIHZhcmlvdXMgZGlzY3Vzc2lvbnMs IGFzIFNpbW9uIHN0YXRlZCwgYW5kIGNvbnNlbnN1cyBzZWVtZWQNCnRvIGJlPGJyPg0KJmd0OyZn dDtmb3JtaW5nIGFyb3VuZCB0aGUgdHdvIGFsdGVybmF0aXZlcyBvZiB0d28gUFdFcyBvciB0d28g VkxBTnMuICZuYnNwO0kNCmJlbGlldmU8YnI+DQomZ3Q7Jmd0O3RocmVlIG9mIHRoZSBhdXRob3Jz IG9mIHRoZSBDVyBhcHByb2FjaCBhcmUgYWxzbyBhdXRob3JzIG9mIHRoZQ0KdHdvIFZMQU48YnI+ DQomZ3Q7Jmd0O2FwcHJvYWNoIGFuZCBvbmUgaXMgYWxzbyBhbiBhdXRob3Igb2YgdGhlIHR3byBQ V0UgYXBwcm9hY2guIFNvDQpwZXJoYXBzPGJyPg0KJmd0OyZndDtpdCdzIGJlc3QgdG8gbGV0IHRo b3NlIGZvdXIgaW5kaXZpZHVhbHMgc2F5IHdoaWNoIGFwcHJvYWNoIHRoZXkNCnByZWZlcjxicj4N CiZndDsmZ3Q7YW5kIHdoeT88YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7R2lsZXM8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7T24gMTAvMDQvMjAxMiAwMDo0NSwgJnF1b3Q7U2ltb24gRGVs b3JkJnF1b3Q7ICZsdDtzaW1vbi5kZWxvcmRAZ21haWwuY29tJmd0Ow0Kd3JvdGU6PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgSGkgQWxleGFuZGVyLDxicj4NCiZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyBZb3UgYXJlIHJpZ2h0LCBubyBkaXNjdXNzaW9uIG9uIHRoZSBXRyBt YWlsaW5nIGxpc3QgcmVjZW50bHksDQpidXQ8YnI+DQomZ3Q7Jmd0OyZndDsgdGhlcmUgaGF2ZSBi ZWVuIHN1YnN0YW50aWFsIGRpc2N1c3Npb25zIGFtb25nIHRoZSBhdXRob3JzDQpvZiB2YXJpb3Vz PGJyPg0KJmd0OyZndDsmZ3Q7IHNvbHV0aW9uIGRyYWZ0cyBvZmYgdGhlIG1haWxpbmcgbGlzdC4g QXMgZmFyIGFzIEkga25vdywgbm8NCmNvbnNlbnN1czxicj4NCiZndDsmZ3Q7Jmd0OyB5ZXQgYmVm b3JlIGlldGY4Mywgbm90IHN1cmUgdGhlIHByb2dyZXNzIGluIHRoZSBQYXJpcyBXRyBtZWV0aW5n Lg0KSTxicj4NCiZndDsmZ3Q7Jmd0OyB0aGluayB0aGUgQ1cgYXBwcm9hY2ggaGFzIG5vdCBiZWVu IHJlamVjdGVkIGJ5IHRoZSBXRyB5ZXQsDQpvciB0aGUgV0c8YnI+DQomZ3Q7Jmd0OyZndDsgaGFz IG5vdCB5ZXQgZGVjaWRlZCBvbiB3aGljaCBvbmUgdG8gYWRvcHQuPGJyPg0KJmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7IFNpbW9uPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7IDIwMTIvNC84IEFsZXhhbmRlciBWYWluc2h0ZWluICZsdDtBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbSZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 ICZuYnNwO0hpIGFsbCw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyBVbmZvcnR1bmF0ZWx5IEkgaGF2ZSBub3QgYmVlbiBhYmxlIHRvIGF0dGVuZCB0aGUgUGFyaXMN CklFVEYuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgSG93ZXZl ciwgbG9va2luZyB1cCB0aGUgTDJWUE4gcHJvY2VlZGluZ3MsIEkndmUgZm91bmQNCmEgc2hvcnQ8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGFub255bW91cyBwcmVzZW50YXRpb24gY2FsbGVkICZxdW90 O0UtVHJlZSBVcGRhdGUmcXVvdDsNCiZuYnNwOyg8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGh0dHA6 Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODMvc2xpZGVzL3NsaWRlcy04My1sMnZwbi0xLnBw dHgpLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgVGhpcyBwcmVzZW50YXRpb24gZGlzY3Vzc2VzIHRo ZSBkaWZmZXJlbmNlcyBvZiB0aGUgRS1UcmVlDQphcHByb2FjaGVzPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyBiYXNlZCBvbiBkZWRpY2F0ZWQgVkxBTnMgKGFzIGluPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNhby1sMnZwbi12cGxzLWV0 cmVlLz9pbmNsdWRlX3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGV4dD0xKSBhbmQgbXVsdGlwbGUg UFdzIGJldHdlZW4gdGhlIFBFcyAoYXMgaW48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmFtLWwydnBuLWV0cmVlLW11bHRpcGxlLXB3 Lz9pbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgY2x1ZGVfdGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 IHh0PTEpPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBhbmQgY29tcGxldGVseSBpZ25vcmVzIHRoZSBz b2x1dGlvbiBiYXNlZCBvbiB1c2FnZSBvZg0KdGhlIENXIGluIHRoZTxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsgUFdzIGNvbm5lY3RpbmcgdGhlIFBFcyAoYXMgaW48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta2V5LWwydnBuLXZwbHMtZXRy ZWUvP2luY2x1ZGVfdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgZXh0PTE8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7ICkuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBUaGUgTWludXRlcyBvZiB0 aGUgUGFyaXMgTDJWUE4gc2Vzc2lvbiBhcmUgbm90IHlldCBhdmFpbGFibGUsDQpidXQgSTxicj4N CiZndDsmZ3Q7Jmd0OyZndDsgd29uZGVyIHdoZXRoZXIgdGhlIFdHIGhhcyB0YWtlbiBhIGRlY2lz aW9uIHRvIHJlamVjdCB0aGUNCmFwcHJvYWNoPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBiYXNlZCBv biB0aGUgQ1cgdXNhZ2U/IEkgZG8gbm90IHJlbWVtYmVyIGFueSByZWNlbnQgZGlzY3Vzc2lvbg0K b2Y8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHRoaXMgdG9waWMgb24gdGhlIFdHIG1haWxpbmcgbGlz dC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFJlZ2FyZHMsIGFuZCBsb3RzIG9mIHRo YW5rcyBpbiBhZHZhbmNlLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7IFNhc2hhPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5k ZWQgZm9yIHRoZSByZWNpcGllbnQgb25seQ0KYW5kIGNvbnRhaW5zPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyBpbmZvcm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBw cm9wcmlldGFyeQ0KdG8gRUNJPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFRl bGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLA0K cGxlYXNlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBv ciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUNCm9yaWdpbmFsIGFuZDxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsgYWxsIGNvcGllcyB0aGVyZW9mLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDtUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBt YXkgY29udGFpbiBUaW1lIFdhcm5lcg0KQ2FibGU8YnI+DQomZ3Q7Jmd0O3Byb3ByaWV0YXJ5IGlu Zm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yDQpzdWJqZWN0 PGJyPg0KJmd0OyZndDt0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxl LiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZDxicj4NCiZndDsmZ3Q7c29sZWx5IGZvciB0aGUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuPGJy Pg0KJmd0OyZndDtJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMg RS1tYWlsLCB5b3UgYXJlIGhlcmVieTxicj4NCiZndDsmZ3Q7bm90aWZpZWQgdGhhdCBhbnkgZGlz c2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24NCnRha2VuPGJyPg0K Jmd0OyZndDtpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRv IHRoaXMgRS1tYWlsIGlzPGJyPg0KJmd0OyZndDtzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkg YmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXM8YnI+DQomZ3Q7Jmd0O0UtbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJt YW5lbnRseTxicj4NCiZndDsmZ3Q7ZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2Yg dGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0O1RoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1h eSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlPGJyPg0KJmd0O3Byb3ByaWV0YXJ5IGluZm9ybWF0 aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QNCnRvPGJy Pg0KJmd0O2NvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1t YWlsIGlzIGludGVuZGVkIHNvbGVseTxicj4NCiZndDtmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZp ZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZg0KeW91PGJyPg0KJmd0 O2FyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBo ZXJlYnkgbm90aWZpZWQ8YnI+DQomZ3Q7dGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0 aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW48YnI+DQomZ3Q7cmVsYXRpb24gdG8gdGhl IGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseTxi cj4NCiZndDtwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgRS1tYWlsIGluPGJyPg0KJmd0O2Vycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZQ0KdGhlPGJyPg0KJmd0O29yaWdp bmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Ljxicj4NCjxi cj4NCjxicj4NClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5DQppbmZvcm1hdGlvbiwgd2hpY2ggaXMg cHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodA0KYmVsb25n aW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkg Zm9yIHRoZQ0KdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBh ZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90DQp0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMg RS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueQ0KZGlzc2VtaW5hdGlvbiwg ZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhl DQpjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkg cHJvaGliaXRlZCBhbmQgbWF5DQpiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlDQpzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mDQp0aGlz IEUtbWFpbCBhbmQgYW55IHByaW50b3V0Ljxicj4NClRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50 ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24NCndo aWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBU ZWxlY29tLiBJZiB5b3UNCmhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3Is IHBsZWFzZSBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZQ0Kb3IgZmF4LCBhbmQgdGhlbiBkZWxl dGUgdGhlIG9yaWdpbmFsIGFuZCBhbGwgY29waWVzIHRoZXJlb2YuPGJyPg0KVGhpcyBlLW1haWwg bWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucyBp bmZvcm1hdGlvbg0Kd2hpY2ggaXMgQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJp ZXRhcnkgdG8gRUNJIFRlbGVjb20uIElmIHlvdQ0KaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlz c2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lDQpvciBmYXgs IGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFsbCBjb3BpZXMgdGhlcmVvZi48YnI+ DQo8YnI+DQo8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCg== --=_alternative 00285D25482579E5_=-- From lizhong.jin@zte.com.cn Thu Apr 19 00:22:07 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983E711E8076 for ; Thu, 19 Apr 2012 00:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.249 X-Spam-Level: X-Spam-Status: No, score=-101.249 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 wcdvl3P2g7mN for ; Thu, 19 Apr 2012 00:22:03 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 58CC911E8085 for ; Thu, 19 Apr 2012 00:22:02 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 28620577109098; Thu, 19 Apr 2012 14:42:28 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 48927.4531525686; Thu, 19 Apr 2012 15:21:46 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q3J7LluQ078556; Thu, 19 Apr 2012 15:21:47 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: lucy.yong@huawei.com Subject: Re: The status of the approaches to the E-Tree solution? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Thu, 19 Apr 2012 15:21:25 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-19 15:21:50, Serialize complete at 2012-04-19 15:21:50 Content-Type: multipart/alternative; boundary="=_alternative 002870FE482579E5_=" X-MAIL: mse02.zte.com.cn q3J7LluQ078556 Cc: l2vpn@ietf.org, yuqun.cao@gmail.com X-BeenThere: l2vpn@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, 19 Apr 2012 07:22:07 -0000 This is a multipart message in MIME format. --=_alternative 002870FE482579E5_= Content-Type: text/plain; charset="US-ASCII" [snipped...] > Yes, 2 pws are only needed between pes with both root and leaf acs after > improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 P2MP > PWs if need. There is no difference between P2MP or normal PW setup. But, > can Leaf-ACs be bound to Root PE of P2MP PW? > > [[LY]] No, it makes complex in setting up P2MP PW. Should a PE with > both root and leaf ACs set up two or one P2MP PW to other PEs (some > PE have both root and leaf AC and some only have leaf ACs)? > Regards, > Lucy [Lizhong] a bit arbitrary to say "complex" here. Both have PROS and CONS. If 2-PW approach uses two P2MP PW, the BUM traffic from leaf would be only to root, and BUM traffic from root would be only to leaf. While if 2-VLAN approach uses only one P2MP PW, the BUM traffic from leaf would be also to other leaf only nodes, and filtered at egress node, which wastes the traffic bandwidth in the network. Thanks Lizhong > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Tuesday, April 17, 2012 4:56 PM > To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); giles.heron@gmail.com; > simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao > Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > Subject: RE: The status of the approaches to the E-Tree solution? > > Adding Sam (as l2vpn@ is holding messages) > > DC > > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Tuesday, April 17, 2012 12:39 AM > To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); > giles.heron@gmail.com; simon.delord@gmail.com; > Alexander.Vainshtein@ecitele.com > Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > Subject: RE: The status of the approaches to the E-Tree solution? > > > Snipped, > > As we discussed extensively in the list, and as reflected in giles > slide, 2 pws are only needed between pes with both root and leaf acs, > which will typically be a small minority. > [[LY]] Don't know if the assumption is true. Even it is the case, both > approaches can benefit from it. I was off for a while and captures some > discussions now. > > Also as per giles slide, dual vlan can have scalability issues due to > additional lookup and double use of vlans in internal emulated lan > interface. Also there are potential backward compatibility issues with > silicon that doesn't support vlan mapping. > [[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am > not clear on all the issues. Could you be more specific? As I mentioned > in below, two PW approach makes VPLS transport construction and packet > forwarding more complex, I can see potential backward compatibility > issues with 2 PW solution. > > Regards, > Lucy > > Regards, > > Daniel > > Thumb typed - please be tolerant > > Lucy yong wrote: > > In my mind, the VLAN approach means dual vlan method. > > The main concern for CW approach is hardware support. > > Two PW approach can be complex too if the VPLS instance for E-Tree uses > P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast > traffic, and some P2MP PWs for multicast traffic. It may double all of > them. > > E-tree is an Ethernet service and there is already VLAN based solution > in IEEE, can we just utilize it without complicating VPLS transport > construction? This also makes interworking with Eth only network easier. > > Cheers, > Lucy > > -----Original Message----- > From: Rogers, Josh [mailto:josh.rogers@twcable.com] > Sent: Monday, April 16, 2012 8:35 AM > To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; > 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' > Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; > 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; > 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' > Subject: RE: The status of the approaches to the E-Tree solution? > > I believe the initial question was in regard to the CW method. Are you > saying that you no longer are interested in that method in preference of > the dual vlan method? > > > > Lucy yong wrote: > > > Agree with Wim. VLAN approach is the best solution for E-Tree. > > Lucy > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Henderickx, Wim (Wim) > Sent: Thursday, April 12, 2012 2:03 AM > To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; > 'Alexander.Vainshtein@ecitele.com' > Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; > 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; > 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' > Subject: Re: The status of the approaches to the E-Tree solution? > > The vlan approach is superior as it also works for eth only networks, > etc. On top some vendors indicate hw issues with the cw approach. As > such we have dropped more or less the cw approach. > > Cheers, > Wim > _________________ > sent from blackberry > > ----- Original Message ----- > From: Giles Heron [mailto:giles.heron@gmail.com] > Sent: Thursday, April 12, 2012 08:22 AM > To: Simon Delord ; Alexander Vainshtein > > Cc: l2vpn@ietf.org ; Vladimir Kleiner > ; Andrew Sergeev > ; Idan Kaspit ; > Mishael Wexler ; Rotem Cohen > > Subject: Re: The status of the approaches to the E-Tree solution? > > Sorry - the "anonymous presentation" was mine. I should possibly have > put in a third column on the CW approach. And hopefully the minutes > will be posted soon. > > We had various discussions, as Simon stated, and consensus seemed to be > forming around the two alternatives of two PWEs or two VLANs. I believe > three of the authors of the CW approach are also authors of the two VLAN > approach and one is also an author of the two PWE approach. So perhaps > it's best to let those four individuals say which approach they prefer > and why? > > Giles > > On 10/04/2012 00:45, "Simon Delord" wrote: > > > Hi Alexander, > > > > You are right, no discussion on the WG mailing list recently, but > > there have been substantial discussions among the authors of various > > solution drafts off the mailing list. As far as I know, no consensus > > yet before ietf83, not sure the progress in the Paris WG meeting. I > > think the CW approach has not been rejected by the WG yet, or the WG > > has not yet decided on which one to adopt. > > > > Simon > > > > 2012/4/8 Alexander Vainshtein > > > >> Hi all, > >> > >> Unfortunately I have not been able to attend the Paris IETF. > >> > >> However, looking up the L2VPN proceedings, I've found a short > >> anonymous presentation called "E-Tree Update" ( > >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). > >> This presentation discusses the differences of the E-Tree approaches > >> based on dedicated VLANs (as in > >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t > >> ext=1) and multiple PWs between the PEs (as in > >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in > >> clude_te > >> xt=1) > >> and completely ignores the solution based on usage of the CW in the > >> PWs connecting the PEs (as in > >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t > >> ext=1 > >> ). > >> > >> > >> > >> The Minutes of the Paris L2VPN session are not yet available, but I > >> wonder whether the WG has taken a decision to reject the approach > >> based on the CW usage? I do not remember any recent discussion of > >> this topic on the WG mailing list. > >> > >> > >> > >> Regards, and lots of thanks in advance, > >> > >> Sasha > >> > >> > >> > >> > >> > >> This e-mail message is intended for the recipient only and contains > >> information which is CONFIDENTIAL and which may be proprietary to ECI > > >> Telecom. If you have received this transmission in error, please > >> inform us by e-mail, phone or fax, and then delete the original and > >> all copies thereof. > >> > > > > --=_alternative 002870FE482579E5_= Content-Type: text/html; charset="US-ASCII"
[snipped...]
> Yes, 2 pws are only needed between pes with both root and leaf acs after
> improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 P2MP
> PWs if need. There is no difference between P2MP or normal PW setup. But,
> can Leaf-ACs be bound to Root PE of P2MP PW?
>
> [[LY]] No, it makes complex in setting up P2MP PW. Should a PE with
> both root and leaf ACs set up two or one P2MP PW to other PEs (some
> PE have both root and leaf AC and some only have leaf ACs)?
> Regards,
> Lucy
[Lizhong] a bit arbitrary to say "complex" here. Both have PROS and CONS. If 2-PW approach uses two P2MP PW, the BUM traffic from leaf would be only to root, and BUM traffic from root would be only to leaf. While if 2-VLAN approach uses only one P2MP PW, the BUM traffic from leaf would be also to other leaf only nodes, and filtered at egress node, which wastes the traffic bandwidth in the network.

Thanks
Lizhong


>
> Regards,
>  
> Yuqun (Sam) Cao
> E-mail: Yuqun.cao@gmail.com
>  
>
> -----Original Message-----
> From: Daniel Cohn [mailto:DanielC@orckit.com]
> Sent: Tuesday, April 17, 2012 4:56 PM
> To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); giles.heron@gmail.com;
> simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao
> Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com;
> Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com;
> Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com
> Subject: RE: The status of the approaches to the E-Tree solution?
>
> Adding Sam (as l2vpn@ is holding messages)
>
> DC
>
> -----Original Message-----
> From: Lucy yong [mailto:lucy.yong@huawei.com]
> Sent: Tuesday, April 17, 2012 12:39 AM
> To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim);
> giles.heron@gmail.com; simon.delord@gmail.com;
> Alexander.Vainshtein@ecitele.com
> Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com;
> Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com;
> Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com
> Subject: RE: The status of the approaches to the E-Tree solution?
>
>
> Snipped,
>
> As we discussed extensively in the list, and as reflected in giles
> slide, 2 pws are only needed between pes with both root and leaf acs,
> which will typically be a small minority.
> [[LY]] Don't know if the assumption is true. Even it is the case, both
> approaches can benefit from it. I was off for a while and captures some
> discussions now.
>
> Also as per giles slide, dual vlan can have scalability issues due to
> additional lookup and double use of vlans in internal emulated lan
> interface. Also there are potential backward compatibility issues with
> silicon that doesn't support vlan mapping.
> [[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am
> not clear on all the issues. Could you be more specific? As I mentioned
> in below, two PW approach makes VPLS transport construction and packet
> forwarding more complex, I can see potential backward compatibility
> issues with 2 PW solution.
>
> Regards,
> Lucy
>
> Regards,
>
> Daniel
>
> Thumb typed - please be tolerant
>
> Lucy yong <lucy.yong@huawei.com> wrote:
>
> In my mind, the VLAN approach means dual vlan method.
>
> The main concern for CW approach is hardware support.
>
> Two PW approach can be complex too if the VPLS instance for E-Tree uses
> P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast
> traffic, and some P2MP PWs for multicast traffic. It may double all of
> them.
>
> E-tree is an Ethernet service and there is already VLAN based solution
> in IEEE, can we just utilize it without complicating VPLS transport
> construction? This also makes interworking with Eth only network easier.
>
> Cheers,
> Lucy
>
> -----Original Message-----
> From: Rogers, Josh [mailto:josh.rogers@twcable.com]
> Sent: Monday, April 16, 2012 8:35 AM
> To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com';
> 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com'
> Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com';
> 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com';
> 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com'
> Subject: RE: The status of the approaches to the E-Tree solution?
>
> I believe the initial question was in regard to the CW method.  Are you
> saying that you no longer are interested in that method in preference of
> the dual vlan method?
>
>
>
> Lucy yong <lucy.yong@huawei.com> wrote:
>
>
> Agree with Wim. VLAN approach is the best solution for E-Tree.
>
> Lucy
>
> -----Original Message-----
> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf
> Of Henderickx, Wim (Wim)
> Sent: Thursday, April 12, 2012 2:03 AM
> To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com';
> 'Alexander.Vainshtein@ecitele.com'
> Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com';
> 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com';
> 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com'
> Subject: Re: The status of the approaches to the E-Tree solution?
>
> The vlan approach is superior as it also works for eth only networks,
> etc. On top some vendors indicate hw issues with the cw approach. As
> such we have dropped more or less the cw approach.
>
> Cheers,
> Wim
> _________________
> sent from blackberry
>
> ----- Original Message -----
> From: Giles Heron [mailto:giles.heron@gmail.com]
> Sent: Thursday, April 12, 2012 08:22 AM
> To: Simon Delord <simon.delord@gmail.com>; Alexander Vainshtein
> <Alexander.Vainshtein@ecitele.com>
> Cc: l2vpn@ietf.org <l2vpn@ietf.org>; Vladimir Kleiner
> <Vladimir.Kleiner@ecitele.com>; Andrew Sergeev
> <Andrew.Sergeev@ecitele.com>; Idan Kaspit <Idan.Kaspit@ecitele.com>;
> Mishael Wexler <Mishael.Wexler@ecitele.com>; Rotem Cohen
> <Rotem.Cohen@ecitele.com>
> Subject: Re: The status of the approaches to the E-Tree solution?
>
> Sorry - the "anonymous presentation" was mine.  I should possibly have
> put in a third column on the CW approach.  And hopefully the minutes
> will be posted soon.
>
> We had various discussions, as Simon stated, and consensus seemed to be
> forming around the two alternatives of two PWEs or two VLANs.  I believe
> three of the authors of the CW approach are also authors of the two VLAN
> approach and one is also an author of the two PWE approach. So perhaps
> it's best to let those four individuals say which approach they prefer
> and why?
>
> Giles
>
> On 10/04/2012 00:45, "Simon Delord" <simon.delord@gmail.com> wrote:
>
> > Hi Alexander,
> >
> > You are right, no discussion on the WG mailing list recently, but
> > there have been substantial discussions among the authors of various
> > solution drafts off the mailing list. As far as I know, no consensus
> > yet before ietf83, not sure the progress in the Paris WG meeting. I
> > think the CW approach has not been rejected by the WG yet, or the WG
> > has not yet decided on which one to adopt.
> >
> > Simon
> >
> > 2012/4/8 Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
> >
> >>  Hi all,
> >>
> >> Unfortunately I have not been able to attend the Paris IETF.
> >>
> >> However, looking up the L2VPN proceedings, I've found a short
> >> anonymous presentation called "E-Tree Update"  (
> >> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx).
> >> This presentation discusses the differences of the E-Tree approaches
> >> based on dedicated VLANs (as in
> >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t
> >> ext=1) and multiple PWs between the PEs (as in
> >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in
> >> clude_te
> >> xt=1)
> >> and completely ignores the solution based on usage of the CW in the
> >> PWs connecting the PEs (as in
> >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t
> >> ext=1
> >> ).
> >>
> >>
> >>
> >> The Minutes of the Paris L2VPN session are not yet available, but I
> >> wonder whether the WG has taken a decision to reject the approach
> >> based on the CW usage? I do not remember any recent discussion of
> >> this topic on the WG mailing list.
> >>
> >>
> >>
> >> Regards, and lots of thanks in advance,
> >>
> >> Sasha
> >>
> >>
> >>
> >>
> >>
> >> This e-mail message is intended for the recipient only and contains
> >> information which is CONFIDENTIAL and which may be proprietary to ECI
>
> >> Telecom. If you have received this transmission in error, please
> >> inform us by e-mail, phone or fax, and then delete the original and
> >> all copies thereof.
> >>
>
>
>
> --=_alternative 002870FE482579E5_=-- From Alexander.Vainshtein@ecitele.com Thu Apr 19 00:22:24 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D19E21F84FB for ; Thu, 19 Apr 2012 00:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.634 X-Spam-Level: X-Spam-Status: No, score=-3.634 tagged_above=-999 required=5 tests=[AWL=1.567, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, 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 mlWEZ7IohuuS for ; Thu, 19 Apr 2012 00:22:20 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 57D2D21F84E4 for ; Thu, 19 Apr 2012 00:22:19 -0700 (PDT) Received: from [85.158.139.83:8248] by server-9.bemta-5.messagelabs.com id 2C/3C-09826-A2DBF8F4; Thu, 19 Apr 2012 07:22:18 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1334820137!24490931!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.7; banners=-,-,- Received: (qmail 5162 invoked from network); 19 Apr 2012 07:22:18 -0000 Received: from unknown (HELO fridlppsb001.ecitele.com) (168.87.1.157) by server-3.tower-182.messagelabs.com with SMTP; 19 Apr 2012 07:22:18 -0000 X-AuditID: a8571401-b7f186d000005261-c1-4f8fbd7150b1 Received: from FRIDWPPCH001.ecitele.com (fridwppch001.ecitele.com [10.1.16.52]) by fridlppsb001.ecitele.com (Symantec Messaging Gateway) with SMTP id E4.38.21089.17DBF8F4; Thu, 19 Apr 2012 09:23:29 +0200 (CEST) Received: from FRIDWPPMB002.ecitele.com ([169.254.4.167]) by FRIDWPPCH001.ecitele.com ([10.1.16.52]) with mapi id 14.01.0339.001; Thu, 19 Apr 2012 09:22:17 +0200 From: Alexander Vainshtein To: "Henderickx, Wim (Wim)" , Daniel Cohn Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdiov///PycP//4qvA//+4WfA= Date: Thu, 19 Apr 2012 07:22:16 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, , <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130777C1D5@tlvmail1> <14C7F4F06DB5814AB0DE29716C4F6D670129623CD2@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D670129623CD2@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTaWjTUBz3NWmWzUViN+2zqMTgPNfRehFxHV5I90E6PBAEj9g+22Cb1qYb qwgWDxhzznmAs06mW72vraIoboh1qB3eTplHPTZRN1E8mLfTpME5MZ9+7/2u95J/SExXlmIg BTGA/CLvZok0PA30MRhXNm62mX48HMWFbtdquN21P3Cu/VMshav/VkNwu9q/ENzuddeIqYR1 w4tGrfVsOJFiXd/0RmuNRL5qrBvrtmHWI0c78QJiYQjk8qLoDfABxDiQZLewBX6hiLcHWUZw WFgzy/jcvB15kBiwsLzPh0QHm5fG/PfkyjJBZJBo9zoE0Wlh8+fajBw3cbLRzObNcwkSg4we XnAzHiRJvBMx8o5yK9Gx9DjmKnkaJ3zXI6D4V1MTEQKJ9aAUpJKQngBbyzYSKh4Ibz4+IeM0 Uke3ALjz5xdcXewD8HRdFFdUBG2B0SOJpCOTtsPKkCrC6O0A7ttaliQy6Glw06tSoIqmw44H tZgiyqSjAFY86dIoBE5nwaqW41oFU/Rs2PjomFatu4PBjvdVSSKVXgrjlXuTGMgH/Nx8NGnG aD188Lxaox6chpGGG5iKB8CO9m6tiofCtYdaUlR9Ntxz7gOh4rFw/97XmFrcH8Z3PsdV/SB4 4WArXgH04V4V4V72cC97uJd9D8APA/1yv+Dw+aRlJpM5B9mFAHKjHLvXEwXyTB1ckAnOgLZN OTFAk4BNp97dK7fptHyRFPTEwCBSww6gJjVstun6LfM6gi5eci3xF7qRFAOQxNhMKp4rc5SD D65Cfu8fipNf4hbM0NfuVb5zYMl4k+mfBaunTszJs+lopzx8KxDyIf8f62CSZCG1Wmns70dO VLxccAf+0hoyVWlOl5u3KRpK8vEeSXCqfDPIIn+djrcAHS56RWTQUyWKiFZErkKxJ6cT6OW7 ZlCLFTZdHsaehE45XCOHD4PlSrj8c/RQhhBYND2jZmD9uNCoF/X3cyzMyTWTu7JrqKyOLmvD 7Fd8XeLy1CFVLy+NG1KZXxo52zwlODN48e20gvG3CrDmWdXnh93Pbpu7PX/Lo8Mld/nzK7u/ 555pW3Pl7akR0UPhqpEfH7+ZX0geMN7uHt53Rv3Voh2tsUXm66MrntnWXSleXR5PzAtXsLjk 4s1jML/E/wYZsDEzHwQAAA== Cc: "l2vpn@ietf.org" , Sam Cao X-BeenThere: l2vpn@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, 19 Apr 2012 07:22:24 -0000 Wim, Daniel and all, I think there are quite a few parameters for comparing three (not two!) prop= osed solutions. I've already mentioned operational implications associated with changes in t= he PE status (Root-Only <--> Mix, Leaf-only <--> Mix, Leaf-only <-->Root-onl= y). Other aspects that should be taken into account are: - Interoperability with VLAN manipulations (push/swap/pop VLAN tag or even t= wo tags). While this functionality is non-standard, every major vendor I'm a= ware of offers it as part of their VPLS solution, so I assume there is some= real demand for it. - Interoperability with PBB. This is one of the major topics at this WG - Interoperability with H-VPLS Of course, interoperability with usage of P2MP PWs for effective delivery of= BUM traffic is also important, but this aspect has been covered (to some ex= tent) in the previous emails. There may be other aspects, but it seems that ones I've mentioned are all wo= rth considering. Regards, Sasha > -----Original Message----- > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > lucent.com] > Sent: Thursday, April 19, 2012 9:34 AM > To: Daniel Cohn; Alexander Vainshtein; Rogers, Josh; Lucy yong; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Daniel, we should discuss this as this is not absolutely required to tear= down > PW. You can also have an indication in the E-TREE fwd to indicate that the > endpoint has no leaf and as such avoid sending traffic down but allow the > PW to be setup. As such we have some flexibility such that operators can > select the proper approach they would like to have/implement. > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: donderdag 19 april 2012 8:16 > To: Alexander Vainshtein; Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; > Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Hi Sasha and all, > > You have exactly the same "problem" in the 2-VLAN approach - quoting > from the draft: > > 6. LDP Extensions for E-Tree Support > > P is a Leaf-only bit, it is set to 1 to indicate that the PE is attached > with only leaves, and set to 0 otherwise. > > If the P bit is set, then: > > { > > If the PE is a leaf-only node itself, then a label release > message with the error code "Leaf to Leaf PW error" is sent to the > peer PE and exit the process; > > > So all that you wrote about a leaf-only PE becoming mixed and viceversa > applies to both solutions. > > Regards, > > Daniel > > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Thursday, April 19, 2012 8:31 AM > To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Wim, > Lots of thanks for a prompt response. > > I think that operational aspects of the VLAN approach (e.g., how is the > Global VID selected and distributed) should be examined in more detail. > > At the same time it seems that the double PW approach carries with it > too many operational problems. > E.g., no PWs are set up between Leaf-only PEs, but once one of these > becomes a Mix PE, all the Leaf-only PEs must now recognize it as a valid > peer. And if a Mix PE reverts to a Leaf only one, all its Leaf-only > peers must drop it and shut down the relevant PWs... > > My 2c, > Sasha > > ________________________________________ > From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] > Sent: Thursday, April 19, 2012 7:21 AM > To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Sasha, the VLAN approach allows for a similar operation as the CW does. > It is orthogonal to the underlying PW deployment of VPLS. > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Alexander Vainshtein > Sent: donderdag 19 april 2012 6:39 > To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Hi all, > I fully understand that that what I am going to say is not very popular, > but: > > IMO one of the advantages of the CW-based solution is that it is > orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of > BUN traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, > and, in a more generic way, localization of effects of changes in the PE > configuration. > > In particular, adding a Leaf AC to a PE that previously has been only > supporting Root ACs (or vice versa), removal of the last Leaf or last > Root AC from a PE that previously has been supporting a mix etc. affect > only the PE where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main > disadvantage of the CW-based approach - I believe it strongly depends on > specific implementations. And some changes in the forwarding process are > required in any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of > Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a more > complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become more > complex. > > Gile's comparison slide still concisely captures the differences between > these methods, in my opinion. I haven't seen any new ideas or thoughts > brought to the group in the past week or two on the subject. I would > hate > for both proposed methods to die on the vine because we couldn't decide > between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" wrote: > > >Send this again. > > > >Two PW approach can be complex too if the VPLS instance for E-Tree uses > >P2P PW for unicast traffic and P2MP PW for broadcast and unknown > >unicast traffic, and some P2MP PWs for multicast traffic. It may double > >all of them. > > > >Lucy > > > >-----Original Message----- > >From: Daniel Cohn [mailto:DanielC@orckit.com] > >Sent: Wednesday, April 18, 2012 1:42 PM > >To: Lucy yong; Rogers, Josh; Sam Cao > >Cc: l2vpn@ietf.org > >Subject: RE: The status of the approaches to the E-Tree solution? > > > >I think the first option its the natural way to go. How is the > processing > >in this case more complex? > > > >Thumb typed - please be tolerant > > > >Lucy yong wrote: > > > > > > > >Snipped.. > > > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP > PW > >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for > >traffic coming from a root AC) > >[[LY]] Not that simple. You construct either two P2MP PWs to all other > >PEs and let egress PE performing filtering, or construct one P2MP PW to > >leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE > >perform forwarding and filtering. Both make node process complex. > > > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for > >delivering the frames to remote PEs. We should utilize them with the > >minimized changes. Dual VLAN solution is simpler than Dual PW. > > > >Regards, > >Lucy > > > > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I > >haven't had any first hand experience with P2MP PW's, however, so don't > >feel terribly strong about this objection. Is this a real problem for > >others (now or in the future), or is this objection in the weeds? > > > >I'm not sure the 'additional complexity' is notable, or even relevant. > I > >encourage others to speak up if they disagree, as P2MP PW is only > >conceptual to me, and I am unfamiliar with real-life use cases for it. > > > >Thanks, > >Josh > > > > > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > > > >>Please see inline. > >> > >>-----Original Message----- > >>From: Sam Cao [mailto:yuqun.cao@gmail.com] > >>Sent: Tuesday, April 17, 2012 7:14 AM > >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; > >>giles.heron@gmail.com; simon.delord@gmail.com; > >>Alexander.Vainshtein@ecitele.com > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > >>Subject: RE: The status of the approaches to the E-Tree solution? > >> > >>Yes, 2 pws are only needed between pes with both root and leaf acs > after > >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup > 2 > >>P2MP > >>PWs if need. There is no difference between P2MP or normal PW setup. > But, > >>can Leaf-ACs be bound to Root PE of P2MP PW? > >> > >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with > both > >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have > >>both root and leaf AC and some only have leaf ACs)? > >>Regards, > >>Lucy > >> > >>Regards, > >> > >>Yuqun (Sam) Cao > >>E-mail: Yuqun.cao@gmail.com > >> > >> > >>-----Original Message----- > >>From: Daniel Cohn [mailto:DanielC@orckit.com] > >>Sent: Tuesday, April 17, 2012 4:56 PM > >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); > >>giles.heron@gmail.com; > >>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > >>Subject: RE: The status of the approaches to the E-Tree solution? > >> > >>Adding Sam (as l2vpn@ is holding messages) > >> > >>DC > >> > >>-----Original Message----- > >>From: Lucy yong [mailto:lucy.yong@huawei.com] > >>Sent: Tuesday, April 17, 2012 12:39 AM > >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); > >>giles.heron@gmail.com; simon.delord@gmail.com; > >>Alexander.Vainshtein@ecitele.com > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > >>Subject: RE: The status of the approaches to the E-Tree solution? > >> > >> > >>Snipped, > >> > >>As we discussed extensively in the list, and as reflected in giles > >>slide, 2 pws are only needed between pes with both root and leaf acs, > >>which will typically be a small minority. > >>[[LY]] Don't know if the assumption is true. Even it is the case, both > >>approaches can benefit from it. I was off for a while and captures > some > >>discussions now. > >> > >>Also as per giles slide, dual vlan can have scalability issues due to > >>additional lookup and double use of vlans in internal emulated lan > >>interface. Also there are potential backward compatibility issues with > >>silicon that doesn't support vlan mapping. > >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I > am > >>not clear on all the issues. Could you be more specific? As I > mentioned > >>in below, two PW approach makes VPLS transport construction and packet > >>forwarding more complex, I can see potential backward compatibility > >>issues with 2 PW solution. > >> > >>Regards, > >>Lucy > >> > >>Regards, > >> > >>Daniel > >> > >>Thumb typed - please be tolerant > >> > >>Lucy yong wrote: > >> > >>In my mind, the VLAN approach means dual vlan method. > >> > >>The main concern for CW approach is hardware support. > >> > >>Two PW approach can be complex too if the VPLS instance for E-Tree > uses > >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown > unicast > >>traffic, and some P2MP PWs for multicast traffic. It may double all of > >>them. > >> > >>E-tree is an Ethernet service and there is already VLAN based solution > >>in IEEE, can we just utilize it without complicating VPLS transport > >>construction? This also makes interworking with Eth only network > easier. > >> > >>Cheers, > >>Lucy > >> > >>-----Original Message----- > >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] > >>Sent: Monday, April 16, 2012 8:35 AM > >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; > >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' > >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; > >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; > >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' > >>Subject: RE: The status of the approaches to the E-Tree solution? > >> > >>I believe the initial question was in regard to the CW method. Are > you > >>saying that you no longer are interested in that method in preference > of > >>the dual vlan method? > >> > >> > >> > >>Lucy yong wrote: > >> > >> > >>Agree with Wim. VLAN approach is the best solution for E-Tree. > >> > >>Lucy > >> > >>-----Original Message----- > >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > >>Of Henderickx, Wim (Wim) > >>Sent: Thursday, April 12, 2012 2:03 AM > >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; > >>'Alexander.Vainshtein@ecitele.com' > >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; > >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; > >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' > >>Subject: Re: The status of the approaches to the E-Tree solution? > >> > >>The vlan approach is superior as it also works for eth only networks, > >>etc. On top some vendors indicate hw issues with the cw approach. As > >>such we have dropped more or less the cw approach. > >> > >>Cheers, > >>Wim > >>_________________ > >>sent from blackberry > >> > >>----- Original Message ----- > >>From: Giles Heron [mailto:giles.heron@gmail.com] > >>Sent: Thursday, April 12, 2012 08:22 AM > >>To: Simon Delord ; Alexander Vainshtein > >> > >>Cc: l2vpn@ietf.org ; Vladimir Kleiner > >>; Andrew Sergeev > >>; Idan Kaspit ; > >>Mishael Wexler ; Rotem Cohen > >> > >>Subject: Re: The status of the approaches to the E-Tree solution? > >> > >>Sorry - the "anonymous presentation" was mine. I should possibly have > >>put in a third column on the CW approach. And hopefully the minutes > >>will be posted soon. > >> > >>We had various discussions, as Simon stated, and consensus seemed to > be > >>forming around the two alternatives of two PWEs or two VLANs. I > believe > >>three of the authors of the CW approach are also authors of the two > VLAN > >>approach and one is also an author of the two PWE approach. So perhaps > >>it's best to let those four individuals say which approach they prefer > >>and why? > >> > >>Giles > >> > >>On 10/04/2012 00:45, "Simon Delord" wrote: > >> > >>> Hi Alexander, > >>> > >>> You are right, no discussion on the WG mailing list recently, but > >>> there have been substantial discussions among the authors of various > >>> solution drafts off the mailing list. As far as I know, no consensus > >>> yet before ietf83, not sure the progress in the Paris WG meeting. I > >>> think the CW approach has not been rejected by the WG yet, or the WG > >>> has not yet decided on which one to adopt. > >>> > >>> Simon > >>> > >>> 2012/4/8 Alexander Vainshtein > >>> > >>>> Hi all, > >>>> > >>>> Unfortunately I have not been able to attend the Paris IETF. > >>>> > >>>> However, looking up the L2VPN proceedings, I've found a short > >>>> anonymous presentation called "E-Tree Update" ( > >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). > >>>> This presentation discusses the differences of the E-Tree > approaches > >>>> based on dedicated VLANs (as in > >>>> > http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t > >>>> ext=3D1) and multiple PWs between the PEs (as in > >>>> > http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in > >>>> clude_te > >>>> xt=3D1) > >>>> and completely ignores the solution based on usage of the CW in the > >>>> PWs connecting the PEs (as in > >>>> > http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t > >>>> ext=3D1 > >>>> ). > >>>> > >>>> > >>>> > >>>> The Minutes of the Paris L2VPN session are not yet available, but I > >>>> wonder whether the WG has taken a decision to reject the approach > >>>> based on the CW usage? I do not remember any recent discussion of > >>>> this topic on the WG mailing list. > >>>> > >>>> > >>>> > >>>> Regards, and lots of thanks in advance, > >>>> > >>>> Sasha > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> This e-mail message is intended for the recipient only and contains > >>>> information which is CONFIDENTIAL and which may be proprietary to > ECI > >> > >>>> Telecom. If you have received this transmission in error, please > >>>> inform us by e-mail, phone or fax, and then delete the original and > >>>> all copies thereof. > >>>> > >> > >> > >> > >> > >> > >>This E-mail and any of its attachments may contain Time Warner Cable > >>proprietary information, which is privileged, confidential, or subject > >>to copyright belonging to Time Warner Cable. This E-mail is intended > >>solely for the use of the individual or entity to which it is > addressed. > >>If you are not the intended recipient of this E-mail, you are hereby > >>notified that any dissemination, distribution, copying, or action > taken > >>in relation to the contents of and attachments to this E-mail is > >>strictly prohibited and may be unlawful. If you have received this > >>E-mail in error, please notify the sender immediately and permanently > >>delete the original and any copy of this E-mail and any printout. > >> > > > > > >This E-mail and any of its attachments may contain Time Warner Cable > >proprietary information, which is privileged, confidential, or subject > to > >copyright belonging to Time Warner Cable. This E-mail is intended > solely > >for the use of the individual or entity to which it is addressed. If > you > >are not the intended recipient of this E-mail, you are hereby notified > >that any dissemination, distribution, copying, or action taken in > >relation to the contents of and attachments to this E-mail is strictly > >prohibited and may be unlawful. If you have received this E-mail in > >error, please notify the sender immediately and permanently delete the > >original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject > to copyright belonging to Time Warner Cable. This E-mail is intended > solely for the use of the individual or entity to which it is addressed. > If you are not the intended recipient of this E-mail, you are hereby > notified that any dissemination, distribution, copying, or action taken > in relation to the contents of and attachments to this E-mail is > strictly prohibited and may be unlawful. If you have received this > E-mail in error, please notify the sender immediately and permanently > delete the original and any copy of this E-mail and any printout. > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform > us by e-mail, phone or fax, and then delete the original and all copies > thereof. > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform > us by e-mail, phone or fax, and then delete the original and all copies > thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From DanielC@orckit.com Thu Apr 19 02:49:29 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955B421F8566 for ; Thu, 19 Apr 2012 02:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=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 7UOdezhLbiZn for ; Thu, 19 Apr 2012 02:49:25 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9707D21F8562 for ; Thu, 19 Apr 2012 02:49:24 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Date: Thu, 19 Apr 2012 12:49:22 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130777C22F@tlvmail1> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D670129623CD2@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdiov///PycP//4qvA//+OPpA= References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, , <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130777C1D5@tlvmail1> <14C7F4F06DB5814AB0DE29716C4F6D670129623CD2@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> From: "Daniel Cohn" To: "Henderickx, Wim (Wim)" , "Alexander Vainshtein" , "Rogers, Josh" , "Lucy yong" , "Sam Cao" Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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, 19 Apr 2012 09:49:29 -0000 Hi Wim, That seems to me a non-negligible change to bridge forwarding logic, I think setting up/tearing down the PE is cleaner. I don't expect that leaf-only to root/leaf PE transformations will happen all that often. But I think it's important to clarify that the issue is common to both drafts. DC -----Original Message----- From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]=20 Sent: Thursday, April 19, 2012 9:34 AM To: Daniel Cohn; Alexander Vainshtein; Rogers, Josh; Lucy yong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Daniel, we should discuss this as this is not absolutely required to tear down PW. You can also have an indication in the E-TREE fwd to indicate that the endpoint has no leaf and as such avoid sending traffic down but allow the PW to be setup. As such we have some flexibility such that operators can select the proper approach they would like to have/implement. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: donderdag 19 april 2012 8:16 To: Alexander Vainshtein; Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Sasha and all, You have exactly the same "problem" in the 2-VLAN approach - quoting from the draft: 6. LDP Extensions for E-Tree Support P is a Leaf-only bit, it is set to 1 to indicate that the PE is attached with only leaves, and set to 0 otherwise. If the P bit is set, then: { If the PE is a leaf-only node itself, then a label release message with the error code "Leaf to Leaf PW error" is sent to the peer PE and exit the process; So all that you wrote about a leaf-only PE becoming mixed and viceversa applies to both solutions. Regards, Daniel -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Thursday, April 19, 2012 8:31 AM To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Wim, Lots of thanks for a prompt response. I think that operational aspects of the VLAN approach (e.g., how is the Global VID selected and distributed) should be examined in more detail. At the same time it seems that the double PW approach carries with it too many operational problems. E.g., no PWs are set up between Leaf-only PEs, but once one of these becomes a Mix PE, all the Leaf-only PEs must now recognize it as a valid peer. And if a Mix PE reverts to a Leaf only one, all its Leaf-only peers must drop it and shut down the relevant PWs... My 2c, Sasha ________________________________________ From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] Sent: Thursday, April 19, 2012 7:21 AM To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Sasha, the VLAN approach allows for a similar operation as the CW does. It is orthogonal to the underlying PW deployment of VPLS. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: donderdag 19 april 2012 6:39 To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi all, I fully understand that that what I am going to say is not very popular, but: IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes in the PE configuration. In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root AC from a PE that previously has been supporting a mix etc. affect only the PE where this operation happens and not the rest of the PEs. As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] Sent: Wednesday, April 18, 2012 9:57 PM To: Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Again, the P2MP situation throws me. Is this something that is used commonly? I'm under the impression that adding P2MP to any model results in a more complex model. Wether outside s-tag is used to differentiate, or dedicated pw's are used for the same purpose, it seems both become more complex. Gile's comparison slide still concisely captures the differences between these methods, in my opinion. I haven't seen any new ideas or thoughts brought to the group in the past week or two on the subject. I would hate for both proposed methods to die on the vine because we couldn't decide between two methods that have nothing inherently wrong with either. -Josh On 4/18/12 1:53 PM, "Lucy yong" wrote: >Send this again. > >Two PW approach can be complex too if the VPLS instance for E-Tree uses >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >unicast traffic, and some P2MP PWs for multicast traffic. It may double >all of them. > >Lucy > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, April 18, 2012 1:42 PM >To: Lucy yong; Rogers, Josh; Sam Cao >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >I think the first option its the natural way to go. How is the processing >in this case more complex? > >Thumb typed - please be tolerant > >Lucy yong wrote: > > > >Snipped.. > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >traffic coming from a root AC) >[[LY]] Not that simple. You construct either two P2MP PWs to all other >PEs and let egress PE performing filtering, or construct one P2MP PW to >leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >perform forwarding and filtering. Both make node process complex. > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >delivering the frames to remote PEs. We should utilize them with the >minimized changes. Dual VLAN solution is simpler than Dual PW. > >Regards, >Lucy > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >haven't had any first hand experience with P2MP PW's, however, so don't >feel terribly strong about this objection. Is this a real problem for >others (now or in the future), or is this objection in the weeds? > >I'm not sure the 'additional complexity' is notable, or even relevant. I >encourage others to speak up if they disagree, as P2MP PW is only >conceptual to me, and I am unfamiliar with real-life use cases for it. > >Thanks, >Josh > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > >>Please see inline. >> >>-----Original Message----- >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>Sent: Tuesday, April 17, 2012 7:14 AM >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Yes, 2 pws are only needed between pes with both root and leaf acs after >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>P2MP >>PWs if need. There is no difference between P2MP or normal PW setup. But, >>can Leaf-ACs be bound to Root PE of P2MP PW? >> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>both root and leaf AC and some only have leaf ACs)? >>Regards, >>Lucy >> >>Regards, >> >>Yuqun (Sam) Cao >>E-mail: Yuqun.cao@gmail.com >> >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Tuesday, April 17, 2012 4:56 PM >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; >>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Adding Sam (as l2vpn@ is holding messages) >> >>DC >> >>-----Original Message----- >>From: Lucy yong [mailto:lucy.yong@huawei.com] >>Sent: Tuesday, April 17, 2012 12:39 AM >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >>Snipped, >> >>As we discussed extensively in the list, and as reflected in giles >>slide, 2 pws are only needed between pes with both root and leaf acs, >>which will typically be a small minority. >>[[LY]] Don't know if the assumption is true. Even it is the case, both >>approaches can benefit from it. I was off for a while and captures some >>discussions now. >> >>Also as per giles slide, dual vlan can have scalability issues due to >>additional lookup and double use of vlans in internal emulated lan >>interface. Also there are potential backward compatibility issues with >>silicon that doesn't support vlan mapping. >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>not clear on all the issues. Could you be more specific? As I mentioned >>in below, two PW approach makes VPLS transport construction and packet >>forwarding more complex, I can see potential backward compatibility >>issues with 2 PW solution. >> >>Regards, >>Lucy >> >>Regards, >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>In my mind, the VLAN approach means dual vlan method. >> >>The main concern for CW approach is hardware support. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>traffic, and some P2MP PWs for multicast traffic. It may double all of >>them. >> >>E-tree is an Ethernet service and there is already VLAN based solution >>in IEEE, can we just utilize it without complicating VPLS transport >>construction? This also makes interworking with Eth only network easier. >> >>Cheers, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Monday, April 16, 2012 8:35 AM >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I believe the initial question was in regard to the CW method. Are you >>saying that you no longer are interested in that method in preference of >>the dual vlan method? >> >> >> >>Lucy yong wrote: >> >> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >> >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Henderickx, Wim (Wim) >>Sent: Thursday, April 12, 2012 2:03 AM >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>The vlan approach is superior as it also works for eth only networks, >>etc. On top some vendors indicate hw issues with the cw approach. As >>such we have dropped more or less the cw approach. >> >>Cheers, >>Wim >>_________________ >>sent from blackberry >> >>----- Original Message ----- >>From: Giles Heron [mailto:giles.heron@gmail.com] >>Sent: Thursday, April 12, 2012 08:22 AM >>To: Simon Delord ; Alexander Vainshtein >> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>; Andrew Sergeev >>; Idan Kaspit ; >>Mishael Wexler ; Rotem Cohen >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Sorry - the "anonymous presentation" was mine. I should possibly have >>put in a third column on the CW approach. And hopefully the minutes >>will be posted soon. >> >>We had various discussions, as Simon stated, and consensus seemed to be >>forming around the two alternatives of two PWEs or two VLANs. I believe >>three of the authors of the CW approach are also authors of the two VLAN >>approach and one is also an author of the two PWE approach. So perhaps >>it's best to let those four individuals say which approach they prefer >>and why? >> >>Giles >> >>On 10/04/2012 00:45, "Simon Delord" wrote: >> >>> Hi Alexander, >>> >>> You are right, no discussion on the WG mailing list recently, but >>> there have been substantial discussions among the authors of various >>> solution drafts off the mailing list. As far as I know, no consensus >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>> think the CW approach has not been rejected by the WG yet, or the WG >>> has not yet decided on which one to adopt. >>> >>> Simon >>> >>> 2012/4/8 Alexander Vainshtein >>> >>>> Hi all, >>>> >>>> Unfortunately I have not been able to attend the Paris IETF. >>>> >>>> However, looking up the L2VPN proceedings, I've found a short >>>> anonymous presentation called "E-Tree Update" ( >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>> This presentation discusses the differences of the E-Tree approaches >>>> based on dedicated VLANs (as in >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>> ext=3D1) and multiple PWs between the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>> clude_te >>>> xt=3D1) >>>> and completely ignores the solution based on usage of the CW in the >>>> PWs connecting the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>> ext=3D1 >>>> ). >>>> >>>> >>>> >>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>> wonder whether the WG has taken a decision to reject the approach >>>> based on the CW usage? I do not remember any recent discussion of >>>> this topic on the WG mailing list. >>>> >>>> >>>> >>>> Regards, and lots of thanks in advance, >>>> >>>> Sasha >>>> >>>> >>>> >>>> >>>> >>>> This e-mail message is intended for the recipient only and contains >>>> information which is CONFIDENTIAL and which may be proprietary to ECI >> >>>> Telecom. If you have received this transmission in error, please >>>> inform us by e-mail, phone or fax, and then delete the original and >>>> all copies thereof. >>>> >> >> >> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is addressed. >>If you are not the intended recipient of this E-mail, you are hereby >>notified that any dissemination, distribution, copying, or action taken >>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this >>E-mail in error, please notify the sender immediately and permanently >>delete the original and any copy of this E-mail and any printout. >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. From wim.henderickx@alcatel-lucent.com Thu Apr 19 04:29:39 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E2321F85DF for ; Thu, 19 Apr 2012 04:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HELO_EQ_FR=0.35, HS_INDEX_PARAM=0.001, 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 GFMpyUKPRDRl for ; Thu, 19 Apr 2012 04:29:35 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6262A21F84E1 for ; Thu, 19 Apr 2012 04:29:35 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3JBSjmK011766 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 19 Apr 2012 13:29:29 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 19 Apr 2012 13:29:24 +0200 From: "Henderickx, Wim (Wim)" To: Daniel Cohn , Alexander Vainshtein , "Rogers, Josh" , Lucy yong , Sam Cao Date: Thu, 19 Apr 2012 13:29:22 +0200 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdiov///PycP//4qvA//+OPpD//v9MIA== Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D670129623EA9@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, , <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130777C1D5@tlvmail1> <14C7F4F06DB5814AB0DE29716C4F6D670129623CD2@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130777C22F@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130777C22F@tlvmail1> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 19 Apr 2012 11:29:39 -0000 Daniel, we will need to change something in the Fwd anyway. As such this be= havior can be added easily I believe. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: donderdag 19 april 2012 11:49 To: Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, Josh; Lucy yong; S= am Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Wim, That seems to me a non-negligible change to bridge forwarding logic, I think setting up/tearing down the PE is cleaner. I don't expect that leaf-only to root/leaf PE transformations will happen all that often. But I think it's important to clarify that the issue is common to both drafts. DC -----Original Message----- From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Thursday, April 19, 2012 9:34 AM To: Daniel Cohn; Alexander Vainshtein; Rogers, Josh; Lucy yong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Daniel, we should discuss this as this is not absolutely required to tear down PW. You can also have an indication in the E-TREE fwd to indicate that the endpoint has no leaf and as such avoid sending traffic down but allow the PW to be setup. As such we have some flexibility such that operators can select the proper approach they would like to have/implement. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: donderdag 19 april 2012 8:16 To: Alexander Vainshtein; Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Sasha and all, You have exactly the same "problem" in the 2-VLAN approach - quoting from the draft: 6. LDP Extensions for E-Tree Support P is a Leaf-only bit, it is set to 1 to indicate that the PE is attached with only leaves, and set to 0 otherwise. If the P bit is set, then: { If the PE is a leaf-only node itself, then a label release message with the error code "Leaf to Leaf PW error" is sent to the peer PE and exit the process; So all that you wrote about a leaf-only PE becoming mixed and viceversa applies to both solutions. Regards, Daniel -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Thursday, April 19, 2012 8:31 AM To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Wim, Lots of thanks for a prompt response. I think that operational aspects of the VLAN approach (e.g., how is the Global VID selected and distributed) should be examined in more detail. At the same time it seems that the double PW approach carries with it too many operational problems. E.g., no PWs are set up between Leaf-only PEs, but once one of these becomes a Mix PE, all the Leaf-only PEs must now recognize it as a valid peer. And if a Mix PE reverts to a Leaf only one, all its Leaf-only peers must drop it and shut down the relevant PWs... My 2c, Sasha ________________________________________ From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] Sent: Thursday, April 19, 2012 7:21 AM To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Sasha, the VLAN approach allows for a similar operation as the CW does. It is orthogonal to the underlying PW deployment of VPLS. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: donderdag 19 april 2012 6:39 To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi all, I fully understand that that what I am going to say is not very popular, but: IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes in the PE configuration. In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root AC from a PE that previously has been supporting a mix etc. affect only the PE where this operation happens and not the rest of the PEs. As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] Sent: Wednesday, April 18, 2012 9:57 PM To: Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Again, the P2MP situation throws me. Is this something that is used commonly? I'm under the impression that adding P2MP to any model results in a more complex model. Wether outside s-tag is used to differentiate, or dedicated pw's are used for the same purpose, it seems both become more complex. Gile's comparison slide still concisely captures the differences between these methods, in my opinion. I haven't seen any new ideas or thoughts brought to the group in the past week or two on the subject. I would hate for both proposed methods to die on the vine because we couldn't decide between two methods that have nothing inherently wrong with either. -Josh On 4/18/12 1:53 PM, "Lucy yong" wrote: >Send this again. > >Two PW approach can be complex too if the VPLS instance for E-Tree uses >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >unicast traffic, and some P2MP PWs for multicast traffic. It may double >all of them. > >Lucy > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, April 18, 2012 1:42 PM >To: Lucy yong; Rogers, Josh; Sam Cao >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >I think the first option its the natural way to go. How is the processing >in this case more complex? > >Thumb typed - please be tolerant > >Lucy yong wrote: > > > >Snipped.. > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >traffic coming from a root AC) >[[LY]] Not that simple. You construct either two P2MP PWs to all other >PEs and let egress PE performing filtering, or construct one P2MP PW to >leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >perform forwarding and filtering. Both make node process complex. > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >delivering the frames to remote PEs. We should utilize them with the >minimized changes. Dual VLAN solution is simpler than Dual PW. > >Regards, >Lucy > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >haven't had any first hand experience with P2MP PW's, however, so don't >feel terribly strong about this objection. Is this a real problem for >others (now or in the future), or is this objection in the weeds? > >I'm not sure the 'additional complexity' is notable, or even relevant. I >encourage others to speak up if they disagree, as P2MP PW is only >conceptual to me, and I am unfamiliar with real-life use cases for it. > >Thanks, >Josh > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > >>Please see inline. >> >>-----Original Message----- >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>Sent: Tuesday, April 17, 2012 7:14 AM >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Yes, 2 pws are only needed between pes with both root and leaf acs after >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>P2MP >>PWs if need. There is no difference between P2MP or normal PW setup. But, >>can Leaf-ACs be bound to Root PE of P2MP PW? >> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>both root and leaf AC and some only have leaf ACs)? >>Regards, >>Lucy >> >>Regards, >> >>Yuqun (Sam) Cao >>E-mail: Yuqun.cao@gmail.com >> >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Tuesday, April 17, 2012 4:56 PM >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; >>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Adding Sam (as l2vpn@ is holding messages) >> >>DC >> >>-----Original Message----- >>From: Lucy yong [mailto:lucy.yong@huawei.com] >>Sent: Tuesday, April 17, 2012 12:39 AM >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >>Snipped, >> >>As we discussed extensively in the list, and as reflected in giles >>slide, 2 pws are only needed between pes with both root and leaf acs, >>which will typically be a small minority. >>[[LY]] Don't know if the assumption is true. Even it is the case, both >>approaches can benefit from it. I was off for a while and captures some >>discussions now. >> >>Also as per giles slide, dual vlan can have scalability issues due to >>additional lookup and double use of vlans in internal emulated lan >>interface. Also there are potential backward compatibility issues with >>silicon that doesn't support vlan mapping. >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>not clear on all the issues. Could you be more specific? As I mentioned >>in below, two PW approach makes VPLS transport construction and packet >>forwarding more complex, I can see potential backward compatibility >>issues with 2 PW solution. >> >>Regards, >>Lucy >> >>Regards, >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>In my mind, the VLAN approach means dual vlan method. >> >>The main concern for CW approach is hardware support. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>traffic, and some P2MP PWs for multicast traffic. It may double all of >>them. >> >>E-tree is an Ethernet service and there is already VLAN based solution >>in IEEE, can we just utilize it without complicating VPLS transport >>construction? This also makes interworking with Eth only network easier. >> >>Cheers, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Monday, April 16, 2012 8:35 AM >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I believe the initial question was in regard to the CW method. Are you >>saying that you no longer are interested in that method in preference of >>the dual vlan method? >> >> >> >>Lucy yong wrote: >> >> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >> >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Henderickx, Wim (Wim) >>Sent: Thursday, April 12, 2012 2:03 AM >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>The vlan approach is superior as it also works for eth only networks, >>etc. On top some vendors indicate hw issues with the cw approach. As >>such we have dropped more or less the cw approach. >> >>Cheers, >>Wim >>_________________ >>sent from blackberry >> >>----- Original Message ----- >>From: Giles Heron [mailto:giles.heron@gmail.com] >>Sent: Thursday, April 12, 2012 08:22 AM >>To: Simon Delord ; Alexander Vainshtein >> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>; Andrew Sergeev >>; Idan Kaspit ; >>Mishael Wexler ; Rotem Cohen >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Sorry - the "anonymous presentation" was mine. I should possibly have >>put in a third column on the CW approach. And hopefully the minutes >>will be posted soon. >> >>We had various discussions, as Simon stated, and consensus seemed to be >>forming around the two alternatives of two PWEs or two VLANs. I believe >>three of the authors of the CW approach are also authors of the two VLAN >>approach and one is also an author of the two PWE approach. So perhaps >>it's best to let those four individuals say which approach they prefer >>and why? >> >>Giles >> >>On 10/04/2012 00:45, "Simon Delord" wrote: >> >>> Hi Alexander, >>> >>> You are right, no discussion on the WG mailing list recently, but >>> there have been substantial discussions among the authors of various >>> solution drafts off the mailing list. As far as I know, no consensus >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>> think the CW approach has not been rejected by the WG yet, or the WG >>> has not yet decided on which one to adopt. >>> >>> Simon >>> >>> 2012/4/8 Alexander Vainshtein >>> >>>> Hi all, >>>> >>>> Unfortunately I have not been able to attend the Paris IETF. >>>> >>>> However, looking up the L2VPN proceedings, I've found a short >>>> anonymous presentation called "E-Tree Update" ( >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>> This presentation discusses the differences of the E-Tree approaches >>>> based on dedicated VLANs (as in >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>> ext=3D1) and multiple PWs between the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>> clude_te >>>> xt=3D1) >>>> and completely ignores the solution based on usage of the CW in the >>>> PWs connecting the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>> ext=3D1 >>>> ). >>>> >>>> >>>> >>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>> wonder whether the WG has taken a decision to reject the approach >>>> based on the CW usage? I do not remember any recent discussion of >>>> this topic on the WG mailing list. >>>> >>>> >>>> >>>> Regards, and lots of thanks in advance, >>>> >>>> Sasha >>>> >>>> >>>> >>>> >>>> >>>> This e-mail message is intended for the recipient only and contains >>>> information which is CONFIDENTIAL and which may be proprietary to ECI >> >>>> Telecom. If you have received this transmission in error, please >>>> inform us by e-mail, phone or fax, and then delete the original and >>>> all copies thereof. >>>> >> >> >> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is addressed. >>If you are not the intended recipient of this E-mail, you are hereby >>notified that any dissemination, distribution, copying, or action taken >>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this >>E-mail in error, please notify the sender immediately and permanently >>delete the original and any copy of this E-mail and any printout. >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. From yuqun.cao@gmail.com Thu Apr 19 05:02:58 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19BD21F85C4 for ; Thu, 19 Apr 2012 05:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifxmIBkBjxhB for ; Thu, 19 Apr 2012 05:02:52 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id D865E21F85BB for ; Thu, 19 Apr 2012 05:02:51 -0700 (PDT) Received: by dady13 with SMTP id y13so15467493dad.27 for ; Thu, 19 Apr 2012 05:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :in-reply-to:x-mimeole; bh=9qENNHjcJjjzVEJVEw/3eX7QgH8Rx6p0rDPGdxiITg4=; b=Kf6per6otLK/X4l/lRe504+f0IOhcYEcEqL92yswXeiNi2BVbPL1VpFZT3a+tdLeQf eVuT5z8XJcrSsOliBMTpsIEvUgcnaIkshpeO20BoG39apzlGt6bHNFM7p5NRLlGDDDbD 6SuazTtjlq3V0yAA/+5PHdxwhhwPwgX17HIrZHVIPImbUTEBbasu7lcwQnFZ4chNOtFS 4gHkl4dcLbsU5vg1wkObBK8xlDFq4Q0BDg3p9hVWu3lPuC3a3TlVUN59XufVM0qNOrMD BikgvMwkaS8sX71/3EptJBVxtVN9zs3P2Uii0gm3MH1b+Zhfiw9aZeSYJ6K/ysUl0ZMg oU+Q== Received: by 10.68.201.9 with SMTP id jw9mr4381502pbc.88.1334836971322; Thu, 19 Apr 2012 05:02:51 -0700 (PDT) Received: from v2comsam ([36.248.16.95]) by mx.google.com with ESMTPS id l1sm2082836pbs.34.2012.04.19.05.02.46 (version=SSLv3 cipher=OTHER); Thu, 19 Apr 2012 05:02:50 -0700 (PDT) From: "Sam Cao" To: "'Lucy yong'" , "'Daniel Cohn'" , "'Rogers, Josh'" References: <12b701cd1d93$3dbbe37d$05280101@corrigent.com> <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx> Subject: RE: The status of the approaches to the E-Tree solution? Date: Thu, 19 Apr 2012 20:02:21 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac0YdJZFe/4Txq0Y50G6N17p5MncdwABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jAAu/59AADoQSiA= In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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, 19 Apr 2012 12:02:58 -0000 Lucy, Not double frames. Just one copy. Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com -----Original Message----- From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Thursday, April 19, 2012 2:53 AM To: Daniel Cohn; Rogers, Josh; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Send this again. Two PW approach can be complex too if the VPLS instance for E-Tree uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast traffic, and some P2MP PWs for multicast traffic. It may double all of them. Lucy -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Wednesday, April 18, 2012 1:42 PM To: Lucy yong; Rogers, Josh; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? I think the first option its the natural way to go. How is the processing in this case more complex? Thumb typed - please be tolerant Lucy yong wrote: Snipped.. Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for traffic coming from a root AC) [[LY]] Not that simple. You construct either two P2MP PWs to all other PEs and let egress PE performing filtering, or construct one P2MP PW to leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE perform forwarding and filtering. Both make node process complex. [[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for delivering the frames to remote PEs. We should utilize them with the minimized changes. Dual VLAN solution is simpler than Dual PW. Regards, Lucy I see how 2VLAN is simpler when P2MP PW's are involved, I think. I haven't had any first hand experience with P2MP PW's, however, so don't feel terribly strong about this objection. Is this a real problem for others (now or in the future), or is this objection in the weeds? I'm not sure the 'additional complexity' is notable, or even relevant. I encourage others to speak up if they disagree, as P2MP PW is only conceptual to me, and I am unfamiliar with real-life use cases for it. Thanks, Josh On 4/18/12 10:30 AM, "Lucy yong" wrote: >Please see inline. > >-----Original Message----- >From: Sam Cao [mailto:yuqun.cao@gmail.com] >Sent: Tuesday, April 17, 2012 7:14 AM >To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >giles.heron@gmail.com; simon.delord@gmail.com; >Alexander.Vainshtein@ecitele.com >Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >Subject: RE: The status of the approaches to the E-Tree solution? > >Yes, 2 pws are only needed between pes with both root and leaf acs after >improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >P2MP >PWs if need. There is no difference between P2MP or normal PW setup. But, >can Leaf-ACs be bound to Root PE of P2MP PW? > >[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >both root and leaf AC and some only have leaf ACs)? >Regards, >Lucy > >Regards, > >Yuqun (Sam) Cao >E-mail: Yuqun.cao@gmail.com > > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Tuesday, April 17, 2012 4:56 PM >To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); giles.heron@gmail.com; >simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >Subject: RE: The status of the approaches to the E-Tree solution? > >Adding Sam (as l2vpn@ is holding messages) > >DC > >-----Original Message----- >From: Lucy yong [mailto:lucy.yong@huawei.com] >Sent: Tuesday, April 17, 2012 12:39 AM >To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >giles.heron@gmail.com; simon.delord@gmail.com; >Alexander.Vainshtein@ecitele.com >Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >Subject: RE: The status of the approaches to the E-Tree solution? > > >Snipped, > >As we discussed extensively in the list, and as reflected in giles >slide, 2 pws are only needed between pes with both root and leaf acs, >which will typically be a small minority. >[[LY]] Don't know if the assumption is true. Even it is the case, both >approaches can benefit from it. I was off for a while and captures some >discussions now. > >Also as per giles slide, dual vlan can have scalability issues due to >additional lookup and double use of vlans in internal emulated lan >interface. Also there are potential backward compatibility issues with >silicon that doesn't support vlan mapping. >[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >not clear on all the issues. Could you be more specific? As I mentioned >in below, two PW approach makes VPLS transport construction and packet >forwarding more complex, I can see potential backward compatibility >issues with 2 PW solution. > >Regards, >Lucy > >Regards, > >Daniel > >Thumb typed - please be tolerant > >Lucy yong wrote: > >In my mind, the VLAN approach means dual vlan method. > >The main concern for CW approach is hardware support. > >Two PW approach can be complex too if the VPLS instance for E-Tree uses >P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >traffic, and some P2MP PWs for multicast traffic. It may double all of >them. > >E-tree is an Ethernet service and there is already VLAN based solution >in IEEE, can we just utilize it without complicating VPLS transport >construction? This also makes interworking with Eth only network easier. > >Cheers, >Lucy > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Monday, April 16, 2012 8:35 AM >To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >Subject: RE: The status of the approaches to the E-Tree solution? > >I believe the initial question was in regard to the CW method. Are you >saying that you no longer are interested in that method in preference of >the dual vlan method? > > > >Lucy yong wrote: > > >Agree with Wim. VLAN approach is the best solution for E-Tree. > >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >Of Henderickx, Wim (Wim) >Sent: Thursday, April 12, 2012 2:03 AM >To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >'Alexander.Vainshtein@ecitele.com' >Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >Subject: Re: The status of the approaches to the E-Tree solution? > >The vlan approach is superior as it also works for eth only networks, >etc. On top some vendors indicate hw issues with the cw approach. As >such we have dropped more or less the cw approach. > >Cheers, >Wim >_________________ >sent from blackberry > >----- Original Message ----- >From: Giles Heron [mailto:giles.heron@gmail.com] >Sent: Thursday, April 12, 2012 08:22 AM >To: Simon Delord ; Alexander Vainshtein > >Cc: l2vpn@ietf.org ; Vladimir Kleiner >; Andrew Sergeev >; Idan Kaspit ; >Mishael Wexler ; Rotem Cohen > >Subject: Re: The status of the approaches to the E-Tree solution? > >Sorry - the "anonymous presentation" was mine. I should possibly have >put in a third column on the CW approach. And hopefully the minutes >will be posted soon. > >We had various discussions, as Simon stated, and consensus seemed to be >forming around the two alternatives of two PWEs or two VLANs. I believe >three of the authors of the CW approach are also authors of the two VLAN >approach and one is also an author of the two PWE approach. So perhaps >it's best to let those four individuals say which approach they prefer >and why? > >Giles > >On 10/04/2012 00:45, "Simon Delord" wrote: > >> Hi Alexander, >> >> You are right, no discussion on the WG mailing list recently, but >> there have been substantial discussions among the authors of various >> solution drafts off the mailing list. As far as I know, no consensus >> yet before ietf83, not sure the progress in the Paris WG meeting. I >> think the CW approach has not been rejected by the WG yet, or the WG >> has not yet decided on which one to adopt. >> >> Simon >> >> 2012/4/8 Alexander Vainshtein >> >>> Hi all, >>> >>> Unfortunately I have not been able to attend the Paris IETF. >>> >>> However, looking up the L2VPN proceedings, I've found a short >>> anonymous presentation called "E-Tree Update" ( >>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>> This presentation discusses the differences of the E-Tree approaches >>> based on dedicated VLANs (as in >>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>> ext=1) and multiple PWs between the PEs (as in >>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>> clude_te >>> xt=1) >>> and completely ignores the solution based on usage of the CW in the >>> PWs connecting the PEs (as in >>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>> ext=1 >>> ). >>> >>> >>> >>> The Minutes of the Paris L2VPN session are not yet available, but I >>> wonder whether the WG has taken a decision to reject the approach >>> based on the CW usage? I do not remember any recent discussion of >>> this topic on the WG mailing list. >>> >>> >>> >>> Regards, and lots of thanks in advance, >>> >>> Sasha >>> >>> >>> >>> >>> >>> This e-mail message is intended for the recipient only and contains >>> information which is CONFIDENTIAL and which may be proprietary to ECI > >>> Telecom. If you have received this transmission in error, please >>> inform us by e-mail, phone or fax, and then delete the original and >>> all copies thereof. >>> > > > > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject >to copyright belonging to Time Warner Cable. This E-mail is intended >solely for the use of the individual or entity to which it is addressed. >If you are not the intended recipient of this E-mail, you are hereby >notified that any dissemination, distribution, copying, or action taken >in relation to the contents of and attachments to this E-mail is >strictly prohibited and may be unlawful. If you have received this >E-mail in error, please notify the sender immediately and permanently >delete the original and any copy of this E-mail and any printout. > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From nick.delregno@verizon.com Thu Apr 19 05:40:34 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A364E21F85CF for ; Thu, 19 Apr 2012 05:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, J_BACKHAIR_34=1, J_BACKHAIR_43=1, 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 cPbWSkLTPjce for ; Thu, 19 Apr 2012 05:40:30 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id F15AF21F85BB for ; Thu, 19 Apr 2012 05:40:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe01.verizon.com with ESMTP; 19 Apr 2012 12:40:14 +0000 From: "DelRegno, Christopher N \(Nick\)" X-IronPort-AV: E=Sophos;i="4.75,446,1330905600"; d="scan'208";a="255109368" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi02.verizon.com with ESMTP; 19 Apr 2012 12:40:13 +0000 Received: from FHDP1LUMXC7V42.us.one.verizon.com ([169.254.2.127]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Thu, 19 Apr 2012 08:40:13 -0400 To: Daniel Cohn , "Henderickx, Wim (Wim)" , Alexander Vainshtein , "Rogers, Josh" , Lucy yong , Sam Cao Date: Thu, 19 Apr 2012 08:40:11 -0400 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdiov///PycP//4qvA//+OPpD//ux5AA== Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, , <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130777C1D5@tlvmail1> <14C7F4F06DB5814AB0DE29716C4F6D670129623CD2@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130777C22F@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130777C22F@tlvmail1> 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 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 19 Apr 2012 12:40:34 -0000 Dan: As the transformation of a PE from Root<-->Mix and Mix<-->Leaf will be driv= en by our customers, we can't say how often this will or won't occur. It m= ust be accommodated regardless of perceived rarity. If I use one of our current extremely popular L2VPN services as an example,= our customers tend to move their ENNI (e.g. Root) locations constantly, qu= ite frequently to switches which heretofore only contained UNIs (e.g. leave= s). Nick -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Thursday, April 19, 2012 4:49 AM To: Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, Josh; Lucy yong; S= am Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Wim, That seems to me a non-negligible change to bridge forwarding logic, I thin= k setting up/tearing down the PE is cleaner. I don't expect that leaf-only = to root/leaf PE transformations will happen all that often. But I think it's important to clarify that the issue is common to both draf= ts. DC -----Original Message----- From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Thursday, April 19, 2012 9:34 AM To: Daniel Cohn; Alexander Vainshtein; Rogers, Josh; Lucy yong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Daniel, we should discuss this as this is not absolutely required to tear d= own PW. You can also have an indication in the E-TREE fwd to indicate that = the endpoint has no leaf and as such avoid sending traffic down but allow t= he PW to be setup. As such we have some flexibility such that operators can= select the proper approach they would like to have/implement. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: donderdag 19 april 2012 8:16 To: Alexander Vainshtein; Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; S= am Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Sasha and all, You have exactly the same "problem" in the 2-VLAN approach - quoting from t= he draft: 6. LDP Extensions for E-Tree Support P is a Leaf-only bit, it is set to 1 to indicate that the PE is attached wi= th only leaves, and set to 0 otherwise. If the P bit is set, then: { If the PE is a leaf-only node itself, then a label release message with the error code "Leaf to Leaf PW error" is sent to the peer PE and exit the process; So all that you wrote about a leaf-only PE becoming mixed and viceversa app= lies to both solutions. Regards, Daniel -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Thursday, April 19, 2012 8:31 AM To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Wim, Lots of thanks for a prompt response. I think that operational aspects of the VLAN approach (e.g., how is the Glo= bal VID selected and distributed) should be examined in more detail. At the same time it seems that the double PW approach carries with it too m= any operational problems. E.g., no PWs are set up between Leaf-only PEs, but once one of these become= s a Mix PE, all the Leaf-only PEs must now recognize it as a valid peer. An= d if a Mix PE reverts to a Leaf only one, all its Leaf-only peers must drop= it and shut down the relevant PWs... My 2c, Sasha ________________________________________ From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] Sent: Thursday, April 19, 2012 7:21 AM To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Sasha, the VLAN approach allows for a similar operation as the CW does. It is orthogonal to the underlying PW deployment of VPLS. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of A= lexander Vainshtein Sent: donderdag 19 april 2012 6:39 To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi all, I fully understand that that what I am going to say is not very popular, but: IMO one of the advantages of the CW-based solution is that it is orthogonal= to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, i= n a more generic way, localization of effects of changes in the PE configur= ation. In particular, adding a Leaf AC to a PE that previously has been only suppo= rting Root ACs (or vice versa), removal of the last Leaf or last Root AC fr= om a PE that previously has been supporting a mix etc. affect only the PE w= here this operation happens and not the rest of the PEs. As for the need for HW changes that have been mentioned as a main disadvant= age of the CW-based approach - I believe it strongly depends on specific im= plementations. And some changes in the forwarding process are required in a= ny solution. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, = Josh [josh.rogers@twcable.com] Sent: Wednesday, April 18, 2012 9:57 PM To: Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Again, the P2MP situation throws me. Is this something that is used common= ly? I'm under the impression that adding P2MP to any model results in a more co= mplex model. Wether outside s-tag is used to differentiate, or dedicated p= w's are used for the same purpose, it seems both become more complex. Gile's comparison slide still concisely captures the differences between th= ese methods, in my opinion. I haven't seen any new ideas or thoughts broug= ht to the group in the past week or two on the subject. I would hate for b= oth proposed methods to die on the vine because we couldn't decide between = two methods that have nothing inherently wrong with either. -Josh On 4/18/12 1:53 PM, "Lucy yong" wrote: >Send this again. > >Two PW approach can be complex too if the VPLS instance for E-Tree uses >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >unicast traffic, and some P2MP PWs for multicast traffic. It may double >all of them. > >Lucy > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, April 18, 2012 1:42 PM >To: Lucy yong; Rogers, Josh; Sam Cao >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >I think the first option its the natural way to go. How is the processing >in this case more complex? > >Thumb typed - please be tolerant > >Lucy yong wrote: > > > >Snipped.. > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >traffic coming from a root AC) [[LY]] Not that simple. You construct >either two P2MP PWs to all other PEs and let egress PE performing >filtering, or construct one P2MP PW to leaf-only PEs and two P2MP PWs >to root and leaf PEs and let ingress PE perform forwarding and >filtering. Both make node process complex. > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >delivering the frames to remote PEs. We should utilize them with the >minimized changes. Dual VLAN solution is simpler than Dual PW. > >Regards, >Lucy > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >haven't had any first hand experience with P2MP PW's, however, so don't >feel terribly strong about this objection. Is this a real problem for >others (now or in the future), or is this objection in the weeds? > >I'm not sure the 'additional complexity' is notable, or even relevant. I >encourage others to speak up if they disagree, as P2MP PW is only >conceptual to me, and I am unfamiliar with real-life use cases for it. > >Thanks, >Josh > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > >>Please see inline. >> >>-----Original Message----- >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>Sent: Tuesday, April 17, 2012 7:14 AM >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Yes, 2 pws are only needed between pes with both root and leaf acs after >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>P2MP PWs if need. There is no difference between P2MP or normal PW >>setup. But, >>can Leaf-ACs be bound to Root PE of P2MP PW? >> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>both root and leaf AC and some only have leaf ACs)? >>Regards, >>Lucy >> >>Regards, >> >>Yuqun (Sam) Cao >>E-mail: Yuqun.cao@gmail.com >> >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Tuesday, April 17, 2012 4:56 PM >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com; Sam Cao >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Adding Sam (as l2vpn@ is holding messages) >> >>DC >> >>-----Original Message----- >>From: Lucy yong [mailto:lucy.yong@huawei.com] >>Sent: Tuesday, April 17, 2012 12:39 AM >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >>Snipped, >> >>As we discussed extensively in the list, and as reflected in giles >>slide, 2 pws are only needed between pes with both root and leaf acs, >>which will typically be a small minority. >>[[LY]] Don't know if the assumption is true. Even it is the case, both >>approaches can benefit from it. I was off for a while and captures some >>discussions now. >> >>Also as per giles slide, dual vlan can have scalability issues due to >>additional lookup and double use of vlans in internal emulated lan >>interface. Also there are potential backward compatibility issues with >>silicon that doesn't support vlan mapping. >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>not clear on all the issues. Could you be more specific? As I mentioned >>in below, two PW approach makes VPLS transport construction and packet >>forwarding more complex, I can see potential backward compatibility >>issues with 2 PW solution. >> >>Regards, >>Lucy >> >>Regards, >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>In my mind, the VLAN approach means dual vlan method. >> >>The main concern for CW approach is hardware support. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>traffic, and some P2MP PWs for multicast traffic. It may double all of >>them. >> >>E-tree is an Ethernet service and there is already VLAN based solution >>in IEEE, can we just utilize it without complicating VPLS transport >>construction? This also makes interworking with Eth only network easier. >> >>Cheers, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Monday, April 16, 2012 8:35 AM >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I believe the initial question was in regard to the CW method. Are you >>saying that you no longer are interested in that method in preference of >>the dual vlan method? >> >> >> >>Lucy yong wrote: >> >> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >> >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Henderickx, Wim (Wim) >>Sent: Thursday, April 12, 2012 2:03 AM >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>The vlan approach is superior as it also works for eth only networks, >>etc. On top some vendors indicate hw issues with the cw approach. As >>such we have dropped more or less the cw approach. >> >>Cheers, >>Wim >>_________________ >>sent from blackberry >> >>----- Original Message ----- >>From: Giles Heron [mailto:giles.heron@gmail.com] >>Sent: Thursday, April 12, 2012 08:22 AM >>To: Simon Delord ; Alexander Vainshtein >> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>; Andrew Sergeev >>; Idan Kaspit ; >>Mishael Wexler ; Rotem Cohen >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Sorry - the "anonymous presentation" was mine. I should possibly have >>put in a third column on the CW approach. And hopefully the minutes >>will be posted soon. >> >>We had various discussions, as Simon stated, and consensus seemed to be >>forming around the two alternatives of two PWEs or two VLANs. I believe >>three of the authors of the CW approach are also authors of the two VLAN >>approach and one is also an author of the two PWE approach. So perhaps >>it's best to let those four individuals say which approach they prefer >>and why? >> >>Giles >> >>On 10/04/2012 00:45, "Simon Delord" wrote: >> >>> Hi Alexander, >>> >>> You are right, no discussion on the WG mailing list recently, but >>> there have been substantial discussions among the authors of various >>> solution drafts off the mailing list. As far as I know, no consensus >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>> think the CW approach has not been rejected by the WG yet, or the WG >>> has not yet decided on which one to adopt. >>> >>> Simon >>> >>> 2012/4/8 Alexander Vainshtein >>> >>>> Hi all, >>>> >>>> Unfortunately I have not been able to attend the Paris IETF. >>>> >>>> However, looking up the L2VPN proceedings, I've found a short >>>> anonymous presentation called "E-Tree Update" ( >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>> This presentation discusses the differences of the E-Tree approaches >>>> based on dedicated VLANs (as in >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>> ext=3D1) and multiple PWs between the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>> clude_te >>>> xt=3D1) >>>> and completely ignores the solution based on usage of the CW in the >>>> PWs connecting the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>> ext=3D1 >>>> ). >>>> >>>> >>>> >>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>> wonder whether the WG has taken a decision to reject the approach >>>> based on the CW usage? I do not remember any recent discussion of >>>> this topic on the WG mailing list. >>>> >>>> >>>> >>>> Regards, and lots of thanks in advance, >>>> >>>> Sasha >>>> >>>> >>>> >>>> >>>> >>>> This e-mail message is intended for the recipient only and contains >>>> information which is CONFIDENTIAL and which may be proprietary to ECI >> >>>> Telecom. If you have received this transmission in error, please >>>> inform us by e-mail, phone or fax, and then delete the original and >>>> all copies thereof. >>>> >> >> >> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is addressed. >>If you are not the intended recipient of this E-mail, you are hereby >>notified that any dissemination, distribution, copying, or action taken >>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this >>E-mail in error, please notify the sender immediately and permanently >>delete the original and any copy of this E-mail and any printout. >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notifi= ed that any dissemination, distribution, copying, or action taken in relati= on to the contents of and attachments to this E-mail is strictly prohibited= and may be unlawful. If you have received this E-mail in error, please not= ify the sender immediately and permanently delete the original and any copy= of this E-mail and any printout. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. From yuqun.cao@gmail.com Thu Apr 19 05:52:35 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398F721F8498 for ; Thu, 19 Apr 2012 05:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4EMuKMDwEqY for ; Thu, 19 Apr 2012 05:52:31 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 106CD21F8495 for ; Thu, 19 Apr 2012 05:52:30 -0700 (PDT) Received: by dady13 with SMTP id y13so15544727dad.27 for ; Thu, 19 Apr 2012 05:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :in-reply-to:x-mimeole; bh=kYOrTbSyx6YcCifOu3A0jDaRqo/AU0FHrecDM38D0U0=; b=ZyZ0oDQh/M0tGVvrvalFxoUY2XqQb+pjRmS9S5pfX6FWHQ9R6aj1Pcq6+6HjjxEgYK zCZoR4BobNl7g56JPlfPpvO8dsk6cE5E7RX+7roFAqqMPSRVJP5X/UQgYmLJkZXUUuWw w5Ohlt8wLv2LWP6OCK+GmCkCDepVBMJImcgz7yM10vkHwd0aupQb5xJJLow8JI4QUbeN sGudFgoje3lyDXUTnRZpLSoVV4UL2gQOcVbcABFVM9OaM753V6mXIZpaE7aJkLDfApA3 xAkCT3UJDw6Gh32ivUWsN3gZqiZGZ9g+C8pRjt2UmnjmUZphTAsHdqdQ/SGrndCCLIuG O95Q== Received: by 10.68.200.225 with SMTP id jv1mr4526163pbc.120.1334839950227; Thu, 19 Apr 2012 05:52:30 -0700 (PDT) Received: from v2comsam ([36.248.16.95]) by mx.google.com with ESMTPS id b10sm2181012pbr.46.2012.04.19.05.50.28 (version=SSLv3 cipher=OTHER); Thu, 19 Apr 2012 05:52:28 -0700 (PDT) From: "Sam Cao" To: "'Alexander Vainshtein'" , "'Henderickx, Wim \(Wim\)'" , "'Rogers, Josh'" , "'Lucy yong'" , "'Daniel Cohn'" References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, , <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Subject: RE: The status of the approaches to the E-Tree solution? Date: Thu, 19 Apr 2012 20:50:19 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdiov//4SRIA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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, 19 Apr 2012 12:52:35 -0000 Sasha, We have discussed this case before. While configuration is changed in fly, it is reasonable to establish or teardown PW. Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Thursday, April 19, 2012 1:31 PM To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Wim, Lots of thanks for a prompt response. I think that operational aspects of the VLAN approach (e.g., how is the Global VID selected and distributed) should be examined in more detail. At the same time it seems that the double PW approach carries with it too many operational problems. E.g., no PWs are set up between Leaf-only PEs, but once one of these becomes a Mix PE, all the Leaf-only PEs must now recognize it as a valid peer. And if a Mix PE reverts to a Leaf only one, all its Leaf-only peers must drop it and shut down the relevant PWs... My 2c, Sasha ________________________________________ From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] Sent: Thursday, April 19, 2012 7:21 AM To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Sasha, the VLAN approach allows for a similar operation as the CW does. It is orthogonal to the underlying PW deployment of VPLS. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: donderdag 19 april 2012 6:39 To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi all, I fully understand that that what I am going to say is not very popular, but: IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes in the PE configuration. In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root AC from a PE that previously has been supporting a mix etc. affect only the PE where this operation happens and not the rest of the PEs. As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] Sent: Wednesday, April 18, 2012 9:57 PM To: Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Again, the P2MP situation throws me. Is this something that is used commonly? I'm under the impression that adding P2MP to any model results in a more complex model. Wether outside s-tag is used to differentiate, or dedicated pw's are used for the same purpose, it seems both become more complex. Gile's comparison slide still concisely captures the differences between these methods, in my opinion. I haven't seen any new ideas or thoughts brought to the group in the past week or two on the subject. I would hate for both proposed methods to die on the vine because we couldn't decide between two methods that have nothing inherently wrong with either. -Josh On 4/18/12 1:53 PM, "Lucy yong" wrote: >Send this again. > >Two PW approach can be complex too if the VPLS instance for E-Tree uses >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >unicast traffic, and some P2MP PWs for multicast traffic. It may double >all of them. > >Lucy > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, April 18, 2012 1:42 PM >To: Lucy yong; Rogers, Josh; Sam Cao >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >I think the first option its the natural way to go. How is the processing >in this case more complex? > >Thumb typed - please be tolerant > >Lucy yong wrote: > > > >Snipped.. > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >traffic coming from a root AC) >[[LY]] Not that simple. You construct either two P2MP PWs to all other >PEs and let egress PE performing filtering, or construct one P2MP PW to >leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >perform forwarding and filtering. Both make node process complex. > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >delivering the frames to remote PEs. We should utilize them with the >minimized changes. Dual VLAN solution is simpler than Dual PW. > >Regards, >Lucy > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >haven't had any first hand experience with P2MP PW's, however, so don't >feel terribly strong about this objection. Is this a real problem for >others (now or in the future), or is this objection in the weeds? > >I'm not sure the 'additional complexity' is notable, or even relevant. I >encourage others to speak up if they disagree, as P2MP PW is only >conceptual to me, and I am unfamiliar with real-life use cases for it. > >Thanks, >Josh > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > >>Please see inline. >> >>-----Original Message----- >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>Sent: Tuesday, April 17, 2012 7:14 AM >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Yes, 2 pws are only needed between pes with both root and leaf acs after >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>P2MP >>PWs if need. There is no difference between P2MP or normal PW setup. But, >>can Leaf-ACs be bound to Root PE of P2MP PW? >> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>both root and leaf AC and some only have leaf ACs)? >>Regards, >>Lucy >> >>Regards, >> >>Yuqun (Sam) Cao >>E-mail: Yuqun.cao@gmail.com >> >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Tuesday, April 17, 2012 4:56 PM >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; >>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Adding Sam (as l2vpn@ is holding messages) >> >>DC >> >>-----Original Message----- >>From: Lucy yong [mailto:lucy.yong@huawei.com] >>Sent: Tuesday, April 17, 2012 12:39 AM >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >>Snipped, >> >>As we discussed extensively in the list, and as reflected in giles >>slide, 2 pws are only needed between pes with both root and leaf acs, >>which will typically be a small minority. >>[[LY]] Don't know if the assumption is true. Even it is the case, both >>approaches can benefit from it. I was off for a while and captures some >>discussions now. >> >>Also as per giles slide, dual vlan can have scalability issues due to >>additional lookup and double use of vlans in internal emulated lan >>interface. Also there are potential backward compatibility issues with >>silicon that doesn't support vlan mapping. >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>not clear on all the issues. Could you be more specific? As I mentioned >>in below, two PW approach makes VPLS transport construction and packet >>forwarding more complex, I can see potential backward compatibility >>issues with 2 PW solution. >> >>Regards, >>Lucy >> >>Regards, >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>In my mind, the VLAN approach means dual vlan method. >> >>The main concern for CW approach is hardware support. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>traffic, and some P2MP PWs for multicast traffic. It may double all of >>them. >> >>E-tree is an Ethernet service and there is already VLAN based solution >>in IEEE, can we just utilize it without complicating VPLS transport >>construction? This also makes interworking with Eth only network easier. >> >>Cheers, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Monday, April 16, 2012 8:35 AM >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I believe the initial question was in regard to the CW method. Are you >>saying that you no longer are interested in that method in preference of >>the dual vlan method? >> >> >> >>Lucy yong wrote: >> >> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >> >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Henderickx, Wim (Wim) >>Sent: Thursday, April 12, 2012 2:03 AM >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>The vlan approach is superior as it also works for eth only networks, >>etc. On top some vendors indicate hw issues with the cw approach. As >>such we have dropped more or less the cw approach. >> >>Cheers, >>Wim >>_________________ >>sent from blackberry >> >>----- Original Message ----- >>From: Giles Heron [mailto:giles.heron@gmail.com] >>Sent: Thursday, April 12, 2012 08:22 AM >>To: Simon Delord ; Alexander Vainshtein >> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>; Andrew Sergeev >>; Idan Kaspit ; >>Mishael Wexler ; Rotem Cohen >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Sorry - the "anonymous presentation" was mine. I should possibly have >>put in a third column on the CW approach. And hopefully the minutes >>will be posted soon. >> >>We had various discussions, as Simon stated, and consensus seemed to be >>forming around the two alternatives of two PWEs or two VLANs. I believe >>three of the authors of the CW approach are also authors of the two VLAN >>approach and one is also an author of the two PWE approach. So perhaps >>it's best to let those four individuals say which approach they prefer >>and why? >> >>Giles >> >>On 10/04/2012 00:45, "Simon Delord" wrote: >> >>> Hi Alexander, >>> >>> You are right, no discussion on the WG mailing list recently, but >>> there have been substantial discussions among the authors of various >>> solution drafts off the mailing list. As far as I know, no consensus >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>> think the CW approach has not been rejected by the WG yet, or the WG >>> has not yet decided on which one to adopt. >>> >>> Simon >>> >>> 2012/4/8 Alexander Vainshtein >>> >>>> Hi all, >>>> >>>> Unfortunately I have not been able to attend the Paris IETF. >>>> >>>> However, looking up the L2VPN proceedings, I've found a short >>>> anonymous presentation called "E-Tree Update" ( >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>> This presentation discusses the differences of the E-Tree approaches >>>> based on dedicated VLANs (as in >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>> ext=1) and multiple PWs between the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>> clude_te >>>> xt=1) >>>> and completely ignores the solution based on usage of the CW in the >>>> PWs connecting the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>> ext=1 >>>> ). >>>> >>>> >>>> >>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>> wonder whether the WG has taken a decision to reject the approach >>>> based on the CW usage? I do not remember any recent discussion of >>>> this topic on the WG mailing list. >>>> >>>> >>>> >>>> Regards, and lots of thanks in advance, >>>> >>>> Sasha >>>> >>>> >>>> >>>> >>>> >>>> This e-mail message is intended for the recipient only and contains >>>> information which is CONFIDENTIAL and which may be proprietary to ECI >> >>>> Telecom. If you have received this transmission in error, please >>>> inform us by e-mail, phone or fax, and then delete the original and >>>> all copies thereof. >>>> >> >> >> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is addressed. >>If you are not the intended recipient of this E-mail, you are hereby >>notified that any dissemination, distribution, copying, or action taken >>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this >>E-mail in error, please notify the sender immediately and permanently >>delete the original and any copy of this E-mail and any printout. >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. From DanielC@orckit.com Thu Apr 19 05:53:19 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347F121F8498 for ; Thu, 19 Apr 2012 05:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, J_BACKHAIR_34=1, J_BACKHAIR_43=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 uKnQ3I4JAwv1 for ; Thu, 19 Apr 2012 05:53:15 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4D46921F84A5 for ; Thu, 19 Apr 2012 05:53:14 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Date: Thu, 19 Apr 2012 15:53:12 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130777C285@tlvmail1> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdiov///PycP//4qvA//+OPpD//ux5AP/915BA References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, , <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><44F4E579A764584EA9BDFD07D0CA08130777C1D5@tlvmail1><14C7F4F06DB5814AB0DE29716C4F6D670129623CD2@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130777C22F@tlvmail1> From: "Daniel Cohn" To: "DelRegno, Christopher N (Nick)" , "Henderickx, Wim (Wim)" , "Alexander Vainshtein" , "Rogers, Josh" , "Lucy yong" , "Sam Cao" Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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, 19 Apr 2012 12:53:19 -0000 Nick, Thanks for the feedback. Now, do you see a problem setting up/tearing down a PW when this happens? Daniel -----Original Message----- From: DelRegno, Christopher N (Nick) [mailto:nick.delregno@verizon.com]=20 Sent: Thursday, April 19, 2012 3:40 PM To: Daniel Cohn; Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, Josh; Lucy yong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Dan: As the transformation of a PE from Root<-->Mix and Mix<-->Leaf will be driven by our customers, we can't say how often this will or won't occur. It must be accommodated regardless of perceived rarity. If I use one of our current extremely popular L2VPN services as an example, our customers tend to move their ENNI (e.g. Root) locations constantly, quite frequently to switches which heretofore only contained UNIs (e.g. leaves). Nick -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: Thursday, April 19, 2012 4:49 AM To: Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, Josh; Lucy yong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Wim, That seems to me a non-negligible change to bridge forwarding logic, I think setting up/tearing down the PE is cleaner. I don't expect that leaf-only to root/leaf PE transformations will happen all that often. But I think it's important to clarify that the issue is common to both drafts. DC -----Original Message----- From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Thursday, April 19, 2012 9:34 AM To: Daniel Cohn; Alexander Vainshtein; Rogers, Josh; Lucy yong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Daniel, we should discuss this as this is not absolutely required to tear down PW. You can also have an indication in the E-TREE fwd to indicate that the endpoint has no leaf and as such avoid sending traffic down but allow the PW to be setup. As such we have some flexibility such that operators can select the proper approach they would like to have/implement. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: donderdag 19 april 2012 8:16 To: Alexander Vainshtein; Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Sasha and all, You have exactly the same "problem" in the 2-VLAN approach - quoting from the draft: 6. LDP Extensions for E-Tree Support P is a Leaf-only bit, it is set to 1 to indicate that the PE is attached with only leaves, and set to 0 otherwise. If the P bit is set, then: { If the PE is a leaf-only node itself, then a label release message with the error code "Leaf to Leaf PW error" is sent to the peer PE and exit the process; So all that you wrote about a leaf-only PE becoming mixed and viceversa applies to both solutions. Regards, Daniel -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Thursday, April 19, 2012 8:31 AM To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Wim, Lots of thanks for a prompt response. I think that operational aspects of the VLAN approach (e.g., how is the Global VID selected and distributed) should be examined in more detail. At the same time it seems that the double PW approach carries with it too many operational problems. E.g., no PWs are set up between Leaf-only PEs, but once one of these becomes a Mix PE, all the Leaf-only PEs must now recognize it as a valid peer. And if a Mix PE reverts to a Leaf only one, all its Leaf-only peers must drop it and shut down the relevant PWs... My 2c, Sasha ________________________________________ From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] Sent: Thursday, April 19, 2012 7:21 AM To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Sasha, the VLAN approach allows for a similar operation as the CW does. It is orthogonal to the underlying PW deployment of VPLS. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: donderdag 19 april 2012 6:39 To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi all, I fully understand that that what I am going to say is not very popular, but: IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes in the PE configuration. In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root AC from a PE that previously has been supporting a mix etc. affect only the PE where this operation happens and not the rest of the PEs. As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] Sent: Wednesday, April 18, 2012 9:57 PM To: Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Again, the P2MP situation throws me. Is this something that is used commonly? I'm under the impression that adding P2MP to any model results in a more complex model. Wether outside s-tag is used to differentiate, or dedicated pw's are used for the same purpose, it seems both become more complex. Gile's comparison slide still concisely captures the differences between these methods, in my opinion. I haven't seen any new ideas or thoughts brought to the group in the past week or two on the subject. I would hate for both proposed methods to die on the vine because we couldn't decide between two methods that have nothing inherently wrong with either. -Josh On 4/18/12 1:53 PM, "Lucy yong" wrote: >Send this again. > >Two PW approach can be complex too if the VPLS instance for E-Tree uses >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >unicast traffic, and some P2MP PWs for multicast traffic. It may double >all of them. > >Lucy > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, April 18, 2012 1:42 PM >To: Lucy yong; Rogers, Josh; Sam Cao >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >I think the first option its the natural way to go. How is the processing >in this case more complex? > >Thumb typed - please be tolerant > >Lucy yong wrote: > > > >Snipped.. > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >traffic coming from a root AC) [[LY]] Not that simple. You construct >either two P2MP PWs to all other PEs and let egress PE performing >filtering, or construct one P2MP PW to leaf-only PEs and two P2MP PWs >to root and leaf PEs and let ingress PE perform forwarding and >filtering. Both make node process complex. > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >delivering the frames to remote PEs. We should utilize them with the >minimized changes. Dual VLAN solution is simpler than Dual PW. > >Regards, >Lucy > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >haven't had any first hand experience with P2MP PW's, however, so don't >feel terribly strong about this objection. Is this a real problem for >others (now or in the future), or is this objection in the weeds? > >I'm not sure the 'additional complexity' is notable, or even relevant. I >encourage others to speak up if they disagree, as P2MP PW is only >conceptual to me, and I am unfamiliar with real-life use cases for it. > >Thanks, >Josh > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > >>Please see inline. >> >>-----Original Message----- >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>Sent: Tuesday, April 17, 2012 7:14 AM >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Yes, 2 pws are only needed between pes with both root and leaf acs after >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>P2MP PWs if need. There is no difference between P2MP or normal PW >>setup. But, >>can Leaf-ACs be bound to Root PE of P2MP PW? >> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>both root and leaf AC and some only have leaf ACs)? >>Regards, >>Lucy >> >>Regards, >> >>Yuqun (Sam) Cao >>E-mail: Yuqun.cao@gmail.com >> >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Tuesday, April 17, 2012 4:56 PM >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com; Sam Cao >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Adding Sam (as l2vpn@ is holding messages) >> >>DC >> >>-----Original Message----- >>From: Lucy yong [mailto:lucy.yong@huawei.com] >>Sent: Tuesday, April 17, 2012 12:39 AM >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >>Snipped, >> >>As we discussed extensively in the list, and as reflected in giles >>slide, 2 pws are only needed between pes with both root and leaf acs, >>which will typically be a small minority. >>[[LY]] Don't know if the assumption is true. Even it is the case, both >>approaches can benefit from it. I was off for a while and captures some >>discussions now. >> >>Also as per giles slide, dual vlan can have scalability issues due to >>additional lookup and double use of vlans in internal emulated lan >>interface. Also there are potential backward compatibility issues with >>silicon that doesn't support vlan mapping. >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>not clear on all the issues. Could you be more specific? As I mentioned >>in below, two PW approach makes VPLS transport construction and packet >>forwarding more complex, I can see potential backward compatibility >>issues with 2 PW solution. >> >>Regards, >>Lucy >> >>Regards, >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>In my mind, the VLAN approach means dual vlan method. >> >>The main concern for CW approach is hardware support. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>traffic, and some P2MP PWs for multicast traffic. It may double all of >>them. >> >>E-tree is an Ethernet service and there is already VLAN based solution >>in IEEE, can we just utilize it without complicating VPLS transport >>construction? This also makes interworking with Eth only network easier. >> >>Cheers, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Monday, April 16, 2012 8:35 AM >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I believe the initial question was in regard to the CW method. Are you >>saying that you no longer are interested in that method in preference of >>the dual vlan method? >> >> >> >>Lucy yong wrote: >> >> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >> >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Henderickx, Wim (Wim) >>Sent: Thursday, April 12, 2012 2:03 AM >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>The vlan approach is superior as it also works for eth only networks, >>etc. On top some vendors indicate hw issues with the cw approach. As >>such we have dropped more or less the cw approach. >> >>Cheers, >>Wim >>_________________ >>sent from blackberry >> >>----- Original Message ----- >>From: Giles Heron [mailto:giles.heron@gmail.com] >>Sent: Thursday, April 12, 2012 08:22 AM >>To: Simon Delord ; Alexander Vainshtein >> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>; Andrew Sergeev >>; Idan Kaspit ; >>Mishael Wexler ; Rotem Cohen >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Sorry - the "anonymous presentation" was mine. I should possibly have >>put in a third column on the CW approach. And hopefully the minutes >>will be posted soon. >> >>We had various discussions, as Simon stated, and consensus seemed to be >>forming around the two alternatives of two PWEs or two VLANs. I believe >>three of the authors of the CW approach are also authors of the two VLAN >>approach and one is also an author of the two PWE approach. So perhaps >>it's best to let those four individuals say which approach they prefer >>and why? >> >>Giles >> >>On 10/04/2012 00:45, "Simon Delord" wrote: >> >>> Hi Alexander, >>> >>> You are right, no discussion on the WG mailing list recently, but >>> there have been substantial discussions among the authors of various >>> solution drafts off the mailing list. As far as I know, no consensus >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>> think the CW approach has not been rejected by the WG yet, or the WG >>> has not yet decided on which one to adopt. >>> >>> Simon >>> >>> 2012/4/8 Alexander Vainshtein >>> >>>> Hi all, >>>> >>>> Unfortunately I have not been able to attend the Paris IETF. >>>> >>>> However, looking up the L2VPN proceedings, I've found a short >>>> anonymous presentation called "E-Tree Update" ( >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>> This presentation discusses the differences of the E-Tree approaches >>>> based on dedicated VLANs (as in >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>> ext=3D1) and multiple PWs between the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>> clude_te >>>> xt=3D1) >>>> and completely ignores the solution based on usage of the CW in the >>>> PWs connecting the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>> ext=3D1 >>>> ). >>>> >>>> >>>> >>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>> wonder whether the WG has taken a decision to reject the approach >>>> based on the CW usage? I do not remember any recent discussion of >>>> this topic on the WG mailing list. >>>> >>>> >>>> >>>> Regards, and lots of thanks in advance, >>>> >>>> Sasha >>>> >>>> >>>> >>>> >>>> >>>> This e-mail message is intended for the recipient only and contains >>>> information which is CONFIDENTIAL and which may be proprietary to ECI >> >>>> Telecom. If you have received this transmission in error, please >>>> inform us by e-mail, phone or fax, and then delete the original and >>>> all copies thereof. >>>> >> >> >> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is addressed. >>If you are not the intended recipient of this E-mail, you are hereby >>notified that any dissemination, distribution, copying, or action taken >>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this >>E-mail in error, please notify the sender immediately and permanently >>delete the original and any copy of this E-mail and any printout. >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. From Alexander.Vainshtein@ecitele.com Thu Apr 19 06:19:28 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2DF21F85B4 for ; Thu, 19 Apr 2012 06:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.918 X-Spam-Level: X-Spam-Status: No, score=-2.918 tagged_above=-999 required=5 tests=[AWL=-0.716, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, 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 ykPBH3heqwFP for ; Thu, 19 Apr 2012 06:19:24 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 515D021F85B1 for ; Thu, 19 Apr 2012 06:19:23 -0700 (PDT) Received: from [85.158.143.35:52887] by server-1.bemta-4.messagelabs.com id 46/DB-20925-AD0109F4; Thu, 19 Apr 2012 13:19:22 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1334841561!5683319!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.7; banners=-,-,- Received: (qmail 21186 invoked from network); 19 Apr 2012 13:19:21 -0000 Received: from unknown (HELO fridlppsb001.ecitele.com) (168.87.1.157) by server-9.tower-21.messagelabs.com with SMTP; 19 Apr 2012 13:19:21 -0000 X-AuditID: a8571401-b7f186d000005261-b2-4f90112120e9 Received: from FRGRWPVCH001.ecitele.com (frgrwpvch001.ecitele.com [10.1.18.35]) by fridlppsb001.ecitele.com (Symantec Messaging Gateway) with SMTP id 55.88.21089.121109F4; Thu, 19 Apr 2012 15:20:33 +0200 (CEST) Received: from FRIDWPPMB002.ecitele.com ([169.254.4.167]) by FRGRWPVCH001.ecitele.com ([10.1.18.35]) with mapi id 14.01.0339.001; Thu, 19 Apr 2012 15:19:20 +0200 From: Alexander Vainshtein To: Sam Cao Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdiov//4SRIP//A88g Date: Thu, 19 Apr 2012 13:19:20 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, , <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTaUwTQRhldrfbBVldKtqx8Sir/vAA26jJGm0FNbFeKR4Rr6hrO7aL7bbp FqGamHolikIwmKhV4kG9iRxGgxFNJGpSEo8YVGyQBCFGMCreeETdZRUx7q8389733jcz31K4 rlBroAQxiAIi72HJJCIJJBjS01JK7KbP8Ylc+EE5xpWVfye4tk/1Wq766wmSO9zWTXJl2++Q maRt5/NrGtuVyFOtbcfNVxpbNPoFs+2pKsVt5ys6iWxyRRhM40XRF+SDyOhEksPCZgeEjbwj xBoFp4U1s0a/h3cgLxKDFpb3+5HoZK1Jxv++abJMEI1IdPicguiysHMW29M5bvKUdDNrXeIW JCNK9/KCx+hFksS7kFHeUU4lOtdewN3txW8wf/MRUHCgpoEIg1tbCkEiBZlJ8ER1N1DxYHi/ pZIsBEmUjmkE8PuL7Rp1cRLA4ngUU1QkY4E155+SCk5l0mBLrEWrYJxpBvDrtywFD2SyYNGL QqBqZsCOeDmuGKUy5wC8faS1p5hgRsMdH5p6MM0sgNFPRb+jP2LwUuxlD5HIcLC57n1PMpD7 +9xQgalpehhvP4qpfTMwWncPV/Eg2NH2Q6Pi4XDb2cbf3Y2Hx66+I1U8Dp46/hJXg1Ng7FA7 oeqHwBtnmogSoI/0iYj0KY/0KY/0KT8GiHNAvz4gOP1+aZ3JZM5ADiGIPCjD4fPWAHmizuSk glrwrCijHjAUYJPprkfFdp2G3yiFvPVgCIWxg+icASV2Xf91PmfIzUvuNYE8D5LqAaRwNpUG WpmjnXxoEwr4/lCcfIn7cEM/h0955eCaiSbTPwtWT1custp1jEsevQ0I+VHgT+lQimIhPYqR XVMCyIUK1gue4F8aoxKV5GQ5eaWioSU/75UEl8o3gNHUz8uxRqAjRJ+IDHo6rIgYReTOE3t9 OoFePutA2qqwyfIo9jp0yuaYbJ4GixVz+dfopQxhMGxK6+Dn180dZeHSkU+4LwWnd7eeErqt mTMfX7+zenHK1F1FTTmTdPko1p19Mz+3bES86qLtnX3269m5Ky6+L1226e2MrAkV25r2zw1Z 9s4csxxNr7vGlQa35ma+gUurvLMO/kyj50uvln2bmgDuLtzTlZA3vOvBqgHz8msfbh7bubv2 I0tIbt48Fg9I/C8QAZhoHQQAAA== Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 19 Apr 2012 13:19:28 -0000 Sam (hope this is the appropriate form of address and my apologies if not), I am actually trying to build a list of operational (not implementation-driv= en) issues that must be addressed by a reasonable E-tree solution. Then we could compare multiple approaches. As for setting up/tearing PWs with multiple peers just because your local co= nfiguration has changed, I am not sure this is reasonable from the operation= al point of view. E.g., consider the case of a Leaf-only PE migrating to a Mixed PE. To the best of my understanding, PWs between Leaf-only PWs are not ever set,= so our original Leaf PE could be unaware about existence of other Leaf-only= PEs (or, even worse, its list of Leaf-only peers could be not matching the= current situation) - and this would not affect traffic in any way. Once it suddenly becomes a Mix PE, it must set up PWs with all the Leaf-only= PEs have been ignored before, and they must agree to this... IMHO and FWIW, unless you use a very elaborate auto-discovery mechanism, thi= s process has all the potential to become an operational nightmare. My 2c, Sasha > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Thursday, April 19, 2012 3:50 PM > To: Alexander Vainshtein; 'Henderickx, Wim (Wim)'; 'Rogers, Josh'; 'Lucy > yong'; 'Daniel Cohn' > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Sasha, > > We have discussed this case before. While configuration is changed in fly, > it is reasonable to establish or teardown PW. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Thursday, April 19, 2012 1:31 PM > To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Wim, > Lots of thanks for a prompt response. > > I think that operational aspects of the VLAN approach (e.g., how is the > Global VID selected and distributed) should be examined in more detail. > > At the same time it seems that the double PW approach carries with it too > many operational problems. > E.g., no PWs are set up between Leaf-only PEs, but once one of these > becomes > a Mix PE, all the Leaf-only PEs must now recognize it as a valid peer. And > if a Mix PE reverts to a Leaf only one, all its Leaf-only peers must drop= it > and shut down the relevant PWs... > > My 2c, > Sasha > > ________________________________________ > From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] > Sent: Thursday, April 19, 2012 7:21 AM > To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Sasha, the VLAN approach allows for a similar operation as the CW does. It > is orthogonal to the underlying PW deployment of VPLS. > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of > Alexander Vainshtein > Sent: donderdag 19 april 2012 6:39 > To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Hi all, > I fully understand that that what I am going to say is not very popular, > but: > > IMO one of the advantages of the CW-based solution is that it is orthogona= l > to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and,= in > a more generic way, localization of effects of changes in the PE > configuration. > > In particular, adding a Leaf AC to a PE that previously has been only > supporting Root ACs (or vice versa), removal of the last Leaf or last Root > AC from a PE that previously has been supporting a mix etc. affect only th= e > PE where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main > disadvantage of the CW-based approach - I believe it strongly depends on > specific implementations. And some changes in the forwarding process are > required in any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of > Rogers, > Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a more > complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become more > complex. > > Gile's comparison slide still concisely captures the differences between > these methods, in my opinion. I haven't seen any new ideas or thoughts > brought to the group in the past week or two on the subject. I would hate > for both proposed methods to die on the vine because we couldn't decide > between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" wrote: > > >Send this again. > > > >Two PW approach can be complex too if the VPLS instance for E-Tree uses > >P2P PW for unicast traffic and P2MP PW for broadcast and unknown > >unicast traffic, and some P2MP PWs for multicast traffic. It may double > >all of them. > > > >Lucy > > > >-----Original Message----- > >From: Daniel Cohn [mailto:DanielC@orckit.com] > >Sent: Wednesday, April 18, 2012 1:42 PM > >To: Lucy yong; Rogers, Josh; Sam Cao > >Cc: l2vpn@ietf.org > >Subject: RE: The status of the approaches to the E-Tree solution? > > > >I think the first option its the natural way to go. How is the processing > >in this case more complex? > > > >Thumb typed - please be tolerant > > > >Lucy yong wrote: > > > > > > > >Snipped.. > > > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW > >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for > >traffic coming from a root AC) > >[[LY]] Not that simple. You construct either two P2MP PWs to all other > >PEs and let egress PE performing filtering, or construct one P2MP PW to > >leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE > >perform forwarding and filtering. Both make node process complex. > > > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for > >delivering the frames to remote PEs. We should utilize them with the > >minimized changes. Dual VLAN solution is simpler than Dual PW. > > > >Regards, > >Lucy > > > > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I > >haven't had any first hand experience with P2MP PW's, however, so don't > >feel terribly strong about this objection. Is this a real problem for > >others (now or in the future), or is this objection in the weeds? > > > >I'm not sure the 'additional complexity' is notable, or even relevant. I > >encourage others to speak up if they disagree, as P2MP PW is only > >conceptual to me, and I am unfamiliar with real-life use cases for it. > > > >Thanks, > >Josh > > > > > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > > > >>Please see inline. > >> > >>-----Original Message----- > >>From: Sam Cao [mailto:yuqun.cao@gmail.com] > >>Sent: Tuesday, April 17, 2012 7:14 AM > >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; > >>giles.heron@gmail.com; simon.delord@gmail.com; > >>Alexander.Vainshtein@ecitele.com > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > >>Subject: RE: The status of the approaches to the E-Tree solution? > >> > >>Yes, 2 pws are only needed between pes with both root and leaf acs after > >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup > 2 > >>P2MP > >>PWs if need. There is no difference between P2MP or normal PW setup. > But, > >>can Leaf-ACs be bound to Root PE of P2MP PW? > >> > >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both > >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have > >>both root and leaf AC and some only have leaf ACs)? > >>Regards, > >>Lucy > >> > >>Regards, > >> > >>Yuqun (Sam) Cao > >>E-mail: Yuqun.cao@gmail.com > >> > >> > >>-----Original Message----- > >>From: Daniel Cohn [mailto:DanielC@orckit.com] > >>Sent: Tuesday, April 17, 2012 4:56 PM > >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); > >>giles.heron@gmail.com; > >>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > >>Subject: RE: The status of the approaches to the E-Tree solution? > >> > >>Adding Sam (as l2vpn@ is holding messages) > >> > >>DC > >> > >>-----Original Message----- > >>From: Lucy yong [mailto:lucy.yong@huawei.com] > >>Sent: Tuesday, April 17, 2012 12:39 AM > >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); > >>giles.heron@gmail.com; simon.delord@gmail.com; > >>Alexander.Vainshtein@ecitele.com > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > >>Subject: RE: The status of the approaches to the E-Tree solution? > >> > >> > >>Snipped, > >> > >>As we discussed extensively in the list, and as reflected in giles > >>slide, 2 pws are only needed between pes with both root and leaf acs, > >>which will typically be a small minority. > >>[[LY]] Don't know if the assumption is true. Even it is the case, both > >>approaches can benefit from it. I was off for a while and captures some > >>discussions now. > >> > >>Also as per giles slide, dual vlan can have scalability issues due to > >>additional lookup and double use of vlans in internal emulated lan > >>interface. Also there are potential backward compatibility issues with > >>silicon that doesn't support vlan mapping. > >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am > >>not clear on all the issues. Could you be more specific? As I mentioned > >>in below, two PW approach makes VPLS transport construction and packet > >>forwarding more complex, I can see potential backward compatibility > >>issues with 2 PW solution. > >> > >>Regards, > >>Lucy > >> > >>Regards, > >> > >>Daniel > >> > >>Thumb typed - please be tolerant > >> > >>Lucy yong wrote: > >> > >>In my mind, the VLAN approach means dual vlan method. > >> > >>The main concern for CW approach is hardware support. > >> > >>Two PW approach can be complex too if the VPLS instance for E-Tree uses > >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown > unicast > >>traffic, and some P2MP PWs for multicast traffic. It may double all of > >>them. > >> > >>E-tree is an Ethernet service and there is already VLAN based solution > >>in IEEE, can we just utilize it without complicating VPLS transport > >>construction? This also makes interworking with Eth only network easier. > >> > >>Cheers, > >>Lucy > >> > >>-----Original Message----- > >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] > >>Sent: Monday, April 16, 2012 8:35 AM > >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; > >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' > >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; > >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; > >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' > >>Subject: RE: The status of the approaches to the E-Tree solution? > >> > >>I believe the initial question was in regard to the CW method. Are you > >>saying that you no longer are interested in that method in preference of > >>the dual vlan method? > >> > >> > >> > >>Lucy yong wrote: > >> > >> > >>Agree with Wim. VLAN approach is the best solution for E-Tree. > >> > >>Lucy > >> > >>-----Original Message----- > >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > >>Of Henderickx, Wim (Wim) > >>Sent: Thursday, April 12, 2012 2:03 AM > >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; > >>'Alexander.Vainshtein@ecitele.com' > >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; > >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; > >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' > >>Subject: Re: The status of the approaches to the E-Tree solution? > >> > >>The vlan approach is superior as it also works for eth only networks, > >>etc. On top some vendors indicate hw issues with the cw approach. As > >>such we have dropped more or less the cw approach. > >> > >>Cheers, > >>Wim > >>_________________ > >>sent from blackberry > >> > >>----- Original Message ----- > >>From: Giles Heron [mailto:giles.heron@gmail.com] > >>Sent: Thursday, April 12, 2012 08:22 AM > >>To: Simon Delord ; Alexander Vainshtein > >> > >>Cc: l2vpn@ietf.org ; Vladimir Kleiner > >>; Andrew Sergeev > >>; Idan Kaspit ; > >>Mishael Wexler ; Rotem Cohen > >> > >>Subject: Re: The status of the approaches to the E-Tree solution? > >> > >>Sorry - the "anonymous presentation" was mine. I should possibly have > >>put in a third column on the CW approach. And hopefully the minutes > >>will be posted soon. > >> > >>We had various discussions, as Simon stated, and consensus seemed to > be > >>forming around the two alternatives of two PWEs or two VLANs. I believe > >>three of the authors of the CW approach are also authors of the two VLAN > >>approach and one is also an author of the two PWE approach. So perhaps > >>it's best to let those four individuals say which approach they prefer > >>and why? > >> > >>Giles > >> > >>On 10/04/2012 00:45, "Simon Delord" wrote: > >> > >>> Hi Alexander, > >>> > >>> You are right, no discussion on the WG mailing list recently, but > >>> there have been substantial discussions among the authors of various > >>> solution drafts off the mailing list. As far as I know, no consensus > >>> yet before ietf83, not sure the progress in the Paris WG meeting. I > >>> think the CW approach has not been rejected by the WG yet, or the WG > >>> has not yet decided on which one to adopt. > >>> > >>> Simon > >>> > >>> 2012/4/8 Alexander Vainshtein > >>> > >>>> Hi all, > >>>> > >>>> Unfortunately I have not been able to attend the Paris IETF. > >>>> > >>>> However, looking up the L2VPN proceedings, I've found a short > >>>> anonymous presentation called "E-Tree Update" ( > >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). > >>>> This presentation discusses the differences of the E-Tree approaches > >>>> based on dedicated VLANs (as in > >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t > >>>> ext=3D1) and multiple PWs between the PEs (as in > >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple- > pw/?in > >>>> clude_te > >>>> xt=3D1) > >>>> and completely ignores the solution based on usage of the CW in the > >>>> PWs connecting the PEs (as in > >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t > >>>> ext=3D1 > >>>> ). > >>>> > >>>> > >>>> > >>>> The Minutes of the Paris L2VPN session are not yet available, but I > >>>> wonder whether the WG has taken a decision to reject the approach > >>>> based on the CW usage? I do not remember any recent discussion of > >>>> this topic on the WG mailing list. > >>>> > >>>> > >>>> > >>>> Regards, and lots of thanks in advance, > >>>> > >>>> Sasha > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> This e-mail message is intended for the recipient only and contains > >>>> information which is CONFIDENTIAL and which may be proprietary to > ECI > >> > >>>> Telecom. If you have received this transmission in error, please > >>>> inform us by e-mail, phone or fax, and then delete the original and > >>>> all copies thereof. > >>>> > >> > >> > >> > >> > >> > >>This E-mail and any of its attachments may contain Time Warner Cable > >>proprietary information, which is privileged, confidential, or subject > >>to copyright belonging to Time Warner Cable. This E-mail is intended > >>solely for the use of the individual or entity to which it is addressed. > >>If you are not the intended recipient of this E-mail, you are hereby > >>notified that any dissemination, distribution, copying, or action taken > >>in relation to the contents of and attachments to this E-mail is > >>strictly prohibited and may be unlawful. If you have received this > >>E-mail in error, please notify the sender immediately and permanently > >>delete the original and any copy of this E-mail and any printout. > >> > > > > > >This E-mail and any of its attachments may contain Time Warner Cable > >proprietary information, which is privileged, confidential, or subject to > >copyright belonging to Time Warner Cable. This E-mail is intended solely > >for the use of the individual or entity to which it is addressed. If you > >are not the intended recipient of this E-mail, you are hereby notified > >that any dissemination, distribution, copying, or action taken in > >relation to the contents of and attachments to this E-mail is strictly > >prohibited and may be unlawful. If you have received this E-mail in > >error, please notify the sender immediately and permanently delete the > >original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely f= or > the use of the individual or entity to which it is addressed. If you are n= ot > the intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may= be > unlawful. If you have received this E-mail in error, please notify the > sender immediately and permanently delete the original and any copy of > this > E-mail and any printout. > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us > by e-mail, phone or fax, and then delete the original and all copies > thereof. > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us > by e-mail, phone or fax, and then delete the original and all copies > thereof. > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From wim.henderickx@alcatel-lucent.com Thu Apr 19 06:51:56 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFC421F85CD for ; Thu, 19 Apr 2012 06:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.048 X-Spam-Level: X-Spam-Status: No, score=-9.048 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, HELO_EQ_FR=0.35, HS_INDEX_PARAM=0.001, J_BACKHAIR_34=1, J_BACKHAIR_43=1, 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 PWZXsoDkqa6C for ; Thu, 19 Apr 2012 06:51:50 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 188EE21F85A2 for ; Thu, 19 Apr 2012 06:51:49 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3JDp2OH016939 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 19 Apr 2012 15:51:13 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 19 Apr 2012 15:51:01 +0200 From: "Henderickx, Wim (Wim)" To: "DelRegno, Christopher N (Nick)" , Daniel Cohn , Alexander Vainshtein , "Rogers, Josh" , Lucy yong , Sam Cao Date: Thu, 19 Apr 2012 15:51:00 +0200 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdiov///PycP//4qvA//+OPpD//ux5AP/9xD/w Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D670129623F96@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, , <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130777C1D5@tlvmail1> <14C7F4F06DB5814AB0DE29716C4F6D670129623CD2@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130777C22F@tlvmail1> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 19 Apr 2012 13:51:56 -0000 Nick, thx for sharing this information. Would you have a problem if the PW = would come up/tiered down are would you prefer the PW to remain intact if s= uch change happens? -----Original Message----- From: DelRegno, Christopher N (Nick) [mailto:nick.delregno@verizon.com] Sent: donderdag 19 april 2012 14:40 To: Daniel Cohn; Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, Josh;= Lucy yong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Dan: As the transformation of a PE from Root<-->Mix and Mix<-->Leaf will be driv= en by our customers, we can't say how often this will or won't occur. It m= ust be accommodated regardless of perceived rarity. If I use one of our current extremely popular L2VPN services as an example,= our customers tend to move their ENNI (e.g. Root) locations constantly, qu= ite frequently to switches which heretofore only contained UNIs (e.g. leave= s). Nick -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Thursday, April 19, 2012 4:49 AM To: Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, Josh; Lucy yong; S= am Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Wim, That seems to me a non-negligible change to bridge forwarding logic, I thin= k setting up/tearing down the PE is cleaner. I don't expect that leaf-only = to root/leaf PE transformations will happen all that often. But I think it's important to clarify that the issue is common to both draf= ts. DC -----Original Message----- From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Thursday, April 19, 2012 9:34 AM To: Daniel Cohn; Alexander Vainshtein; Rogers, Josh; Lucy yong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Daniel, we should discuss this as this is not absolutely required to tear d= own PW. You can also have an indication in the E-TREE fwd to indicate that = the endpoint has no leaf and as such avoid sending traffic down but allow t= he PW to be setup. As such we have some flexibility such that operators can= select the proper approach they would like to have/implement. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: donderdag 19 april 2012 8:16 To: Alexander Vainshtein; Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; S= am Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Sasha and all, You have exactly the same "problem" in the 2-VLAN approach - quoting from t= he draft: 6. LDP Extensions for E-Tree Support P is a Leaf-only bit, it is set to 1 to indicate that the PE is attached wi= th only leaves, and set to 0 otherwise. If the P bit is set, then: { If the PE is a leaf-only node itself, then a label release message with the error code "Leaf to Leaf PW error" is sent to the peer PE and exit the process; So all that you wrote about a leaf-only PE becoming mixed and viceversa app= lies to both solutions. Regards, Daniel -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Thursday, April 19, 2012 8:31 AM To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Wim, Lots of thanks for a prompt response. I think that operational aspects of the VLAN approach (e.g., how is the Glo= bal VID selected and distributed) should be examined in more detail. At the same time it seems that the double PW approach carries with it too m= any operational problems. E.g., no PWs are set up between Leaf-only PEs, but once one of these become= s a Mix PE, all the Leaf-only PEs must now recognize it as a valid peer. An= d if a Mix PE reverts to a Leaf only one, all its Leaf-only peers must drop= it and shut down the relevant PWs... My 2c, Sasha ________________________________________ From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] Sent: Thursday, April 19, 2012 7:21 AM To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Sasha, the VLAN approach allows for a similar operation as the CW does. It is orthogonal to the underlying PW deployment of VPLS. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of A= lexander Vainshtein Sent: donderdag 19 april 2012 6:39 To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi all, I fully understand that that what I am going to say is not very popular, but: IMO one of the advantages of the CW-based solution is that it is orthogonal= to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, i= n a more generic way, localization of effects of changes in the PE configur= ation. In particular, adding a Leaf AC to a PE that previously has been only suppo= rting Root ACs (or vice versa), removal of the last Leaf or last Root AC fr= om a PE that previously has been supporting a mix etc. affect only the PE w= here this operation happens and not the rest of the PEs. As for the need for HW changes that have been mentioned as a main disadvant= age of the CW-based approach - I believe it strongly depends on specific im= plementations. And some changes in the forwarding process are required in a= ny solution. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, = Josh [josh.rogers@twcable.com] Sent: Wednesday, April 18, 2012 9:57 PM To: Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Again, the P2MP situation throws me. Is this something that is used common= ly? I'm under the impression that adding P2MP to any model results in a more co= mplex model. Wether outside s-tag is used to differentiate, or dedicated p= w's are used for the same purpose, it seems both become more complex. Gile's comparison slide still concisely captures the differences between th= ese methods, in my opinion. I haven't seen any new ideas or thoughts broug= ht to the group in the past week or two on the subject. I would hate for b= oth proposed methods to die on the vine because we couldn't decide between = two methods that have nothing inherently wrong with either. -Josh On 4/18/12 1:53 PM, "Lucy yong" wrote: >Send this again. > >Two PW approach can be complex too if the VPLS instance for E-Tree uses >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >unicast traffic, and some P2MP PWs for multicast traffic. It may double >all of them. > >Lucy > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, April 18, 2012 1:42 PM >To: Lucy yong; Rogers, Josh; Sam Cao >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >I think the first option its the natural way to go. How is the processing >in this case more complex? > >Thumb typed - please be tolerant > >Lucy yong wrote: > > > >Snipped.. > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >traffic coming from a root AC) [[LY]] Not that simple. You construct >either two P2MP PWs to all other PEs and let egress PE performing >filtering, or construct one P2MP PW to leaf-only PEs and two P2MP PWs >to root and leaf PEs and let ingress PE perform forwarding and >filtering. Both make node process complex. > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >delivering the frames to remote PEs. We should utilize them with the >minimized changes. Dual VLAN solution is simpler than Dual PW. > >Regards, >Lucy > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >haven't had any first hand experience with P2MP PW's, however, so don't >feel terribly strong about this objection. Is this a real problem for >others (now or in the future), or is this objection in the weeds? > >I'm not sure the 'additional complexity' is notable, or even relevant. I >encourage others to speak up if they disagree, as P2MP PW is only >conceptual to me, and I am unfamiliar with real-life use cases for it. > >Thanks, >Josh > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > >>Please see inline. >> >>-----Original Message----- >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>Sent: Tuesday, April 17, 2012 7:14 AM >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Yes, 2 pws are only needed between pes with both root and leaf acs after >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>P2MP PWs if need. There is no difference between P2MP or normal PW >>setup. But, >>can Leaf-ACs be bound to Root PE of P2MP PW? >> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>both root and leaf AC and some only have leaf ACs)? >>Regards, >>Lucy >> >>Regards, >> >>Yuqun (Sam) Cao >>E-mail: Yuqun.cao@gmail.com >> >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Tuesday, April 17, 2012 4:56 PM >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com; Sam Cao >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Adding Sam (as l2vpn@ is holding messages) >> >>DC >> >>-----Original Message----- >>From: Lucy yong [mailto:lucy.yong@huawei.com] >>Sent: Tuesday, April 17, 2012 12:39 AM >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >>Snipped, >> >>As we discussed extensively in the list, and as reflected in giles >>slide, 2 pws are only needed between pes with both root and leaf acs, >>which will typically be a small minority. >>[[LY]] Don't know if the assumption is true. Even it is the case, both >>approaches can benefit from it. I was off for a while and captures some >>discussions now. >> >>Also as per giles slide, dual vlan can have scalability issues due to >>additional lookup and double use of vlans in internal emulated lan >>interface. Also there are potential backward compatibility issues with >>silicon that doesn't support vlan mapping. >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>not clear on all the issues. Could you be more specific? As I mentioned >>in below, two PW approach makes VPLS transport construction and packet >>forwarding more complex, I can see potential backward compatibility >>issues with 2 PW solution. >> >>Regards, >>Lucy >> >>Regards, >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>In my mind, the VLAN approach means dual vlan method. >> >>The main concern for CW approach is hardware support. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>traffic, and some P2MP PWs for multicast traffic. It may double all of >>them. >> >>E-tree is an Ethernet service and there is already VLAN based solution >>in IEEE, can we just utilize it without complicating VPLS transport >>construction? This also makes interworking with Eth only network easier. >> >>Cheers, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Monday, April 16, 2012 8:35 AM >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I believe the initial question was in regard to the CW method. Are you >>saying that you no longer are interested in that method in preference of >>the dual vlan method? >> >> >> >>Lucy yong wrote: >> >> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >> >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Henderickx, Wim (Wim) >>Sent: Thursday, April 12, 2012 2:03 AM >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>The vlan approach is superior as it also works for eth only networks, >>etc. On top some vendors indicate hw issues with the cw approach. As >>such we have dropped more or less the cw approach. >> >>Cheers, >>Wim >>_________________ >>sent from blackberry >> >>----- Original Message ----- >>From: Giles Heron [mailto:giles.heron@gmail.com] >>Sent: Thursday, April 12, 2012 08:22 AM >>To: Simon Delord ; Alexander Vainshtein >> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>; Andrew Sergeev >>; Idan Kaspit ; >>Mishael Wexler ; Rotem Cohen >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Sorry - the "anonymous presentation" was mine. I should possibly have >>put in a third column on the CW approach. And hopefully the minutes >>will be posted soon. >> >>We had various discussions, as Simon stated, and consensus seemed to be >>forming around the two alternatives of two PWEs or two VLANs. I believe >>three of the authors of the CW approach are also authors of the two VLAN >>approach and one is also an author of the two PWE approach. So perhaps >>it's best to let those four individuals say which approach they prefer >>and why? >> >>Giles >> >>On 10/04/2012 00:45, "Simon Delord" wrote: >> >>> Hi Alexander, >>> >>> You are right, no discussion on the WG mailing list recently, but >>> there have been substantial discussions among the authors of various >>> solution drafts off the mailing list. As far as I know, no consensus >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>> think the CW approach has not been rejected by the WG yet, or the WG >>> has not yet decided on which one to adopt. >>> >>> Simon >>> >>> 2012/4/8 Alexander Vainshtein >>> >>>> Hi all, >>>> >>>> Unfortunately I have not been able to attend the Paris IETF. >>>> >>>> However, looking up the L2VPN proceedings, I've found a short >>>> anonymous presentation called "E-Tree Update" ( >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>> This presentation discusses the differences of the E-Tree approaches >>>> based on dedicated VLANs (as in >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>> ext=3D1) and multiple PWs between the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>> clude_te >>>> xt=3D1) >>>> and completely ignores the solution based on usage of the CW in the >>>> PWs connecting the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>> ext=3D1 >>>> ). >>>> >>>> >>>> >>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>> wonder whether the WG has taken a decision to reject the approach >>>> based on the CW usage? I do not remember any recent discussion of >>>> this topic on the WG mailing list. >>>> >>>> >>>> >>>> Regards, and lots of thanks in advance, >>>> >>>> Sasha >>>> >>>> >>>> >>>> >>>> >>>> This e-mail message is intended for the recipient only and contains >>>> information which is CONFIDENTIAL and which may be proprietary to ECI >> >>>> Telecom. If you have received this transmission in error, please >>>> inform us by e-mail, phone or fax, and then delete the original and >>>> all copies thereof. >>>> >> >> >> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is addressed. >>If you are not the intended recipient of this E-mail, you are hereby >>notified that any dissemination, distribution, copying, or action taken >>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this >>E-mail in error, please notify the sender immediately and permanently >>delete the original and any copy of this E-mail and any printout. >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notifi= ed that any dissemination, distribution, copying, or action taken in relati= on to the contents of and attachments to this E-mail is strictly prohibited= and may be unlawful. If you have received this E-mail in error, please not= ify the sender immediately and permanently delete the original and any copy= of this E-mail and any printout. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. From nick.delregno@verizon.com Thu Apr 19 09:38:00 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15CA721F86D0 for ; Thu, 19 Apr 2012 09:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, J_BACKHAIR_34=1, J_BACKHAIR_43=1, 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 SDvcm-L1t5o8 for ; Thu, 19 Apr 2012 09:37:56 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id B251321F86CB for ; Thu, 19 Apr 2012 09:37:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe01.verizon.com with ESMTP; 19 Apr 2012 16:37:54 +0000 From: "DelRegno, Christopher N \(Nick\)" X-IronPort-AV: E=Sophos;i="4.75,447,1330905600"; d="scan'208";a="257368633" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi01.verizon.com with ESMTP; 19 Apr 2012 16:37:52 +0000 Received: from FHDP1LUMXC7V42.us.one.verizon.com ([169.254.2.127]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Thu, 19 Apr 2012 12:37:52 -0400 To: Daniel Cohn , "Henderickx, Wim (Wim)" , Alexander Vainshtein , "Rogers, Josh" , Lucy yong , Sam Cao Date: Thu, 19 Apr 2012 12:37:50 -0400 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdiov///PycP//4qvA//+OPpD//ux5AP/915BA//ujPiA= Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, , <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><44F4E579A764584EA9BDFD07D0CA08130777C1D5@tlvmail1><14C7F4F06DB5814AB0DE29716C4F6D670129623CD2@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130777C22F@tlvmail1> <44F4E579A764584EA9BDFD07D0CA08130777C285@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130777C285@tlvmail1> 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 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 19 Apr 2012 16:38:00 -0000 No, I don't see a problem with setting up/tearing down a PW when there is a= move of the root to leaf nodes or vice versa, assuming the move is based o= n a provisioning action (e.g. an customer order), not some dynamic bouncing= between switches. Nick -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Thursday, April 19, 2012 7:53 AM To: DelRegno, Christopher N (Nick); Henderickx, Wim (Wim); Alexander Vainsh= tein; Rogers, Josh; Lucy yong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Nick, Thanks for the feedback. Now, do you see a problem setting up/tearing down = a PW when this happens? Daniel -----Original Message----- From: DelRegno, Christopher N (Nick) [mailto:nick.delregno@verizon.com] Sent: Thursday, April 19, 2012 3:40 PM To: Daniel Cohn; Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, Josh;= Lucy yong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Dan: As the transformation of a PE from Root<-->Mix and Mix<-->Leaf will be driv= en by our customers, we can't say how often this will or won't occur. It m= ust be accommodated regardless of perceived rarity. If I use one of our current extremely popular L2VPN services as an example,= our customers tend to move their ENNI (e.g. Root) locations constantly, qu= ite frequently to switches which heretofore only contained UNIs (e.g. leave= s). Nick -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Thursday, April 19, 2012 4:49 AM To: Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, Josh; Lucy yong; S= am Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Wim, That seems to me a non-negligible change to bridge forwarding logic, I thin= k setting up/tearing down the PE is cleaner. I don't expect that leaf-only = to root/leaf PE transformations will happen all that often. But I think it's important to clarify that the issue is common to both draf= ts. DC -----Original Message----- From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Thursday, April 19, 2012 9:34 AM To: Daniel Cohn; Alexander Vainshtein; Rogers, Josh; Lucy yong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Daniel, we should discuss this as this is not absolutely required to tear d= own PW. You can also have an indication in the E-TREE fwd to indicate that = the endpoint has no leaf and as such avoid sending traffic down but allow t= he PW to be setup. As such we have some flexibility such that operators can= select the proper approach they would like to have/implement. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: donderdag 19 april 2012 8:16 To: Alexander Vainshtein; Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; S= am Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Sasha and all, You have exactly the same "problem" in the 2-VLAN approach - quoting from t= he draft: 6. LDP Extensions for E-Tree Support P is a Leaf-only bit, it is set to 1 to indicate that the PE is attached wi= th only leaves, and set to 0 otherwise. If the P bit is set, then: { If the PE is a leaf-only node itself, then a label release message with the error code "Leaf to Leaf PW error" is sent to the peer PE and exit the process; So all that you wrote about a leaf-only PE becoming mixed and viceversa app= lies to both solutions. Regards, Daniel -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Thursday, April 19, 2012 8:31 AM To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Wim, Lots of thanks for a prompt response. I think that operational aspects of the VLAN approach (e.g., how is the Glo= bal VID selected and distributed) should be examined in more detail. At the same time it seems that the double PW approach carries with it too m= any operational problems. E.g., no PWs are set up between Leaf-only PEs, but once one of these become= s a Mix PE, all the Leaf-only PEs must now recognize it as a valid peer. An= d if a Mix PE reverts to a Leaf only one, all its Leaf-only peers must drop= it and shut down the relevant PWs... My 2c, Sasha ________________________________________ From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] Sent: Thursday, April 19, 2012 7:21 AM To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Sasha, the VLAN approach allows for a similar operation as the CW does. It is orthogonal to the underlying PW deployment of VPLS. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of A= lexander Vainshtein Sent: donderdag 19 april 2012 6:39 To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi all, I fully understand that that what I am going to say is not very popular, but: IMO one of the advantages of the CW-based solution is that it is orthogonal= to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, i= n a more generic way, localization of effects of changes in the PE configur= ation. In particular, adding a Leaf AC to a PE that previously has been only suppo= rting Root ACs (or vice versa), removal of the last Leaf or last Root AC fr= om a PE that previously has been supporting a mix etc. affect only the PE w= here this operation happens and not the rest of the PEs. As for the need for HW changes that have been mentioned as a main disadvant= age of the CW-based approach - I believe it strongly depends on specific im= plementations. And some changes in the forwarding process are required in a= ny solution. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, = Josh [josh.rogers@twcable.com] Sent: Wednesday, April 18, 2012 9:57 PM To: Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Again, the P2MP situation throws me. Is this something that is used common= ly? I'm under the impression that adding P2MP to any model results in a more co= mplex model. Wether outside s-tag is used to differentiate, or dedicated p= w's are used for the same purpose, it seems both become more complex. Gile's comparison slide still concisely captures the differences between th= ese methods, in my opinion. I haven't seen any new ideas or thoughts broug= ht to the group in the past week or two on the subject. I would hate for b= oth proposed methods to die on the vine because we couldn't decide between = two methods that have nothing inherently wrong with either. -Josh On 4/18/12 1:53 PM, "Lucy yong" wrote: >Send this again. > >Two PW approach can be complex too if the VPLS instance for E-Tree uses >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >unicast traffic, and some P2MP PWs for multicast traffic. It may double >all of them. > >Lucy > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, April 18, 2012 1:42 PM >To: Lucy yong; Rogers, Josh; Sam Cao >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >I think the first option its the natural way to go. How is the processing >in this case more complex? > >Thumb typed - please be tolerant > >Lucy yong wrote: > > > >Snipped.. > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >traffic coming from a root AC) [[LY]] Not that simple. You construct >either two P2MP PWs to all other PEs and let egress PE performing >filtering, or construct one P2MP PW to leaf-only PEs and two P2MP PWs >to root and leaf PEs and let ingress PE perform forwarding and >filtering. Both make node process complex. > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >delivering the frames to remote PEs. We should utilize them with the >minimized changes. Dual VLAN solution is simpler than Dual PW. > >Regards, >Lucy > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >haven't had any first hand experience with P2MP PW's, however, so don't >feel terribly strong about this objection. Is this a real problem for >others (now or in the future), or is this objection in the weeds? > >I'm not sure the 'additional complexity' is notable, or even relevant. I >encourage others to speak up if they disagree, as P2MP PW is only >conceptual to me, and I am unfamiliar with real-life use cases for it. > >Thanks, >Josh > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > >>Please see inline. >> >>-----Original Message----- >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>Sent: Tuesday, April 17, 2012 7:14 AM >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Yes, 2 pws are only needed between pes with both root and leaf acs after >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>P2MP PWs if need. There is no difference between P2MP or normal PW >>setup. But, >>can Leaf-ACs be bound to Root PE of P2MP PW? >> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>both root and leaf AC and some only have leaf ACs)? >>Regards, >>Lucy >> >>Regards, >> >>Yuqun (Sam) Cao >>E-mail: Yuqun.cao@gmail.com >> >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Tuesday, April 17, 2012 4:56 PM >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com; Sam Cao >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Adding Sam (as l2vpn@ is holding messages) >> >>DC >> >>-----Original Message----- >>From: Lucy yong [mailto:lucy.yong@huawei.com] >>Sent: Tuesday, April 17, 2012 12:39 AM >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >>Snipped, >> >>As we discussed extensively in the list, and as reflected in giles >>slide, 2 pws are only needed between pes with both root and leaf acs, >>which will typically be a small minority. >>[[LY]] Don't know if the assumption is true. Even it is the case, both >>approaches can benefit from it. I was off for a while and captures some >>discussions now. >> >>Also as per giles slide, dual vlan can have scalability issues due to >>additional lookup and double use of vlans in internal emulated lan >>interface. Also there are potential backward compatibility issues with >>silicon that doesn't support vlan mapping. >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>not clear on all the issues. Could you be more specific? As I mentioned >>in below, two PW approach makes VPLS transport construction and packet >>forwarding more complex, I can see potential backward compatibility >>issues with 2 PW solution. >> >>Regards, >>Lucy >> >>Regards, >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>In my mind, the VLAN approach means dual vlan method. >> >>The main concern for CW approach is hardware support. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>traffic, and some P2MP PWs for multicast traffic. It may double all of >>them. >> >>E-tree is an Ethernet service and there is already VLAN based solution >>in IEEE, can we just utilize it without complicating VPLS transport >>construction? This also makes interworking with Eth only network easier. >> >>Cheers, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Monday, April 16, 2012 8:35 AM >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I believe the initial question was in regard to the CW method. Are you >>saying that you no longer are interested in that method in preference of >>the dual vlan method? >> >> >> >>Lucy yong wrote: >> >> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >> >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Henderickx, Wim (Wim) >>Sent: Thursday, April 12, 2012 2:03 AM >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>The vlan approach is superior as it also works for eth only networks, >>etc. On top some vendors indicate hw issues with the cw approach. As >>such we have dropped more or less the cw approach. >> >>Cheers, >>Wim >>_________________ >>sent from blackberry >> >>----- Original Message ----- >>From: Giles Heron [mailto:giles.heron@gmail.com] >>Sent: Thursday, April 12, 2012 08:22 AM >>To: Simon Delord ; Alexander Vainshtein >> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>; Andrew Sergeev >>; Idan Kaspit ; >>Mishael Wexler ; Rotem Cohen >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Sorry - the "anonymous presentation" was mine. I should possibly have >>put in a third column on the CW approach. And hopefully the minutes >>will be posted soon. >> >>We had various discussions, as Simon stated, and consensus seemed to be >>forming around the two alternatives of two PWEs or two VLANs. I believe >>three of the authors of the CW approach are also authors of the two VLAN >>approach and one is also an author of the two PWE approach. So perhaps >>it's best to let those four individuals say which approach they prefer >>and why? >> >>Giles >> >>On 10/04/2012 00:45, "Simon Delord" wrote: >> >>> Hi Alexander, >>> >>> You are right, no discussion on the WG mailing list recently, but >>> there have been substantial discussions among the authors of various >>> solution drafts off the mailing list. As far as I know, no consensus >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>> think the CW approach has not been rejected by the WG yet, or the WG >>> has not yet decided on which one to adopt. >>> >>> Simon >>> >>> 2012/4/8 Alexander Vainshtein >>> >>>> Hi all, >>>> >>>> Unfortunately I have not been able to attend the Paris IETF. >>>> >>>> However, looking up the L2VPN proceedings, I've found a short >>>> anonymous presentation called "E-Tree Update" ( >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>> This presentation discusses the differences of the E-Tree approaches >>>> based on dedicated VLANs (as in >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>> ext=3D1) and multiple PWs between the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>> clude_te >>>> xt=3D1) >>>> and completely ignores the solution based on usage of the CW in the >>>> PWs connecting the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>> ext=3D1 >>>> ). >>>> >>>> >>>> >>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>> wonder whether the WG has taken a decision to reject the approach >>>> based on the CW usage? I do not remember any recent discussion of >>>> this topic on the WG mailing list. >>>> >>>> >>>> >>>> Regards, and lots of thanks in advance, >>>> >>>> Sasha >>>> >>>> >>>> >>>> >>>> >>>> This e-mail message is intended for the recipient only and contains >>>> information which is CONFIDENTIAL and which may be proprietary to ECI >> >>>> Telecom. If you have received this transmission in error, please >>>> inform us by e-mail, phone or fax, and then delete the original and >>>> all copies thereof. >>>> >> >> >> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is addressed. >>If you are not the intended recipient of this E-mail, you are hereby >>notified that any dissemination, distribution, copying, or action taken >>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this >>E-mail in error, please notify the sender immediately and permanently >>delete the original and any copy of this E-mail and any printout. >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notifi= ed that any dissemination, distribution, copying, or action taken in relati= on to the contents of and attachments to this E-mail is strictly prohibited= and may be unlawful. If you have received this E-mail in error, please not= ify the sender immediately and permanently delete the original and any copy= of this E-mail and any printout. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. From nick.delregno@verizon.com Thu Apr 19 09:45:51 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E2221F85B1 for ; Thu, 19 Apr 2012 09:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, J_BACKHAIR_34=1, J_BACKHAIR_43=1, 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 DzDpfuG8OpiL for ; Thu, 19 Apr 2012 09:45:47 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 19BCE21F86F5 for ; Thu, 19 Apr 2012 09:45:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe02.verizon.com with ESMTP; 19 Apr 2012 16:45:45 +0000 From: "DelRegno, Christopher N \(Nick\)" X-IronPort-AV: E=Sophos;i="4.75,447,1330905600"; d="scan'208";a="255274080" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi02.verizon.com with ESMTP; 19 Apr 2012 16:45:45 +0000 Received: from FHDP1LUMXC7V42.us.one.verizon.com ([169.254.2.127]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Thu, 19 Apr 2012 12:45:45 -0400 To: "Henderickx, Wim (Wim)" , Daniel Cohn , Alexander Vainshtein , "Rogers, Josh" , Lucy yong , Sam Cao Date: Thu, 19 Apr 2012 12:45:42 -0400 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdiov///PycP//4qvA//+OPpD//ux5AP/9xD/w//tZXFA= Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, , <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130777C1D5@tlvmail1> <14C7F4F06DB5814AB0DE29716C4F6D670129623CD2@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130777C22F@tlvmail1> <14C7F4F06DB5814AB0DE29716C4F6D670129623F96@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D670129623F96@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 19 Apr 2012 16:45:51 -0000 Wim: My use case assumes that the change was precipitated by a customer order an= d subsequent provisioning change. For example, the customer wishes to enab= le LEAF attachments out of a CO where previously they only had the ROOT, or= vice versa. Given that assumption, the original PW should be torn down. Ideally, I would like a mechanism to automatically signal this along the li= nes of BGP-AD, so that my provisioning systems only have to worry about whe= re the customer attaches, what kind of attachment (root/leaf) and to which = instance. Nick -----Original Message----- From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Thursday, April 19, 2012 8:51 AM To: DelRegno, Christopher N (Nick); Daniel Cohn; Alexander Vainshtein; Roge= rs, Josh; Lucy yong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Nick, thx for sharing this information. Would you have a problem if the PW = would come up/tiered down are would you prefer the PW to remain intact if s= uch change happens? -----Original Message----- From: DelRegno, Christopher N (Nick) [mailto:nick.delregno@verizon.com] Sent: donderdag 19 april 2012 14:40 To: Daniel Cohn; Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, Josh;= Lucy yong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Dan: As the transformation of a PE from Root<-->Mix and Mix<-->Leaf will be driv= en by our customers, we can't say how often this will or won't occur. It m= ust be accommodated regardless of perceived rarity. If I use one of our current extremely popular L2VPN services as an example,= our customers tend to move their ENNI (e.g. Root) locations constantly, qu= ite frequently to switches which heretofore only contained UNIs (e.g. leave= s). Nick -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Thursday, April 19, 2012 4:49 AM To: Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, Josh; Lucy yong; S= am Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Wim, That seems to me a non-negligible change to bridge forwarding logic, I thin= k setting up/tearing down the PE is cleaner. I don't expect that leaf-only = to root/leaf PE transformations will happen all that often. But I think it's important to clarify that the issue is common to both draf= ts. DC -----Original Message----- From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Thursday, April 19, 2012 9:34 AM To: Daniel Cohn; Alexander Vainshtein; Rogers, Josh; Lucy yong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Daniel, we should discuss this as this is not absolutely required to tear d= own PW. You can also have an indication in the E-TREE fwd to indicate that = the endpoint has no leaf and as such avoid sending traffic down but allow t= he PW to be setup. As such we have some flexibility such that operators can= select the proper approach they would like to have/implement. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: donderdag 19 april 2012 8:16 To: Alexander Vainshtein; Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; S= am Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Sasha and all, You have exactly the same "problem" in the 2-VLAN approach - quoting from t= he draft: 6. LDP Extensions for E-Tree Support P is a Leaf-only bit, it is set to 1 to indicate that the PE is attached wi= th only leaves, and set to 0 otherwise. If the P bit is set, then: { If the PE is a leaf-only node itself, then a label release message with the error code "Leaf to Leaf PW error" is sent to the peer PE and exit the process; So all that you wrote about a leaf-only PE becoming mixed and viceversa app= lies to both solutions. Regards, Daniel -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Thursday, April 19, 2012 8:31 AM To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Wim, Lots of thanks for a prompt response. I think that operational aspects of the VLAN approach (e.g., how is the Glo= bal VID selected and distributed) should be examined in more detail. At the same time it seems that the double PW approach carries with it too m= any operational problems. E.g., no PWs are set up between Leaf-only PEs, but once one of these become= s a Mix PE, all the Leaf-only PEs must now recognize it as a valid peer. An= d if a Mix PE reverts to a Leaf only one, all its Leaf-only peers must drop= it and shut down the relevant PWs... My 2c, Sasha ________________________________________ From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] Sent: Thursday, April 19, 2012 7:21 AM To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Sasha, the VLAN approach allows for a similar operation as the CW does. It is orthogonal to the underlying PW deployment of VPLS. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of A= lexander Vainshtein Sent: donderdag 19 april 2012 6:39 To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi all, I fully understand that that what I am going to say is not very popular, but: IMO one of the advantages of the CW-based solution is that it is orthogonal= to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, i= n a more generic way, localization of effects of changes in the PE configur= ation. In particular, adding a Leaf AC to a PE that previously has been only suppo= rting Root ACs (or vice versa), removal of the last Leaf or last Root AC fr= om a PE that previously has been supporting a mix etc. affect only the PE w= here this operation happens and not the rest of the PEs. As for the need for HW changes that have been mentioned as a main disadvant= age of the CW-based approach - I believe it strongly depends on specific im= plementations. And some changes in the forwarding process are required in a= ny solution. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, = Josh [josh.rogers@twcable.com] Sent: Wednesday, April 18, 2012 9:57 PM To: Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Again, the P2MP situation throws me. Is this something that is used common= ly? I'm under the impression that adding P2MP to any model results in a more co= mplex model. Wether outside s-tag is used to differentiate, or dedicated p= w's are used for the same purpose, it seems both become more complex. Gile's comparison slide still concisely captures the differences between th= ese methods, in my opinion. I haven't seen any new ideas or thoughts broug= ht to the group in the past week or two on the subject. I would hate for b= oth proposed methods to die on the vine because we couldn't decide between = two methods that have nothing inherently wrong with either. -Josh On 4/18/12 1:53 PM, "Lucy yong" wrote: >Send this again. > >Two PW approach can be complex too if the VPLS instance for E-Tree uses >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >unicast traffic, and some P2MP PWs for multicast traffic. It may double >all of them. > >Lucy > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, April 18, 2012 1:42 PM >To: Lucy yong; Rogers, Josh; Sam Cao >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >I think the first option its the natural way to go. How is the processing >in this case more complex? > >Thumb typed - please be tolerant > >Lucy yong wrote: > > > >Snipped.. > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >traffic coming from a root AC) [[LY]] Not that simple. You construct >either two P2MP PWs to all other PEs and let egress PE performing >filtering, or construct one P2MP PW to leaf-only PEs and two P2MP PWs >to root and leaf PEs and let ingress PE perform forwarding and >filtering. Both make node process complex. > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >delivering the frames to remote PEs. We should utilize them with the >minimized changes. Dual VLAN solution is simpler than Dual PW. > >Regards, >Lucy > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >haven't had any first hand experience with P2MP PW's, however, so don't >feel terribly strong about this objection. Is this a real problem for >others (now or in the future), or is this objection in the weeds? > >I'm not sure the 'additional complexity' is notable, or even relevant. I >encourage others to speak up if they disagree, as P2MP PW is only >conceptual to me, and I am unfamiliar with real-life use cases for it. > >Thanks, >Josh > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > >>Please see inline. >> >>-----Original Message----- >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>Sent: Tuesday, April 17, 2012 7:14 AM >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Yes, 2 pws are only needed between pes with both root and leaf acs after >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>P2MP PWs if need. There is no difference between P2MP or normal PW >>setup. But, >>can Leaf-ACs be bound to Root PE of P2MP PW? >> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>both root and leaf AC and some only have leaf ACs)? >>Regards, >>Lucy >> >>Regards, >> >>Yuqun (Sam) Cao >>E-mail: Yuqun.cao@gmail.com >> >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Tuesday, April 17, 2012 4:56 PM >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com; Sam Cao >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Adding Sam (as l2vpn@ is holding messages) >> >>DC >> >>-----Original Message----- >>From: Lucy yong [mailto:lucy.yong@huawei.com] >>Sent: Tuesday, April 17, 2012 12:39 AM >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >>Snipped, >> >>As we discussed extensively in the list, and as reflected in giles >>slide, 2 pws are only needed between pes with both root and leaf acs, >>which will typically be a small minority. >>[[LY]] Don't know if the assumption is true. Even it is the case, both >>approaches can benefit from it. I was off for a while and captures some >>discussions now. >> >>Also as per giles slide, dual vlan can have scalability issues due to >>additional lookup and double use of vlans in internal emulated lan >>interface. Also there are potential backward compatibility issues with >>silicon that doesn't support vlan mapping. >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>not clear on all the issues. Could you be more specific? As I mentioned >>in below, two PW approach makes VPLS transport construction and packet >>forwarding more complex, I can see potential backward compatibility >>issues with 2 PW solution. >> >>Regards, >>Lucy >> >>Regards, >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>In my mind, the VLAN approach means dual vlan method. >> >>The main concern for CW approach is hardware support. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>traffic, and some P2MP PWs for multicast traffic. It may double all of >>them. >> >>E-tree is an Ethernet service and there is already VLAN based solution >>in IEEE, can we just utilize it without complicating VPLS transport >>construction? This also makes interworking with Eth only network easier. >> >>Cheers, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Monday, April 16, 2012 8:35 AM >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I believe the initial question was in regard to the CW method. Are you >>saying that you no longer are interested in that method in preference of >>the dual vlan method? >> >> >> >>Lucy yong wrote: >> >> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >> >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Henderickx, Wim (Wim) >>Sent: Thursday, April 12, 2012 2:03 AM >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>The vlan approach is superior as it also works for eth only networks, >>etc. On top some vendors indicate hw issues with the cw approach. As >>such we have dropped more or less the cw approach. >> >>Cheers, >>Wim >>_________________ >>sent from blackberry >> >>----- Original Message ----- >>From: Giles Heron [mailto:giles.heron@gmail.com] >>Sent: Thursday, April 12, 2012 08:22 AM >>To: Simon Delord ; Alexander Vainshtein >> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>; Andrew Sergeev >>; Idan Kaspit ; >>Mishael Wexler ; Rotem Cohen >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Sorry - the "anonymous presentation" was mine. I should possibly have >>put in a third column on the CW approach. And hopefully the minutes >>will be posted soon. >> >>We had various discussions, as Simon stated, and consensus seemed to be >>forming around the two alternatives of two PWEs or two VLANs. I believe >>three of the authors of the CW approach are also authors of the two VLAN >>approach and one is also an author of the two PWE approach. So perhaps >>it's best to let those four individuals say which approach they prefer >>and why? >> >>Giles >> >>On 10/04/2012 00:45, "Simon Delord" wrote: >> >>> Hi Alexander, >>> >>> You are right, no discussion on the WG mailing list recently, but >>> there have been substantial discussions among the authors of various >>> solution drafts off the mailing list. As far as I know, no consensus >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>> think the CW approach has not been rejected by the WG yet, or the WG >>> has not yet decided on which one to adopt. >>> >>> Simon >>> >>> 2012/4/8 Alexander Vainshtein >>> >>>> Hi all, >>>> >>>> Unfortunately I have not been able to attend the Paris IETF. >>>> >>>> However, looking up the L2VPN proceedings, I've found a short >>>> anonymous presentation called "E-Tree Update" ( >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>> This presentation discusses the differences of the E-Tree approaches >>>> based on dedicated VLANs (as in >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>> ext=3D1) and multiple PWs between the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>> clude_te >>>> xt=3D1) >>>> and completely ignores the solution based on usage of the CW in the >>>> PWs connecting the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>> ext=3D1 >>>> ). >>>> >>>> >>>> >>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>> wonder whether the WG has taken a decision to reject the approach >>>> based on the CW usage? I do not remember any recent discussion of >>>> this topic on the WG mailing list. >>>> >>>> >>>> >>>> Regards, and lots of thanks in advance, >>>> >>>> Sasha >>>> >>>> >>>> >>>> >>>> >>>> This e-mail message is intended for the recipient only and contains >>>> information which is CONFIDENTIAL and which may be proprietary to ECI >> >>>> Telecom. If you have received this transmission in error, please >>>> inform us by e-mail, phone or fax, and then delete the original and >>>> all copies thereof. >>>> >> >> >> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is addressed. >>If you are not the intended recipient of this E-mail, you are hereby >>notified that any dissemination, distribution, copying, or action taken >>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this >>E-mail in error, please notify the sender immediately and permanently >>delete the original and any copy of this E-mail and any printout. >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notifi= ed that any dissemination, distribution, copying, or action taken in relati= on to the contents of and attachments to this E-mail is strictly prohibited= and may be unlawful. If you have received this E-mail in error, please not= ify the sender immediately and permanently delete the original and any copy= of this E-mail and any printout. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. From Alexander.Vainshtein@ecitele.com Thu Apr 19 09:46:39 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BF721F8703 for ; Thu, 19 Apr 2012 09:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.179 X-Spam-Level: X-Spam-Status: No, score=-3.179 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, J_BACKHAIR_34=1, J_BACKHAIR_43=1, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, 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 CrqhCegsenjf for ; Thu, 19 Apr 2012 09:46:34 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id F2FD321F85B1 for ; Thu, 19 Apr 2012 09:46:33 -0700 (PDT) Received: from [85.158.139.83:46235] by server-6.bemta-5.messagelabs.com id 5A/70-13222-861409F4; Thu, 19 Apr 2012 16:46:32 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1334853992!24596103!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.7; banners=-,-,- Received: (qmail 4173 invoked from network); 19 Apr 2012 16:46:32 -0000 Received: from unknown (HELO fridlppsb001.ecitele.com) (168.87.1.157) by server-12.tower-182.messagelabs.com with SMTP; 19 Apr 2012 16:46:32 -0000 X-AuditID: a8571401-b7f186d000005261-3a-4f9041b028ec Received: from FRIDWPPCH002.ecitele.com (fridwppch002.ecitele.com [10.1.16.53]) by fridlppsb001.ecitele.com (Symantec Messaging Gateway) with SMTP id 74.B8.21089.0B1409F4; Thu, 19 Apr 2012 18:47:44 +0200 (CEST) Received: from FRIDWPPMB002.ecitele.com ([169.254.4.167]) by FRIDWPPCH002.ecitele.com ([10.1.16.53]) with mapi id 14.01.0339.001; Thu, 19 Apr 2012 18:46:31 +0200 From: Alexander Vainshtein To: "DelRegno, Christopher N (Nick)" Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdiov///PycP//4qvA//+OPpD//ux5AP/915BA//ujPiD/9w8fQA== Date: Thu, 19 Apr 2012 16:46:30 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, , <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><44F4E579A764584EA9BDFD07D0CA08130777C1D5@tlvmail1><14C7F4F06DB5814AB0DE29716C4F6D670129623CD2@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130777C22F@tlvmail1> <44F4E579A764584EA9BDFD07D0CA08130777C285@tlvmail1> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTf0wTSRi96W63S2XPpYAdqyF1Ey9GpZYgyZ5SBGJMzZ1WBTV3JuDSju1K u212iwETYyPiH4gKqMnRkxOvqJwoP0zO01ijFhMFfxtMlAQ1YkTraYwJikrUXVYR4/z1Zt77 3ptv9xsSM9TrTCQvBJEocF6G0ON68IMpvTOv1mF93qVnQ7ciGrYxMoKzA69jOrbz3d8E2z0y l/1zYJhgGyuvErk6e9XjM1r7qXC/zr71wnOtvbn5rca+vWM3Zm89GsftVW9Sl+l+D4FsThD8 QS6IzC4kOW3MMpHfwDkrGDPvsjEZjDng5ZzIh4SgjeECASS4mBy9+buVLct4wYwEp9/FC24b s7jAkc6yWT+nZzA5hR5eMqN0H8d7zT4kSZwbmeUTpTvBtbYN84SuFgb2ngDldZE2IgR66kE1 SCAhPRcOV/ZpVTwJ3rjXTlQDPWmgewGM1bZp1M1BACsHG0YrCNoGj7f2EwpOoXPhtc4Irogw egjAJ019GoVIpvPgjifVQBXlw6d9EUzF1wC8/D9SME5Ph/Ga87iCKXoJPP12SKum3dTCyy8e 6BQigf4NRvfUjIqAfL83PUdHAzDaCPse7deo96Zhc/Q6puJU+HTgw+d+0uCWf3p1qn42bDr9 ilDxLHjowDNMDU6C3Q2PcFU/GZ5vuYPXAmN4XER4XHl4XHl4XHkTwI8A4zqRdwUCUonVmmFB Tj6IvMji9PuOA3myWlangJPg4Q5LDNAkYBIpEtY6DFpug1Thi4HJpIZJpbJy5aMfS/yuCg8n eYrFMi+SYgCSGJNC7VfklIur2IhE/xeKlT9iHWaa4PQrfzlYnGm1frNhjFT7ihyHgXbLo1eK UACJX0qnkiQDqXNKYpKI3Kh8He8NfqU1ZIKSnCgnRxUNJQU4n8S7Vb4HTCc/nujuBQZc8AvI ZKR8iohWRJ4yYcwnDoxyr8lUo8ImyqM45hCXzTWy+TS4UzGXn8YYZQoBtKDy8WB0kSSc+9e3 chsom6lbVeDNfC9eXMB4l85bfnehtrA46MyamJZ8/4+y9uFfUVH+ndKuNWePzWieM/TXSH5J 223LoP+/qXHH8l8OnOlYmjfU9SJ7YuK+w1Ub6zp2ZTY0bj92SZxnedkTXV+079X8D1cKrJu5 n1aX12wqulKYVDyFwSUPlzETEyXuEyq71sklBAAA Cc: "l2vpn@ietf.org" , Sam Cao X-BeenThere: l2vpn@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, 19 Apr 2012 16:46:39 -0000 Nick, I am probably repeating myself, but please consider the case when a Leaf-onl= y PE migrates to a Mix one. Prior to migration all the other Leaf PEs in this VPN did not need any PWs t= o the migrating one so there is a good chance they did not even know of its= existence. After migration you need PWs between the migrated PE and all the= se Leaf PEs. This means that the configuration action is not local to a migr= ating PE. (PW teardown is easier, since it is enough for one side to initiat= e it, but with setup you need two to tango:-). My 2c, Sasha > -----Original Message----- > From: DelRegno, Christopher N (Nick) [mailto:nick.delregno@verizon.com] > Sent: Thursday, April 19, 2012 7:38 PM > To: Daniel Cohn; Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, > Josh; Lucy yong; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > No, I don't see a problem with setting up/tearing down a PW when there is > a move of the root to leaf nodes or vice versa, assuming the move is based > on a provisioning action (e.g. an customer order), not some dynamic > bouncing between switches. > > Nick > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Thursday, April 19, 2012 7:53 AM > To: DelRegno, Christopher N (Nick); Henderickx, Wim (Wim); Alexander > Vainshtein; Rogers, Josh; Lucy yong; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Nick, > > Thanks for the feedback. Now, do you see a problem setting up/tearing > down a PW when this happens? > > Daniel > > -----Original Message----- > From: DelRegno, Christopher N (Nick) [mailto:nick.delregno@verizon.com] > Sent: Thursday, April 19, 2012 3:40 PM > To: Daniel Cohn; Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, > Josh; Lucy yong; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Dan: > > As the transformation of a PE from Root<-->Mix and Mix<-->Leaf will be > driven by our customers, we can't say how often this will or won't occur.= It > must be accommodated regardless of perceived rarity. > > If I use one of our current extremely popular L2VPN services as an example= , > our customers tend to move their ENNI (e.g. Root) locations constantly, > quite frequently to switches which heretofore only contained UNIs (e.g. > leaves). > > Nick > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Daniel Cohn > Sent: Thursday, April 19, 2012 4:49 AM > To: Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, Josh; Lucy yong; > Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Hi Wim, > > That seems to me a non-negligible change to bridge forwarding logic, I thi= nk > setting up/tearing down the PE is cleaner. I don't expect that leaf-only t= o > root/leaf PE transformations will happen all that often. > But I think it's important to clarify that the issue is common to both dra= fts. > > DC > > -----Original Message----- > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > lucent.com] > Sent: Thursday, April 19, 2012 9:34 AM > To: Daniel Cohn; Alexander Vainshtein; Rogers, Josh; Lucy yong; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Daniel, we should discuss this as this is not absolutely required to tear= down > PW. You can also have an indication in the E-TREE fwd to indicate that the > endpoint has no leaf and as such avoid sending traffic down but allow the > PW to be setup. As such we have some flexibility such that operators can > select the proper approach they would like to have/implement. > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: donderdag 19 april 2012 8:16 > To: Alexander Vainshtein; Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; > Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Hi Sasha and all, > > You have exactly the same "problem" in the 2-VLAN approach - quoting > from the draft: > > 6. LDP Extensions for E-Tree Support > > P is a Leaf-only bit, it is set to 1 to indicate that the PE is attached w= ith only > leaves, and set to 0 otherwise. > > If the P bit is set, then: > > { > > If the PE is a leaf-only node itself, then a label release > message with the error code "Leaf to Leaf PW error" is sent to the > peer PE and exit the process; > > > So all that you wrote about a leaf-only PE becoming mixed and viceversa > applies to both solutions. > > Regards, > > Daniel > > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Thursday, April 19, 2012 8:31 AM > To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Wim, > Lots of thanks for a prompt response. > > I think that operational aspects of the VLAN approach (e.g., how is the > Global VID selected and distributed) should be examined in more detail. > > At the same time it seems that the double PW approach carries with it too > many operational problems. > E.g., no PWs are set up between Leaf-only PEs, but once one of these > becomes a Mix PE, all the Leaf-only PEs must now recognize it as a valid > peer. And if a Mix PE reverts to a Leaf only one, all its Leaf-only peers= must > drop it and shut down the relevant PWs... > > My 2c, > Sasha > > ________________________________________ > From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] > Sent: Thursday, April 19, 2012 7:21 AM > To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Sasha, the VLAN approach allows for a similar operation as the CW does. > It is orthogonal to the underlying PW deployment of VPLS. > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Alexander Vainshtein > Sent: donderdag 19 april 2012 6:39 > To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Hi all, > I fully understand that that what I am going to say is not very popular, > but: > > IMO one of the advantages of the CW-based solution is that it is orthogona= l > to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and,= in > a more generic way, localization of effects of changes in the PE > configuration. > > In particular, adding a Leaf AC to a PE that previously has been only > supporting Root ACs (or vice versa), removal of the last Leaf or last Root= AC > from a PE that previously has been supporting a mix etc. affect only the P= E > where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main > disadvantage of the CW-based approach - I believe it strongly depends on > specific implementations. And some changes in the forwarding process are > required in any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of > Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a more > complex model. Wether outside s-tag is used to differentiate, or dedicate= d > pw's are used for the same purpose, it seems both become more complex. > > Gile's comparison slide still concisely captures the differences between > these methods, in my opinion. I haven't seen any new ideas or thoughts > brought to the group in the past week or two on the subject. I would hate > for both proposed methods to die on the vine because we couldn't decide > between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" wrote: > > >Send this again. > > > >Two PW approach can be complex too if the VPLS instance for E-Tree uses > >P2P PW for unicast traffic and P2MP PW for broadcast and unknown > >unicast traffic, and some P2MP PWs for multicast traffic. It may double > >all of them. > > > >Lucy > > > >-----Original Message----- > >From: Daniel Cohn [mailto:DanielC@orckit.com] > >Sent: Wednesday, April 18, 2012 1:42 PM > >To: Lucy yong; Rogers, Josh; Sam Cao > >Cc: l2vpn@ietf.org > >Subject: RE: The status of the approaches to the E-Tree solution? > > > >I think the first option its the natural way to go. How is the > processing > >in this case more complex? > > > >Thumb typed - please be tolerant > > > >Lucy yong wrote: > > > > > > > >Snipped.. > > > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP > PW > >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for > >traffic coming from a root AC) [[LY]] Not that simple. You construct > >either two P2MP PWs to all other PEs and let egress PE performing > >filtering, or construct one P2MP PW to leaf-only PEs and two P2MP PWs > >to root and leaf PEs and let ingress PE perform forwarding and > >filtering. Both make node process complex. > > > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for > >delivering the frames to remote PEs. We should utilize them with the > >minimized changes. Dual VLAN solution is simpler than Dual PW. > > > >Regards, > >Lucy > > > > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I > >haven't had any first hand experience with P2MP PW's, however, so don't > >feel terribly strong about this objection. Is this a real problem for > >others (now or in the future), or is this objection in the weeds? > > > >I'm not sure the 'additional complexity' is notable, or even relevant. > I > >encourage others to speak up if they disagree, as P2MP PW is only > >conceptual to me, and I am unfamiliar with real-life use cases for it. > > > >Thanks, > >Josh > > > > > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > > > >>Please see inline. > >> > >>-----Original Message----- > >>From: Sam Cao [mailto:yuqun.cao@gmail.com] > >>Sent: Tuesday, April 17, 2012 7:14 AM > >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; > >>giles.heron@gmail.com; simon.delord@gmail.com; > >>Alexander.Vainshtein@ecitele.com > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > >>Subject: RE: The status of the approaches to the E-Tree solution? > >> > >>Yes, 2 pws are only needed between pes with both root and leaf acs > after > >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup > 2 > >>P2MP PWs if need. There is no difference between P2MP or normal PW > >>setup. > But, > >>can Leaf-ACs be bound to Root PE of P2MP PW? > >> > >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with > both > >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have > >>both root and leaf AC and some only have leaf ACs)? > >>Regards, > >>Lucy > >> > >>Regards, > >> > >>Yuqun (Sam) Cao > >>E-mail: Yuqun.cao@gmail.com > >> > >> > >>-----Original Message----- > >>From: Daniel Cohn [mailto:DanielC@orckit.com] > >>Sent: Tuesday, April 17, 2012 4:56 PM > >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); > >>giles.heron@gmail.com; simon.delord@gmail.com; > >>Alexander.Vainshtein@ecitele.com; Sam Cao > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > >>Subject: RE: The status of the approaches to the E-Tree solution? > >> > >>Adding Sam (as l2vpn@ is holding messages) > >> > >>DC > >> > >>-----Original Message----- > >>From: Lucy yong [mailto:lucy.yong@huawei.com] > >>Sent: Tuesday, April 17, 2012 12:39 AM > >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); > >>giles.heron@gmail.com; simon.delord@gmail.com; > >>Alexander.Vainshtein@ecitele.com > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > >>Subject: RE: The status of the approaches to the E-Tree solution? > >> > >> > >>Snipped, > >> > >>As we discussed extensively in the list, and as reflected in giles > >>slide, 2 pws are only needed between pes with both root and leaf acs, > >>which will typically be a small minority. > >>[[LY]] Don't know if the assumption is true. Even it is the case, both > >>approaches can benefit from it. I was off for a while and captures > some > >>discussions now. > >> > >>Also as per giles slide, dual vlan can have scalability issues due to > >>additional lookup and double use of vlans in internal emulated lan > >>interface. Also there are potential backward compatibility issues with > >>silicon that doesn't support vlan mapping. > >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I > am > >>not clear on all the issues. Could you be more specific? As I > mentioned > >>in below, two PW approach makes VPLS transport construction and packet > >>forwarding more complex, I can see potential backward compatibility > >>issues with 2 PW solution. > >> > >>Regards, > >>Lucy > >> > >>Regards, > >> > >>Daniel > >> > >>Thumb typed - please be tolerant > >> > >>Lucy yong wrote: > >> > >>In my mind, the VLAN approach means dual vlan method. > >> > >>The main concern for CW approach is hardware support. > >> > >>Two PW approach can be complex too if the VPLS instance for E-Tree > uses > >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown > unicast > >>traffic, and some P2MP PWs for multicast traffic. It may double all of > >>them. > >> > >>E-tree is an Ethernet service and there is already VLAN based solution > >>in IEEE, can we just utilize it without complicating VPLS transport > >>construction? This also makes interworking with Eth only network > easier. > >> > >>Cheers, > >>Lucy > >> > >>-----Original Message----- > >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] > >>Sent: Monday, April 16, 2012 8:35 AM > >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; > >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' > >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; > >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; > >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' > >>Subject: RE: The status of the approaches to the E-Tree solution? > >> > >>I believe the initial question was in regard to the CW method. Are > you > >>saying that you no longer are interested in that method in preference > of > >>the dual vlan method? > >> > >> > >> > >>Lucy yong wrote: > >> > >> > >>Agree with Wim. VLAN approach is the best solution for E-Tree. > >> > >>Lucy > >> > >>-----Original Message----- > >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > >>Of Henderickx, Wim (Wim) > >>Sent: Thursday, April 12, 2012 2:03 AM > >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; > >>'Alexander.Vainshtein@ecitele.com' > >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; > >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; > >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' > >>Subject: Re: The status of the approaches to the E-Tree solution? > >> > >>The vlan approach is superior as it also works for eth only networks, > >>etc. On top some vendors indicate hw issues with the cw approach. As > >>such we have dropped more or less the cw approach. > >> > >>Cheers, > >>Wim > >>_________________ > >>sent from blackberry > >> > >>----- Original Message ----- > >>From: Giles Heron [mailto:giles.heron@gmail.com] > >>Sent: Thursday, April 12, 2012 08:22 AM > >>To: Simon Delord ; Alexander Vainshtein > >> > >>Cc: l2vpn@ietf.org ; Vladimir Kleiner > >>; Andrew Sergeev > >>; Idan Kaspit ; > >>Mishael Wexler ; Rotem Cohen > >> > >>Subject: Re: The status of the approaches to the E-Tree solution? > >> > >>Sorry - the "anonymous presentation" was mine. I should possibly have > >>put in a third column on the CW approach. And hopefully the minutes > >>will be posted soon. > >> > >>We had various discussions, as Simon stated, and consensus seemed to > be > >>forming around the two alternatives of two PWEs or two VLANs. I > believe > >>three of the authors of the CW approach are also authors of the two > VLAN > >>approach and one is also an author of the two PWE approach. So perhaps > >>it's best to let those four individuals say which approach they prefer > >>and why? > >> > >>Giles > >> > >>On 10/04/2012 00:45, "Simon Delord" wrote: > >> > >>> Hi Alexander, > >>> > >>> You are right, no discussion on the WG mailing list recently, but > >>> there have been substantial discussions among the authors of various > >>> solution drafts off the mailing list. As far as I know, no consensus > >>> yet before ietf83, not sure the progress in the Paris WG meeting. I > >>> think the CW approach has not been rejected by the WG yet, or the WG > >>> has not yet decided on which one to adopt. > >>> > >>> Simon > >>> > >>> 2012/4/8 Alexander Vainshtein > >>> > >>>> Hi all, > >>>> > >>>> Unfortunately I have not been able to attend the Paris IETF. > >>>> > >>>> However, looking up the L2VPN proceedings, I've found a short > >>>> anonymous presentation called "E-Tree Update" ( > >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). > >>>> This presentation discusses the differences of the E-Tree > approaches > >>>> based on dedicated VLANs (as in > >>>> > http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t > >>>> ext=3D1) and multiple PWs between the PEs (as in > >>>> > http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in > >>>> clude_te > >>>> xt=3D1) > >>>> and completely ignores the solution based on usage of the CW in the > >>>> PWs connecting the PEs (as in > >>>> > http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t > >>>> ext=3D1 > >>>> ). > >>>> > >>>> > >>>> > >>>> The Minutes of the Paris L2VPN session are not yet available, but I > >>>> wonder whether the WG has taken a decision to reject the approach > >>>> based on the CW usage? I do not remember any recent discussion of > >>>> this topic on the WG mailing list. > >>>> > >>>> > >>>> > >>>> Regards, and lots of thanks in advance, > >>>> > >>>> Sasha > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> This e-mail message is intended for the recipient only and contains > >>>> information which is CONFIDENTIAL and which may be proprietary to > ECI > >> > >>>> Telecom. If you have received this transmission in error, please > >>>> inform us by e-mail, phone or fax, and then delete the original and > >>>> all copies thereof. > >>>> > >> > >> > >> > >> > >> > >>This E-mail and any of its attachments may contain Time Warner Cable > >>proprietary information, which is privileged, confidential, or subject > >>to copyright belonging to Time Warner Cable. This E-mail is intended > >>solely for the use of the individual or entity to which it is > addressed. > >>If you are not the intended recipient of this E-mail, you are hereby > >>notified that any dissemination, distribution, copying, or action > taken > >>in relation to the contents of and attachments to this E-mail is > >>strictly prohibited and may be unlawful. If you have received this > >>E-mail in error, please notify the sender immediately and permanently > >>delete the original and any copy of this E-mail and any printout. > >> > > > > > >This E-mail and any of its attachments may contain Time Warner Cable > >proprietary information, which is privileged, confidential, or subject > to > >copyright belonging to Time Warner Cable. This E-mail is intended > solely > >for the use of the individual or entity to which it is addressed. If > you > >are not the intended recipient of this E-mail, you are hereby notified > >that any dissemination, distribution, copying, or action taken in > >relation to the contents of and attachments to this E-mail is strictly > >prohibited and may be unlawful. If you have received this E-mail in > >error, please notify the sender immediately and permanently delete the > >original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely f= or > the use of the individual or entity to which it is addressed. > If you are not the intended recipient of this E-mail, you are hereby notif= ied > that any dissemination, distribution, copying, or action taken in relation= to > the contents of and attachments to this E-mail is strictly prohibited and= may > be unlawful. If you have received this E-mail in error, please notify the > sender immediately and permanently delete the original and any copy of > this E-mail and any printout. > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us= by > e-mail, phone or fax, and then delete the original and all copies thereof. > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us= by > e-mail, phone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From josh.rogers@twcable.com Thu Apr 19 11:18:26 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4CE21F85F6 for ; Thu, 19 Apr 2012 11:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.738 X-Spam-Level: X-Spam-Status: No, score=0.738 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HS_INDEX_PARAM=0.001, J_BACKHAIR_34=1, J_BACKHAIR_43=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 C92yRD6q8Ma2 for ; Thu, 19 Apr 2012 11:18:24 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8460621F85F0 for ; Thu, 19 Apr 2012 11:18:24 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,447,1330923600"; d="scan'208";a="353494114" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 19 Apr 2012 14:17:17 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Thu, 19 Apr 2012 14:18:23 -0400 From: "Rogers, Josh" To: Alexander Vainshtein , "DelRegno, Christopher N (Nick)" Date: Thu, 19 Apr 2012 14:18:22 -0400 Subject: Re: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0eWM34JLkQD2tpR4yLTDTZI7n14A== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@ietf.org" , Sam Cao X-BeenThere: l2vpn@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, 19 Apr 2012 18:18:26 -0000 Sasha, are you considering a vantage of using BGP-AD, or no? BGP-AD isn't what I'd call 'an elaborate' auto discovery. If BGP signaling is enlisted, then all PE's are aware of the existence of all other PE's (regardless of type), even if they don't setup PW to them. So, for your example, current Leaf PE moves to mixed PE. As soon as it does, it updates signaling (presumably via a defined route-target), all other PE's now know this is a Mixed PE, and set up PW's to it, just the same as they would if a new PE was added to the instance. If no signaling is involved, these sorts of changes could be laborious, but no more than any PE add/remove from an instance. Thanks, -Josh On 4/19/12 12:46 PM, "Alexander Vainshtein" wrote: >Nick, >I am probably repeating myself, but please consider the case when a >Leaf-only PE migrates to a Mix one. > >Prior to migration all the other Leaf PEs in this VPN did not need any >PWs to the migrating one so there is a good chance they did not even know >of its existence. After migration you need PWs between the migrated PE >and all these Leaf PEs. This means that the configuration action is not >local to a migrating PE. (PW teardown is easier, since it is enough for >one side to initiate it, but with setup you need two to tango:-). > >My 2c, > Sasha > > >> -----Original Message----- >> From: DelRegno, Christopher N (Nick) [mailto:nick.delregno@verizon.com] >> Sent: Thursday, April 19, 2012 7:38 PM >> To: Daniel Cohn; Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, >> Josh; Lucy yong; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> No, I don't see a problem with setting up/tearing down a PW when there >>is >> a move of the root to leaf nodes or vice versa, assuming the move is >>based >> on a provisioning action (e.g. an customer order), not some dynamic >> bouncing between switches. >> >> Nick >> >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: Thursday, April 19, 2012 7:53 AM >> To: DelRegno, Christopher N (Nick); Henderickx, Wim (Wim); Alexander >> Vainshtein; Rogers, Josh; Lucy yong; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Nick, >> >> Thanks for the feedback. Now, do you see a problem setting up/tearing >> down a PW when this happens? >> >> Daniel >> >> -----Original Message----- >> From: DelRegno, Christopher N (Nick) [mailto:nick.delregno@verizon.com] >> Sent: Thursday, April 19, 2012 3:40 PM >> To: Daniel Cohn; Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, >> Josh; Lucy yong; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Dan: >> >> As the transformation of a PE from Root<-->Mix and Mix<-->Leaf will be >> driven by our customers, we can't say how often this will or won't >>occur. It >> must be accommodated regardless of perceived rarity. >> >> If I use one of our current extremely popular L2VPN services as an >>example, >> our customers tend to move their ENNI (e.g. Root) locations constantly, >> quite frequently to switches which heretofore only contained UNIs (e.g. >> leaves). >> >> Nick >> >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Daniel Cohn >> Sent: Thursday, April 19, 2012 4:49 AM >> To: Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, Josh; Lucy >>yong; >> Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Hi Wim, >> >> That seems to me a non-negligible change to bridge forwarding logic, I >>think >> setting up/tearing down the PE is cleaner. I don't expect that >>leaf-only to >> root/leaf PE transformations will happen all that often. >> But I think it's important to clarify that the issue is common to both >>drafts. >> >> DC >> >> -----Original Message----- >> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- >> lucent.com] >> Sent: Thursday, April 19, 2012 9:34 AM >> To: Daniel Cohn; Alexander Vainshtein; Rogers, Josh; Lucy yong; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Daniel, we should discuss this as this is not absolutely required to >>tear down >> PW. You can also have an indication in the E-TREE fwd to indicate that >>the >> endpoint has no leaf and as such avoid sending traffic down but allow >>the >> PW to be setup. As such we have some flexibility such that operators can >> select the proper approach they would like to have/implement. >> >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: donderdag 19 april 2012 8:16 >> To: Alexander Vainshtein; Henderickx, Wim (Wim); Rogers, Josh; Lucy >>yong; >> Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Hi Sasha and all, >> >> You have exactly the same "problem" in the 2-VLAN approach - quoting >> from the draft: >> >> 6. LDP Extensions for E-Tree Support >> >> P is a Leaf-only bit, it is set to 1 to indicate that the PE is >>attached with only >> leaves, and set to 0 otherwise. >> >> If the P bit is set, then: >> >> { >> >> If the PE is a leaf-only node itself, then a label release >> message with the error code "Leaf to Leaf PW error" is sent to the >> peer PE and exit the process; >> >> >> So all that you wrote about a leaf-only PE becoming mixed and viceversa >> applies to both solutions. >> >> Regards, >> >> Daniel >> >> -----Original Message----- >> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] >> Sent: Thursday, April 19, 2012 8:31 AM >> To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Wim, >> Lots of thanks for a prompt response. >> >> I think that operational aspects of the VLAN approach (e.g., how is the >> Global VID selected and distributed) should be examined in more detail. >> >> At the same time it seems that the double PW approach carries with it >>too >> many operational problems. >> E.g., no PWs are set up between Leaf-only PEs, but once one of these >> becomes a Mix PE, all the Leaf-only PEs must now recognize it as a valid >> peer. And if a Mix PE reverts to a Leaf only one, all its Leaf-only >>peers must >> drop it and shut down the relevant PWs... >> >> My 2c, >> Sasha >> >> ________________________________________ >> From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] >> Sent: Thursday, April 19, 2012 7:21 AM >> To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Sasha, the VLAN approach allows for a similar operation as the CW does. >> It is orthogonal to the underlying PW deployment of VPLS. >> >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Alexander Vainshtein >> Sent: donderdag 19 april 2012 6:39 >> To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Hi all, >> I fully understand that that what I am going to say is not very popular, >> but: >> >> IMO one of the advantages of the CW-based solution is that it is >>orthogonal >> to usage (or non-usage) of P2MP PWs for effective delivery of BUN >>traffic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>and, in >> a more generic way, localization of effects of changes in the PE >> configuration. >> >> In particular, adding a Leaf AC to a PE that previously has been only >> supporting Root ACs (or vice versa), removal of the last Leaf or last >>Root AC >> from a PE that previously has been supporting a mix etc. affect only >>the PE >> where this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main >> disadvantage of the CW-based approach - I believe it strongly depends on >> specific implementations. And some changes in the forwarding process are >> required in any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of >> Rogers, Josh [josh.rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a more >> complex model. Wether outside s-tag is used to differentiate, or >>dedicated >> pw's are used for the same purpose, it seems both become more complex. >> >> Gile's comparison slide still concisely captures the differences between >> these methods, in my opinion. I haven't seen any new ideas or thoughts >> brought to the group in the past week or two on the subject. I would >>hate >> for both proposed methods to die on the vine because we couldn't decide >> between two methods that have nothing inherently wrong with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" wrote: >> >> >Send this again. >> > >> >Two PW approach can be complex too if the VPLS instance for E-Tree uses >> >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >> >unicast traffic, and some P2MP PWs for multicast traffic. It may double >> >all of them. >> > >> >Lucy >> > >> >-----Original Message----- >> >From: Daniel Cohn [mailto:DanielC@orckit.com] >> >Sent: Wednesday, April 18, 2012 1:42 PM >> >To: Lucy yong; Rogers, Josh; Sam Cao >> >Cc: l2vpn@ietf.org >> >Subject: RE: The status of the approaches to the E-Tree solution? >> > >> >I think the first option its the natural way to go. How is the >> processing >> >in this case more complex? >> > >> >Thumb typed - please be tolerant >> > >> >Lucy yong wrote: >> > >> > >> > >> >Snipped.. >> > >> >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >> PW >> >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >> >traffic coming from a root AC) [[LY]] Not that simple. You construct >> >either two P2MP PWs to all other PEs and let egress PE performing >> >filtering, or construct one P2MP PW to leaf-only PEs and two P2MP PWs >> >to root and leaf PEs and let ingress PE perform forwarding and >> >filtering. Both make node process complex. >> > >> >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >> >delivering the frames to remote PEs. We should utilize them with the >> >minimized changes. Dual VLAN solution is simpler than Dual PW. >> > >> >Regards, >> >Lucy >> > >> > >> >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >> >haven't had any first hand experience with P2MP PW's, however, so don't >> >feel terribly strong about this objection. Is this a real problem for >> >others (now or in the future), or is this objection in the weeds? >> > >> >I'm not sure the 'additional complexity' is notable, or even relevant. >> I >> >encourage others to speak up if they disagree, as P2MP PW is only >> >conceptual to me, and I am unfamiliar with real-life use cases for it. >> > >> >Thanks, >> >Josh >> > >> > >> > >> >On 4/18/12 10:30 AM, "Lucy yong" wrote: >> > >> >>Please see inline. >> >> >> >>-----Original Message----- >> >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >> >>Sent: Tuesday, April 17, 2012 7:14 AM >> >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >> >>giles.heron@gmail.com; simon.delord@gmail.com; >> >>Alexander.Vainshtein@ecitele.com >> >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >> >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >> >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >> >>Yes, 2 pws are only needed between pes with both root and leaf acs >> after >> >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup >> 2 >> >>P2MP PWs if need. There is no difference between P2MP or normal PW >> >>setup. >> But, >> >>can Leaf-ACs be bound to Root PE of P2MP PW? >> >> >> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >> both >> >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >> >>both root and leaf AC and some only have leaf ACs)? >> >>Regards, >> >>Lucy >> >> >> >>Regards, >> >> >> >>Yuqun (Sam) Cao >> >>E-mail: Yuqun.cao@gmail.com >> >> >> >> >> >>-----Original Message----- >> >>From: Daniel Cohn [mailto:DanielC@orckit.com] >> >>Sent: Tuesday, April 17, 2012 4:56 PM >> >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >> >>giles.heron@gmail.com; simon.delord@gmail.com; >> >>Alexander.Vainshtein@ecitele.com; Sam Cao >> >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >> >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >> >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >> >>Adding Sam (as l2vpn@ is holding messages) >> >> >> >>DC >> >> >> >>-----Original Message----- >> >>From: Lucy yong [mailto:lucy.yong@huawei.com] >> >>Sent: Tuesday, April 17, 2012 12:39 AM >> >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >> >>giles.heron@gmail.com; simon.delord@gmail.com; >> >>Alexander.Vainshtein@ecitele.com >> >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >> >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >> >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >> >> >> >>Snipped, >> >> >> >>As we discussed extensively in the list, and as reflected in giles >> >>slide, 2 pws are only needed between pes with both root and leaf acs, >> >>which will typically be a small minority. >> >>[[LY]] Don't know if the assumption is true. Even it is the case, both >> >>approaches can benefit from it. I was off for a while and captures >> some >> >>discussions now. >> >> >> >>Also as per giles slide, dual vlan can have scalability issues due to >> >>additional lookup and double use of vlans in internal emulated lan >> >>interface. Also there are potential backward compatibility issues with >> >>silicon that doesn't support vlan mapping. >> >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >> am >> >>not clear on all the issues. Could you be more specific? As I >> mentioned >> >>in below, two PW approach makes VPLS transport construction and packet >> >>forwarding more complex, I can see potential backward compatibility >> >>issues with 2 PW solution. >> >> >> >>Regards, >> >>Lucy >> >> >> >>Regards, >> >> >> >>Daniel >> >> >> >>Thumb typed - please be tolerant >> >> >> >>Lucy yong wrote: >> >> >> >>In my mind, the VLAN approach means dual vlan method. >> >> >> >>The main concern for CW approach is hardware support. >> >> >> >>Two PW approach can be complex too if the VPLS instance for E-Tree >> uses >> >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >> unicast >> >>traffic, and some P2MP PWs for multicast traffic. It may double all of >> >>them. >> >> >> >>E-tree is an Ethernet service and there is already VLAN based solution >> >>in IEEE, can we just utilize it without complicating VPLS transport >> >>construction? This also makes interworking with Eth only network >> easier. >> >> >> >>Cheers, >> >>Lucy >> >> >> >>-----Original Message----- >> >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >> >>Sent: Monday, April 16, 2012 8:35 AM >> >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >> >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >> >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >> >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >> >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >> >>I believe the initial question was in regard to the CW method. Are >> you >> >>saying that you no longer are interested in that method in preference >> of >> >>the dual vlan method? >> >> >> >> >> >> >> >>Lucy yong wrote: >> >> >> >> >> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >> >> >> >>Lucy >> >> >> >>-----Original Message----- >> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> Behalf >> >>Of Henderickx, Wim (Wim) >> >>Sent: Thursday, April 12, 2012 2:03 AM >> >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >> >>'Alexander.Vainshtein@ecitele.com' >> >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >> >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >> >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >> >> >>The vlan approach is superior as it also works for eth only networks, >> >>etc. On top some vendors indicate hw issues with the cw approach. As >> >>such we have dropped more or less the cw approach. >> >> >> >>Cheers, >> >>Wim >> >>_________________ >> >>sent from blackberry >> >> >> >>----- Original Message ----- >> >>From: Giles Heron [mailto:giles.heron@gmail.com] >> >>Sent: Thursday, April 12, 2012 08:22 AM >> >>To: Simon Delord ; Alexander Vainshtein >> >> >> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >> >>; Andrew Sergeev >> >>; Idan Kaspit ; >> >>Mishael Wexler ; Rotem Cohen >> >> >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >> >> >>Sorry - the "anonymous presentation" was mine. I should possibly have >> >>put in a third column on the CW approach. And hopefully the minutes >> >>will be posted soon. >> >> >> >>We had various discussions, as Simon stated, and consensus seemed to >> be >> >>forming around the two alternatives of two PWEs or two VLANs. I >> believe >> >>three of the authors of the CW approach are also authors of the two >> VLAN >> >>approach and one is also an author of the two PWE approach. So perhaps >> >>it's best to let those four individuals say which approach they prefer >> >>and why? >> >> >> >>Giles >> >> >> >>On 10/04/2012 00:45, "Simon Delord" wrote: >> >> >> >>> Hi Alexander, >> >>> >> >>> You are right, no discussion on the WG mailing list recently, but >> >>> there have been substantial discussions among the authors of various >> >>> solution drafts off the mailing list. As far as I know, no consensus >> >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >> >>> think the CW approach has not been rejected by the WG yet, or the WG >> >>> has not yet decided on which one to adopt. >> >>> >> >>> Simon >> >>> >> >>> 2012/4/8 Alexander Vainshtein >> >>> >> >>>> Hi all, >> >>>> >> >>>> Unfortunately I have not been able to attend the Paris IETF. >> >>>> >> >>>> However, looking up the L2VPN proceedings, I've found a short >> >>>> anonymous presentation called "E-Tree Update" ( >> >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >> >>>> This presentation discusses the differences of the E-Tree >> approaches >> >>>> based on dedicated VLANs (as in >> >>>> >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >> >>>> ext=3D1) and multiple PWs between the PEs (as in >> >>>> >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >> >>>> clude_te >> >>>> xt=3D1) >> >>>> and completely ignores the solution based on usage of the CW in the >> >>>> PWs connecting the PEs (as in >> >>>> >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >> >>>> ext=3D1 >> >>>> ). >> >>>> >> >>>> >> >>>> >> >>>> The Minutes of the Paris L2VPN session are not yet available, but I >> >>>> wonder whether the WG has taken a decision to reject the approach >> >>>> based on the CW usage? I do not remember any recent discussion of >> >>>> this topic on the WG mailing list. >> >>>> >> >>>> >> >>>> >> >>>> Regards, and lots of thanks in advance, >> >>>> >> >>>> Sasha >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> This e-mail message is intended for the recipient only and contains >> >>>> information which is CONFIDENTIAL and which may be proprietary to >> ECI >> >> >> >>>> Telecom. If you have received this transmission in error, please >> >>>> inform us by e-mail, phone or fax, and then delete the original and >> >>>> all copies thereof. >> >>>> >> >> >> >> >> >> >> >> >> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >> >>proprietary information, which is privileged, confidential, or subject >> >>to copyright belonging to Time Warner Cable. This E-mail is intended >> >>solely for the use of the individual or entity to which it is >> addressed. >> >>If you are not the intended recipient of this E-mail, you are hereby >> >>notified that any dissemination, distribution, copying, or action >> taken >> >>in relation to the contents of and attachments to this E-mail is >> >>strictly prohibited and may be unlawful. If you have received this >> >>E-mail in error, please notify the sender immediately and permanently >> >>delete the original and any copy of this E-mail and any printout. >> >> >> > >> > >> >This E-mail and any of its attachments may contain Time Warner Cable >> >proprietary information, which is privileged, confidential, or subject >> to >> >copyright belonging to Time Warner Cable. This E-mail is intended >> solely >> >for the use of the individual or entity to which it is addressed. If >> you >> >are not the intended recipient of this E-mail, you are hereby notified >> >that any dissemination, distribution, copying, or action taken in >> >relation to the contents of and attachments to this E-mail is strictly >> >prohibited and may be unlawful. If you have received this E-mail in >> >error, please notify the sender immediately and permanently delete the >> >original and any copy of this E-mail and any printout. >> >> >> This E-mail and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or subject >>to >> copyright belonging to Time Warner Cable. This E-mail is intended >>solely for >> the use of the individual or entity to which it is addressed. >> If you are not the intended recipient of this E-mail, you are hereby >>notified >> that any dissemination, distribution, copying, or action taken in >>relation to >> the contents of and attachments to this E-mail is strictly prohibited >>and may >> be unlawful. If you have received this E-mail in error, please notify >>the >> sender immediately and permanently delete the original and any copy of >> this E-mail and any printout. >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please inform >>us by >> e-mail, phone or fax, and then delete the original and all copies >>thereof. >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please inform >>us by >> e-mail, phone or fax, and then delete the original and all copies >>thereof. > > >This e-mail message is intended for the recipient only and contains >information which is CONFIDENTIAL and which may be proprietary to ECI >Telecom. If you have received this transmission in error, please inform >us by e-mail, phone or fax, and then delete the original and all copies >thereof. > This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From Alexander.Vainshtein@ecitele.com Thu Apr 19 11:30:44 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF63D11E8072 for ; Thu, 19 Apr 2012 11:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.076 X-Spam-Level: X-Spam-Status: No, score=-3.076 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, J_BACKHAIR_34=1, J_BACKHAIR_43=1, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, 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 B5mrOGlFJKk7 for ; Thu, 19 Apr 2012 11:30:42 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id EFEA211E8073 for ; Thu, 19 Apr 2012 11:30:41 -0700 (PDT) Received: from [85.158.138.51:52397] by server-8.bemta-3.messagelabs.com id F9/3A-24428-0D9509F4; Thu, 19 Apr 2012 18:30:40 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1334860240!22913280!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.7; banners=-,-,- Received: (qmail 4985 invoked from network); 19 Apr 2012 18:30:40 -0000 Received: from unknown (HELO FRIDLPPSB002.ECITELE.COM) (168.87.1.157) by server-4.tower-174.messagelabs.com with SMTP; 19 Apr 2012 18:30:40 -0000 X-AuditID: a8571402-b7f796d00000340a-98-4f9057c85245 Received: from FRIDWPPCH001.ecitele.com (fridwppch001.ecitele.com [10.1.16.52]) by FRIDLPPSB002.ECITELE.COM (Symantec Messaging Gateway) with SMTP id 78.19.13322.8C7509F4; Thu, 19 Apr 2012 20:22:00 +0200 (CEST) Received: from FRIDWPPMB002.ecitele.com ([169.254.4.167]) by FRIDWPPCH001.ecitele.com ([10.1.16.52]) with mapi id 14.01.0339.001; Thu, 19 Apr 2012 20:30:38 +0200 From: Alexander Vainshtein To: "Rogers, Josh" , "DelRegno, Christopher N (Nick)" Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdiov///PycP//4qvA//+OPpD//ux5AP/915BA//ujPiD/9w8fQP/uJLgA/9wlmWg= Date: Thu, 19 Apr 2012 18:30:38 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.1] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELsWRmVeSWpSXmKPExsXCxcggpXsyfIK/weEjTBYNlxYzWcxd/IfF 4vG3Q+wWG38tYrM4+cfEYvbjH2wWc5vPsjmwe7Q+28vqsXPWXXaPliNvWT2WLPnJ5NG9YTKz x+o1r1g8Wr+LBrBHNTDaJObl5ZcklqQqpKQWJ9sqBRRlliUmVyopZKbYKhkqKRTkJCan5qbm ldgqJRYUpOalKNlxKWAAG6CyzDyF1Lzk/JTMvHRbJc9gf10LC1NLXUMlu5CMzGKFVN3cxMwc hdzU4uLE9FQFoAjId3kpCeuYMyZM/MNYMOcsY8Xp7a9ZGxhbljF2MXJySAiYSGxctZAdwhaT uHBvPVsXIxeHkMAVRonuPVPYIZyljBITjuwGq2ITsJXYtPouG4gtIpAj8WHTMmYQm1ngJKPE 6Y+sILawgKNE74suRogaJ4mXtxYzQ9i3GCXuv60HsVkEVCUOTz8FFucV8JVYMe0c2EwhgRKJ J5/3g+3iFDCWuLh5A9gcRqDrvp9awwSxS1zi1pP5TBBXC0gs2XOeGcIWlXj5+B8rhC0vcfHD A6h6HYkFuz+xQdjaEssWvobaKyhxcuYTFoh6SYmDK26wTGAUn4VkxSwk7bOQtM9C0r6AkWUV o4RbkKeLT0BAsJOBgZGeq7NniKuPq56zv+8mRmDKWhEuwrSDsfmm4SFGAQ5GJR7eDaIT/IVY E8uKK3MPMUpyMCmJ8m4CJjwhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrzzJYByvCmJlVWpRfkw KQtgIE5kluJOzgfFckm8sYEBCkdJnDcuyM5fSCAdmPSyU1MLUotgWmU4OJQkeHdHAE0VLEpN T61Iy8wpQUgzcXCCbOYB2rwepIa3uCAxtzgzHSJ/ilGV4/+2k1cYhVjy8vNSpcR5H4MUCYAU ZZTmwc15xSgO9Ksw7xmQLA8wKcJNeAU0nAlouKJEH8hwYNaAS0k1MCZuv7vxXW7WgkUlD4Nk 74atcY1LuHbHT+efoRvzoo8+rsItCxYq/0l5t75sy71W1ilTTgfeXvdg5sJm6bj32yZO4ryq u2tRuYyY83Vdxn6ORvsIU05/5S0npKJ7+qfoMVz2fFcjMPPgZDHNG+u7F6qF34qIX+v0RSUj u4bvaZdZZ/N0++dTY5RYijMSDbWYi4oTAVGBLFIlBAAA Cc: "l2vpn@ietf.org" , Sam Cao X-BeenThere: l2vpn@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, 19 Apr 2012 18:30:45 -0000 Josh, Lots of thanks for a prompt response. Yes, of course I consider BGP-AD and fully agree that with BGP-AD (extended= to distribute PE state - AFAIK, it is not part of the regular VPLS-related= NRLI) the situation becomes manageable. The question is, can the dual-PW solution manageable without BGP-AD? Regards, Sasha ________________________________________ From: Rogers, Josh [josh.rogers@twcable.com] Sent: Thursday, April 19, 2012 8:18 PM To: Alexander Vainshtein; DelRegno, Christopher N (Nick) Cc: l2vpn@ietf.org; Daniel Cohn; Henderickx, Wim (Wim); Lucy yong; Sam Cao Subject: Re: The status of the approaches to the E-Tree solution? Sasha, are you considering a vantage of using BGP-AD, or no? BGP-AD isn't what I'd call 'an elaborate' auto discovery. If BGP signaling is enlisted, then all PE's are aware of the existence of all other PE's (regardless of type), even if they don't setup PW to them. So, for your example, current Leaf PE moves to mixed PE. As soon as it does, it updates signaling (presumably via a defined route-target), all other PE's now know this is a Mixed PE, and set up PW's to it, just the same as they would if a new PE was added to the instance. If no signaling is involved, these sorts of changes could be laborious, but no more than any PE add/remove from an instance. Thanks, -Josh On 4/19/12 12:46 PM, "Alexander Vainshtein" wrote: >Nick, >I am probably repeating myself, but please consider the case when a >Leaf-only PE migrates to a Mix one. > >Prior to migration all the other Leaf PEs in this VPN did not need any >PWs to the migrating one so there is a good chance they did not even know >of its existence. After migration you need PWs between the migrated PE >and all these Leaf PEs. This means that the configuration action is not >local to a migrating PE. (PW teardown is easier, since it is enough for >one side to initiate it, but with setup you need two to tango:-). > >My 2c, > Sasha > > >> -----Original Message----- >> From: DelRegno, Christopher N (Nick) [mailto:nick.delregno@verizon.com] >> Sent: Thursday, April 19, 2012 7:38 PM >> To: Daniel Cohn; Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, >> Josh; Lucy yong; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> No, I don't see a problem with setting up/tearing down a PW when there >>is >> a move of the root to leaf nodes or vice versa, assuming the move is >>based >> on a provisioning action (e.g. an customer order), not some dynamic >> bouncing between switches. >> >> Nick >> >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: Thursday, April 19, 2012 7:53 AM >> To: DelRegno, Christopher N (Nick); Henderickx, Wim (Wim); Alexander >> Vainshtein; Rogers, Josh; Lucy yong; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Nick, >> >> Thanks for the feedback. Now, do you see a problem setting up/tearing >> down a PW when this happens? >> >> Daniel >> >> -----Original Message----- >> From: DelRegno, Christopher N (Nick) [mailto:nick.delregno@verizon.com] >> Sent: Thursday, April 19, 2012 3:40 PM >> To: Daniel Cohn; Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, >> Josh; Lucy yong; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Dan: >> >> As the transformation of a PE from Root<-->Mix and Mix<-->Leaf will be >> driven by our customers, we can't say how often this will or won't >>occur. It >> must be accommodated regardless of perceived rarity. >> >> If I use one of our current extremely popular L2VPN services as an >>example, >> our customers tend to move their ENNI (e.g. Root) locations constantly, >> quite frequently to switches which heretofore only contained UNIs (e.g. >> leaves). >> >> Nick >> >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Daniel Cohn >> Sent: Thursday, April 19, 2012 4:49 AM >> To: Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, Josh; Lucy >>yong; >> Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Hi Wim, >> >> That seems to me a non-negligible change to bridge forwarding logic, I >>think >> setting up/tearing down the PE is cleaner. I don't expect that >>leaf-only to >> root/leaf PE transformations will happen all that often. >> But I think it's important to clarify that the issue is common to both >>drafts. >> >> DC >> >> -----Original Message----- >> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- >> lucent.com] >> Sent: Thursday, April 19, 2012 9:34 AM >> To: Daniel Cohn; Alexander Vainshtein; Rogers, Josh; Lucy yong; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Daniel, we should discuss this as this is not absolutely required to >>tear down >> PW. You can also have an indication in the E-TREE fwd to indicate that >>the >> endpoint has no leaf and as such avoid sending traffic down but allow >>the >> PW to be setup. As such we have some flexibility such that operators can >> select the proper approach they would like to have/implement. >> >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: donderdag 19 april 2012 8:16 >> To: Alexander Vainshtein; Henderickx, Wim (Wim); Rogers, Josh; Lucy >>yong; >> Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Hi Sasha and all, >> >> You have exactly the same "problem" in the 2-VLAN approach - quoting >> from the draft: >> >> 6. LDP Extensions for E-Tree Support >> >> P is a Leaf-only bit, it is set to 1 to indicate that the PE is >>attached with only >> leaves, and set to 0 otherwise. >> >> If the P bit is set, then: >> >> { >> >> If the PE is a leaf-only node itself, then a label release >> message with the error code "Leaf to Leaf PW error" is sent to the >> peer PE and exit the process; >> >> >> So all that you wrote about a leaf-only PE becoming mixed and viceversa >> applies to both solutions. >> >> Regards, >> >> Daniel >> >> -----Original Message----- >> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] >> Sent: Thursday, April 19, 2012 8:31 AM >> To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Wim, >> Lots of thanks for a prompt response. >> >> I think that operational aspects of the VLAN approach (e.g., how is the >> Global VID selected and distributed) should be examined in more detail. >> >> At the same time it seems that the double PW approach carries with it >>too >> many operational problems. >> E.g., no PWs are set up between Leaf-only PEs, but once one of these >> becomes a Mix PE, all the Leaf-only PEs must now recognize it as a valid >> peer. And if a Mix PE reverts to a Leaf only one, all its Leaf-only >>peers must >> drop it and shut down the relevant PWs... >> >> My 2c, >> Sasha >> >> ________________________________________ >> From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] >> Sent: Thursday, April 19, 2012 7:21 AM >> To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Sasha, the VLAN approach allows for a similar operation as the CW does. >> It is orthogonal to the underlying PW deployment of VPLS. >> >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Alexander Vainshtein >> Sent: donderdag 19 april 2012 6:39 >> To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Hi all, >> I fully understand that that what I am going to say is not very popular, >> but: >> >> IMO one of the advantages of the CW-based solution is that it is >>orthogonal >> to usage (or non-usage) of P2MP PWs for effective delivery of BUN >>traffic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>and, in >> a more generic way, localization of effects of changes in the PE >> configuration. >> >> In particular, adding a Leaf AC to a PE that previously has been only >> supporting Root ACs (or vice versa), removal of the last Leaf or last >>Root AC >> from a PE that previously has been supporting a mix etc. affect only >>the PE >> where this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main >> disadvantage of the CW-based approach - I believe it strongly depends on >> specific implementations. And some changes in the forwarding process are >> required in any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of >> Rogers, Josh [josh.rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a more >> complex model. Wether outside s-tag is used to differentiate, or >>dedicated >> pw's are used for the same purpose, it seems both become more complex. >> >> Gile's comparison slide still concisely captures the differences between >> these methods, in my opinion. I haven't seen any new ideas or thoughts >> brought to the group in the past week or two on the subject. I would >>hate >> for both proposed methods to die on the vine because we couldn't decide >> between two methods that have nothing inherently wrong with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" wrote: >> >> >Send this again. >> > >> >Two PW approach can be complex too if the VPLS instance for E-Tree uses >> >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >> >unicast traffic, and some P2MP PWs for multicast traffic. It may double >> >all of them. >> > >> >Lucy >> > >> >-----Original Message----- >> >From: Daniel Cohn [mailto:DanielC@orckit.com] >> >Sent: Wednesday, April 18, 2012 1:42 PM >> >To: Lucy yong; Rogers, Josh; Sam Cao >> >Cc: l2vpn@ietf.org >> >Subject: RE: The status of the approaches to the E-Tree solution? >> > >> >I think the first option its the natural way to go. How is the >> processing >> >in this case more complex? >> > >> >Thumb typed - please be tolerant >> > >> >Lucy yong wrote: >> > >> > >> > >> >Snipped.. >> > >> >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >> PW >> >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >> >traffic coming from a root AC) [[LY]] Not that simple. You construct >> >either two P2MP PWs to all other PEs and let egress PE performing >> >filtering, or construct one P2MP PW to leaf-only PEs and two P2MP PWs >> >to root and leaf PEs and let ingress PE perform forwarding and >> >filtering. Both make node process complex. >> > >> >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >> >delivering the frames to remote PEs. We should utilize them with the >> >minimized changes. Dual VLAN solution is simpler than Dual PW. >> > >> >Regards, >> >Lucy >> > >> > >> >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >> >haven't had any first hand experience with P2MP PW's, however, so don't >> >feel terribly strong about this objection. Is this a real problem for >> >others (now or in the future), or is this objection in the weeds? >> > >> >I'm not sure the 'additional complexity' is notable, or even relevant. >> I >> >encourage others to speak up if they disagree, as P2MP PW is only >> >conceptual to me, and I am unfamiliar with real-life use cases for it. >> > >> >Thanks, >> >Josh >> > >> > >> > >> >On 4/18/12 10:30 AM, "Lucy yong" wrote: >> > >> >>Please see inline. >> >> >> >>-----Original Message----- >> >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >> >>Sent: Tuesday, April 17, 2012 7:14 AM >> >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >> >>giles.heron@gmail.com; simon.delord@gmail.com; >> >>Alexander.Vainshtein@ecitele.com >> >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >> >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >> >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >> >>Yes, 2 pws are only needed between pes with both root and leaf acs >> after >> >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup >> 2 >> >>P2MP PWs if need. There is no difference between P2MP or normal PW >> >>setup. >> But, >> >>can Leaf-ACs be bound to Root PE of P2MP PW? >> >> >> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >> both >> >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >> >>both root and leaf AC and some only have leaf ACs)? >> >>Regards, >> >>Lucy >> >> >> >>Regards, >> >> >> >>Yuqun (Sam) Cao >> >>E-mail: Yuqun.cao@gmail.com >> >> >> >> >> >>-----Original Message----- >> >>From: Daniel Cohn [mailto:DanielC@orckit.com] >> >>Sent: Tuesday, April 17, 2012 4:56 PM >> >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >> >>giles.heron@gmail.com; simon.delord@gmail.com; >> >>Alexander.Vainshtein@ecitele.com; Sam Cao >> >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >> >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >> >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >> >>Adding Sam (as l2vpn@ is holding messages) >> >> >> >>DC >> >> >> >>-----Original Message----- >> >>From: Lucy yong [mailto:lucy.yong@huawei.com] >> >>Sent: Tuesday, April 17, 2012 12:39 AM >> >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >> >>giles.heron@gmail.com; simon.delord@gmail.com; >> >>Alexander.Vainshtein@ecitele.com >> >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >> >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >> >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >> >> >> >>Snipped, >> >> >> >>As we discussed extensively in the list, and as reflected in giles >> >>slide, 2 pws are only needed between pes with both root and leaf acs, >> >>which will typically be a small minority. >> >>[[LY]] Don't know if the assumption is true. Even it is the case, both >> >>approaches can benefit from it. I was off for a while and captures >> some >> >>discussions now. >> >> >> >>Also as per giles slide, dual vlan can have scalability issues due to >> >>additional lookup and double use of vlans in internal emulated lan >> >>interface. Also there are potential backward compatibility issues with >> >>silicon that doesn't support vlan mapping. >> >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >> am >> >>not clear on all the issues. Could you be more specific? As I >> mentioned >> >>in below, two PW approach makes VPLS transport construction and packet >> >>forwarding more complex, I can see potential backward compatibility >> >>issues with 2 PW solution. >> >> >> >>Regards, >> >>Lucy >> >> >> >>Regards, >> >> >> >>Daniel >> >> >> >>Thumb typed - please be tolerant >> >> >> >>Lucy yong wrote: >> >> >> >>In my mind, the VLAN approach means dual vlan method. >> >> >> >>The main concern for CW approach is hardware support. >> >> >> >>Two PW approach can be complex too if the VPLS instance for E-Tree >> uses >> >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >> unicast >> >>traffic, and some P2MP PWs for multicast traffic. It may double all of >> >>them. >> >> >> >>E-tree is an Ethernet service and there is already VLAN based solution >> >>in IEEE, can we just utilize it without complicating VPLS transport >> >>construction? This also makes interworking with Eth only network >> easier. >> >> >> >>Cheers, >> >>Lucy >> >> >> >>-----Original Message----- >> >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >> >>Sent: Monday, April 16, 2012 8:35 AM >> >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >> >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >> >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >> >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >> >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >> >>I believe the initial question was in regard to the CW method. Are >> you >> >>saying that you no longer are interested in that method in preference >> of >> >>the dual vlan method? >> >> >> >> >> >> >> >>Lucy yong wrote: >> >> >> >> >> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >> >> >> >>Lucy >> >> >> >>-----Original Message----- >> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> Behalf >> >>Of Henderickx, Wim (Wim) >> >>Sent: Thursday, April 12, 2012 2:03 AM >> >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >> >>'Alexander.Vainshtein@ecitele.com' >> >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >> >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >> >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >> >> >>The vlan approach is superior as it also works for eth only networks, >> >>etc. On top some vendors indicate hw issues with the cw approach. As >> >>such we have dropped more or less the cw approach. >> >> >> >>Cheers, >> >>Wim >> >>_________________ >> >>sent from blackberry >> >> >> >>----- Original Message ----- >> >>From: Giles Heron [mailto:giles.heron@gmail.com] >> >>Sent: Thursday, April 12, 2012 08:22 AM >> >>To: Simon Delord ; Alexander Vainshtein >> >> >> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >> >>; Andrew Sergeev >> >>; Idan Kaspit ; >> >>Mishael Wexler ; Rotem Cohen >> >> >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >> >> >>Sorry - the "anonymous presentation" was mine. I should possibly have >> >>put in a third column on the CW approach. And hopefully the minutes >> >>will be posted soon. >> >> >> >>We had various discussions, as Simon stated, and consensus seemed to >> be >> >>forming around the two alternatives of two PWEs or two VLANs. I >> believe >> >>three of the authors of the CW approach are also authors of the two >> VLAN >> >>approach and one is also an author of the two PWE approach. So perhaps >> >>it's best to let those four individuals say which approach they prefer >> >>and why? >> >> >> >>Giles >> >> >> >>On 10/04/2012 00:45, "Simon Delord" wrote: >> >> >> >>> Hi Alexander, >> >>> >> >>> You are right, no discussion on the WG mailing list recently, but >> >>> there have been substantial discussions among the authors of various >> >>> solution drafts off the mailing list. As far as I know, no consensus >> >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >> >>> think the CW approach has not been rejected by the WG yet, or the WG >> >>> has not yet decided on which one to adopt. >> >>> >> >>> Simon >> >>> >> >>> 2012/4/8 Alexander Vainshtein >> >>> >> >>>> Hi all, >> >>>> >> >>>> Unfortunately I have not been able to attend the Paris IETF. >> >>>> >> >>>> However, looking up the L2VPN proceedings, I've found a short >> >>>> anonymous presentation called "E-Tree Update" ( >> >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >> >>>> This presentation discusses the differences of the E-Tree >> approaches >> >>>> based on dedicated VLANs (as in >> >>>> >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >> >>>> ext=3D1) and multiple PWs between the PEs (as in >> >>>> >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >> >>>> clude_te >> >>>> xt=3D1) >> >>>> and completely ignores the solution based on usage of the CW in the >> >>>> PWs connecting the PEs (as in >> >>>> >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >> >>>> ext=3D1 >> >>>> ). >> >>>> >> >>>> >> >>>> >> >>>> The Minutes of the Paris L2VPN session are not yet available, but I >> >>>> wonder whether the WG has taken a decision to reject the approach >> >>>> based on the CW usage? I do not remember any recent discussion of >> >>>> this topic on the WG mailing list. >> >>>> >> >>>> >> >>>> >> >>>> Regards, and lots of thanks in advance, >> >>>> >> >>>> Sasha >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> This e-mail message is intended for the recipient only and contains >> >>>> information which is CONFIDENTIAL and which may be proprietary to >> ECI >> >> >> >>>> Telecom. If you have received this transmission in error, please >> >>>> inform us by e-mail, phone or fax, and then delete the original and >> >>>> all copies thereof. >> >>>> >> >> >> >> >> >> >> >> >> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >> >>proprietary information, which is privileged, confidential, or subject >> >>to copyright belonging to Time Warner Cable. This E-mail is intended >> >>solely for the use of the individual or entity to which it is >> addressed. >> >>If you are not the intended recipient of this E-mail, you are hereby >> >>notified that any dissemination, distribution, copying, or action >> taken >> >>in relation to the contents of and attachments to this E-mail is >> >>strictly prohibited and may be unlawful. If you have received this >> >>E-mail in error, please notify the sender immediately and permanently >> >>delete the original and any copy of this E-mail and any printout. >> >> >> > >> > >> >This E-mail and any of its attachments may contain Time Warner Cable >> >proprietary information, which is privileged, confidential, or subject >> to >> >copyright belonging to Time Warner Cable. This E-mail is intended >> solely >> >for the use of the individual or entity to which it is addressed. If >> you >> >are not the intended recipient of this E-mail, you are hereby notified >> >that any dissemination, distribution, copying, or action taken in >> >relation to the contents of and attachments to this E-mail is strictly >> >prohibited and may be unlawful. If you have received this E-mail in >> >error, please notify the sender immediately and permanently delete the >> >original and any copy of this E-mail and any printout. >> >> >> This E-mail and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or subject >>to >> copyright belonging to Time Warner Cable. This E-mail is intended >>solely for >> the use of the individual or entity to which it is addressed. >> If you are not the intended recipient of this E-mail, you are hereby >>notified >> that any dissemination, distribution, copying, or action taken in >>relation to >> the contents of and attachments to this E-mail is strictly prohibited >>and may >> be unlawful. If you have received this E-mail in error, please notify >>the >> sender immediately and permanently delete the original and any copy of >> this E-mail and any printout. >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please inform >>us by >> e-mail, phone or fax, and then delete the original and all copies >>thereof. >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please inform >>us by >> e-mail, phone or fax, and then delete the original and all copies >>thereof. > > >This e-mail message is intended for the recipient only and contains >information which is CONFIDENTIAL and which may be proprietary to ECI >Telecom. If you have received this transmission in error, please inform >us by e-mail, phone or fax, and then delete the original and all copies >thereof. > This E-mail and any of its attachments may contain Time Warner Cable proprie= tary information, which is privileged, confidential, or subject to copyright= belonging to Time Warner Cable. This E-mail is intended solely for the use= of the individual or entity to which it is addressed. If you are not the in= tended recipient of this E-mail, you are hereby notified that any disseminat= ion, distribution, copying, or action taken in relation to the contents of a= nd attachments to this E-mail is strictly prohibited and may be unlawful. If= you have received this E-mail in error, please notify the sender immediatel= y and permanently delete the original and any copy of this E-mail and any pr= intout. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From josh.rogers@twcable.com Thu Apr 19 11:33:07 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B3F11E80B7 for ; Thu, 19 Apr 2012 11:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.898 X-Spam-Level: X-Spam-Status: No, score=0.898 tagged_above=-999 required=5 tests=[AWL=-0.640, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HS_INDEX_PARAM=0.001, J_BACKHAIR_34=1, J_BACKHAIR_43=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 NoxSbkvNqq+5 for ; Thu, 19 Apr 2012 11:33:05 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id EDD3A11E80AF for ; Thu, 19 Apr 2012 11:33:04 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,447,1330923600"; d="scan'208";a="353503524" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 19 Apr 2012 14:31:58 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Thu, 19 Apr 2012 14:33:04 -0400 From: "Rogers, Josh" To: Alexander Vainshtein , "DelRegno, Christopher N (Nick)" Date: Thu, 19 Apr 2012 14:33:03 -0400 Subject: Re: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0eWtsfXTL4ZTonTma1jYCQD0aZow== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@ietf.org" , Sam Cao X-BeenThere: l2vpn@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, 19 Apr 2012 18:33:07 -0000 It is a good question, and frankly, I wouldn't want to manage a network with this solution w/out BGP-AD. (personally, I don't want to manage ANY VPLS w/out BGP-AD though. ;) ) On 4/19/12 2:30 PM, "Alexander Vainshtein" wrote: >Josh, >Lots of thanks for a prompt response. > >Yes, of course I consider BGP-AD and fully agree that with BGP-AD >(extended to distribute PE state - AFAIK, it is not part of the regular >VPLS-related NRLI) the situation becomes manageable. > >The question is, can the dual-PW solution manageable without BGP-AD? > >Regards, > Sasha > >________________________________________ >From: Rogers, Josh [josh.rogers@twcable.com] >Sent: Thursday, April 19, 2012 8:18 PM >To: Alexander Vainshtein; DelRegno, Christopher N (Nick) >Cc: l2vpn@ietf.org; Daniel Cohn; Henderickx, Wim (Wim); Lucy yong; Sam Cao >Subject: Re: The status of the approaches to the E-Tree solution? > >Sasha, > >are you considering a vantage of using BGP-AD, or no? BGP-AD isn't what >I'd call 'an elaborate' auto discovery. If BGP signaling is enlisted, >then all PE's are aware of the existence of all other PE's (regardless of >type), even if they don't setup PW to them. > >So, for your example, current Leaf PE moves to mixed PE. As soon as it >does, it updates signaling (presumably via a defined route-target), all >other PE's now know this is a Mixed PE, and set up PW's to it, just the >same as they would if a new PE was added to the instance. > >If no signaling is involved, these sorts of changes could be laborious, >but no more than any PE add/remove from an instance. > >Thanks, >-Josh > > > >On 4/19/12 12:46 PM, "Alexander Vainshtein" > wrote: > >>Nick, >>I am probably repeating myself, but please consider the case when a >>Leaf-only PE migrates to a Mix one. >> >>Prior to migration all the other Leaf PEs in this VPN did not need any >>PWs to the migrating one so there is a good chance they did not even know >>of its existence. After migration you need PWs between the migrated PE >>and all these Leaf PEs. This means that the configuration action is not >>local to a migrating PE. (PW teardown is easier, since it is enough for >>one side to initiate it, but with setup you need two to tango:-). >> >>My 2c, >> Sasha >> >> >>> -----Original Message----- >>> From: DelRegno, Christopher N (Nick) [mailto:nick.delregno@verizon.com] >>> Sent: Thursday, April 19, 2012 7:38 PM >>> To: Daniel Cohn; Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, >>> Josh; Lucy yong; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> No, I don't see a problem with setting up/tearing down a PW when there >>>is >>> a move of the root to leaf nodes or vice versa, assuming the move is >>>based >>> on a provisioning action (e.g. an customer order), not some dynamic >>> bouncing between switches. >>> >>> Nick >>> >>> -----Original Message----- >>> From: Daniel Cohn [mailto:DanielC@orckit.com] >>> Sent: Thursday, April 19, 2012 7:53 AM >>> To: DelRegno, Christopher N (Nick); Henderickx, Wim (Wim); Alexander >>> Vainshtein; Rogers, Josh; Lucy yong; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> Nick, >>> >>> Thanks for the feedback. Now, do you see a problem setting up/tearing >>> down a PW when this happens? >>> >>> Daniel >>> >>> -----Original Message----- >>> From: DelRegno, Christopher N (Nick) [mailto:nick.delregno@verizon.com] >>> Sent: Thursday, April 19, 2012 3:40 PM >>> To: Daniel Cohn; Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, >>> Josh; Lucy yong; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> Dan: >>> >>> As the transformation of a PE from Root<-->Mix and Mix<-->Leaf will be >>> driven by our customers, we can't say how often this will or won't >>>occur. It >>> must be accommodated regardless of perceived rarity. >>> >>> If I use one of our current extremely popular L2VPN services as an >>>example, >>> our customers tend to move their ENNI (e.g. Root) locations constantly, >>> quite frequently to switches which heretofore only contained UNIs (e.g. >>> leaves). >>> >>> Nick >>> >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>> Of Daniel Cohn >>> Sent: Thursday, April 19, 2012 4:49 AM >>> To: Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, Josh; Lucy >>>yong; >>> Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> Hi Wim, >>> >>> That seems to me a non-negligible change to bridge forwarding logic, I >>>think >>> setting up/tearing down the PE is cleaner. I don't expect that >>>leaf-only to >>> root/leaf PE transformations will happen all that often. >>> But I think it's important to clarify that the issue is common to both >>>drafts. >>> >>> DC >>> >>> -----Original Message----- >>> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- >>> lucent.com] >>> Sent: Thursday, April 19, 2012 9:34 AM >>> To: Daniel Cohn; Alexander Vainshtein; Rogers, Josh; Lucy yong; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> Daniel, we should discuss this as this is not absolutely required to >>>tear down >>> PW. You can also have an indication in the E-TREE fwd to indicate that >>>the >>> endpoint has no leaf and as such avoid sending traffic down but allow >>>the >>> PW to be setup. As such we have some flexibility such that operators >>>can >>> select the proper approach they would like to have/implement. >>> >>> -----Original Message----- >>> From: Daniel Cohn [mailto:DanielC@orckit.com] >>> Sent: donderdag 19 april 2012 8:16 >>> To: Alexander Vainshtein; Henderickx, Wim (Wim); Rogers, Josh; Lucy >>>yong; >>> Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> Hi Sasha and all, >>> >>> You have exactly the same "problem" in the 2-VLAN approach - quoting >>> from the draft: >>> >>> 6. LDP Extensions for E-Tree Support >>> >>> P is a Leaf-only bit, it is set to 1 to indicate that the PE is >>>attached with only >>> leaves, and set to 0 otherwise. >>> >>> If the P bit is set, then: >>> >>> { >>> >>> If the PE is a leaf-only node itself, then a label release >>> message with the error code "Leaf to Leaf PW error" is sent to >>>the >>> peer PE and exit the process; >>> >>> >>> So all that you wrote about a leaf-only PE becoming mixed and viceversa >>> applies to both solutions. >>> >>> Regards, >>> >>> Daniel >>> >>> -----Original Message----- >>> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] >>> Sent: Thursday, April 19, 2012 8:31 AM >>> To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam >>>Cao >>> Cc: l2vpn@ietf.org >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> Wim, >>> Lots of thanks for a prompt response. >>> >>> I think that operational aspects of the VLAN approach (e.g., how is the >>> Global VID selected and distributed) should be examined in more detail. >>> >>> At the same time it seems that the double PW approach carries with it >>>too >>> many operational problems. >>> E.g., no PWs are set up between Leaf-only PEs, but once one of these >>> becomes a Mix PE, all the Leaf-only PEs must now recognize it as a >>>valid >>> peer. And if a Mix PE reverts to a Leaf only one, all its Leaf-only >>>peers must >>> drop it and shut down the relevant PWs... >>> >>> My 2c, >>> Sasha >>> >>> ________________________________________ >>> From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] >>> Sent: Thursday, April 19, 2012 7:21 AM >>> To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> Sasha, the VLAN approach allows for a similar operation as the CW does. >>> It is orthogonal to the underlying PW deployment of VPLS. >>> >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>> Of Alexander Vainshtein >>> Sent: donderdag 19 april 2012 6:39 >>> To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> Hi all, >>> I fully understand that that what I am going to say is not very >>>popular, >>> but: >>> >>> IMO one of the advantages of the CW-based solution is that it is >>>orthogonal >>> to usage (or non-usage) of P2MP PWs for effective delivery of BUN >>>traffic. >>> >>> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>>and, in >>> a more generic way, localization of effects of changes in the PE >>> configuration. >>> >>> In particular, adding a Leaf AC to a PE that previously has been only >>> supporting Root ACs (or vice versa), removal of the last Leaf or last >>>Root AC >>> from a PE that previously has been supporting a mix etc. affect only >>>the PE >>> where this operation happens and not the rest of the PEs. >>> >>> As for the need for HW changes that have been mentioned as a main >>> disadvantage of the CW-based approach - I believe it strongly depends >>>on >>> specific implementations. And some changes in the forwarding process >>>are >>> required in any solution. >>> >>> My 2c, >>> Sasha >>> >>> >>> >>> ________________________________________ >>> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of >>> Rogers, Josh [josh.rogers@twcable.com] >>> Sent: Wednesday, April 18, 2012 9:57 PM >>> To: Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: Re: The status of the approaches to the E-Tree solution? >>> >>> Again, the P2MP situation throws me. Is this something that is used >>> commonly? >>> >>> I'm under the impression that adding P2MP to any model results in a >>>more >>> complex model. Wether outside s-tag is used to differentiate, or >>>dedicated >>> pw's are used for the same purpose, it seems both become more complex. >>> >>> Gile's comparison slide still concisely captures the differences >>>between >>> these methods, in my opinion. I haven't seen any new ideas or thoughts >>> brought to the group in the past week or two on the subject. I would >>>hate >>> for both proposed methods to die on the vine because we couldn't decide >>> between two methods that have nothing inherently wrong with either. >>> >>> -Josh >>> >>> >>> On 4/18/12 1:53 PM, "Lucy yong" wrote: >>> >>> >Send this again. >>> > >>> >Two PW approach can be complex too if the VPLS instance for E-Tree >>>uses >>> >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>> >unicast traffic, and some P2MP PWs for multicast traffic. It may >>>double >>> >all of them. >>> > >>> >Lucy >>> > >>> >-----Original Message----- >>> >From: Daniel Cohn [mailto:DanielC@orckit.com] >>> >Sent: Wednesday, April 18, 2012 1:42 PM >>> >To: Lucy yong; Rogers, Josh; Sam Cao >>> >Cc: l2vpn@ietf.org >>> >Subject: RE: The status of the approaches to the E-Tree solution? >>> > >>> >I think the first option its the natural way to go. How is the >>> processing >>> >in this case more complex? >>> > >>> >Thumb typed - please be tolerant >>> > >>> >Lucy yong wrote: >>> > >>> > >>> > >>> >Snipped.. >>> > >>> >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >>> PW >>> >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >>> >traffic coming from a root AC) [[LY]] Not that simple. You construct >>> >either two P2MP PWs to all other PEs and let egress PE performing >>> >filtering, or construct one P2MP PW to leaf-only PEs and two P2MP PWs >>> >to root and leaf PEs and let ingress PE perform forwarding and >>> >filtering. Both make node process complex. >>> > >>> >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>> >delivering the frames to remote PEs. We should utilize them with the >>> >minimized changes. Dual VLAN solution is simpler than Dual PW. >>> > >>> >Regards, >>> >Lucy >>> > >>> > >>> >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>> >haven't had any first hand experience with P2MP PW's, however, so >>>don't >>> >feel terribly strong about this objection. Is this a real problem for >>> >others (now or in the future), or is this objection in the weeds? >>> > >>> >I'm not sure the 'additional complexity' is notable, or even relevant. >>> I >>> >encourage others to speak up if they disagree, as P2MP PW is only >>> >conceptual to me, and I am unfamiliar with real-life use cases for it. >>> > >>> >Thanks, >>> >Josh >>> > >>> > >>> > >>> >On 4/18/12 10:30 AM, "Lucy yong" wrote: >>> > >>> >>Please see inline. >>> >> >>> >>-----Original Message----- >>> >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>> >>Sent: Tuesday, April 17, 2012 7:14 AM >>> >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>(Wim)'; >>> >>giles.heron@gmail.com; simon.delord@gmail.com; >>> >>Alexander.Vainshtein@ecitele.com >>> >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>> >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>> >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >>> >> >>> >>Yes, 2 pws are only needed between pes with both root and leaf acs >>> after >>> >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup >>> 2 >>> >>P2MP PWs if need. There is no difference between P2MP or normal PW >>> >>setup. >>> But, >>> >>can Leaf-ACs be bound to Root PE of P2MP PW? >>> >> >>> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>> both >>> >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE >>>have >>> >>both root and leaf AC and some only have leaf ACs)? >>> >>Regards, >>> >>Lucy >>> >> >>> >>Regards, >>> >> >>> >>Yuqun (Sam) Cao >>> >>E-mail: Yuqun.cao@gmail.com >>> >> >>> >> >>> >>-----Original Message----- >>> >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>> >>Sent: Tuesday, April 17, 2012 4:56 PM >>> >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>> >>giles.heron@gmail.com; simon.delord@gmail.com; >>> >>Alexander.Vainshtein@ecitele.com; Sam Cao >>> >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>> >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>> >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >>> >> >>> >>Adding Sam (as l2vpn@ is holding messages) >>> >> >>> >>DC >>> >> >>> >>-----Original Message----- >>> >>From: Lucy yong [mailto:lucy.yong@huawei.com] >>> >>Sent: Tuesday, April 17, 2012 12:39 AM >>> >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>> >>giles.heron@gmail.com; simon.delord@gmail.com; >>> >>Alexander.Vainshtein@ecitele.com >>> >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>> >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>> >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >>> >> >>> >> >>> >>Snipped, >>> >> >>> >>As we discussed extensively in the list, and as reflected in giles >>> >>slide, 2 pws are only needed between pes with both root and leaf acs, >>> >>which will typically be a small minority. >>> >>[[LY]] Don't know if the assumption is true. Even it is the case, >>>both >>> >>approaches can benefit from it. I was off for a while and captures >>> some >>> >>discussions now. >>> >> >>> >>Also as per giles slide, dual vlan can have scalability issues due to >>> >>additional lookup and double use of vlans in internal emulated lan >>> >>interface. Also there are potential backward compatibility issues >>>with >>> >>silicon that doesn't support vlan mapping. >>> >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >>> am >>> >>not clear on all the issues. Could you be more specific? As I >>> mentioned >>> >>in below, two PW approach makes VPLS transport construction and >>>packet >>> >>forwarding more complex, I can see potential backward compatibility >>> >>issues with 2 PW solution. >>> >> >>> >>Regards, >>> >>Lucy >>> >> >>> >>Regards, >>> >> >>> >>Daniel >>> >> >>> >>Thumb typed - please be tolerant >>> >> >>> >>Lucy yong wrote: >>> >> >>> >>In my mind, the VLAN approach means dual vlan method. >>> >> >>> >>The main concern for CW approach is hardware support. >>> >> >>> >>Two PW approach can be complex too if the VPLS instance for E-Tree >>> uses >>> >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>> unicast >>> >>traffic, and some P2MP PWs for multicast traffic. It may double all >>>of >>> >>them. >>> >> >>> >>E-tree is an Ethernet service and there is already VLAN based >>>solution >>> >>in IEEE, can we just utilize it without complicating VPLS transport >>> >>construction? This also makes interworking with Eth only network >>> easier. >>> >> >>> >>Cheers, >>> >>Lucy >>> >> >>> >>-----Original Message----- >>> >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>> >>Sent: Monday, April 16, 2012 8:35 AM >>> >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>> >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>> >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>> >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>> >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >>> >> >>> >>I believe the initial question was in regard to the CW method. Are >>> you >>> >>saying that you no longer are interested in that method in preference >>> of >>> >>the dual vlan method? >>> >> >>> >> >>> >> >>> >>Lucy yong wrote: >>> >> >>> >> >>> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >> >>> >>Lucy >>> >> >>> >>-----Original Message----- >>> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>> Behalf >>> >>Of Henderickx, Wim (Wim) >>> >>Sent: Thursday, April 12, 2012 2:03 AM >>> >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>> >>'Alexander.Vainshtein@ecitele.com' >>> >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>> >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>> >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>> >>Subject: Re: The status of the approaches to the E-Tree solution? >>> >> >>> >>The vlan approach is superior as it also works for eth only networks, >>> >>etc. On top some vendors indicate hw issues with the cw approach. As >>> >>such we have dropped more or less the cw approach. >>> >> >>> >>Cheers, >>> >>Wim >>> >>_________________ >>> >>sent from blackberry >>> >> >>> >>----- Original Message ----- >>> >>From: Giles Heron [mailto:giles.heron@gmail.com] >>> >>Sent: Thursday, April 12, 2012 08:22 AM >>> >>To: Simon Delord ; Alexander Vainshtein >>> >> >>> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>> >>; Andrew Sergeev >>> >>; Idan Kaspit ; >>> >>Mishael Wexler ; Rotem Cohen >>> >> >>> >>Subject: Re: The status of the approaches to the E-Tree solution? >>> >> >>> >>Sorry - the "anonymous presentation" was mine. I should possibly >>>have >>> >>put in a third column on the CW approach. And hopefully the minutes >>> >>will be posted soon. >>> >> >>> >>We had various discussions, as Simon stated, and consensus seemed to >>> be >>> >>forming around the two alternatives of two PWEs or two VLANs. I >>> believe >>> >>three of the authors of the CW approach are also authors of the two >>> VLAN >>> >>approach and one is also an author of the two PWE approach. So >>>perhaps >>> >>it's best to let those four individuals say which approach they >>>prefer >>> >>and why? >>> >> >>> >>Giles >>> >> >>> >>On 10/04/2012 00:45, "Simon Delord" wrote: >>> >> >>> >>> Hi Alexander, >>> >>> >>> >>> You are right, no discussion on the WG mailing list recently, but >>> >>> there have been substantial discussions among the authors of >>>various >>> >>> solution drafts off the mailing list. As far as I know, no >>>consensus >>> >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>> >>> think the CW approach has not been rejected by the WG yet, or the >>>WG >>> >>> has not yet decided on which one to adopt. >>> >>> >>> >>> Simon >>> >>> >>> >>> 2012/4/8 Alexander Vainshtein >>> >>> >>> >>>> Hi all, >>> >>>> >>> >>>> Unfortunately I have not been able to attend the Paris IETF. >>> >>>> >>> >>>> However, looking up the L2VPN proceedings, I've found a short >>> >>>> anonymous presentation called "E-Tree Update" ( >>> >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>> >>>> This presentation discusses the differences of the E-Tree >>> approaches >>> >>>> based on dedicated VLANs (as in >>> >>>> >>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>> >>>> ext=3D1) and multiple PWs between the PEs (as in >>> >>>> >>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>> >>>> clude_te >>> >>>> xt=3D1) >>> >>>> and completely ignores the solution based on usage of the CW in >>>the >>> >>>> PWs connecting the PEs (as in >>> >>>> >>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>> >>>> ext=3D1 >>> >>>> ). >>> >>>> >>> >>>> >>> >>>> >>> >>>> The Minutes of the Paris L2VPN session are not yet available, but >>>I >>> >>>> wonder whether the WG has taken a decision to reject the approach >>> >>>> based on the CW usage? I do not remember any recent discussion of >>> >>>> this topic on the WG mailing list. >>> >>>> >>> >>>> >>> >>>> >>> >>>> Regards, and lots of thanks in advance, >>> >>>> >>> >>>> Sasha >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> This e-mail message is intended for the recipient only and >>>contains >>> >>>> information which is CONFIDENTIAL and which may be proprietary to >>> ECI >>> >> >>> >>>> Telecom. If you have received this transmission in error, please >>> >>>> inform us by e-mail, phone or fax, and then delete the original >>>and >>> >>>> all copies thereof. >>> >>>> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >>This E-mail and any of its attachments may contain Time Warner Cable >>> >>proprietary information, which is privileged, confidential, or >>>subject >>> >>to copyright belonging to Time Warner Cable. This E-mail is intended >>> >>solely for the use of the individual or entity to which it is >>> addressed. >>> >>If you are not the intended recipient of this E-mail, you are hereby >>> >>notified that any dissemination, distribution, copying, or action >>> taken >>> >>in relation to the contents of and attachments to this E-mail is >>> >>strictly prohibited and may be unlawful. If you have received this >>> >>E-mail in error, please notify the sender immediately and permanently >>> >>delete the original and any copy of this E-mail and any printout. >>> >> >>> > >>> > >>> >This E-mail and any of its attachments may contain Time Warner Cable >>> >proprietary information, which is privileged, confidential, or subject >>> to >>> >copyright belonging to Time Warner Cable. This E-mail is intended >>> solely >>> >for the use of the individual or entity to which it is addressed. If >>> you >>> >are not the intended recipient of this E-mail, you are hereby notified >>> >that any dissemination, distribution, copying, or action taken in >>> >relation to the contents of and attachments to this E-mail is strictly >>> >prohibited and may be unlawful. If you have received this E-mail in >>> >error, please notify the sender immediately and permanently delete the >>> >original and any copy of this E-mail and any printout. >>> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>> proprietary information, which is privileged, confidential, or subject >>>to >>> copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for >>> the use of the individual or entity to which it is addressed. >>> If you are not the intended recipient of this E-mail, you are hereby >>>notified >>> that any dissemination, distribution, copying, or action taken in >>>relation to >>> the contents of and attachments to this E-mail is strictly prohibited >>>and may >>> be unlawful. If you have received this E-mail in error, please notify >>>the >>> sender immediately and permanently delete the original and any copy of >>> this E-mail and any printout. >>> This e-mail message is intended for the recipient only and contains >>> information which is CONFIDENTIAL and which may be proprietary to ECI >>> Telecom. If you have received this transmission in error, please inform >>>us by >>> e-mail, phone or fax, and then delete the original and all copies >>>thereof. >>> This e-mail message is intended for the recipient only and contains >>> information which is CONFIDENTIAL and which may be proprietary to ECI >>> Telecom. If you have received this transmission in error, please inform >>>us by >>> e-mail, phone or fax, and then delete the original and all copies >>>thereof. >> >> >>This e-mail message is intended for the recipient only and contains >>information which is CONFIDENTIAL and which may be proprietary to ECI >>Telecom. If you have received this transmission in error, please inform >>us by e-mail, phone or fax, and then delete the original and all copies >>thereof. >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. >This e-mail message is intended for the recipient only and contains >information which is CONFIDENTIAL and which may be proprietary to ECI >Telecom. If you have received this transmission in error, please inform >us by e-mail, phone or fax, and then delete the original and all copies >thereof. > This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From DanielC@orckit.com Thu Apr 19 12:24:10 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61C611E809A for ; Thu, 19 Apr 2012 12:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.377 X-Spam-Level: ** X-Spam-Status: No, score=2.377 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, J_BACKHAIR_34=1, J_BACKHAIR_43=1, RCVD_ILLEGAL_IP=1.908, RCVD_NUMERIC_HELO=2.067] 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 FKmku11S6hga for ; Thu, 19 Apr 2012 12:24:09 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0B11C11E8074 for ; Thu, 19 Apr 2012 12:24:07 -0700 (PDT) Received: from 1.1.40.5 ([1.1.40.5]) by tlvmail1.corrigent.com ([1.1.40.5]) with Microsoft Exchange Server HTTP-DAV ; Thu, 19 Apr 2012 19:26:19 +0000 Date: Thu, 19 Apr 2012 22:24:00 +0300 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <13dd01cd1e62$4bfaddac$05280101@corrigent.com> Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdiov///PycP//4qvA//+OPpD//ux5AP/915BA//ujPiD/9w8fQP/uJLgA/9wlmWj/uDqFxQ== X-MimeOLE: Produced By Microsoft Exchange V6.5 Importance: normal From: "Daniel Cohn" To: "Alexander Vainshtein" , "Rogers, Josh" , "DelRegno, Christopher N (Nick)" MIME-Version: 1.0 Cc: l2vpn@ietf.org, Sam Cao X-BeenThere: l2vpn@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, 19 Apr 2012 19:24:11 -0000 Hi Sasha, =0A= =0A= Both solutions include the leaf-only information in the bgp extension=0A= =0A= Thumb typed - please be tolerant=0A= =0A= Alexander Vainshtein wrote:=0A= =0A= Josh, Lots of thanks for a prompt response. Yes, of course I consider BGP-AD and fully agree that with BGP-AD = (extended to distribute PE state - AFAIK, it is not part of the regular = VPLS-related NRLI) the situation becomes manageable. The question is, can the dual-PW solution manageable without BGP-AD? Regards, Sasha=20 ________________________________________ From: Rogers, Josh [josh.rogers@twcable.com] Sent: Thursday, April 19, 2012 8:18 PM To: Alexander Vainshtein; DelRegno, Christopher N (Nick) Cc: l2vpn@ietf.org; Daniel Cohn; Henderickx, Wim (Wim); Lucy yong; Sam = Cao Subject: Re: The status of the approaches to the E-Tree solution? Sasha, are you considering a vantage of using BGP-AD, or no? BGP-AD isn't what I'd call 'an elaborate' auto discovery. If BGP signaling is enlisted, then all PE's are aware of the existence of all other PE's (regardless = of type), even if they don't setup PW to them. So, for your example, current Leaf PE moves to mixed PE. As soon as it does, it updates signaling (presumably via a defined route-target), all other PE's now know this is a Mixed PE, and set up PW's to it, just the same as they would if a new PE was added to the instance. If no signaling is involved, these sorts of changes could be laborious, but no more than any PE add/remove from an instance. Thanks, -Josh On 4/19/12 12:46 PM, "Alexander Vainshtein" wrote: >Nick, >I am probably repeating myself, but please consider the case when a >Leaf-only PE migrates to a Mix one. > >Prior to migration all the other Leaf PEs in this VPN did not need any >PWs to the migrating one so there is a good chance they did not even = know >of its existence. After migration you need PWs between the migrated PE >and all these Leaf PEs. This means that the configuration action is not >local to a migrating PE. (PW teardown is easier, since it is enough for >one side to initiate it, but with setup you need two to tango:-). > >My 2c, > Sasha > > >> -----Original Message----- >> From: DelRegno, Christopher N (Nick) = [mailto:nick.delregno@verizon.com] >> Sent: Thursday, April 19, 2012 7:38 PM >> To: Daniel Cohn; Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, >> Josh; Lucy yong; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> No, I don't see a problem with setting up/tearing down a PW when = there >>is >> a move of the root to leaf nodes or vice versa, assuming the move is >>based >> on a provisioning action (e.g. an customer order), not some dynamic >> bouncing between switches. >> >> Nick >> >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: Thursday, April 19, 2012 7:53 AM >> To: DelRegno, Christopher N (Nick); Henderickx, Wim (Wim); Alexander >> Vainshtein; Rogers, Josh; Lucy yong; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Nick, >> >> Thanks for the feedback. Now, do you see a problem setting up/tearing >> down a PW when this happens? >> >> Daniel >> >> -----Original Message----- >> From: DelRegno, Christopher N (Nick) = [mailto:nick.delregno@verizon.com] >> Sent: Thursday, April 19, 2012 3:40 PM >> To: Daniel Cohn; Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, >> Josh; Lucy yong; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Dan: >> >> As the transformation of a PE from Root<-->Mix and Mix<-->Leaf will = be >> driven by our customers, we can't say how often this will or won't >>occur. It >> must be accommodated regardless of perceived rarity. >> >> If I use one of our current extremely popular L2VPN services as an >>example, >> our customers tend to move their ENNI (e.g. Root) locations = constantly, >> quite frequently to switches which heretofore only contained UNIs = (e.g. >> leaves). >> >> Nick >> >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On = Behalf >> Of Daniel Cohn >> Sent: Thursday, April 19, 2012 4:49 AM >> To: Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, Josh; Lucy >>yong; >> Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Hi Wim, >> >> That seems to me a non-negligible change to bridge forwarding logic, = I >>think >> setting up/tearing down the PE is cleaner. I don't expect that >>leaf-only to >> root/leaf PE transformations will happen all that often. >> But I think it's important to clarify that the issue is common to = both >>drafts. >> >> DC >> >> -----Original Message----- >> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- >> lucent.com] >> Sent: Thursday, April 19, 2012 9:34 AM >> To: Daniel Cohn; Alexander Vainshtein; Rogers, Josh; Lucy yong; Sam = Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Daniel, we should discuss this as this is not absolutely required to >>tear down >> PW. You can also have an indication in the E-TREE fwd to indicate = that >>the >> endpoint has no leaf and as such avoid sending traffic down but allow >>the >> PW to be setup. As such we have some flexibility such that operators = can >> select the proper approach they would like to have/implement. >> >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: donderdag 19 april 2012 8:16 >> To: Alexander Vainshtein; Henderickx, Wim (Wim); Rogers, Josh; Lucy >>yong; >> Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Hi Sasha and all, >> >> You have exactly the same "problem" in the 2-VLAN approach - quoting >> from the draft: >> >> 6. LDP Extensions for E-Tree Support >> >> P is a Leaf-only bit, it is set to 1 to indicate that the PE is >>attached with only >> leaves, and set to 0 otherwise. >> >> If the P bit is set, then: >> >> { >> >> If the PE is a leaf-only node itself, then a label release >> message with the error code "Leaf to Leaf PW error" is sent to = the >> peer PE and exit the process; >> >> >> So all that you wrote about a leaf-only PE becoming mixed and = viceversa >> applies to both solutions. >> >> Regards, >> >> Daniel >> >> -----Original Message----- >> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] >> Sent: Thursday, April 19, 2012 8:31 AM >> To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam = Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Wim, >> Lots of thanks for a prompt response. >> >> I think that operational aspects of the VLAN approach (e.g., how is = the >> Global VID selected and distributed) should be examined in more = detail. >> >> At the same time it seems that the double PW approach carries with it >>too >> many operational problems. >> E.g., no PWs are set up between Leaf-only PEs, but once one of these >> becomes a Mix PE, all the Leaf-only PEs must now recognize it as a = valid >> peer. And if a Mix PE reverts to a Leaf only one, all its Leaf-only >>peers must >> drop it and shut down the relevant PWs... >> >> My 2c, >> Sasha >> >> ________________________________________ >> From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] >> Sent: Thursday, April 19, 2012 7:21 AM >> To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam = Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Sasha, the VLAN approach allows for a similar operation as the CW = does. >> It is orthogonal to the underlying PW deployment of VPLS. >> >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On = Behalf >> Of Alexander Vainshtein >> Sent: donderdag 19 april 2012 6:39 >> To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Hi all, >> I fully understand that that what I am going to say is not very = popular, >> but: >> >> IMO one of the advantages of the CW-based solution is that it is >>orthogonal >> to usage (or non-usage) of P2MP PWs for effective delivery of BUN >>traffic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>and, in >> a more generic way, localization of effects of changes in the PE >> configuration. >> >> In particular, adding a Leaf AC to a PE that previously has been only >> supporting Root ACs (or vice versa), removal of the last Leaf or last >>Root AC >> from a PE that previously has been supporting a mix etc. affect only >>the PE >> where this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main >> disadvantage of the CW-based approach - I believe it strongly depends = on >> specific implementations. And some changes in the forwarding process = are >> required in any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of >> Rogers, Josh [josh.rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a = more >> complex model. Wether outside s-tag is used to differentiate, or >>dedicated >> pw's are used for the same purpose, it seems both become more = complex. >> >> Gile's comparison slide still concisely captures the differences = between >> these methods, in my opinion. I haven't seen any new ideas or = thoughts >> brought to the group in the past week or two on the subject. I would >>hate >> for both proposed methods to die on the vine because we couldn't = decide >> between two methods that have nothing inherently wrong with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" wrote: >> >> >Send this again. >> > >> >Two PW approach can be complex too if the VPLS instance for E-Tree = uses >> >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >> >unicast traffic, and some P2MP PWs for multicast traffic. It may = double >> >all of them. >> > >> >Lucy >> > >> >-----Original Message----- >> >From: Daniel Cohn [mailto:DanielC@orckit.com] >> >Sent: Wednesday, April 18, 2012 1:42 PM >> >To: Lucy yong; Rogers, Josh; Sam Cao >> >Cc: l2vpn@ietf.org >> >Subject: RE: The status of the approaches to the E-Tree solution? >> > >> >I think the first option its the natural way to go. How is the >> processing >> >in this case more complex? >> > >> >Thumb typed - please be tolerant >> > >> >Lucy yong wrote: >> > >> > >> > >> >Snipped.. >> > >> >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only = P2MP >> PW >> >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW = (for >> >traffic coming from a root AC) [[LY]] Not that simple. You construct >> >either two P2MP PWs to all other PEs and let egress PE performing >> >filtering, or construct one P2MP PW to leaf-only PEs and two P2MP = PWs >> >to root and leaf PEs and let ingress PE perform forwarding and >> >filtering. Both make node process complex. >> > >> >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW = for >> >delivering the frames to remote PEs. We should utilize them with the >> >minimized changes. Dual VLAN solution is simpler than Dual PW. >> > >> >Regards, >> >Lucy >> > >> > >> >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >> >haven't had any first hand experience with P2MP PW's, however, so = don't >> >feel terribly strong about this objection. Is this a real problem = for >> >others (now or in the future), or is this objection in the weeds? >> > >> >I'm not sure the 'additional complexity' is notable, or even = relevant. >> I >> >encourage others to speak up if they disagree, as P2MP PW is only >> >conceptual to me, and I am unfamiliar with real-life use cases for = it. >> > >> >Thanks, >> >Josh >> > >> > >> > >> >On 4/18/12 10:30 AM, "Lucy yong" wrote: >> > >> >>Please see inline. >> >> >> >>-----Original Message----- >> >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >> >>Sent: Tuesday, April 17, 2012 7:14 AM >> >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim = (Wim)'; >> >>giles.heron@gmail.com; simon.delord@gmail.com; >> >>Alexander.Vainshtein@ecitele.com >> >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >> >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >> >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >> >>Yes, 2 pws are only needed between pes with both root and leaf acs >> after >> >>improving Dual-PW approach. If consider P2MP, Dual-PW approach = setup >> 2 >> >>P2MP PWs if need. There is no difference between P2MP or normal PW >> >>setup. >> But, >> >>can Leaf-ACs be bound to Root PE of P2MP PW? >> >> >> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >> both >> >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE = have >> >>both root and leaf AC and some only have leaf ACs)? >> >>Regards, >> >>Lucy >> >> >> >>Regards, >> >> >> >>Yuqun (Sam) Cao >> >>E-mail: Yuqun.cao@gmail.com >> >> >> >> >> >>-----Original Message----- >> >>From: Daniel Cohn [mailto:DanielC@orckit.com] >> >>Sent: Tuesday, April 17, 2012 4:56 PM >> >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >> >>giles.heron@gmail.com; simon.delord@gmail.com; >> >>Alexander.Vainshtein@ecitele.com; Sam Cao >> >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >> >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >> >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >> >>Adding Sam (as l2vpn@ is holding messages) >> >> >> >>DC >> >> >> >>-----Original Message----- >> >>From: Lucy yong [mailto:lucy.yong@huawei.com] >> >>Sent: Tuesday, April 17, 2012 12:39 AM >> >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >> >>giles.heron@gmail.com; simon.delord@gmail.com; >> >>Alexander.Vainshtein@ecitele.com >> >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >> >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >> >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >> >> >> >>Snipped, >> >> >> >>As we discussed extensively in the list, and as reflected in giles >> >>slide, 2 pws are only needed between pes with both root and leaf = acs, >> >>which will typically be a small minority. >> >>[[LY]] Don't know if the assumption is true. Even it is the case, = both >> >>approaches can benefit from it. I was off for a while and captures >> some >> >>discussions now. >> >> >> >>Also as per giles slide, dual vlan can have scalability issues due = to >> >>additional lookup and double use of vlans in internal emulated lan >> >>interface. Also there are potential backward compatibility issues = with >> >>silicon that doesn't support vlan mapping. >> >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. = I >> am >> >>not clear on all the issues. Could you be more specific? As I >> mentioned >> >>in below, two PW approach makes VPLS transport construction and = packet >> >>forwarding more complex, I can see potential backward compatibility >> >>issues with 2 PW solution. >> >> >> >>Regards, >> >>Lucy >> >> >> >>Regards, >> >> >> >>Daniel >> >> >> >>Thumb typed - please be tolerant >> >> >> >>Lucy yong wrote: >> >> >> >>In my mind, the VLAN approach means dual vlan method. >> >> >> >>The main concern for CW approach is hardware support. >> >> >> >>Two PW approach can be complex too if the VPLS instance for E-Tree >> uses >> >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >> unicast >> >>traffic, and some P2MP PWs for multicast traffic. It may double all = of >> >>them. >> >> >> >>E-tree is an Ethernet service and there is already VLAN based = solution >> >>in IEEE, can we just utilize it without complicating VPLS transport >> >>construction? This also makes interworking with Eth only network >> easier. >> >> >> >>Cheers, >> >>Lucy >> >> >> >>-----Original Message----- >> >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >> >>Sent: Monday, April 16, 2012 8:35 AM >> >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >> >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >> >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >> >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >> >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >> >>I believe the initial question was in regard to the CW method. Are >> you >> >>saying that you no longer are interested in that method in = preference >> of >> >>the dual vlan method? >> >> >> >> >> >> >> >>Lucy yong wrote: >> >> >> >> >> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >> >> >> >>Lucy >> >> >> >>-----Original Message----- >> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> Behalf >> >>Of Henderickx, Wim (Wim) >> >>Sent: Thursday, April 12, 2012 2:03 AM >> >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >> >>'Alexander.Vainshtein@ecitele.com' >> >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >> >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >> >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >> >> >>The vlan approach is superior as it also works for eth only = networks, >> >>etc. On top some vendors indicate hw issues with the cw approach. = As >> >>such we have dropped more or less the cw approach. >> >> >> >>Cheers, >> >>Wim >> >>_________________ >> >>sent from blackberry >> >> >> >>----- Original Message ----- >> >>From: Giles Heron [mailto:giles.heron@gmail.com] >> >>Sent: Thursday, April 12, 2012 08:22 AM >> >>To: Simon Delord ; Alexander Vainshtein >> >> >> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >> >>; Andrew Sergeev >> >>; Idan Kaspit = ; >> >>Mishael Wexler ; Rotem Cohen >> >> >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >> >> >>Sorry - the "anonymous presentation" was mine. I should possibly = have >> >>put in a third column on the CW approach. And hopefully the = minutes >> >>will be posted soon. >> >> >> >>We had various discussions, as Simon stated, and consensus seemed = to >> be >> >>forming around the two alternatives of two PWEs or two VLANs. I >> believe >> >>three of the authors of the CW approach are also authors of the two >> VLAN >> >>approach and one is also an author of the two PWE approach. So = perhaps >> >>it's best to let those four individuals say which approach they = prefer >> >>and why? >> >> >> >>Giles >> >> >> >>On 10/04/2012 00:45, "Simon Delord" wrote: >> >> >> >>> Hi Alexander, >> >>> >> >>> You are right, no discussion on the WG mailing list recently, but >> >>> there have been substantial discussions among the authors of = various >> >>> solution drafts off the mailing list. As far as I know, no = consensus >> >>> yet before ietf83, not sure the progress in the Paris WG meeting. = I >> >>> think the CW approach has not been rejected by the WG yet, or the = WG >> >>> has not yet decided on which one to adopt. >> >>> >> >>> Simon >> >>> >> >>> 2012/4/8 Alexander Vainshtein >> >>> >> >>>> Hi all, >> >>>> >> >>>> Unfortunately I have not been able to attend the Paris IETF. >> >>>> >> >>>> However, looking up the L2VPN proceedings, I've found a short >> >>>> anonymous presentation called "E-Tree Update" ( >> >>>> = http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >> >>>> This presentation discusses the differences of the E-Tree >> approaches >> >>>> based on dedicated VLANs (as in >> >>>> >> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >> >>>> ext=3D1) and multiple PWs between the PEs (as in >> >>>> >> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >> >>>> clude_te >> >>>> xt=3D1) >> >>>> and completely ignores the solution based on usage of the CW in = the >> >>>> PWs connecting the PEs (as in >> >>>> >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >> >>>> ext=3D1 >> >>>> ). >> >>>> >> >>>> >> >>>> >> >>>> The Minutes of the Paris L2VPN session are not yet available, = but I >> >>>> wonder whether the WG has taken a decision to reject the = approach >> >>>> based on the CW usage? I do not remember any recent discussion = of >> >>>> this topic on the WG mailing list. >> >>>> >> >>>> >> >>>> >> >>>> Regards, and lots of thanks in advance, >> >>>> >> >>>> Sasha >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> This e-mail message is intended for the recipient only and = contains >> >>>> information which is CONFIDENTIAL and which may be proprietary = to >> ECI >> >> >> >>>> Telecom. If you have received this transmission in error, please >> >>>> inform us by e-mail, phone or fax, and then delete the original = and >> >>>> all copies thereof. >> >>>> >> >> >> >> >> >> >> >> >> >> >> >>This E-mail and any of its attachments may contain Time Warner = Cable >> >>proprietary information, which is privileged, confidential, or = subject >> >>to copyright belonging to Time Warner Cable. This E-mail is = intended >> >>solely for the use of the individual or entity to which it is >> addressed. >> >>If you are not the intended recipient of this E-mail, you are = hereby >> >>notified that any dissemination, distribution, copying, or action >> taken >> >>in relation to the contents of and attachments to this E-mail is >> >>strictly prohibited and may be unlawful. If you have received this >> >>E-mail in error, please notify the sender immediately and = permanently >> >>delete the original and any copy of this E-mail and any printout. >> >> >> > >> > >> >This E-mail and any of its attachments may contain Time Warner Cable >> >proprietary information, which is privileged, confidential, or = subject >> to >> >copyright belonging to Time Warner Cable. This E-mail is intended >> solely >> >for the use of the individual or entity to which it is addressed. If >> you >> >are not the intended recipient of this E-mail, you are hereby = notified >> >that any dissemination, distribution, copying, or action taken in >> >relation to the contents of and attachments to this E-mail is = strictly >> >prohibited and may be unlawful. If you have received this E-mail in >> >error, please notify the sender immediately and permanently delete = the >> >original and any copy of this E-mail and any printout. >> >> >> This E-mail and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or = subject >>to >> copyright belonging to Time Warner Cable. This E-mail is intended >>solely for >> the use of the individual or entity to which it is addressed. >> If you are not the intended recipient of this E-mail, you are hereby >>notified >> that any dissemination, distribution, copying, or action taken in >>relation to >> the contents of and attachments to this E-mail is strictly prohibited >>and may >> be unlawful. If you have received this E-mail in error, please notify >>the >> sender immediately and permanently delete the original and any copy = of >> this E-mail and any printout. >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please = inform >>us by >> e-mail, phone or fax, and then delete the original and all copies >>thereof. >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please = inform >>us by >> e-mail, phone or fax, and then delete the original and all copies >>thereof. > > >This e-mail message is intended for the recipient only and contains >information which is CONFIDENTIAL and which may be proprietary to ECI >Telecom. If you have received this transmission in error, please inform >us by e-mail, phone or fax, and then delete the original and all copies >thereof. > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies = thereof. From yuqun.cao@gmail.com Thu Apr 19 18:44:58 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A45511E8091; Thu, 19 Apr 2012 18:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=-1.667, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 amnF6FGNWBae; Thu, 19 Apr 2012 18:44:55 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8423721F8569; Thu, 19 Apr 2012 18:44:55 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so460538pbb.31 for ; Thu, 19 Apr 2012 18:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:x-mailer:x-mimeole:in-reply-to:thread-index; bh=H6e9bjExrPqm9wfMasIVbflT+I+2QW1qM+HCdzUgYbU=; b=EhXD6vHeg1eAR3PIjsP7uIFfQ60LQN9z9G+nW8o+wwNjs516IY7Oa5+/Y+NOSMwYD+ 1xM2b2IbRjyJ5FkRGBfIdG2vejv52q8T3bFnQY9iIEh47nOfgLHAyzIbKVk4ZbfM3wIM 1BEWJZH3hgP6dyaAY2o5+PoA2uEedb/7ULk6pHG5Uz4TgvxpQLS9j+Q0hmA1OUHaLmTj XIOhHQuwOGuZcCdHDYDPf49veLos/MgEJpWsBHZGNAYRcoTKj7TelWuJVyQKU9brwsqq 3yTe9NC0lU54BhK2SRSKcmo0reL9mEfNIi8zHgK6O92YR9nithuTMYSeTpaBGyjboR7n iu2w== Received: by 10.68.221.136 with SMTP id qe8mr8953381pbc.108.1334886294723; Thu, 19 Apr 2012 18:44:54 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id ge1sm3825110pbc.0.2012.04.19.18.44.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Apr 2012 18:44:53 -0700 (PDT) From: "Sam Cao" To: "'Ran Chen'" , "'Alexander Vainshtein'" References: Subject: RE: RE: The status of the approaches to the E-Tree solution? Date: Fri, 20 Apr 2012 09:44:46 +0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01CD1EDA.3E7B6370" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: Thread-Index: Ac0d/QO5cV++UJzkTNeO1rU21a7DMQAmSR8w Cc: l2vpn@ietf.org, l2vpn-bounces@ietf.org X-BeenThere: l2vpn@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, 20 Apr 2012 01:44:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01CD1EDA.3E7B6370 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Ran, =20 I have listed this case before, and it is reasonable.=20 =20 We may teardown PW if VSI attributes change, such as Control Word, MTU = Nego, and etc. Current solutions also do like this. I gave one example, if all = ACs are down, we SHOULD teardown PWs. If Leaf-only is changed to Mixed, obviously its attribute changes. We may teardown PW and re-setup. =20 IMO, this seems reasonable behavior. =20 Sam =20 _____ =20 From: Ran Chen [mailto:chen.ran@zte.com.cn]=20 Sent: Thursday, April 19, 2012 3:21 PM To: Alexander Vainshtein Cc: Daniel Cohn; Rogers, Josh; l2vpn@ietf.org; l2vpn-bounces@ietf.org; = Lucy yong; Henderickx, Wim (Wim); Sam Cao Subject: =B4=F0=B8=B4: RE: The status of the approaches to the E-Tree = solution? =20 Hi Sasha,=20 Plese see inline, thanks=20 Alexander Vainshtein =20 =B7=A2=BC=FE=C8=CB: l2vpn-bounces@ietf.org=20 2012/04/19 13:31=20 =CA=D5=BC=FE=C8=CB "Henderickx, Wim (Wim)" , "Rogers, Josh" , Lucy yong , = Daniel Cohn , Sam Cao =20 =B3=AD=CB=CD "l2vpn@ietf.org" =20 =D6=F7=CC=E2 RE: The status of the approaches to the E-Tree solution? =20 =20 =20 Wim, Lots of thanks for a prompt response. I think that operational aspects of the VLAN approach (e.g., how is the Global VID selected and distributed) should be examined in more detail. [Ran] Agree, and there have already been such draft that describe "how = is the Gloabal VID selected and distributed" in L2VPN WG, the link is:http://tools.ietf.org/html/draft-chen-l2vpn-vpls-etree-vlan-01.=20 At the same time it seems that the double PW approach carries with it = too many operational problems. E.g., no PWs are set up between Leaf-only PEs, but once one of these = becomes a Mix PE, all the Leaf-only PEs must now recognize it as a valid peer. = And if a Mix PE reverts to a Leaf only one, all its Leaf-only peers must = drop it and shut down the relevant PWs... My 2c, Sasha ________________________________________ From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] Sent: Thursday, April 19, 2012 7:21 AM To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Sasha, the VLAN approach allows for a similar operation as the CW does. = It is orthogonal to the underlying PW deployment of VPLS. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Alexander Vainshtein Sent: donderdag 19 april 2012 6:39 To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi all, I fully understand that that what I am going to say is not very popular, but: IMO one of the advantages of the CW-based solution is that it is = orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN = traffic. Another advantage is preservation of full mesh of P2P PWs in a VPLS, = and, in a more generic way, localization of effects of changes in the PE configuration. In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect only = the PE where this operation happens and not the rest of the PEs. As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of = Rogers, Josh [josh.rogers@twcable.com] Sent: Wednesday, April 18, 2012 9:57 PM To: Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Again, the P2MP situation throws me. Is this something that is used commonly? I'm under the impression that adding P2MP to any model results in a more complex model. Wether outside s-tag is used to differentiate, or dedicated pw's are used for the same purpose, it seems both become more complex. Gile's comparison slide still concisely captures the differences between these methods, in my opinion. I haven't seen any new ideas or thoughts brought to the group in the past week or two on the subject. I would = hate for both proposed methods to die on the vine because we couldn't decide between two methods that have nothing inherently wrong with either. -Josh On 4/18/12 1:53 PM, "Lucy yong" wrote: >Send this again. > >Two PW approach can be complex too if the VPLS instance for E-Tree uses >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >unicast traffic, and some P2MP PWs for multicast traffic. It may double >all of them. > >Lucy > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, April 18, 2012 1:42 PM >To: Lucy yong; Rogers, Josh; Sam Cao >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >I think the first option its the natural way to go. How is the = processing >in this case more complex? > >Thumb typed - please be tolerant > >Lucy yong wrote: > > > >Snipped.. > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP = PW >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >traffic coming from a root AC) >[[LY]] Not that simple. You construct either two P2MP PWs to all other >PEs and let egress PE performing filtering, or construct one P2MP PW to >leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >perform forwarding and filtering. Both make node process complex. > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >delivering the frames to remote PEs. We should utilize them with the >minimized changes. Dual VLAN solution is simpler than Dual PW. > >Regards, >Lucy > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >haven't had any first hand experience with P2MP PW's, however, so don't >feel terribly strong about this objection. Is this a real problem for >others (now or in the future), or is this objection in the weeds? > >I'm not sure the 'additional complexity' is notable, or even relevant. = I >encourage others to speak up if they disagree, as P2MP PW is only >conceptual to me, and I am unfamiliar with real-life use cases for it. > >Thanks, >Josh > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > >>Please see inline. >> >>-----Original Message----- >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>Sent: Tuesday, April 17, 2012 7:14 AM >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Yes, 2 pws are only needed between pes with both root and leaf acs = after >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>P2MP >>PWs if need. There is no difference between P2MP or normal PW setup. = But, >>can Leaf-ACs be bound to Root PE of P2MP PW? >> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with = both >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>both root and leaf AC and some only have leaf ACs)? >>Regards, >>Lucy >> >>Regards, >> >>Yuqun (Sam) Cao >>E-mail: Yuqun.cao@gmail.com >> >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Tuesday, April 17, 2012 4:56 PM >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; >>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Adding Sam (as l2vpn@ is holding messages) >> >>DC >> >>-----Original Message----- >>From: Lucy yong [mailto:lucy.yong@huawei.com] >>Sent: Tuesday, April 17, 2012 12:39 AM >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >>Snipped, >> >>As we discussed extensively in the list, and as reflected in giles >>slide, 2 pws are only needed between pes with both root and leaf acs, >>which will typically be a small minority. >>[[LY]] Don't know if the assumption is true. Even it is the case, both >>approaches can benefit from it. I was off for a while and captures = some >>discussions now. >> >>Also as per giles slide, dual vlan can have scalability issues due to >>additional lookup and double use of vlans in internal emulated lan >>interface. Also there are potential backward compatibility issues with >>silicon that doesn't support vlan mapping. >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I = am >>not clear on all the issues. Could you be more specific? As I = mentioned >>in below, two PW approach makes VPLS transport construction and packet >>forwarding more complex, I can see potential backward compatibility >>issues with 2 PW solution. >> >>Regards, >>Lucy >> >>Regards, >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>In my mind, the VLAN approach means dual vlan method. >> >>The main concern for CW approach is hardware support. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree = uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown = unicast >>traffic, and some P2MP PWs for multicast traffic. It may double all of >>them. >> >>E-tree is an Ethernet service and there is already VLAN based solution >>in IEEE, can we just utilize it without complicating VPLS transport >>construction? This also makes interworking with Eth only network = easier. >> >>Cheers, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Monday, April 16, 2012 8:35 AM >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I believe the initial question was in regard to the CW method. Are = you >>saying that you no longer are interested in that method in preference = of >>the dual vlan method? >> >> >> >>Lucy yong wrote: >> >> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >> >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Henderickx, Wim (Wim) >>Sent: Thursday, April 12, 2012 2:03 AM >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>The vlan approach is superior as it also works for eth only networks, >>etc. On top some vendors indicate hw issues with the cw approach. As >>such we have dropped more or less the cw approach. >> >>Cheers, >>Wim >>_________________ >>sent from blackberry >> >>----- Original Message ----- >>From: Giles Heron [mailto:giles.heron@gmail.com] >>Sent: Thursday, April 12, 2012 08:22 AM >>To: Simon Delord ; Alexander Vainshtein >> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>; Andrew Sergeev >>; Idan Kaspit ; >>Mishael Wexler ; Rotem Cohen >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Sorry - the "anonymous presentation" was mine. I should possibly have >>put in a third column on the CW approach. And hopefully the minutes >>will be posted soon. >> >>We had various discussions, as Simon stated, and consensus seemed to = be >>forming around the two alternatives of two PWEs or two VLANs. I = believe >>three of the authors of the CW approach are also authors of the two = VLAN >>approach and one is also an author of the two PWE approach. So perhaps >>it's best to let those four individuals say which approach they prefer >>and why? >> >>Giles >> >>On 10/04/2012 00:45, "Simon Delord" wrote: >> >>> Hi Alexander, >>> >>> You are right, no discussion on the WG mailing list recently, but >>> there have been substantial discussions among the authors of various >>> solution drafts off the mailing list. As far as I know, no consensus >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>> think the CW approach has not been rejected by the WG yet, or the WG >>> has not yet decided on which one to adopt. >>> >>> Simon >>> >>> 2012/4/8 Alexander Vainshtein >>> >>>> Hi all, >>>> >>>> Unfortunately I have not been able to attend the Paris IETF. >>>> >>>> However, looking up the L2VPN proceedings, I've found a short >>>> anonymous presentation called "E-Tree Update" ( >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>> This presentation discusses the differences of the E-Tree = approaches >>>> based on dedicated VLANs (as in >>>> = http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>> ext=3D1) and multiple PWs between the PEs (as in >>>> = http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>> clude_te >>>> xt=3D1) >>>> and completely ignores the solution based on usage of the CW in the >>>> PWs connecting the PEs (as in >>>> = http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>> ext=3D1 >>>> ). >>>> >>>> >>>> >>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>> wonder whether the WG has taken a decision to reject the approach >>>> based on the CW usage? I do not remember any recent discussion of >>>> this topic on the WG mailing list. >>>> >>>> >>>> >>>> Regards, and lots of thanks in advance, >>>> >>>> Sasha >>>> >>>> >>>> >>>> >>>> >>>> This e-mail message is intended for the recipient only and contains >>>> information which is CONFIDENTIAL and which may be proprietary to = ECI >> >>>> Telecom. If you have received this transmission in error, please >>>> inform us by e-mail, phone or fax, and then delete the original and >>>> all copies thereof. >>>> >> >> >> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is = addressed. >>If you are not the intended recipient of this E-mail, you are hereby >>notified that any dissemination, distribution, copying, or action = taken >>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this >>E-mail in error, please notify the sender immediately and permanently >>delete the original and any copy of this E-mail and any printout. >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject = to >copyright belonging to Time Warner Cable. This E-mail is intended = solely >for the use of the individual or entity to which it is addressed. If = you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended solely = for the use of the individual or entity to which it is addressed. If you are = not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and = may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of = this E-mail and any printout. This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies thereof. ------=_NextPart_000_0006_01CD1EDA.3E7B6370 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Ran,

 <= /span>

I have listed = this case before, and it is reasonable.

 <= /span>

We may teardown = PW if VSI attributes change, such as Control Word, MTU Nego, and etc. Current = solutions also do like this. I gave one example, if all ACs are down, we SHOULD = teardown PWs. If Leaf-only is changed to Mixed, obviously its attribute changes. = We may teardown PW and re-setup.

 <= /span>

IMO, this seems = reasonable behavior.

 <= /span>

Sam

 <= /span>

From: Ran Chen [mailto:chen.ran@zte.com.cn]
Sent: Thursday, April 19, = 2012 3:21 PM
To: Alexander = Vainshtein
Cc: Daniel Cohn; Rogers, = Josh; l2vpn@ietf.org; l2vpn-bounces@ietf.org; = Lucy yong; Henderickx, Wim (Wim); Sam Cao
Subject: = =B4=F0=B8=B4: RE: The = status of the approaches to the E-Tree solution?

 


Hi Sasha,
Plese see inline, thanks

Alexand= er Vainshtein = <Alexander.Vainshtein@ecitele.com>
=B7=A2=BC=FE=C8=CB:  l2vpn-bounces@ietf.org

2012/04/19 13:31

=CA=D5=BC=FE=C8=CB

"Henderickx, = Wim (Wim)" <wim.henderickx@alcatel-lucent.com>, "Rogers, =        Josh" <josh.rogers@twcable.com>, Lucy = yong <lucy.yong@huawei.com>, Daniel        Cohn <DanielC@orckit.com>, Sam Cao = <yuqun.cao@gmail.com>

=B3=AD=CB=CD

"l2vpn@ietf.org" <l2vpn@ietf.org>

=D6=F7=CC=E2

RE: The status of = the approaches to the E-Tree solution?

 

 

 




Wim,
Lots of thanks for a prompt = response.

I think that operational aspects of the = VLAN approach (e.g., how is the Global VID selected and distributed) should be examined in = more detail.
[Ran] Agree, and there have already been = such draft that describe "how is the Gloabal VID selected and distributed" in = L2VPN WG, the link = is:http://tools.ietf.org/html/draft-chen-l2vpn-vpls-etree-vlan-01.

At the same time it seems that the double = PW approach carries with it too many operational problems.
E.g., no PWs are set up between Leaf-only = PEs, but once one of these becomes a Mix PE, all the Leaf-only PEs must now recognize it as a = valid peer. And if a Mix PE reverts to a Leaf only one, all its Leaf-only = peers must drop it and shut down the relevant PWs...

My 2c,
    Sasha

________________________________________<= br> From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com]
Sent: Thursday, April 19, 2012 7:21 = AM
To: Alexander Vainshtein; Rogers, Josh; = Lucy yong; Daniel Cohn; Sam Cao
Cc: l2vpn@ietf.org
Subject: RE: The status of the approaches = to the E-Tree solution?

Sasha, the VLAN approach allows for a = similar operation as the CW does. It is orthogonal to the underlying PW deployment of = VPLS.

-----Original Message-----
From: l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: donderdag 19 april 2012 = 6:39
To: Rogers, Josh; Lucy yong; Daniel Cohn; = Sam Cao
Cc: l2vpn@ietf.org
Subject: RE: The status of the approaches = to the E-Tree solution?

Hi all,
I fully understand that that what I am = going to say is not very popular, but:

IMO one of the advantages of the CW-based = solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery = of BUN traffic.

Another advantage is preservation of full = mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes = in the PE configuration.

In particular, adding a Leaf AC to a PE = that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf = or last Root AC from a PE that previously has been supporting a mix etc. affect = only the PE where this operation happens and not the rest of the = PEs.

As for the need for HW changes that have = been mentioned as a main disadvantage of the CW-based approach - I believe it strongly = depends on specific implementations. And some changes in the forwarding process are required in any solution.

My 2c,
    Sasha



________________________________________<= br> From: l2vpn-bounces@ietf.org = [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com]
Sent: Wednesday, April 18, 2012 9:57 = PM
To: Lucy yong; Daniel Cohn; Sam = Cao
Cc: l2vpn@ietf.org
Subject: Re: The status of the approaches = to the E-Tree solution?

Again, the P2MP situation throws me. =  Is this something that is used
commonly?

I'm under the impression that adding P2MP = to any model results in a more
complex model.  Wether outside s-tag = is used to differentiate, or
dedicated pw's are used for the same = purpose, it seems both become more
complex.

Gile's comparison slide still concisely = captures the differences between
these methods, in my opinion.  I = haven't seen any new ideas or thoughts
brought to the group in the past week or = two on the subject.  I would hate
for both proposed methods to die on the = vine because we couldn't decide
between two methods that have nothing = inherently wrong with either.

-Josh


On 4/18/12 1:53 PM, "Lucy yong" <lucy.yong@huawei.com> wrote:

>Send this again.
>
>Two PW approach can be complex too if = the VPLS instance for E-Tree uses
>P2P PW for unicast traffic and P2MP PW = for broadcast and unknown
>unicast traffic, and some P2MP PWs for = multicast traffic. It may double
>all of them.
>
>Lucy
>
>-----Original = Message-----
>From: Daniel Cohn = [mailto:DanielC@orckit.com]
>Sent: Wednesday, April 18, 2012 1:42 = PM
>To: Lucy yong; Rogers, Josh; Sam = Cao
>Cc: l2vpn@ietf.org
>Subject: RE: The status of the = approaches to the E-Tree solution?
>
>I think the first option its the = natural way to go. How is the processing
>in this case more = complex?
>
>Thumb typed - please be = tolerant
>
>Lucy yong <lucy.yong@huawei.com> = wrote:
>
>
>
>Snipped..
>
>Multi-PW - On ingress PE, frame is = placed onto either a Leaf-only P2MP PW
>(for traffic coming from a leaf AC), = or onto a Root/Leaf P2MP PW (for
>traffic coming from a root = AC)
>[[LY]] Not that simple. You construct = either two P2MP PWs to all other
>PEs and let egress PE performing = filtering, or construct one P2MP PW to
>leaf-only PEs and two P2MP PWs to root = and leaf PEs and let ingress PE
>perform forwarding and filtering. Both = make node process complex.
>
>[[LY]] VPLS is built with the = mechanism utilizing P2P and P2MP PW for
>delivering the frames to remote PEs. = We should utilize them with the
>minimized changes. Dual VLAN solution = is simpler than Dual PW.
>
>Regards,
>Lucy
>
>
>I see how 2VLAN is simpler when P2MP = PW's are involved, I think.  I
>haven't had any first hand experience = with P2MP PW's, however, so don't
>feel terribly strong about this = objection.  Is this a real problem for
>others (now or in the future), or is = this objection in the weeds?
>
>I'm not sure the 'additional = complexity' is notable, or even relevant.  I
>encourage others to speak up if they = disagree, as P2MP PW is only
>conceptual to me, and I am unfamiliar = with real-life use cases for it.
>
>Thanks,
>Josh
>
>
>
>On 4/18/12 10:30 AM, "Lucy = yong" <lucy.yong@huawei.com> wrote:
>
>>Please see inline.
>>
>>-----Original = Message-----
>>From: Sam Cao = [mailto:yuqun.cao@gmail.com]
>>Sent: Tuesday, April 17, 2012 7:14 = AM
>>To: 'Daniel Cohn'; Lucy yong; = 'Rogers, Josh'; 'Henderickx, Wim (Wim)';
>>giles.heron@gmail.com; = simon.delord@gmail.com;
>>Alexander.Vainshtein@ecitele.com<= br> >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com;
>>Andrew.Sergeev@ecitele.com; = Idan.Kaspit@ecitele.com;
>>Mishael.Wexler@ecitele.com; = Rotem.Cohen@ecitele.com
>>Subject: RE: The status of the = approaches to the E-Tree solution?
>>
>>Yes, 2 pws are only needed between = pes with both root and leaf acs after
>>improving Dual-PW approach. If = consider P2MP, Dual-PW approach setup 2
>>P2MP
>>PWs if need. There is no = difference between P2MP or normal PW setup. But,
>>can Leaf-ACs be bound to = Root PE of P2MP PW?
>>
>>[[LY]] No, it makes complex in = setting up P2MP PW. Should a PE with both
>>root and leaf ACs set up two or = one P2MP PW to other PEs (some PE have
>>both root and leaf AC and some = only have leaf ACs)?
>>Regards,
>>Lucy
>>
>>Regards,
>>
>>Yuqun (Sam) Cao
>>E-mail: = Yuqun.cao@gmail.com
>>
>>
>>-----Original = Message-----
>>From: Daniel Cohn = [mailto:DanielC@orckit.com]
>>Sent: Tuesday, April 17, 2012 4:56 = PM
>>To: Lucy yong; Rogers, Josh; = Henderickx, Wim (Wim);
>>giles.heron@gmail.com;
>>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao
>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com;
>>Andrew.Sergeev@ecitele.com; = Idan.Kaspit@ecitele.com;
>>Mishael.Wexler@ecitele.com; = Rotem.Cohen@ecitele.com
>>Subject: RE: The status of the = approaches to the E-Tree solution?
>>
>>Adding Sam (as l2vpn@ is holding = messages)
>>
>>DC
>>
>>-----Original = Message-----
>>From: Lucy yong = [mailto:lucy.yong@huawei.com]
>>Sent: Tuesday, April 17, 2012 = 12:39 AM
>>To: Daniel Cohn; Rogers, Josh; = Henderickx, Wim (Wim);
>>giles.heron@gmail.com; = simon.delord@gmail.com;
>>Alexander.Vainshtein@ecitele.com<= br> >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com;
>>Andrew.Sergeev@ecitele.com; = Idan.Kaspit@ecitele.com;
>>Mishael.Wexler@ecitele.com; = Rotem.Cohen@ecitele.com
>>Subject: RE: The status of the = approaches to the E-Tree solution?
>>
>>
>>Snipped,
>>
>>As we discussed extensively in the = list, and as reflected in giles
>>slide, 2 pws are only needed = between pes with both root and leaf acs,
>>which will typically be a small = minority.
>>[[LY]] Don't know if the = assumption is true. Even it is the case, both
>>approaches can benefit from it. I = was off for a while and captures some
>>discussions now.
>>
>>Also as per giles slide, dual vlan = can have scalability issues due to
>>additional lookup and double use = of vlans in internal emulated lan
>>interface. Also there are = potential backward compatibility issues with
>>silicon that doesn't support vlan = mapping.
>>[[LY]] I was not in IETF83 meeting = and wait on the meeting minutes. I am
>>not clear on all the issues. Could = you be more specific? As I mentioned
>>in below, two PW approach makes = VPLS transport construction and packet
>>forwarding more complex, I can see = potential backward compatibility
>>issues with 2 PW = solution.
>>
>>Regards,
>>Lucy
>>
>>Regards,
>>
>>Daniel
>>
>>Thumb typed - please be = tolerant
>>
>>Lucy yong = <lucy.yong@huawei.com> wrote:
>>
>>In my mind, the VLAN approach = means dual vlan method.
>>
>>The main concern for CW approach = is hardware support.
>>
>>Two PW approach can be complex too = if the VPLS instance for E-Tree uses
>>P2P PW for unicast traffic and = P2MP PW for broadcast and unknown unicast
>>traffic, and some P2MP PWs for = multicast traffic. It may double all of
>>them.
>>
>>E-tree is an Ethernet service and = there is already VLAN based solution
>>in IEEE, can we just utilize it = without complicating VPLS transport
>>construction? This also makes = interworking with Eth only network easier.
>>
>>Cheers,
>>Lucy
>>
>>-----Original = Message-----
>>From: Rogers, Josh = [mailto:josh.rogers@twcable.com]
>>Sent: Monday, April 16, 2012 8:35 = AM
>>To: Lucy yong; Henderickx, Wim = (Wim); 'giles.heron@gmail.com';
>>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com'
>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com';
>>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com';
>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com'
>>Subject: RE: The status of the = approaches to the E-Tree solution?
>>
>>I believe the initial question was = in regard to the CW method.  Are you
>>saying that you no longer are = interested in that method in preference of
>>the dual vlan = method?
>>
>>
>>
>>Lucy yong = <lucy.yong@huawei.com> wrote:
>>
>>
>>Agree with Wim. VLAN approach is = the best solution for E-Tree.
>>
>>Lucy
>>
>>-----Original = Message-----
>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf
>>Of Henderickx, Wim = (Wim)
>>Sent: Thursday, April 12, 2012 = 2:03 AM
>>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com';
>>'Alexander.Vainshtein@ecitele.com'
>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com';
>>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com';
>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com'
>>Subject: Re: The status of the = approaches to the E-Tree solution?
>>
>>The vlan approach is superior as = it also works for eth only networks,
>>etc. On top some vendors indicate = hw issues with the cw approach. As
>>such we have dropped more or less = the cw approach.
>>
>>Cheers,
>>Wim
>>_________________
>>sent from = blackberry
>>
>>----- Original Message = -----
>>From: Giles Heron = [mailto:giles.heron@gmail.com]
>>Sent: Thursday, April 12, 2012 = 08:22 AM
>>To: Simon Delord = <simon.delord@gmail.com>; Alexander Vainshtein
>><Alexander.Vainshtein@ecitele.com>
>>Cc: l2vpn@ietf.org <l2vpn@ietf.org>; = Vladimir Kleiner
>><Vladimir.Kleiner@ecitele.com>; Andrew = Sergeev
>><Andrew.Sergeev@ecitele.com>; Idan = Kaspit <Idan.Kaspit@ecitele.com>;
>>Mishael Wexler = <Mishael.Wexler@ecitele.com>; Rotem Cohen
>><Rotem.Cohen@ecitele.com> >>Subject: Re: The status of the = approaches to the E-Tree solution?
>>
>>Sorry - the "anonymous = presentation" was mine.  I should possibly have
>>put in a third column on the CW = approach.  And hopefully the minutes
>>will be posted = soon.
>>
>>We had various discussions, as = Simon stated, and consensus seemed to be
>>forming around the two = alternatives of two PWEs or two VLANs.  I believe
>>three of the authors of the CW = approach are also authors of the two VLAN
>>approach and one is also an author = of the two PWE approach. So perhaps
>>it's best to let those four = individuals say which approach they prefer
>>and why?
>>
>>Giles
>>
>>On 10/04/2012 00:45, "Simon = Delord" <simon.delord@gmail.com> wrote:
>>
>>> Hi Alexander,
>>>
>>> You are right, no discussion = on the WG mailing list recently, but
>>> there have been substantial = discussions among the authors of various
>>> solution drafts off the = mailing list. As far as I know, no consensus
>>> yet before ietf83, not sure = the progress in the Paris WG meeting. I
>>> think the CW approach has not = been rejected by the WG yet, or the WG
>>> has not yet decided on which = one to adopt.
>>>
>>> Simon
>>>
>>> 2012/4/8 Alexander Vainshtein = <Alexander.Vainshtein@ecitele.com>
>>>
>>>>  Hi = all,
>>>>
>>>> Unfortunately I have not = been able to attend the Paris IETF.
>>>>
>>>> However, looking up the = L2VPN proceedings, I've found a short
>>>> anonymous presentation = called "E-Tree Update"  (
>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx).=
>>>> This presentation = discusses the differences of the E-Tree approaches
>>>> based on dedicated VLANs = (as in
>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t
>>>> ext=3D1) and multiple PWs = between the PEs (as in
>>>> = http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in
>>>> clude_te
>>>> xt=3D1)
>>>> and completely ignores = the solution based on usage of the CW in the
>>>> PWs connecting the PEs = (as in
>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t
>>>> ext=3D1
>>>> ).
>>>>
>>>>
>>>>
>>>> The Minutes of the Paris = L2VPN session are not yet available, but I
>>>> wonder whether the WG has = taken a decision to reject the approach
>>>> based on the CW usage? I = do not remember any recent discussion of
>>>> this topic on the WG = mailing list.
>>>>
>>>>
>>>>
>>>> Regards, and lots of = thanks in advance,
>>>>
>>>> Sasha
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> This e-mail message is = intended for the recipient only and contains
>>>> information which is = CONFIDENTIAL and which may be proprietary to ECI
>>
>>>> Telecom. If you have = received this transmission in error, please
>>>> inform us by e-mail, = phone or fax, and then delete the original and
>>>> all copies = thereof.
>>>>
>>
>>
>>
>>
>>
>>This E-mail and any of its = attachments may contain Time Warner Cable
>>proprietary information, which is = privileged, confidential, or subject
>>to copyright belonging to Time = Warner Cable. This E-mail is intended
>>solely for the use of the = individual or entity to which it is addressed.
>>If you are not the intended = recipient of this E-mail, you are hereby
>>notified that any dissemination, = distribution, copying, or action taken
>>in relation to the contents of and = attachments to this E-mail is
>>strictly prohibited and may be = unlawful. If you have received this
>>E-mail in error, please notify the = sender immediately and permanently
>>delete the original and any copy = of this E-mail and any printout.
>>
>
>
>This E-mail and any of its attachments = may contain Time Warner Cable
>proprietary information, which is = privileged, confidential, or subject to
>copyright belonging to Time Warner = Cable. This E-mail is intended solely
>for the use of the individual or = entity to which it is addressed. If you
>are not the intended recipient of this = E-mail, you are hereby notified
>that any dissemination, distribution, = copying, or action taken in
>relation to the contents of and = attachments to this E-mail is strictly
>prohibited and may be unlawful. If you = have received this E-mail in
>error, please notify the sender = immediately and permanently delete the
>original and any copy of this E-mail = and any printout.


This E-mail and any of its attachments may = contain Time Warner Cable proprietary information, which is privileged, confidential, = or subject to copyright belonging to Time Warner Cable. This E-mail is = intended solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby notified = that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and = may be unlawful. If you have received this E-mail in error, please notify the = sender immediately and permanently delete the original and any copy of this = E-mail and any printout.
This e-mail message is intended for the = recipient only and contains information which is CONFIDENTIAL and which may be proprietary = to ECI Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies = thereof.
This e-mail message is intended for the = recipient only and contains information which is CONFIDENTIAL and which may be proprietary = to ECI Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies = thereof.


------=_NextPart_000_0006_01CD1EDA.3E7B6370-- From yuqun.cao@gmail.com Thu Apr 19 18:49:44 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3726921F8655 for ; Thu, 19 Apr 2012 18:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.764 X-Spam-Level: X-Spam-Status: No, score=-1.764 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, J_BACKHAIR_34=1, J_BACKHAIR_43=1, 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 QSwxESbt3aHl for ; Thu, 19 Apr 2012 18:49:42 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B9C3D21F8650 for ; Thu, 19 Apr 2012 18:49:42 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so464441pbb.31 for ; Thu, 19 Apr 2012 18:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:x-mimeole :in-reply-to:thread-index; bh=mffvmNw2XknV7ALiWdDRbeb3MHGVq8JGIDpHxZrXR00=; b=IEkNFMQNmMnDCh3aj4a1rpsNh5NAGsJBHAv+y9HMIZXxFW3DFz5iVZyrYeCey5mzBy aDc98v7dEycRi8Iyw+CRki1Cp4KZOaRVfJ76OgcJZv2+dAhMU0b2QpWBBb29G06ft9N7 A1CsshtWc+FA/8JCTP/pKAzdbZRBjzKmexX+0pNUVTmsRepSLmLvEobVRLrBXjYTq/vN kxQ+tBN7dwHj4gR1MVA9kBYSs5h/lA6ZUfdfePbmKOsp+CJQmIe/5FUEXbHosW6Ouzq5 psixpuQhKsxDtNg093LzPHt86AT6UhxZniRAXsZiwDXQL7fQZcRIQe91T3JwktqzPnLo lbAA== Received: by 10.68.238.134 with SMTP id vk6mr1437478pbc.138.1334886582237; Thu, 19 Apr 2012 18:49:42 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id d2sm3818142pbw.39.2012.04.19.18.49.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Apr 2012 18:49:41 -0700 (PDT) From: "Sam Cao" To: "'DelRegno, Christopher N \(Nick\)'" , "'Daniel Cohn'" , "'Henderickx, Wim \(Wim\)'" , "'Alexander Vainshtein'" , "'Rogers, Josh'" , "'Lucy yong'" References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, , <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><44F4E579A764584EA9BDFD07D0CA08130777C1D5@tlvmail1><14C7F4F06DB5814AB0DE29716C4F6D670129623CD2@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130777C22F@tlvmail1> Subject: RE: The status of the approaches to the E-Tree solution? Date: Fri, 20 Apr 2012 09:49:38 +0800 Message-ID: <9A0C659623124942940B88AB181DDFC8@R01842> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdiov///PycP//4qvA//+OPpD//ux5AP/8/CyA Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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, 20 Apr 2012 01:49:44 -0000 Hi, Nick, Agreed. If mixed-PE may join E-Tree, Multi-PW or Dual-VLAN is valuable approach for carriers. Sam -----Original Message----- From: DelRegno, Christopher N (Nick) [mailto:nick.delregno@verizon.com] Sent: Thursday, April 19, 2012 8:40 PM To: Daniel Cohn; Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, Josh; Lucy yong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Dan: As the transformation of a PE from Root<-->Mix and Mix<-->Leaf will be driven by our customers, we can't say how often this will or won't occur. It must be accommodated regardless of perceived rarity. If I use one of our current extremely popular L2VPN services as an example, our customers tend to move their ENNI (e.g. Root) locations constantly, quite frequently to switches which heretofore only contained UNIs (e.g. leaves). Nick -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: Thursday, April 19, 2012 4:49 AM To: Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, Josh; Lucy yong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Wim, That seems to me a non-negligible change to bridge forwarding logic, I think setting up/tearing down the PE is cleaner. I don't expect that leaf-only to root/leaf PE transformations will happen all that often. But I think it's important to clarify that the issue is common to both drafts. DC -----Original Message----- From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Thursday, April 19, 2012 9:34 AM To: Daniel Cohn; Alexander Vainshtein; Rogers, Josh; Lucy yong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Daniel, we should discuss this as this is not absolutely required to tear down PW. You can also have an indication in the E-TREE fwd to indicate that the endpoint has no leaf and as such avoid sending traffic down but allow the PW to be setup. As such we have some flexibility such that operators can select the proper approach they would like to have/implement. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: donderdag 19 april 2012 8:16 To: Alexander Vainshtein; Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Sasha and all, You have exactly the same "problem" in the 2-VLAN approach - quoting from the draft: 6. LDP Extensions for E-Tree Support P is a Leaf-only bit, it is set to 1 to indicate that the PE is attached with only leaves, and set to 0 otherwise. If the P bit is set, then: { If the PE is a leaf-only node itself, then a label release message with the error code "Leaf to Leaf PW error" is sent to the peer PE and exit the process; So all that you wrote about a leaf-only PE becoming mixed and viceversa applies to both solutions. Regards, Daniel -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Thursday, April 19, 2012 8:31 AM To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Wim, Lots of thanks for a prompt response. I think that operational aspects of the VLAN approach (e.g., how is the Global VID selected and distributed) should be examined in more detail. At the same time it seems that the double PW approach carries with it too many operational problems. E.g., no PWs are set up between Leaf-only PEs, but once one of these becomes a Mix PE, all the Leaf-only PEs must now recognize it as a valid peer. And if a Mix PE reverts to a Leaf only one, all its Leaf-only peers must drop it and shut down the relevant PWs... My 2c, Sasha ________________________________________ From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] Sent: Thursday, April 19, 2012 7:21 AM To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Sasha, the VLAN approach allows for a similar operation as the CW does. It is orthogonal to the underlying PW deployment of VPLS. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: donderdag 19 april 2012 6:39 To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi all, I fully understand that that what I am going to say is not very popular, but: IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes in the PE configuration. In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root AC from a PE that previously has been supporting a mix etc. affect only the PE where this operation happens and not the rest of the PEs. As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] Sent: Wednesday, April 18, 2012 9:57 PM To: Lucy yong; Daniel Cohn; Sam Cao Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Again, the P2MP situation throws me. Is this something that is used commonly? I'm under the impression that adding P2MP to any model results in a more complex model. Wether outside s-tag is used to differentiate, or dedicated pw's are used for the same purpose, it seems both become more complex. Gile's comparison slide still concisely captures the differences between these methods, in my opinion. I haven't seen any new ideas or thoughts brought to the group in the past week or two on the subject. I would hate for both proposed methods to die on the vine because we couldn't decide between two methods that have nothing inherently wrong with either. -Josh On 4/18/12 1:53 PM, "Lucy yong" wrote: >Send this again. > >Two PW approach can be complex too if the VPLS instance for E-Tree uses >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >unicast traffic, and some P2MP PWs for multicast traffic. It may double >all of them. > >Lucy > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, April 18, 2012 1:42 PM >To: Lucy yong; Rogers, Josh; Sam Cao >Cc: l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >I think the first option its the natural way to go. How is the processing >in this case more complex? > >Thumb typed - please be tolerant > >Lucy yong wrote: > > > >Snipped.. > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >traffic coming from a root AC) [[LY]] Not that simple. You construct >either two P2MP PWs to all other PEs and let egress PE performing >filtering, or construct one P2MP PW to leaf-only PEs and two P2MP PWs >to root and leaf PEs and let ingress PE perform forwarding and >filtering. Both make node process complex. > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >delivering the frames to remote PEs. We should utilize them with the >minimized changes. Dual VLAN solution is simpler than Dual PW. > >Regards, >Lucy > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >haven't had any first hand experience with P2MP PW's, however, so don't >feel terribly strong about this objection. Is this a real problem for >others (now or in the future), or is this objection in the weeds? > >I'm not sure the 'additional complexity' is notable, or even relevant. I >encourage others to speak up if they disagree, as P2MP PW is only >conceptual to me, and I am unfamiliar with real-life use cases for it. > >Thanks, >Josh > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > >>Please see inline. >> >>-----Original Message----- >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>Sent: Tuesday, April 17, 2012 7:14 AM >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Yes, 2 pws are only needed between pes with both root and leaf acs after >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>P2MP PWs if need. There is no difference between P2MP or normal PW >>setup. But, >>can Leaf-ACs be bound to Root PE of P2MP PW? >> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>both root and leaf AC and some only have leaf ACs)? >>Regards, >>Lucy >> >>Regards, >> >>Yuqun (Sam) Cao >>E-mail: Yuqun.cao@gmail.com >> >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Tuesday, April 17, 2012 4:56 PM >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com; Sam Cao >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Adding Sam (as l2vpn@ is holding messages) >> >>DC >> >>-----Original Message----- >>From: Lucy yong [mailto:lucy.yong@huawei.com] >>Sent: Tuesday, April 17, 2012 12:39 AM >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>giles.heron@gmail.com; simon.delord@gmail.com; >>Alexander.Vainshtein@ecitele.com >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >> >>Snipped, >> >>As we discussed extensively in the list, and as reflected in giles >>slide, 2 pws are only needed between pes with both root and leaf acs, >>which will typically be a small minority. >>[[LY]] Don't know if the assumption is true. Even it is the case, both >>approaches can benefit from it. I was off for a while and captures some >>discussions now. >> >>Also as per giles slide, dual vlan can have scalability issues due to >>additional lookup and double use of vlans in internal emulated lan >>interface. Also there are potential backward compatibility issues with >>silicon that doesn't support vlan mapping. >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>not clear on all the issues. Could you be more specific? As I mentioned >>in below, two PW approach makes VPLS transport construction and packet >>forwarding more complex, I can see potential backward compatibility >>issues with 2 PW solution. >> >>Regards, >>Lucy >> >>Regards, >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>In my mind, the VLAN approach means dual vlan method. >> >>The main concern for CW approach is hardware support. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>traffic, and some P2MP PWs for multicast traffic. It may double all of >>them. >> >>E-tree is an Ethernet service and there is already VLAN based solution >>in IEEE, can we just utilize it without complicating VPLS transport >>construction? This also makes interworking with Eth only network easier. >> >>Cheers, >>Lucy >> >>-----Original Message----- >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>Sent: Monday, April 16, 2012 8:35 AM >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I believe the initial question was in regard to the CW method. Are you >>saying that you no longer are interested in that method in preference of >>the dual vlan method? >> >> >> >>Lucy yong wrote: >> >> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >> >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Henderickx, Wim (Wim) >>Sent: Thursday, April 12, 2012 2:03 AM >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>'Alexander.Vainshtein@ecitele.com' >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>The vlan approach is superior as it also works for eth only networks, >>etc. On top some vendors indicate hw issues with the cw approach. As >>such we have dropped more or less the cw approach. >> >>Cheers, >>Wim >>_________________ >>sent from blackberry >> >>----- Original Message ----- >>From: Giles Heron [mailto:giles.heron@gmail.com] >>Sent: Thursday, April 12, 2012 08:22 AM >>To: Simon Delord ; Alexander Vainshtein >> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>; Andrew Sergeev >>; Idan Kaspit ; >>Mishael Wexler ; Rotem Cohen >> >>Subject: Re: The status of the approaches to the E-Tree solution? >> >>Sorry - the "anonymous presentation" was mine. I should possibly have >>put in a third column on the CW approach. And hopefully the minutes >>will be posted soon. >> >>We had various discussions, as Simon stated, and consensus seemed to be >>forming around the two alternatives of two PWEs or two VLANs. I believe >>three of the authors of the CW approach are also authors of the two VLAN >>approach and one is also an author of the two PWE approach. So perhaps >>it's best to let those four individuals say which approach they prefer >>and why? >> >>Giles >> >>On 10/04/2012 00:45, "Simon Delord" wrote: >> >>> Hi Alexander, >>> >>> You are right, no discussion on the WG mailing list recently, but >>> there have been substantial discussions among the authors of various >>> solution drafts off the mailing list. As far as I know, no consensus >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>> think the CW approach has not been rejected by the WG yet, or the WG >>> has not yet decided on which one to adopt. >>> >>> Simon >>> >>> 2012/4/8 Alexander Vainshtein >>> >>>> Hi all, >>>> >>>> Unfortunately I have not been able to attend the Paris IETF. >>>> >>>> However, looking up the L2VPN proceedings, I've found a short >>>> anonymous presentation called "E-Tree Update" ( >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>> This presentation discusses the differences of the E-Tree approaches >>>> based on dedicated VLANs (as in >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>> ext=1) and multiple PWs between the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>> clude_te >>>> xt=1) >>>> and completely ignores the solution based on usage of the CW in the >>>> PWs connecting the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>> ext=1 >>>> ). >>>> >>>> >>>> >>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>> wonder whether the WG has taken a decision to reject the approach >>>> based on the CW usage? I do not remember any recent discussion of >>>> this topic on the WG mailing list. >>>> >>>> >>>> >>>> Regards, and lots of thanks in advance, >>>> >>>> Sasha >>>> >>>> >>>> >>>> >>>> >>>> This e-mail message is intended for the recipient only and contains >>>> information which is CONFIDENTIAL and which may be proprietary to ECI >> >>>> Telecom. If you have received this transmission in error, please >>>> inform us by e-mail, phone or fax, and then delete the original and >>>> all copies thereof. >>>> >> >> >> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is addressed. >>If you are not the intended recipient of this E-mail, you are hereby >>notified that any dissemination, distribution, copying, or action taken >>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this >>E-mail in error, please notify the sender immediately and permanently >>delete the original and any copy of this E-mail and any printout. >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. From stbryant@cisco.com Fri Apr 20 07:37:54 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6649321F872A; Fri, 20 Apr 2012 07:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.545 X-Spam-Level: X-Spam-Status: No, score=-110.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 rY668gvHRjkc; Fri, 20 Apr 2012 07:37:53 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id DDE5221F8726; Fri, 20 Apr 2012 07:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=20655; q=dns/txt; s=iport; t=1334932671; x=1336142271; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=9hNTZLptSWKvspEXM77p5FlJPKmqpLIdYx5VyYg9zvo=; b=eC8j1icYT7RmCJcxuryuAXxv9grtJH5SBF3dm1iKeL0u01COWSmBE431 CklHjfNmIkU+ZVJcoVluEeb3nQRGcOamB3L4sOlC1eRQwPLt7S2bvO3Q5 /Oke7gZeB39BdXDAYIB8m2d+6nv/vddq2h7/hl6MMz+rdKKAicINE6+k2 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADZ0kU+Q/khM/2dsb2JhbABEsTiBB4IJAQEBAwESAQJjBgcEHAMBAgoWDwkDAgECAQ8sAggGAQwGAgEBHodfAwYFC5psgz8QkwUNEIk/BIQWhV+GcgSVeYs8gxiBAmeCaA X-IronPort-AV: E=Sophos;i="4.75,453,1330905600"; d="scan'208,217";a="135783399" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 20 Apr 2012 14:37:28 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3KEbSek009306; Fri, 20 Apr 2012 14:37:28 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q3KEbNul000108; Fri, 20 Apr 2012 15:37:23 +0100 (BST) Message-ID: <4F9174A3.6000102@cisco.com> Date: Fri, 20 Apr 2012 15:37:23 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "l2vpn@ietf.org" , "l2vpn-chairs@tools.ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Fwd: IPR Statements concerning etree References: <51AC216A-75C8-4075-AA23-D80081CB61CA@vigilsec.com> In-Reply-To: <51AC216A-75C8-4075-AA23-D80081CB61CA@vigilsec.com> X-Forwarded-Message-Id: <51AC216A-75C8-4075-AA23-D80081CB61CA@vigilsec.com> Content-Type: multipart/alternative; boundary="------------000202030501020805090605" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 14:37:54 -0000 This is a multi-part message in MIME format. --------------000202030501020805090605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit WGs, You may wish to look at the following IPR statements that were received yesterday. They all relate to etree. The stated terms appear to require payment of a royalty. Stewart -------- Original Message -------- Subject: IPR Statements Date: Thu, 19 Apr 2012 13:04:27 -0400 From: Russ Housley To: Stewart Bryant Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:14:30 PM EDT > To: simon.delord@gmail.com, raymond.key@ieee.org, wim.henderickx@alcatel-lucent.com, lucy.yong@huawei.com, lizhong.jin@zte.com.cn, frederic.jounay@orange.ch > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-delord-pwe3-cw-bit-etree-07 > > > Dear Simon DeLord, Raymond Key, Wim Henderickx, Lucy Yong, Lizhong Jin, Frederic JOUNAY: > > An IPR disclosure that pertains to your Internet-Draft entitled "Control Word > Reserved bit for use in E-Tree" (draft-delord-pwe3-cw-bit-etree) was submitted > to the IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of > Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1760/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related to draft-delord-pwe3-cw-bit-etree-07.""); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:15:08 PM EDT > To: yuqun.cao@gmail.com > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-cao-l2vpn-vpls-etree-02 > > > Dear Yuqun Cao: > > An IPR disclosure that pertains to your Internet-Draft entitled "Extension to > VPLS for E-Tree" (draft-cao-l2vpn-vpls-etree) was submitted to the IETF > Secretariat on 2012-04-19 and has been posted on the "IETF Page of Intellectual > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1759/). The title > of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related to > draft-cao-l2vpn-vpls-etree-02."); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:15:34 PM EDT > To: chen.ran@zte.com.cn > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-chen-l2vpn-vpls-etree-vlan-01 > > > Dear Ran Chen: > > An IPR disclosure that pertains to your Internet-Draft entitled "Automatic VLAN > allocation in E-tree" (draft-chen-l2vpn-vpls-etree-vlan) was submitted to the > IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of > Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1758/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related to draft-chen-l2vpn-vpls-etree-vlan-01."); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:16:29 PM EDT > To: jiangyuanlong@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.de, frederic.jounay@orange.ch, florin.balus@alcatel-lucent.com, wim.henderickx@alcatel-lucent.com, sajassi@cisco.com > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-jiang-l2vpn-etree-bgp-00 > > > Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Balus, Wim Henderickx, Ali Sajassi: > > An IPR disclosure that pertains to your Internet-Draft entitled "E-Tree Support > in VPLS with BGP Signaling" (draft-jiang-l2vpn-etree-bgp) was submitted to the > IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of > Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1757/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related to draft-jiang-l2vpn-etree-bgp-00."); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:17:02 PM EDT > To: yljiang@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.de, frederic.jounay@orange-ftgroup.com, florin.balus@alcatel-lucent.com, wim.henderickx@alcatel-lucent.com > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-jiang-l2vpn-vpls-pe-etree-05 > > > Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Balus, Wim Henderickx: > > An IPR disclosure that pertains to your Internet-Draft entitled "VPLS PE Model > for E-Tree Support" (draft-jiang-l2vpn-vpls-pe-etree) was submitted to the IETF > Secretariat on 2012-04-19 and has been posted on the "IETF Page of Intellectual > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1756/). The title > of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related to > draft-jiang-l2vpn-vpls-pe-etree-05.""); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:17:48 PM EDT > To: danielc@orckit.com, rafir@orckit.com, pagarwal@broadcom.com, raymond.key@team.telstra.com > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-ldp-vpls-etree-2pw-02 > > > Dear Daniel Cohn, Rafi Ram, Puneet Agarwal, Raymond Key: > > An IPR disclosure that pertains to your Internet-Draft entitled "Extension to > LDP-VPLS for E-Tree Using Two PW" (draft-ram-l2vpn-ldp-vpls-etree-2pw) was > submitted to the IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1755/). The title of the IPR disclosure is > "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-ldp-vpls- > etree-2pw-02.""); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:18:32 PM EDT > To: rafir@orckit.com, danielc@orckit.com, raymond.key@ieee.org, pagarwal@broadcom.com, josh.rogers@twcable.com > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-etree-multiple-pw-01 > > > Dear Rafi Ram, Daniel Cohn, Raymond Key, Puneet Agarwal, Joshua Rogers: > > An IPR disclosure that pertains to your Internet-Draft entitled "Extension to > VPLS for E-Tree Using Multiple PWs" (draft-ram-l2vpn-etree-multiple-pw) was > submitted to the IETF Secretariat on 2012-04-19 and has been posted on the "IETF > Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1754/). The title of the IPR disclosure is > "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-etree- > multiple-pw-01.""); > > The IETF Secretariat > --------------000202030501020805090605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
WGs,

You may wish to look at the following IPR statements that were
received yesterday.

They all relate to etree.

The stated terms appear to require payment of a royalty.

Stewart


-------- Original Message --------
Subject: IPR Statements
Date: Thu, 19 Apr 2012 13:04:27 -0400
From: Russ Housley <housley@vigilsec.com>
To: Stewart Bryant <stbryant@cisco.com> 


Begin forwarded message:

> From: IETF Secretariat <ietf-ipr@ietf.org>
> Date: April 19, 2012 12:14:30 PM EDT
> To: simon.delord@gmail.com, raymond.key@ieee.org, wim.henderickx@alcatel-lucent.com, lucy.yong@huawei.com, lizhong.jin@zte.com.cn, frederic.jounay@orange.ch
> Cc: housley@vigilsec.com, ipr-announce@ietf.org
> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-delord-pwe3-cw-bit-etree-07
> 
> 
> Dear Simon DeLord, Raymond Key, Wim Henderickx, Lucy Yong, Lizhong Jin, Frederic JOUNAY:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled "Control Word
> Reserved bit for use in E-Tree" (draft-delord-pwe3-cw-bit-etree) was submitted
> to the IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of
> Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1760/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related to draft-delord-pwe3-cw-bit-etree-07."");
> 
> The IETF Secretariat
> 
Begin forwarded message:

> From: IETF Secretariat <ietf-ipr@ietf.org>
> Date: April 19, 2012 12:15:08 PM EDT
> To: yuqun.cao@gmail.com
> Cc: housley@vigilsec.com, ipr-announce@ietf.org
> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-cao-l2vpn-vpls-etree-02
> 
> 
> Dear Yuqun Cao:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled "Extension to
> VPLS for E-Tree" (draft-cao-l2vpn-vpls-etree) was submitted to the IETF
> Secretariat on 2012-04-19 and has been posted on the "IETF Page of Intellectual
> Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1759/). The title
> of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related to
> draft-cao-l2vpn-vpls-etree-02.");
> 
> The IETF Secretariat
> 
Begin forwarded message:

> From: IETF Secretariat <ietf-ipr@ietf.org>
> Date: April 19, 2012 12:15:34 PM EDT
> To: chen.ran@zte.com.cn
> Cc: housley@vigilsec.com, ipr-announce@ietf.org
> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-chen-l2vpn-vpls-etree-vlan-01
> 
> 
> Dear Ran Chen:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled "Automatic VLAN
> allocation in E-tree" (draft-chen-l2vpn-vpls-etree-vlan) was submitted to the
> IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of
> Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1758/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related to draft-chen-l2vpn-vpls-etree-vlan-01.");
> 
> The IETF Secretariat
> 
Begin forwarded message:

> From: IETF Secretariat <ietf-ipr@ietf.org>
> Date: April 19, 2012 12:16:29 PM EDT
> To: jiangyuanlong@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.de, frederic.jounay@orange.ch, florin.balus@alcatel-lucent.com, wim.henderickx@alcatel-lucent.com, sajassi@cisco.com
> Cc: housley@vigilsec.com, ipr-announce@ietf.org
> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-jiang-l2vpn-etree-bgp-00
> 
> 
> Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Balus, Wim Henderickx, Ali Sajassi:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled "E-Tree Support
> in VPLS with BGP Signaling" (draft-jiang-l2vpn-etree-bgp) was submitted to the
> IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of
> Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1757/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related to draft-jiang-l2vpn-etree-bgp-00.");
> 
> The IETF Secretariat
> 
Begin forwarded message:

> From: IETF Secretariat <ietf-ipr@ietf.org>
> Date: April 19, 2012 12:17:02 PM EDT
> To: yljiang@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.de, frederic.jounay@orange-ftgroup.com, florin.balus@alcatel-lucent.com, wim.henderickx@alcatel-lucent.com
> Cc: housley@vigilsec.com, ipr-announce@ietf.org
> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-jiang-l2vpn-vpls-pe-etree-05
> 
> 
> Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Balus, Wim Henderickx:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled "VPLS PE Model
> for E-Tree Support" (draft-jiang-l2vpn-vpls-pe-etree) was submitted to the IETF
> Secretariat on 2012-04-19 and has been posted on the "IETF Page of Intellectual
> Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1756/). The title
> of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related to
> draft-jiang-l2vpn-vpls-pe-etree-05."");
> 
> The IETF Secretariat
> 
Begin forwarded message:

> From: IETF Secretariat <ietf-ipr@ietf.org>
> Date: April 19, 2012 12:17:48 PM EDT
> To: danielc@orckit.com, rafir@orckit.com, pagarwal@broadcom.com, raymond.key@team.telstra.com
> Cc: housley@vigilsec.com, ipr-announce@ietf.org
> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-ldp-vpls-etree-2pw-02
> 
> 
> Dear Daniel Cohn, Rafi Ram, Puneet Agarwal, Raymond Key:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled "Extension to
> LDP-VPLS for E-Tree Using Two PW" (draft-ram-l2vpn-ldp-vpls-etree-2pw) was
> submitted to the IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures"
> (https://datatracker.ietf.org/ipr/1755/). The title of the IPR disclosure is
> "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-ldp-vpls-
> etree-2pw-02."");
> 
> The IETF Secretariat
> 
Begin forwarded message:

> From: IETF Secretariat <ietf-ipr@ietf.org>
> Date: April 19, 2012 12:18:32 PM EDT
> To: rafir@orckit.com, danielc@orckit.com, raymond.key@ieee.org, pagarwal@broadcom.com, josh.rogers@twcable.com
> Cc: housley@vigilsec.com, ipr-announce@ietf.org
> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-etree-multiple-pw-01
> 
> 
> Dear Rafi Ram, Daniel Cohn, Raymond Key, Puneet Agarwal, Joshua Rogers:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled "Extension to
> VPLS for E-Tree Using Multiple PWs" (draft-ram-l2vpn-etree-multiple-pw) was
> submitted to the IETF Secretariat on 2012-04-19 and has been posted on the "IETF
> Page of Intellectual Property Rights Disclosures"
> (https://datatracker.ietf.org/ipr/1754/). The title of the IPR disclosure is
> "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-etree-
> multiple-pw-01."");
> 
> The IETF Secretariat
>
--------------000202030501020805090605-- From lizho.jin@gmail.com Fri Apr 20 09:37:45 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023BD21F85C5 for ; Fri, 20 Apr 2012 09:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZ6CIyPQnVX0 for ; Fri, 20 Apr 2012 09:37:42 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6971121F85C4 for ; Fri, 20 Apr 2012 09:37:42 -0700 (PDT) Received: by iazz13 with SMTP id z13so16611895iaz.31 for ; Fri, 20 Apr 2012 09:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=FrfeNCTZaVXnCPI0djHlQcy/Bvayz0f2cc+ZQ2awyno=; b=KDgyBEO7GevoYOJ43n9L6qwh9ehTwGbabBzt52oQs0gFsbXxUN1pLcyRxEtbIT6pJl 64XnrN51JLhTyUaLO5eSYeUSJ273Ho5H4t1STvScyACZfQOkeavcDW0lSTmfsMl74n7w OosM7Zez2mT1qUGBkbVC9og2XH4E50p/a/rTP5CNbCgbgnwIO1m5FmK3Awzuvrvg8zTe kDkhw+NOea8lcMvelbjXaabGcuZKVVa+pvDS++DRXA4mr3IJzYlFu6mi8LGwmjbY9DxC Nw0V6DbjaUee69UqtFukLIqJ9TTlzJETSkTdRaPHyJEI4mOcetyxZbV3K2+tWVyrPYax nAyg== MIME-Version: 1.0 Received: by 10.50.51.197 with SMTP id m5mr7029977igo.38.1334939861701; Fri, 20 Apr 2012 09:37:41 -0700 (PDT) Received: by 10.50.8.100 with HTTP; Fri, 20 Apr 2012 09:37:41 -0700 (PDT) Date: Sat, 21 Apr 2012 00:37:41 +0800 Message-ID: Subject: RE: The status of the approaches to the E-Tree solution? From: Lizhong Jin To: "l2vpn@ietf.org" , Alexander.Vainshtein@ecitele.com Content-Type: multipart/alternative; boundary=14dae934039f40d3bb04be1ee8aa Cc: yuqun.cao@gmail.com X-BeenThere: l2vpn@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, 20 Apr 2012 16:37:45 -0000 --14dae934039f40d3bb04be1ee8aa Content-Type: text/plain; charset=ISO-8859-1 Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW will carry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > To: "Rogers, Josh" , Lucy yong > , Daniel Cohn , Sam Cao > > Cc: "l2vpn@ietf.org" > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, but: > > IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes in the PE configuration. > > In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root AC from a PE that previously has been supporting a mix etc. affect only the PE where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a more > complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become more > complex. > > Gile's comparison slide still concisely captures the differences between > these methods, in my opinion. I haven't seen any new ideas or thoughts > brought to the group in the past week or two on the subject. I would hate > for both proposed methods to die on the vine because we couldn't decide > between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may double >>all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the processing >>in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >>traffic coming from a root AC) >>[[LY]] Not that simple. You construct either two P2MP PWs to all other >>PEs and let egress PE performing filtering, or construct one P2MP PW to >>leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >>perform forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so don't >>feel terribly strong about this objection. Is this a real problem for >>others (now or in the future), or is this objection in the weeds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. I >>encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>>giles.heron@gmail.com; simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs after >>>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>>P2MP >>>PWs if need. There is no difference between P2MP or normal PW setup. But, >>>can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>>both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong [mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, both >>>approaches can benefit from it. I was off for a while and captures some >>>discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues with >>>silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>>not clear on all the issues. Could you be more specific? As I mentioned >>>in below, two PW approach makes VPLS transport construction and packet >>>forwarding more complex, I can see potential backward compatibility >>>issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>>traffic, and some P2MP PWs for multicast traffic. It may double all of >>>them. >>> >>>E-tree is an Ethernet service and there is already VLAN based solution >>>in IEEE, can we just utilize it without complicating VPLS transport >>>construction? This also makes interworking with Eth only network easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are you >>>saying that you no longer are interested in that method in preference of >>>the dual vlan method? >>> >>> >>> >>>Lucy yong wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron [mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord ; Alexander Vainshtein >>> >>>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>>; Andrew Sergeev >>>; Idan Kaspit ; >>>Mishael Wexler ; Rotem Cohen >>> >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly have >>>put in a third column on the CW approach. And hopefully the minutes >>>will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to be >>>forming around the two alternatives of two PWEs or two VLANs. I believe >>>three of the authors of the CW approach are also authors of the two VLAN >>>approach and one is also an author of the two PWE approach. So perhaps >>>it's best to let those four individuals say which approach they prefer >>>and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of various >>>> solution drafts off the mailing list. As far as I know, no consensus >>>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>>> think the CW approach has not been rejected by the WG yet, or the WG >>>> has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree approaches >>>>> based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>>> ext=1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>>> clude_te >>>>> xt=1) >>>>> and completely ignores the solution based on usage of the CW in the >>>>> PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>>> ext=1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>>> wonder whether the WG has taken a decision to reject the approach >>>>> based on the CW usage? I do not remember any recent discussion of >>>>> this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and contains >>>>> information which is CONFIDENTIAL and which may be proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original and >>>>> all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action taken >>>in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use of the individual or entity to which it is addressed. If you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** --14dae934039f40d3bb04be1ee8aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all,
The difference between 2-VLAN and CW approach is who will provi= de the R/L information, customer payload or PW? The customer payload will b= e always modified to carry R/L information in 2-VLAN approach, while PW wit= h CW will carry R/L information for CW approach.
I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is access= ed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informati= on?

Thanks
Lizhong

> ------------------------------
>> Message: 2
> Date: Thu, 19 Apr 2012 04:38:36 +0000
> From= : Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
> To: "Rogers, Josh" <josh.rogers@twcable.com>, Lucy yong
> =A0 =A0 =A0 =A0<= ;lucy.yong@huawei.com>, Dani= el Cohn <DanielC@orckit.com>= ;, Sam Cao
> =A0 =A0 =A0 =A0<yuqun.cao@gm= ail.com>
> Cc: "l2vpn@i= etf.org" <l2vpn@ietf.org&= gt;
> Subject: RE: The status of the approaches to the E-Tree solutio= n?
> Message-ID:
> =A0 =A0 =A0 =A0<F9336571731ADE42A5397FC= 831CEAA02034192@FRIDWPPMB002.ecitele.com>
> Content-Type: text= /plain; charset=3D"us-ascii"
>
> Hi all,
> I fully understand that that what I am going t= o say is not very popular, but:
>
> IMO one of the advantages o= f the CW-based solution is that it is orthogonal to usage (or non-usage) of= P2MP PWs for effective delivery of BUN traffic.
>
> Another advantage is preservation of full mesh of P2P PWs in a= VPLS, and, in a more generic way, localization of effects of changes in th= e PE configuration.
>
> In particular, adding a Leaf AC to a PE= that previously has been only supporting Root ACs (or vice versa), removal= of the last Leaf or last Root AC from a PE that previously has been suppor= ting a mix etc. affect only the PE where this operation happens and not the= rest of the PEs.
>
> As for the need for HW changes that have been mentioned as a m= ain disadvantage of the CW-based approach - I believe it strongly depends o= n specific implementations. And some changes in the forwarding process are = required in any solution.
>
> My 2c,
> =A0 =A0 Sasha
>
>
>
> _= _______________________________________
> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com]
> Sent: Wednesday, April 18, 2012 9:57 PM
> To: Lucy yong; Daniel = Cohn; Sam Cao
> Cc: l2vpn@ietf.org<= /a>
> Subject: Re: The status of the approaches to the E-Tree solutio= n?
>
> Again, the P2MP situation throws me. =A0Is this something that= is used
> commonly?
>
> I'm under the impression tha= t adding P2MP to any model results in a more
> complex model. =A0Weth= er outside s-tag is used to differentiate, or
> dedicated pw's are used for the same purpose, it seems both become= more
> complex.
>
> Gile's comparison slide still co= ncisely captures the differences between
> these methods, in my opini= on. =A0I haven't seen any new ideas or thoughts
> brought to the group in the past week or two on the subject. =A0I woul= d hate
> for both proposed methods to die on the vine because we coul= dn't decide
> between two methods that have nothing inherently wr= ong with either.
>
> -Josh
>
>
> On 4/18/12 1:53 PM, "Lucy y= ong" <lucy.yong@huawei.com<= /a>> wrote:
>
>>Send this again.
>>
>>T= wo PW approach can be complex too if the VPLS instance for E-Tree uses
>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown>>unicast traffic, and some P2MP PWs for multicast traffic. It may d= ouble
>>all of them.
>>
>>Lucy
>>
>>-----Original Message-----
>>From: Daniel Cohn [mailto:DanielC@orckit.com]
>>Sent:= Wednesday, April 18, 2012 1:42 PM
>>To: Lucy yong; Rogers, Josh; = Sam Cao
>>Cc: l2vpn@ietf.org
>>= ;Subject: RE: The status of the approaches to the E-Tree solution?
>&= gt;
>>I think the first option its the natural way to go. How is t= he processing
>>in this case more complex?
>>
>>Thumb typed - ple= ase be tolerant
>>
>>Lucy yong <lucy.yong@huawei.com> wrote:
>>
>&g= t;
>>
>>Snipped..
>>
>>Multi-PW - On ingress = PE, frame is placed onto either a Leaf-only P2MP PW
>>(for traffic= coming from a leaf AC), or onto a Root/Leaf P2MP PW (for
>>traffi= c coming from a root AC)
>>[[LY]] Not that simple. You construct either two P2MP PWs to all ot= her
>>PEs and let egress PE performing filtering, or construct one= P2MP PW to
>>leaf-only PEs and two P2MP PWs to root and leaf PEs = and let ingress PE
>>perform forwarding and filtering. Both make node process complex.>>
>>[[LY]] VPLS is built with the mechanism utilizing P2P= and P2MP PW for
>>delivering the frames to remote PEs. We should = utilize them with the
>>minimized changes. Dual VLAN solution is simpler than Dual PW.
&= gt;>
>>Regards,
>>Lucy
>>
>>
>= >I see how 2VLAN is simpler when P2MP PW's are involved, I think. = =A0I
>>haven't had any first hand experience with P2MP PW's, howev= er, so don't
>>feel terribly strong about this objection. =A0I= s this a real problem for
>>others (now or in the future), or is t= his objection in the weeds?
>>
>>I'm not sure the 'additional complexity' is= notable, or even relevant. =A0I
>>encourage others to speak up if= they disagree, as P2MP PW is only
>>conceptual to me, and I am un= familiar with real-life use cases for it.
>>
>>Thanks,
>>Josh
>>
>>
>= >
>>On 4/18/12 10:30 AM, "Lucy yong" <lucy.yong@huawei.com> wrote:
>>=
>>>Please see inline.
>>>
>>>-----Original= Message-----
>>>From: Sam Cao [mailto:yuqun.cao@gmail.com]
>>>Sent: Tuesday, April= 17, 2012 7:14 AM
>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; &= #39;Henderickx, Wim (Wim)';
>>>giles.heron@gmail.com; simon.delord@gmail.com;
>>>Alexander.V= ainshtein@ecitele.com
>>>Cc: l2vpn@ietf.org; Vla= dimir.Kleiner@ecitele.com;
>>>Andrew.Sergeev@ec= itele.com; Idan.Kaspit@ecite= le.com;
>>>Mi= shael.Wexler@ecitele.com; Ro= tem.Cohen@ecitele.com
>>>Subject: RE: The status of the approaches to the E-Tree solutio= n?
>>>
>>>Yes, 2 pws are only needed between pes wi= th both root and leaf acs after
>>>improving Dual-PW approach. = If consider P2MP, Dual-PW approach setup 2
>>>P2MP
>>>PWs if need. There is no difference between= P2MP or normal PW setup. But,
>>>can Leaf-ACs be bound to Root= PE of P2MP PW?
>>>
>>>[[LY]] No, it makes complex = in setting up P2MP PW. Should a PE with both
>>>root and leaf ACs set up two or one P2MP PW to other PEs (some = PE have
>>>both root and leaf AC and some only have leaf ACs)?<= br>>>>Regards,
>>>Lucy
>>>
>>>= Regards,
>>>
>>>Yuqun (Sam) Cao
>>>E-mail: Yuqun.cao@gmail.com
>>>
= >>>
>>>-----Original Message-----
>>>From:= Daniel Cohn [mailto:DanielC@orckit.c= om]
>>>Sent: Tuesday, April 17, 2012 4:56 PM
>>>To: Lucy y= ong; Rogers, Josh; Henderickx, Wim (Wim);
>>>giles.heron@gmail.com;
>>>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; = Sam Cao
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com= ;
>>>Andrew.Serge= ev@ecitele.com; Idan.Kaspit@= ecitele.com;
>>>Mishael.Wexler@ec= itele.com; Rotem.Cohen@ecite= le.com
>>>Subject: RE: The status of the approaches to the = E-Tree solution?
>>>
>>>Adding Sam (as l2vpn@ is holding messages)
&= gt;>>
>>>DC
>>>
>>>-----Original = Message-----
>>>From: Lucy yong [mailto:lucy.yong@huawei.com]
>>>Sent: Tuesday, April 17, 2012 12:39 AM
>>>To: Danie= l Cohn; Rogers, Josh; Henderickx, Wim (Wim);
>>>giles.heron@gmail.com; simon.delord@gmail.com;
>>>Alexander.V= ainshtein@ecitele.com
>>>Cc: l2vpn@ietf.org; Vla= dimir.Kleiner@ecitele.com;
>>>Andrew.Sergeev@ec= itele.com; Idan.Kaspit@ecite= le.com;
>>>Mi= shael.Wexler@ecitele.com; Ro= tem.Cohen@ecitele.com
>>>Subject: RE: The status of the approaches to the E-Tree solutio= n?
>>>
>>>
>>>Snipped,
>>><= br>>>>As we discussed extensively in the list, and as reflected in= giles
>>>slide, 2 pws are only needed between pes with both root and lea= f acs,
>>>which will typically be a small minority.
>>= >[[LY]] Don't know if the assumption is true. Even it is the case, b= oth
>>>approaches can benefit from it. I was off for a while and captu= res some
>>>discussions now.
>>>
>>>Als= o as per giles slide, dual vlan can have scalability issues due to
>&= gt;>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issu= es with
>>>silicon that doesn't support vlan mapping.
&g= t;>>[[LY]] I was not in IETF83 meeting and wait on the meeting minute= s. I am
>>>not clear on all the issues. Could you be more specific? As I m= entioned
>>>in below, two PW approach makes VPLS transport cons= truction and packet
>>>forwarding more complex, I can see poten= tial backward compatibility
>>>issues with 2 PW solution.
>>>
>>>Regar= ds,
>>>Lucy
>>>
>>>Regards,
>>= >
>>>Daniel
>>>
>>>Thumb typed - ple= ase be tolerant
>>>
>>>Lucy yong <lucy.yong@huawei.com> wrote:
>>>
>>>I= n my mind, the VLAN approach means dual vlan method.
>>>
>= ;>>The main concern for CW approach is hardware support.
>>>
>>>Two PW approach can be complex too if the VPLS = instance for E-Tree uses
>>>P2P PW for unicast traffic and P2MP= PW for broadcast and unknown unicast
>>>traffic, and some P2MP= PWs for multicast traffic. It may double all of
>>>them.
>>>
>>>E-tree is an Ethernet serv= ice and there is already VLAN based solution
>>>in IEEE, can we= just utilize it without complicating VPLS transport
>>>constru= ction? This also makes interworking with Eth only network easier.
>>>
>>>Cheers,
>>>Lucy
>>>
= >>>-----Original Message-----
>>>From: Rogers, Josh [m= ailto:josh.rogers@twcable.com]
>>>Sent: Monday, April 16, 2012 8:35 AM
>>>To: Lucy yo= ng; Henderickx, Wim (Wim); 'gi= les.heron@gmail.com';
>>>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org&#= 39;; 'Vladimir.Kleiner@= ecitele.com';
>>>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com';
>>>'Mishael.Wexl= er@ecitele.com'; 'Ro= tem.Cohen@ecitele.com'
>>>Subject: RE: The status of th= e approaches to the E-Tree solution?
>>>
>>>I believe the initial question was in regard to= the CW method. =A0Are you
>>>saying that you no longer are int= erested in that method in preference of
>>>the dual vlan method= ?
>>>
>>>
>>>
>>>Lucy yong <<= a href=3D"mailto:lucy.yong@huawei.com">lucy.yong@huawei.com> wrote:<= br>>>>
>>>
>>>Agree with Wim. VLAN approac= h is the best solution for E-Tree.
>>>
>>>Lucy
>>>
>>>-----Origin= al Message-----
>>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf
>>>Of Henderickx, Wim (Wim)
>>>Sent: Thursday, April 1= 2, 2012 2:03 AM
>>>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com';
>>>'Alexan= der.Vainshtein@ecitele.com'
>>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com';
>>>'Andrew.Serge= ev@ecitele.com'; 'Id= an.Kaspit@ecitele.com';
>>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com'
>>>Subject: Re: The status of the approaches to the E-Tree solutio= n?
>>>
>>>The vlan approach is superior as it also = works for eth only networks,
>>>etc. On top some vendors indica= te hw issues with the cw approach. As
>>>such we have dropped more or less the cw approach.
>>&= gt;
>>>Cheers,
>>>Wim
>>>______________= ___
>>>sent from blackberry
>>>
>>>----= - Original Message -----
>>>From: Giles Heron [mailto:giles.heron@gmail.com]
>>>Sent: Thursday, April 12, 201= 2 08:22 AM
>>>To: Simon Delord <simon.delord@gmail.com>; Alexander Vainshtein
>>><Alexand= er.Vainshtein@ecitele.com>
>>>Cc: l2vpn@ietf.org <l2vpn@= ietf.org>; Vladimir Kleiner
>>><Vladimir.Kl= einer@ecitele.com>; Andrew Sergeev
>>><Andrew.Sergeev@ecitele.com>; Idan Ka= spit <Idan.Kaspit@ecitele.com= >;
>>>Mishael Wexler <Mishael.Wexler@ecitele.com>; Rotem Cohen
>>><Rotem.Cohen@ecitele.com>
>= ;>>Subject: Re: The status of the approaches to the E-Tree solution?<= br> >>>
>>>Sorry - the "anonymous presentation" = was mine. =A0I should possibly have
>>>put in a third column on= the CW approach. =A0And hopefully the minutes
>>>will be poste= d soon.
>>>
>>>We had various discussions, as Simon stated, an= d consensus seemed to be
>>>forming around the two alternatives= of two PWEs or two VLANs. =A0I believe
>>>three of the authors= of the CW approach are also authors of the two VLAN
>>>approach and one is also an author of the two PWE approach. So = perhaps
>>>it's best to let those four individuals say whic= h approach they prefer
>>>and why?
>>>
>>&= gt;Giles
>>>
>>>On 10/04/2012 00:45, "Simon Delord" &= lt;simon.delord@gmail.com>= wrote:
>>>
>>>> Hi Alexander,
>>>&g= t;
>>>> You are right, no discussion on the WG mailing list recent= ly, but
>>>> there have been substantial discussions among t= he authors of various
>>>> solution drafts off the mailing l= ist. As far as I know, no consensus
>>>> yet before ietf83, not sure the progress in the Paris WG m= eeting. I
>>>> think the CW approach has not been rejected b= y the WG yet, or the WG
>>>> has not yet decided on which on= e to adopt.
>>>>
>>>> Simon
>>>>
>>&= gt;> 2012/4/8 Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
>>>= >
>>>>> =A0Hi all,
>>>>>
>>>>= > Unfortunately I have not been able to attend the Paris IETF.
>&g= t;>>>
>>>>> However, looking up the L2VPN procee= dings, I've found a short
>>>>> anonymous presentation called "E-Tree Update"= ; =A0(
>>>>> http://www.ietf.org/proceedings/83/slides/= slides-83-l2vpn-1.pptx).
>>>>> This presentation discusses the differences of the E-T= ree approaches
>>>>> based on dedicated VLANs (as in
&= gt;>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-= vpls-etree/?include_t
>>>>> ext=3D1) and multiple PWs between the PEs (as in
&g= t;>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-e= tree-multiple-pw/?in
>>>>> clude_te
>>>>> xt=3D1)
>>&g= t;>> and completely ignores the solution based on usage of the CW in = the
>>>>> PWs connecting the PEs (as in
>>>&g= t;> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?i= nclude_t
>>>>> ext=3D1
>>>>> ).
>>>>= >
>>>>>
>>>>>
>>>>>= ; The Minutes of the Paris L2VPN session are not yet available, but I
>>>>> wonder whether the WG has taken a decision to reject t= he approach
>>>>> based on the CW usage? I do not remembe= r any recent discussion of
>>>>> this topic on the WG mai= ling list.
>>>>>
>>>>>
>>>>>
>= ;>>>> Regards, and lots of thanks in advance,
>>>&g= t;>
>>>>> Sasha
>>>>>
>>>= ;>>
>>>>>
>>>>>
>>>>>
>= ;>>>> This e-mail message is intended for the recipient only an= d contains
>>>>> information which is CONFIDENTIAL and wh= ich may be proprietary to ECI
>>>
>>>>> Telecom. If you have received this tra= nsmission in error, please
>>>>> inform us by e-mail, pho= ne or fax, and then delete the original and
>>>>> all cop= ies thereof.
>>>>>
>>>
>>>
>>>
>= ;>>
>>>
>>>This E-mail and any of its attachm= ents may contain Time Warner Cable
>>>proprietary information, = which is privileged, confidential, or subject
>>>to copyright belonging to Time Warner Cable. This E-mail is int= ended
>>>solely for the use of the individual or entity to whic= h it is addressed.
>>>If you are not the intended recipient of = this E-mail, you are hereby
>>>notified that any dissemination, distribution, copying, or acti= on taken
>>>in relation to the contents of and attachments to t= his E-mail is
>>>strictly prohibited and may be unlawful. If yo= u have received this
>>>E-mail in error, please notify the sender immediately and perma= nently
>>>delete the original and any copy of this E-mail and a= ny printout.
>>>
>>
>>
>>This E-mail= and any of its attachments may contain Time Warner Cable
>>proprietary information, which is privileged, confidential, or subj= ect to
>>copyright belonging to Time Warner Cable. This E-mail is = intended solely
>>for the use of the individual or entity to which= it is addressed. If you
>>are not the intended recipient of this E-mail, you are hereby notif= ied
>>that any dissemination, distribution, copying, or action tak= en in
>>relation to the contents of and attachments to this E-mail= is strictly
>>prohibited and may be unlawful. If you have received this E-mail in=
>>error, please notify the sender immediately and permanently del= ete the
>>original and any copy of this E-mail and any printout. >
>
> This E-mail and any of its attachments may contain Tim= e Warner Cable proprietary information, which is privileged, confidential, = or subject to copyright belonging to Time Warner Cable. This E-mail is inte= nded solely for the use of the individual or entity to which it is addresse= d. If you are not the intended recipient of this E-mail, you are hereby not= ified that any dissemination, distribution, copying, or action taken in rel= ation to the contents of and attachments to this E-mail is strictly prohibi= ted and may be unlawful. If you have received this E-mail in error, please = notify the sender immediately and permanently delete the original and any c= opy of this E-mail and any printout.
> This e-mail message is intended for the recipient only and contains in= formation which is CONFIDENTIAL and which may be proprietary to ECI Telecom= . If you have received this transmission in error, please inform us by e-ma= il, phone or fax, and then delete the original and all copies thereof.
>
>
>
> ------------------------------
>
>= _______________________________________________
> L2vpn mailing list=
> L2vpn@ietf.org
> https://www.ietf.org/mai= lman/listinfo/l2vpn
>
>
> End of L2vpn Digest, Vol 95, Issue 25
> ********= *************************** --14dae934039f40d3bb04be1ee8aa-- From wim.henderickx@alcatel-lucent.com Fri Apr 20 10:27:08 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2FB21F8680 for ; Fri, 20 Apr 2012 10:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.975 X-Spam-Level: X-Spam-Status: No, score=-9.975 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, HELO_EQ_FR=0.35, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, 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 577YaWUj8BcI for ; Fri, 20 Apr 2012 10:27:05 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id E7E0121F85AD for ; Fri, 20 Apr 2012 10:27:04 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3KHR05U006429 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 20 Apr 2012 19:27:00 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 20 Apr 2012 19:26:59 +0200 From: "Henderickx, Wim (Wim)" To: Lizhong Jin , "l2vpn@ietf.org" , "Alexander.Vainshtein@ecitele.com" Date: Fri, 20 Apr 2012 19:26:57 +0200 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fE+/VJOoSOD11Q9C1vh8Hzw7u/QABsAIg Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6701296244C3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: multipart/alternative; boundary="_000_14C7F4F06DB5814AB0DE29716C4F6D6701296244C3FRMRSSXCHMBSB_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "yuqun.cao@gmail.com" X-BeenThere: l2vpn@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, 20 Apr 2012 17:27:08 -0000 --_000_14C7F4F06DB5814AB0DE29716C4F6D6701296244C3FRMRSSXCHMBSB_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The VPWS which terminates at the H-VPLS node is indicated to be root or lea= f and the procedures associated will do the VLAN manipulation From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of L= izhong Jin Sent: vrijdag 20 april 2012 18:38 To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L i= nformation, customer payload or PW? The customer payload will be always mod= ified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is access= ed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informati= on? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > > To: "Rogers, Josh" >, Lucy yong > >, Daniel Cohn <= DanielC@orckit.com>, Sam Cao > > > Cc: "l2vpn@ietf.org" > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, = but: > > IMO one of the advantages of the CW-based solution is that it is orthogon= al to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffi= c. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and,= in a more generic way, localization of effects of changes in the PE config= uration. > > In particular, adding a Leaf AC to a PE that previously has been only sup= porting Root ACs (or vice versa), removal of the last Leaf or last Root AC = from a PE that previously has been supporting a mix etc. affect only the PE= where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadva= ntage of the CW-based approach - I believe it strongly depends on specific = implementations. And some changes in the forwarding process are required in= any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounce= s@ietf.org] on behalf of Rogers, Josh [josh.= rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a more > complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become more > complex. > > Gile's comparison slide still concisely captures the differences between > these methods, in my opinion. I haven't seen any new ideas or thoughts > brought to the group in the past week or two on the subject. I would hat= e > for both proposed methods to die on the vine because we couldn't decide > between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may double >>all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the processing >>in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >>traffic coming from a root AC) >>[[LY]] Not that simple. You construct either two P2MP PWs to all other >>PEs and let egress PE performing filtering, or construct one P2MP PW to >>leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >>perform forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so don't >>feel terribly strong about this objection. Is this a real problem for >>others (now or in the future), or is this objection in the weeds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. I >>encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>>giles.heron@gmail.com; simon.delord@gmail.= com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com<= mailto:Vladimir.Kleiner@ecitele.com>; >>>Andrew.Sergeev@ecitele.com; Idan.Kasp= it@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Coh= en@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs after >>>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>>P2MP >>>PWs if need. There is no difference between P2MP or normal PW setup. But= , >>>can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>>both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; Alexander.Vainsht= ein@ecitele.com; Sam Cao >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com<= mailto:Vladimir.Kleiner@ecitele.com>; >>>Andrew.Sergeev@ecitele.com; Idan.Kasp= it@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Coh= en@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong [mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; simon.delord@gmail.= com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com<= mailto:Vladimir.Kleiner@ecitele.com>; >>>Andrew.Sergeev@ecitele.com; Idan.Kasp= it@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Coh= en@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, both >>>approaches can benefit from it. I was off for a while and captures some >>>discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues with >>>silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>>not clear on all the issues. Could you be more specific? As I mentioned >>>in below, two PW approach makes VPLS transport construction and packet >>>forwarding more complex, I can see potential backward compatibility >>>issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>>traffic, and some P2MP PWs for multicast traffic. It may double all of >>>them. >>> >>>E-tree is an Ethernet service and there is already VLAN based solution >>>in IEEE, can we just utilize it without complicating VPLS transport >>>construction? This also makes interworking with Eth only network easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vain= shtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.c= om'; >>>'Andrew.Sergeev@ecitele.com'; 'Idan.K= aspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are you >>>saying that you no longer are interested in that method in preference of >>>the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org [mailto:l2vp= n-bounces@ietf.org] On Behalf >>>Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; 'simon.delord= @gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.c= om'; >>>'Andrew.Sergeev@ecitele.com'; 'Idan.K= aspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron [mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord >= ; Alexander Vainshtein >>>> >>>Cc: l2vpn@ietf.org >; Vladimir Kleiner >>>>; And= rew Sergeev >>>>; Idan Ka= spit >; >>>Mishael Wexler >; Rotem Cohen >>>> >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly have >>>put in a third column on the CW approach. And hopefully the minutes >>>will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to be >>>forming around the two alternatives of two PWEs or two VLANs. I believe >>>three of the authors of the CW approach are also authors of the two VLAN >>>approach and one is also an author of the two PWE approach. So perhaps >>>it's best to let those four individuals say which approach they prefer >>>and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of various >>>> solution drafts off the mailing list. As far as I know, no consensus >>>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>>> think the CW approach has not been rejected by the WG yet, or the WG >>>> has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein > >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree approaches >>>>> based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in the >>>>> PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>>> wonder whether the WG has taken a decision to reject the approach >>>>> based on the CW usage? I do not remember any recent discussion of >>>>> this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and contains >>>>> information which is CONFIDENTIAL and which may be proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original and >>>>> all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action taken >>>in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use of the individual or entity to which it is addressed. If you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** --_000_14C7F4F06DB5814AB0DE29716C4F6D6701296244C3FRMRSSXCHMBSB_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The VPWS = which terminates at the H-VPLS node is indicated to be root or leaf and the= procedures associated will do the VLAN manipulation

<= p class=3DMsoNormal> 

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On = Behalf Of Lizhong Jin
Sent: vrijdag 20 april 2012 18:38
To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com
Cc: yuq= un.cao@gmail.com
Subject: RE: The status of the approaches to the= E-Tree solution?

&nbs= p;

Hi, all,
The difference between 2-VLAN = and CW approach is who will provide the R/L information, customer payload o= r PW? The customer payload will be always modified to carry R/L information= in 2-VLAN approach, while PW with CW will carry R/L information for CW app= roach.
I have a question with the 2-VLAN approach in H-VPLS where H-VPLS= is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is use= d to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L= information?

Thanks
Lizhong

> ------------------------= ------
>
> Message: 2
> Date: Thu, 19 Apr 2012 04:38:36 += 0000
> From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
> To: &= quot;Rogers, Josh" <josh= .rogers@twcable.com>, Lucy yong
>        &= lt;lucy.yong@huawei.com>, Da= niel Cohn <DanielC@orckit.com&= gt;, Sam Cao
>        <yuqun.cao@gmail.com>
> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
> Subject: RE: The status of the appr= oaches to the E-Tree solution?
> Message-ID:
>     &n= bsp;  <F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.= ecitele.com>
> Content-Type: text/plain; charset=3D"us-as= cii"
>
> Hi all,
> I fully understand that that what= I am going to say is not very popular, but:
>
> IMO one of the= advantages of the CW-based solution is that it is orthogonal to usage (or = non-usage) of P2MP PWs for effective delivery of BUN traffic.
>
&g= t; Another advantage is preservation of full mesh of P2P PWs in a VPLS, and= , in a more generic way, localization of effects of changes in the PE confi= guration.
>
> In particular, adding a Leaf AC to a PE that prev= iously has been only supporting Root ACs (or vice versa), removal of the la= st Leaf or last Root AC from a PE that previously has been supporting a mix= etc. affect only the PE where this operation happens and not the rest of t= he PEs.
>
> As for the need for HW changes that have been menti= oned as a main disadvantage of the CW-based approach - I believe it strongl= y depends on specific implementations. And some changes in the forwarding p= rocess are required in any solution.
>
> My 2c,
>   =   Sasha
>
>
>
> ______________________________= __________
> From: l2vpn-bo= unces@ietf.org [l2vpn-bounces= @ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com]
> Sent: Wednesday, April 18, 2= 012 9:57 PM
> To: Lucy yong; Daniel Cohn; Sam Cao
> Cc: l2vpn@ietf.org
> Subject: Re: The stat= us of the approaches to the E-Tree solution?
>
> Again, the P2M= P situation throws me.  Is this something that is used
> commonl= y?
>
> I'm under the impression that adding P2MP to any model r= esults in a more
> complex model.  Wether outside s-tag is used = to differentiate, or
> dedicated pw's are used for the same purpose, = it seems both become more
> complex.
>
> Gile's compariso= n slide still concisely captures the differences between
> these meth= ods, in my opinion.  I haven't seen any new ideas or thoughts
> = brought to the group in the past week or two on the subject.  I would = hate
> for both proposed methods to die on the vine because we couldn= 't decide
> between two methods that have nothing inherently wrong wi= th either.
>
> -Josh
>
>
> On 4/18/12 1:53 PM= , "Lucy yong" <lucy.yo= ng@huawei.com> wrote:
>
>>Send this again.
>>= ;
>>Two PW approach can be complex too if the VPLS instance for E-= Tree uses
>>P2P PW for unicast traffic and P2MP PW for broadcast a= nd unknown
>>unicast traffic, and some P2MP PWs for multicast traf= fic. It may double
>>all of them.
>>
>>Lucy
&= gt;>
>>-----Original Message-----
>>From: Daniel Cohn = [mailto:DanielC@orckit.com]
&g= t;>Sent: Wednesday, April 18, 2012 1:42 PM
>>To: Lucy yong; Rog= ers, Josh; Sam Cao
>>Cc: l2vpn@i= etf.org
>>Subject: RE: The status of the approaches to the E-T= ree solution?
>>
>>I think the first option its the natur= al way to go. How is the processing
>>in this case more complex?>>
>>Thumb typed - please be tolerant
>>
>&= gt;Lucy yong <lucy.yong@huawei.c= om> wrote:
>>
>>
>>
>>Snipped..<= br>>>
>>Multi-PW - On ingress PE, frame is placed onto eithe= r a Leaf-only P2MP PW
>>(for traffic coming from a leaf AC), or on= to a Root/Leaf P2MP PW (for
>>traffic coming from a root AC)
&g= t;>[[LY]] Not that simple. You construct either two P2MP PWs to all othe= r
>>PEs and let egress PE performing filtering, or construct one P= 2MP PW to
>>leaf-only PEs and two P2MP PWs to root and leaf PEs an= d let ingress PE
>>perform forwarding and filtering. Both make nod= e process complex.
>>
>>[[LY]] VPLS is built with the mec= hanism utilizing P2P and P2MP PW for
>>delivering the frames to re= mote PEs. We should utilize them with the
>>minimized changes. Dua= l VLAN solution is simpler than Dual PW.
>>
>>Regards,>>Lucy
>>
>>
>>I see how 2VLAN is simpler= when P2MP PW's are involved, I think.  I
>>haven't had any f= irst hand experience with P2MP PW's, however, so don't
>>feel terr= ibly strong about this objection.  Is this a real problem for
>&= gt;others (now or in the future), or is this objection in the weeds?
>= ;>
>>I'm not sure the 'additional complexity' is notable, or ev= en relevant.  I
>>encourage others to speak up if they disagr= ee, as P2MP PW is only
>>conceptual to me, and I am unfamiliar wit= h real-life use cases for it.
>>
>>Thanks,
>>Jos= h
>>
>>
>>
>>On 4/18/12 10:30 AM, "= ;Lucy yong" <lucy.yong@huaw= ei.com> wrote:
>>
>>>Please see inline.
>= >>
>>>-----Original Message-----
>>>From: Sam= Cao [mailto:yuqun.cao@gmail.com= ]
>>>Sent: Tuesday, April 17, 2012 7:14 AM
>>>To: '= Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)';
>&g= t;>giles.heron@gmail.com; <= a href=3D"mailto:simon.delord@gmail.com">simon.delord@gmail.com;
>= ;>>Alexander.Vain= shtein@ecitele.com
>>>Cc: l2vpn@ietf.org; Vladim= ir.Kleiner@ecitele.com;
>>>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com;
>>>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com
>>>Sub= ject: RE: The status of the approaches to the E-Tree solution?
>>&= gt;
>>>Yes, 2 pws are only needed between pes with both root an= d leaf acs after
>>>improving Dual-PW approach. If consider P2M= P, Dual-PW approach setup 2
>>>P2MP
>>>PWs if need.= There is no difference between P2MP or normal PW setup. But,
>>&g= t;can Leaf-ACs be bound to Root PE of P2MP PW?
>>>
>>&= gt;[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both=
>>>root and leaf ACs set up two or one P2MP PW to other PEs (s= ome PE have
>>>both root and leaf AC and some only have leaf AC= s)?
>>>Regards,
>>>Lucy
>>>
>>= >Regards,
>>>
>>>Yuqun (Sam) Cao
>>>= E-mail: Yuqun.cao@gmail.com
&= gt;>>
>>>
>>>-----Original Message-----
&g= t;>>From: Daniel Cohn [mailto:D= anielC@orckit.com]
>>>Sent: Tuesday, April 17, 2012 4:56 PM=
>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim);
>= >>giles.heron@gmail.com;=
>>>simon.delord@gmai= l.com; Alexander.Va= inshtein@ecitele.com; Sam Cao
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com;
>>>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com;
>>>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com
>= >>Subject: RE: The status of the approaches to the E-Tree solution?>>>
>>>Adding Sam (as l2vpn@ is holding messages)>>>
>>>DC
>>>
>>>-----Origina= l Message-----
>>>From: Lucy yong [mailto:lucy.yong@huawei.com]
>>>Sent: Tuesday, = April 17, 2012 12:39 AM
>>>To: Daniel Cohn; Rogers, Josh; Hende= rickx, Wim (Wim);
>>>g= iles.heron@gmail.com; simon.d= elord@gmail.com;
>>>Alexander.Vainshtein@ecitele.com
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com;
>>>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com;
&g= t;>>Mishael.Wexler@ecit= ele.com; Rotem.Cohen@ecitele= .com
>>>Subject: RE: The status of the approaches to the E-= Tree solution?
>>>
>>>
>>>Snipped,
&= gt;>>
>>>As we discussed extensively in the list, and as = reflected in giles
>>>slide, 2 pws are only needed between pes = with both root and leaf acs,
>>>which will typically be a small= minority.
>>>[[LY]] Don't know if the assumption is true. Even= it is the case, both
>>>approaches can benefit from it. I was = off for a while and captures some
>>>discussions now.
>&g= t;>
>>>Also as per giles slide, dual vlan can have scalabili= ty issues due to
>>>additional lookup and double use of vlans i= n internal emulated lan
>>>interface. Also there are potential = backward compatibility issues with
>>>silicon that doesn't supp= ort vlan mapping.
>>>[[LY]] I was not in IETF83 meeting and wai= t on the meeting minutes. I am
>>>not clear on all the issues. = Could you be more specific? As I mentioned
>>>in below, two PW = approach makes VPLS transport construction and packet
>>>forwar= ding more complex, I can see potential backward compatibility
>>&g= t;issues with 2 PW solution.
>>>
>>>Regards,
>= ;>>Lucy
>>>
>>>Regards,
>>>
&g= t;>>Daniel
>>>
>>>Thumb typed - please be tol= erant
>>>
>>>Lucy yong <lucy.yong@huawei.com> wrote:
>>>
>= >>In my mind, the VLAN approach means dual vlan method.
>>&g= t;
>>>The main concern for CW approach is hardware support.
= >>>
>>>Two PW approach can be complex too if the VPLS = instance for E-Tree uses
>>>P2P PW for unicast traffic and P2MP= PW for broadcast and unknown unicast
>>>traffic, and some P2MP= PWs for multicast traffic. It may double all of
>>>them.
&g= t;>>
>>>E-tree is an Ethernet service and there is alread= y VLAN based solution
>>>in IEEE, can we just utilize it withou= t complicating VPLS transport
>>>construction? This also makes = interworking with Eth only network easier.
>>>
>>>C= heers,
>>>Lucy
>>>
>>>-----Original Mes= sage-----
>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com]
>>>Sent: Monda= y, April 16, 2012 8:35 AM
>>>To: Lucy yong; Henderickx, Wim (Wi= m); 'giles.heron@gmail.com';>>>'simon.delord@gmail= .com'; 'Alexander.V= ainshtein@ecitele.com'
>>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com';
>>>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com';
>>>'Mishael.Wexler@ecitele.com'; = 'Rotem.Cohen@ecitele.com'>>>Subject: RE: The status of the approaches to the E-Tree soluti= on?
>>>
>>>I believe the initial question was in re= gard to the CW method.  Are you
>>>saying that you no long= er are interested in that method in preference of
>>>the dual v= lan method?
>>>
>>>
>>>
>>>= Lucy yong <lucy.yong@huawei.com<= /a>> wrote:
>>>
>>>
>>>Agree with Wi= m. VLAN approach is the best solution for E-Tree.
>>>
>&g= t;>Lucy
>>>
>>>-----Original Message-----
>= ;>>From: l2vpn-bounces@ietf= .org [mailto:l2vpn-bounces@ie= tf.org] On Behalf
>>>Of Henderickx, Wim (Wim)
>>&g= t;Sent: Thursday, April 12, 2012 2:03 AM
>>>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com';
>>>'Alexander.Vainshtein@ecitele.c= om'
>>>Cc: 'l2vpn@ietf.or= g'; 'Vladimir.Kleiner@e= citele.com';
>>>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com';
>>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com'
>>>Subjec= t: Re: The status of the approaches to the E-Tree solution?
>>>=
>>>The vlan approach is superior as it also works for eth only= networks,
>>>etc. On top some vendors indicate hw issues with = the cw approach. As
>>>such we have dropped more or less the cw= approach.
>>>
>>>Cheers,
>>>Wim
>= ;>>_________________
>>>sent from blackberry
>>&= gt;
>>>----- Original Message -----
>>>From: Giles = Heron [mailto:giles.heron@gmail.co= m]
>>>Sent: Thursday, April 12, 2012 08:22 AM
>>&g= t;To: Simon Delord <simon.delo= rd@gmail.com>; Alexander Vainshtein
>>><Alexander.Vainshtein@ecitele.com= >
>>>Cc: l2vpn@ietf.org <l2vpn@ietf.org>; Vladimir Kl= einer
>>><Vl= adimir.Kleiner@ecitele.com>; Andrew Sergeev
>>><Andrew.Sergeev@ecitele.com>= ; Idan Kaspit <Idan.Kaspit@ec= itele.com>;
>>>Mishael Wexler <Mishael.Wexler@ecitele.com>; Rotem Cohen
= >>><Rotem.Cohen@ecit= ele.com>
>>>Subject: Re: The status of the approaches to= the E-Tree solution?
>>>
>>>Sorry - the "anon= ymous presentation" was mine.  I should possibly have
>>= >put in a third column on the CW approach.  And hopefully the minut= es
>>>will be posted soon.
>>>
>>>We ha= d various discussions, as Simon stated, and consensus seemed to be
>&= gt;>forming around the two alternatives of two PWEs or two VLANs.  = I believe
>>>three of the authors of the CW approach are also a= uthors of the two VLAN
>>>approach and one is also an author of= the two PWE approach. So perhaps
>>>it's best to let those fou= r individuals say which approach they prefer
>>>and why?
>= ;>>
>>>Giles
>>>
>>>On 10/04/2012= 00:45, "Simon Delord" <simon.delord@gmail.com> wrote:
>>>
>>>&g= t; Hi Alexander,
>>>>
>>>> You are right, no = discussion on the WG mailing list recently, but
>>>> there h= ave been substantial discussions among the authors of various
>>&g= t;> solution drafts off the mailing list. As far as I know, no consensus=
>>>> yet before ietf83, not sure the progress in the Paris = WG meeting. I
>>>> think the CW approach has not been reject= ed by the WG yet, or the WG
>>>> has not yet decided on whic= h one to adopt.
>>>>
>>>> Simon
>>&g= t;>
>>>> 2012/4/8 Alexander Vainshtein <Alexander.Vainshtein@ecitele.com&= gt;
>>>>
>>>>>  Hi all,
>>&g= t;>>
>>>>> Unfortunately I have not been able to at= tend the Paris IETF.
>>>>>
>>>>> Howeve= r, looking up the L2VPN proceedings, I've found a short
>>>>= > anonymous presentation called "E-Tree Update"  (
>= ;>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2v= pn-1.pptx).
>>>>> This presentation discusses the dif= ferences of the E-Tree approaches
>>>>> based on dedicate= d VLANs (as in
>>>>> http://datatracker.ietf.org/d= oc/draft-cao-l2vpn-vpls-etree/?include_t
>>>>> ext=3D= 1) and multiple PWs between the PEs (as in
>>>>> = http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in>>>>> clude_te
>>>>> xt=3D1)
>>= >>> and completely ignores the solution based on usage of the CW i= n the
>>>>> PWs connecting the PEs (as in
>>>= >> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/= ?include_t
>>>>> ext=3D1
>>>>> ).>>>>>
>>>>>
>>>>>
&= gt;>>>> The Minutes of the Paris L2VPN session are not yet avai= lable, but I
>>>>> wonder whether the WG has taken a deci= sion to reject the approach
>>>>> based on the CW usage? = I do not remember any recent discussion of
>>>>> this top= ic on the WG mailing list.
>>>>>
>>>>><= br>>>>>>
>>>>> Regards, and lots of thanks= in advance,
>>>>>
>>>>> Sasha
>&= gt;>>>
>>>>>
>>>>>
>>= >>>
>>>>>
>>>>> This e-mail me= ssage is intended for the recipient only and contains
>>>>&g= t; information which is CONFIDENTIAL and which may be proprietary to ECI>>>
>>>>> Telecom. If you have received this tr= ansmission in error, please
>>>>> inform us by e-mail, ph= one or fax, and then delete the original and
>>>>> all co= pies thereof.
>>>>>
>>>
>>>
&g= t;>>
>>>
>>>
>>>This E-mail and a= ny of its attachments may contain Time Warner Cable
>>>propriet= ary information, which is privileged, confidential, or subject
>>&= gt;to copyright belonging to Time Warner Cable. This E-mail is intended
= >>>solely for the use of the individual or entity to which it is a= ddressed.
>>>If you are not the intended recipient of this E-ma= il, you are hereby
>>>notified that any dissemination, distribu= tion, copying, or action taken
>>>in relation to the contents o= f and attachments to this E-mail is
>>>strictly prohibited and = may be unlawful. If you have received this
>>>E-mail in error, = please notify the sender immediately and permanently
>>>delete = the original and any copy of this E-mail and any printout.
>>><= br>>>
>>
>>This E-mail and any of its attachments m= ay contain Time Warner Cable
>>proprietary information, which is p= rivileged, confidential, or subject to
>>copyright belonging to Ti= me Warner Cable. This E-mail is intended solely
>>for the use of t= he individual or entity to which it is addressed. If you
>>are not= the intended recipient of this E-mail, you are hereby notified
>>= that any dissemination, distribution, copying, or action taken in
>&g= t;relation to the contents of and attachments to this E-mail is strictly>>prohibited and may be unlawful. If you have received this E-mail i= n
>>error, please notify the sender immediately and permanently de= lete the
>>original and any copy of this E-mail and any printout.<= br>>
>
> This E-mail and any of its attachments may contain = Time Warner Cable proprietary information, which is privileged, confidentia= l, or subject to copyright belonging to Time Warner Cable. This E-mail is i= ntended solely for the use of the individual or entity to which it is addre= ssed. If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken in = relation to the contents of and attachments to this E-mail is strictly proh= ibited and may be unlawful. If you have received this E-mail in error, plea= se notify the sender immediately and permanently delete the original and an= y copy of this E-mail and any printout.
> This e-mail message is inte= nded for the recipient only and contains information which is CONFIDENTIAL = and which may be proprietary to ECI Telecom. If you have received this tran= smission in error, please inform us by e-mail, phone or fax, and then delet= e the original and all copies thereof.
>
>
>
> ----= --------------------------
>
> ________________________________= _______________
> L2vpn mailing list
> L2vpn@ietf.org
> https://www.ietf.org/mailman/listinfo/l2vpn
>>
> End of L2vpn Digest, Vol 95, Issue 25
> **************= *********************

= --_000_14C7F4F06DB5814AB0DE29716C4F6D6701296244C3FRMRSSXCHMBSB_-- From giles.heron@gmail.com Fri Apr 20 10:36:28 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80EB421F8625 for ; Fri, 20 Apr 2012 10:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Geypq-25fuR6 for ; Fri, 20 Apr 2012 10:36:28 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C1A3321F85C7 for ; Fri, 20 Apr 2012 10:36:27 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so6707420wgb.13 for ; Fri, 20 Apr 2012 10:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:mime-version:content-type:content-transfer-encoding; bh=YgNqcpG9a7ZIqNDRkX2TgzSOeKVqL91BzkiU2kS/h5o=; b=AFmcXrNW55p/Xo38/4stI6jLaAKgCNJOtz5gDd6C9X6dn2beDoKs7NyFYNvkqcpeJy 0PPNSTxlwwDf80djBVfu05lwENObLmbVXnrfoJKJsg8sYB442YFIMb0B7fOvQzm+6dvA aCm/8HrX0MuAgz12uipjxmW/BOUUXLgkE3Bl/xgYEvdjYqW+wrofFncP35NXCfetqo5t MVSlfj2hcRHbJIWfk788rJ75GBTCT6NLHqp34QlV3ACDbV5IHboKRyqE7k5JzMdAI6lH C3e1R+46b9gk7LGpV3C5FjQXs3/twWBWn+qsJCiak4uAtb45U435VxPUEFOkSo7UgVJL 4sng== Received: by 10.180.102.100 with SMTP id fn4mr17135734wib.1.1334943386986; Fri, 20 Apr 2012 10:36:26 -0700 (PDT) Received: from [10.147.56.58] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id l5sm6924754wia.11.2012.04.20.10.36.23 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Apr 2012 10:36:25 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 20 Apr 2012 18:36:31 +0100 Subject: IETF83 L2VPN Minutes From: Giles Heron To: Message-ID: Thread-Topic: IETF83 L2VPN Minutes Thread-Index: Ac0fHB9mTNU9jpABRU+u8EnrwLai8w== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Andrew McLachlan X-BeenThere: l2vpn@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, 20 Apr 2012 17:36:28 -0000 All, The draft minutes from Paris are available at: http://www.ietf.org/proceedings/83/minutes/minutes-83-l2vpn Please review and comment to the list (or to the chairs) as soon as possible if you'd to see any corrections. Many thanks to Andrew McLachlan for taking the minutes. Nabil & Giles From davari@broadcom.com Fri Apr 20 11:29:19 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525C221F866C for ; Fri, 20 Apr 2012 11:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, 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 urgE8RKj+SnF for ; Fri, 20 Apr 2012 11:29:16 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9E46921F865E for ; Fri, 20 Apr 2012 11:29:16 -0700 (PDT) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 20 Apr 2012 11:29:10 -0700 X-Server-Uuid: 72204117-5C29-4314-8910-60DB108979CB Received: from SJEXCHCAS02.corp.ad.broadcom.com (10.16.192.37) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Fri, 20 Apr 2012 11:29:07 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by sjexchcas02.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Fri, 20 Apr 2012 11:29:07 -0700 From: "Shahram Davari" To: "Lizhong Jin" , "l2vpn@ietf.org" , "Alexander.Vainshtein@ecitele.com" Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNHxPndjZLWcpAE0uaMYACV/K6GZakCIXw Date: Fri, 20 Apr 2012 18:29:06 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F28021737@SJEXCHMB12.corp.ad.broadcom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.240.251.217] MIME-Version: 1.0 X-WSS-ID: 638F757F3IO7758467-01-01 Content-Type: multipart/alternative; boundary=_000_4A6CE49E6084B141B15C0713B8993F28021737SJEXCHMB12corpadb_ Cc: "yuqun.cao@gmail.com" X-BeenThere: l2vpn@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, 20 Apr 2012 18:29:19 -0000 --_000_4A6CE49E6084B141B15C0713B8993F28021737SJEXCHMB12corpadb_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, I also have a question regarding 2-VLAN. What if the customer traffic alrea= dy has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of L= izhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L i= nformation, customer payload or PW? The customer payload will be always mod= ified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is access= ed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informati= on? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > > To: "Rogers, Josh" >, Lucy yong > >, Daniel Cohn <= DanielC@orckit.com>, Sam Cao > > > Cc: "l2vpn@ietf.org" > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, = but: > > IMO one of the advantages of the CW-based solution is that it is orthogon= al to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffi= c. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and,= in a more generic way, localization of effects of changes in the PE config= uration. > > In particular, adding a Leaf AC to a PE that previously has been only sup= porting Root ACs (or vice versa), removal of the last Leaf or last Root AC = from a PE that previously has been supporting a mix etc. affect only the PE= where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadva= ntage of the CW-based approach - I believe it strongly depends on specific = implementations. And some changes in the forwarding process are required in= any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounce= s@ietf.org] on behalf of Rogers, Josh [josh.= rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a more > complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become more > complex. > > Gile's comparison slide still concisely captures the differences between > these methods, in my opinion. I haven't seen any new ideas or thoughts > brought to the group in the past week or two on the subject. I would hat= e > for both proposed methods to die on the vine because we couldn't decide > between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may double >>all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the processing >>in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >>traffic coming from a root AC) >>[[LY]] Not that simple. You construct either two P2MP PWs to all other >>PEs and let egress PE performing filtering, or construct one P2MP PW to >>leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >>perform forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so don't >>feel terribly strong about this objection. Is this a real problem for >>others (now or in the future), or is this objection in the weeds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. I >>encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>>giles.heron@gmail.com; simon.delord@gmail.= com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com<= mailto:Vladimir.Kleiner@ecitele.com>; >>>Andrew.Sergeev@ecitele.com; Idan.Kasp= it@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Coh= en@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs after >>>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>>P2MP >>>PWs if need. There is no difference between P2MP or normal PW setup. But= , >>>can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>>both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; Alexander.Vainsht= ein@ecitele.com; Sam Cao >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com<= mailto:Vladimir.Kleiner@ecitele.com>; >>>Andrew.Sergeev@ecitele.com; Idan.Kasp= it@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Coh= en@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong [mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; simon.delord@gmail.= com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com<= mailto:Vladimir.Kleiner@ecitele.com>; >>>Andrew.Sergeev@ecitele.com; Idan.Kasp= it@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Coh= en@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, both >>>approaches can benefit from it. I was off for a while and captures some >>>discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues with >>>silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>>not clear on all the issues. Could you be more specific? As I mentioned >>>in below, two PW approach makes VPLS transport construction and packet >>>forwarding more complex, I can see potential backward compatibility >>>issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>>traffic, and some P2MP PWs for multicast traffic. It may double all of >>>them. >>> >>>E-tree is an Ethernet service and there is already VLAN based solution >>>in IEEE, can we just utilize it without complicating VPLS transport >>>construction? This also makes interworking with Eth only network easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vain= shtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.c= om'; >>>'Andrew.Sergeev@ecitele.com'; 'Idan.K= aspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are you >>>saying that you no longer are interested in that method in preference of >>>the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org [mailto:l2vp= n-bounces@ietf.org] On Behalf >>>Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; 'simon.delord= @gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.c= om'; >>>'Andrew.Sergeev@ecitele.com'; 'Idan.K= aspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron [mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord >= ; Alexander Vainshtein >>>> >>>Cc: l2vpn@ietf.org >; Vladimir Kleiner >>>>; And= rew Sergeev >>>>; Idan Ka= spit >; >>>Mishael Wexler >; Rotem Cohen >>>> >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly have >>>put in a third column on the CW approach. And hopefully the minutes >>>will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to be >>>forming around the two alternatives of two PWEs or two VLANs. I believe >>>three of the authors of the CW approach are also authors of the two VLAN >>>approach and one is also an author of the two PWE approach. So perhaps >>>it's best to let those four individuals say which approach they prefer >>>and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of various >>>> solution drafts off the mailing list. As far as I know, no consensus >>>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>>> think the CW approach has not been rejected by the WG yet, or the WG >>>> has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein > >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree approaches >>>>> based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in the >>>>> PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>>> wonder whether the WG has taken a decision to reject the approach >>>>> based on the CW usage? I do not remember any recent discussion of >>>>> this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and contains >>>>> information which is CONFIDENTIAL and which may be proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original and >>>>> all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action taken >>>in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use of the individual or entity to which it is addressed. If you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** --_000_4A6CE49E6084B141B15C0713B8993F28021737SJEXCHMB12corpadb_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

I also have a question re= garding 2-VLAN. What if the customer traffic already has an S-VLAN? Do we n= eed a 3rd VLAN to identify the L/R?

 <= /p>

Thx

Shahram=

 <= /p>

From: l2vpn-bo= unces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin
Sent: Friday, April 20, 2012 9:38 AM
To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com
Cc: yuqun.cao@gmail.com
Subject: RE: The status of the approaches to the E-Tree solution?

 

Hi, all,
The difference between 2-VLAN and CW approach is who will provide the R/L i= nformation, customer payload or PW? The customer payload will be always mod= ified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach.
I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is access= ed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informati= on?

Thanks
Lizhong

> ------------------------------
>
> Message: 2
> Date: Thu, 19 Apr 2012 04:38:36 +0000
> From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
> To: "Rogers, Josh" <josh.rogers@twcable.com>, Lucy yong
>        <lucy.yong@huawei.com>, Daniel Cohn <DanielC@orckit.com>, Sam Cao
>        <= yuqun.cao@gmail.com>
> Cc: "l2vpn@ietf.org" &= lt;l2vpn@ietf.org>
> Subject: RE: The status of the approaches to the E-Tree solution?
> Message-ID:
>        <F9336571731ADE42A5397FC831CEAA0= 2034192@FRIDWPPMB002.ecitele.com>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> Hi all,
> I fully understand that that what I am going to say is not very popula= r, but:
>
> IMO one of the advantages of the CW-based solution is that it is ortho= gonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN tra= ffic.
>
> Another advantage is preservation of full mesh of P2P PWs in a VPLS, a= nd, in a more generic way, localization of effects of changes in the PE con= figuration.
>
> In particular, adding a Leaf AC to a PE that previously has been only = supporting Root ACs (or vice versa), removal of the last Leaf or last Root = AC from a PE that previously has been supporting a mix etc. affect only the= PE where this operation happens and not the rest of the PEs.
>
> As for the need for HW changes that have been mentioned as a main disa= dvantage of the CW-based approach - I believe it strongly depends on specif= ic implementations. And some changes in the forwarding process are required= in any solution.
>
> My 2c,
>     Sasha
>
>
>
> ________________________________________
> From: l2vpn-bounces@ietf.org= [l2vpn-bounces@ietf.org]= on behalf of Rogers, Josh [josh= .rogers@twcable.com]
> Sent: Wednesday, April 18, 2012 9:57 PM
> To: Lucy yong; Daniel Cohn; Sam Cao
> Cc: l2vpn@ietf.org
> Subject: Re: The status of the approaches to the E-Tree solution?
>
> Again, the P2MP situation throws me.  Is this something that is u= sed
> commonly?
>
> I'm under the impression that adding P2MP to any model results in a mo= re
> complex model.  Wether outside s-tag is used to differentiate, or=
> dedicated pw's are used for the same purpose, it seems both become mor= e
> complex.
>
> Gile's comparison slide still concisely captures the differences betwe= en
> these methods, in my opinion.  I haven't seen any new ideas or th= oughts
> brought to the group in the past week or two on the subject.  I w= ould hate
> for both proposed methods to die on the vine because we couldn't decid= e
> between two methods that have nothing inherently wrong with either. >
> -Josh
>
>
> On 4/18/12 1:53 PM, "Lucy yong" <lucy.yong@huawei.com> wrote:
>
>>Send this again.
>>
>>Two PW approach can be complex too if the VPLS instance for E-Tree = uses
>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may do= uble
>>all of them.
>>
>>Lucy
>>
>>-----Original Message-----
>>From: Daniel Cohn [mailto:Dan= ielC@orckit.com]
>>Sent: Wednesday, April 18, 2012 1:42 PM
>>To: Lucy yong; Rogers, Josh; Sam Cao
>>Cc: l2vpn@ietf.org
>>Subject: RE: The status of the approaches to the E-Tree solution? >>
>>I think the first option its the natural way to go. How is the proc= essing
>>in this case more complex?
>>
>>Thumb typed - please be tolerant
>>
>>Lucy yong <lucy.yong@hua= wei.com> wrote:
>>
>>
>>
>>Snipped..
>>
>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P= 2MP PW
>>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (f= or
>>traffic coming from a root AC)
>>[[LY]] Not that simple. You construct either two P2MP PWs to all ot= her
>>PEs and let egress PE performing filtering, or construct one P2MP P= W to
>>leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress= PE
>>perform forwarding and filtering. Both make node process complex. >>
>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW f= or
>>delivering the frames to remote PEs. We should utilize them with th= e
>>minimized changes. Dual VLAN solution is simpler than Dual PW.
>>
>>Regards,
>>Lucy
>>
>>
>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. &n= bsp;I
>>haven't had any first hand experience with P2MP PW's, however, so d= on't
>>feel terribly strong about this objection.  Is this a real pro= blem for
>>others (now or in the future), or is this objection in the weeds? >>
>>I'm not sure the 'additional complexity' is notable, or even releva= nt.  I
>>encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for = it.
>>
>>Thanks,
>>Josh
>>
>>
>>
>>On 4/18/12 10:30 AM, "Lucy yong" <lucy.yong@huawei.com> wrote:
>>
>>>Please see inline.
>>>
>>>-----Original Message-----
>>>From: Sam Cao [mailto:yu= qun.cao@gmail.com]
>>>Sent: Tuesday, April 17, 2012 7:14 AM
>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim = (Wim)';
>>>giles.heron@gmail.com<= /a>; simon.delord@gmail.com;
>>>Alexander.V= ainshtein@ecitele.com
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com;
>>>Andrew.Sergeev@ec= itele.com; Idan.Kaspit@ecitele.com;
>>>Mishael.Wexler@ec= itele.com; Rotem.Cohen@ecitele.com
>>>Subject: RE: The status of the approaches to the E-Tree solutio= n?
>>>
>>>Yes, 2 pws are only needed between pes with both root and leaf = acs after
>>>improving Dual-PW approach. If consider P2MP, Dual-PW approach = setup 2
>>>P2MP
>>>PWs if need. There is no difference between P2MP or normal PW s= etup. But,
>>>can Leaf-ACs be bound to Root PE of P2MP PW?
>>>
>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE = with both
>>>root and leaf ACs set up two or one P2MP PW to other PEs (some = PE have
>>>both root and leaf AC and some only have leaf ACs)?
>>>Regards,
>>>Lucy
>>>
>>>Regards,
>>>
>>>Yuqun (Sam) Cao
>>>E-mail: Yuqun.cao@gmail.= com
>>>
>>>
>>>-----Original Message-----
>>>From: Daniel Cohn [mailto:DanielC@orckit.com]
>>>Sent: Tuesday, April 17, 2012 4:56 PM
>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim);
>>>giles.heron@gmail.com<= /a>;
>>>simon.delord@gmail.co= m; Alexander.Vainshtein@ecitele.com; Sam Cao
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com;
>>>Andrew.Sergeev@ec= itele.com; Idan.Kaspit@ecitele.com;
>>>Mishael.Wexler@ec= itele.com; Rotem.Cohen@ecitele.com
>>>Subject: RE: The status of the approaches to the E-Tree solutio= n?
>>>
>>>Adding Sam (as l2vpn@ is holding messages)
>>>
>>>DC
>>>
>>>-----Original Message-----
>>>From: Lucy yong [mailto:lucy.yong@huawei.com]
>>>Sent: Tuesday, April 17, 2012 12:39 AM
>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim);
>>>giles.heron@gmail.com<= /a>; simon.delord@gmail.com;
>>>Alexander.V= ainshtein@ecitele.com
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com;
>>>Andrew.Sergeev@ec= itele.com; Idan.Kaspit@ecitele.com;
>>>Mishael.Wexler@ec= itele.com; Rotem.Cohen@ecitele.com
>>>Subject: RE: The status of the approaches to the E-Tree solutio= n?
>>>
>>>
>>>Snipped,
>>>
>>>As we discussed extensively in the list, and as reflected in gi= les
>>>slide, 2 pws are only needed between pes with both root and lea= f acs,
>>>which will typically be a small minority.
>>>[[LY]] Don't know if the assumption is true. Even it is the cas= e, both
>>>approaches can benefit from it. I was off for a while and captu= res some
>>>discussions now.
>>>
>>>Also as per giles slide, dual vlan can have scalability issues = due to
>>>additional lookup and double use of vlans in internal emulated = lan
>>>interface. Also there are potential backward compatibility issu= es with
>>>silicon that doesn't support vlan mapping.
>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minu= tes. I am
>>>not clear on all the issues. Could you be more specific? As I m= entioned
>>>in below, two PW approach makes VPLS transport construction and= packet
>>>forwarding more complex, I can see potential backward compatibi= lity
>>>issues with 2 PW solution.
>>>
>>>Regards,
>>>Lucy
>>>
>>>Regards,
>>>
>>>Daniel
>>>
>>>Thumb typed - please be tolerant
>>>
>>>Lucy yong <lucy.yong= @huawei.com> wrote:
>>>
>>>In my mind, the VLAN approach means dual vlan method.
>>>
>>>The main concern for CW approach is hardware support.
>>>
>>>Two PW approach can be complex too if the VPLS instance for E-T= ree uses
>>>P2P PW for unicast traffic and P2MP PW for broadcast and unknow= n unicast
>>>traffic, and some P2MP PWs for multicast traffic. It may double= all of
>>>them.
>>>
>>>E-tree is an Ethernet service and there is already VLAN based s= olution
>>>in IEEE, can we just utilize it without complicating VPLS trans= port
>>>construction? This also makes interworking with Eth only networ= k easier.
>>>
>>>Cheers,
>>>Lucy
>>>
>>>-----Original Message-----
>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com]
>>>Sent: Monday, April 16, 2012 8:35 AM
>>>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com';
>>>'simon.delord@gmail.c= om'; 'Alexander.Vai= nshtein@ecitele.com'
>>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com<= /a>';
>>>'Andrew.Sergeev@e= citele.com'; 'Idan.Kaspit@ec= itele.com';
>>>'Mishael.Wexler@e= citele.com'; 'Rotem.Cohen@ec= itele.com'
>>>Subject: RE: The status of the approaches to the E-Tree solutio= n?
>>>
>>>I believe the initial question was in regard to the CW method. =  Are you
>>>saying that you no longer are interested in that method in pref= erence of
>>>the dual vlan method?
>>>
>>>
>>>
>>>Lucy yong <lucy.yong= @huawei.com> wrote:
>>>
>>>
>>>Agree with Wim. VLAN approach is the best solution for E-Tree.<= br> >>>
>>>Lucy
>>>
>>>-----Original Message-----
>>>From: l2vpn-bounces@i= etf.org [mailto:l2vpn-bounces= @ietf.org] On Behalf
>>>Of Henderickx, Wim (Wim)
>>>Sent: Thursday, April 12, 2012 2:03 AM
>>>To: 'giles.heron@gmail= .com'; 'simon.delord@gmail.co= m';
>>>'Alexander.= Vainshtein@ecitele.com'
>>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com<= /a>';
>>>'Andrew.Sergeev@e= citele.com'; 'Idan.Kaspit@ec= itele.com';
>>>'Mishael.Wexler@e= citele.com'; 'Rotem.Cohen@ec= itele.com'
>>>Subject: Re: The status of the approaches to the E-Tree solutio= n?
>>>
>>>The vlan approach is superior as it also works for eth only net= works,
>>>etc. On top some vendors indicate hw issues with the cw approac= h. As
>>>such we have dropped more or less the cw approach.
>>>
>>>Cheers,
>>>Wim
>>>_________________
>>>sent from blackberry
>>>
>>>----- Original Message -----
>>>From: Giles Heron [mailto:giles.heron@gmail.com]
>>>Sent: Thursday, April 12, 2012 08:22 AM
>>>To: Simon Delord <= simon.delord@gmail.com>; Alexander Vainshtein
>>><Alexand= er.Vainshtein@ecitele.com>
>>>Cc: l2vpn@ietf.org <l2vpn@ietf.org>; Vladimir Kleiner >>><Vladimir.Kl= einer@ecitele.com>; Andrew Sergeev
>>><Andrew.Sergee= v@ecitele.com>; Idan Kaspit <Idan.Kaspit@ecitele.com>;
>>>Mishael Wexler <Mishael.Wexler@ecitele.com>; Rotem Cohen
>>><Rotem.Cohen@ecit= ele.com>
>>>Subject: Re: The status of the approaches to the E-Tree solutio= n?
>>>
>>>Sorry - the "anonymous presentation" was mine.  = I should possibly have
>>>put in a third column on the CW approach.  And hopefully t= he minutes
>>>will be posted soon.
>>>
>>>We had various discussions, as Simon stated, and consensus seem= ed to be
>>>forming around the two alternatives of two PWEs or two VLANs. &= nbsp;I believe
>>>three of the authors of the CW approach are also authors of the= two VLAN
>>>approach and one is also an author of the two PWE approach. So = perhaps
>>>it's best to let those four individuals say which approach they= prefer
>>>and why?
>>>
>>>Giles
>>>
>>>On 10/04/2012 00:45, "Simon Delord" <simon.delord@gmail.com> wrote:
>>>
>>>> Hi Alexander,
>>>>
>>>> You are right, no discussion on the WG mailing list recent= ly, but
>>>> there have been substantial discussions among the authors = of various
>>>> solution drafts off the mailing list. As far as I know, no= consensus
>>>> yet before ietf83, not sure the progress in the Paris WG m= eeting. I
>>>> think the CW approach has not been rejected by the WG yet,= or the WG
>>>> has not yet decided on which one to adopt.
>>>>
>>>> Simon
>>>>
>>>> 2012/4/8 Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
>>>>
>>>>>  Hi all,
>>>>>
>>>>> Unfortunately I have not been able to attend the Paris= IETF.
>>>>>
>>>>> However, looking up the L2VPN proceedings, I've found = a short
>>>>> anonymous presentation called "E-Tree Update"= ;  (
>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx).
>>>>> This presentation discusses the differences of the E-T= ree approaches
>>>>> based on dedicated VLANs (as in
>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>>> ext=3D1) and multiple PWs between the PEs (as in
>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>>> clude_te
>>>>> xt=3D1)
>>>>> and completely ignores the solution based on usage of = the CW in the
>>>>> PWs connecting the PEs (as in
>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>>> ext=3D1
>>>>> ).
>>>>>
>>>>>
>>>>>
>>>>> The Minutes of the Paris L2VPN session are not yet ava= ilable, but I
>>>>> wonder whether the WG has taken a decision to reject t= he approach
>>>>> based on the CW usage? I do not remember any recent di= scussion of
>>>>> this topic on the WG mailing list.
>>>>>
>>>>>
>>>>>
>>>>> Regards, and lots of thanks in advance,
>>>>>
>>>>> Sasha
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This e-mail message is intended for the recipient only= and contains
>>>>> information which is CONFIDENTIAL and which may be pro= prietary to ECI
>>>
>>>>> Telecom. If you have received this transmission in err= or, please
>>>>> inform us by e-mail, phone or fax, and then delete the= original and
>>>>> all copies thereof.
>>>>>
>>>
>>>
>>>
>>>
>>>
>>>This E-mail and any of its attachments may contain Time Warner = Cable
>>>proprietary information, which is privileged, confidential, or = subject
>>>to copyright belonging to Time Warner Cable. This E-mail is int= ended
>>>solely for the use of the individual or entity to which it is a= ddressed.
>>>If you are not the intended recipient of this E-mail, you are h= ereby
>>>notified that any dissemination, distribution, copying, or acti= on taken
>>>in relation to the contents of and attachments to this E-mail i= s
>>>strictly prohibited and may be unlawful. If you have received t= his
>>>E-mail in error, please notify the sender immediately and perma= nently
>>>delete the original and any copy of this E-mail and any printou= t.
>>>
>>
>>
>>This E-mail and any of its attachments may contain Time Warner Cabl= e
>>proprietary information, which is privileged, confidential, or subj= ect to
>>copyright belonging to Time Warner Cable. This E-mail is intended s= olely
>>for the use of the individual or entity to which it is addressed. I= f you
>>are not the intended recipient of this E-mail, you are hereby notif= ied
>>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is stric= tly
>>prohibited and may be unlawful. If you have received this E-mail in=
>>error, please notify the sender immediately and permanently delete = the
>>original and any copy of this E-mail and any printout.
>
>
> This E-mail and any of its attachments may contain Time Warner Cable p= roprietary information, which is privileged, confidential, or subject to co= pyright belonging to Time Warner Cable. This E-mail is intended solely for = the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-= mail, you are hereby notified that any dissemination, distribution, copying= , or action taken in relation to the contents of and attachments to this E-= mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify = the sender immediately and permanently delete the original and any copy of = this E-mail and any printout.
> This e-mail message is intended for the recipient only and contains in= formation which is CONFIDENTIAL and which may be proprietary to ECI Telecom= . If you have received this transmission in error, please inform us by e-ma= il, phone or fax, and then delete the original and all copies thereof.
>
>
>
> ------------------------------
>
> _______________________________________________
> L2vpn mailing list
> L2vpn@ietf.org
> https://www.ie= tf.org/mailman/listinfo/l2vpn
>
>
> End of L2vpn Digest, Vol 95, Issue 25
> ***********************************

--_000_4A6CE49E6084B141B15C0713B8993F28021737SJEXCHMB12corpadb_-- From josh.rogers@twcable.com Fri Apr 20 11:44:08 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3077F21F85C4 for ; Fri, 20 Apr 2012 11:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.005 X-Spam-Level: X-Spam-Status: No, score=0.005 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HS_INDEX_PARAM=0.001, HTML_MESSAGE=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 DzRABiddedjL for ; Fri, 20 Apr 2012 11:44:04 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 41CA521F859F for ; Fri, 20 Apr 2012 11:44:03 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,454,1330923600"; d="scan'208,217";a="353978538" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 20 Apr 2012 14:39:00 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Fri, 20 Apr 2012 14:40:09 -0400 From: "Rogers, Josh" To: Shahram Davari , Lizhong Jin , "l2vpn@ietf.org" , "Alexander.Vainshtein@ecitele.com" Date: Fri, 20 Apr 2012 14:40:09 -0400 Subject: Re: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNW6V0LmvcLTaO7yAMdZqeRCQ== Message-ID: In-Reply-To: <4A6CE49E6084B141B15C0713B8993F28021737@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBB7245EAF1joshrogerstwcablecom_" MIME-Version: 1.0 Cc: "yuqun.cao@gmail.com" X-BeenThere: l2vpn@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, 20 Apr 2012 18:44:08 -0000 --_000_CBB7245EAF1joshrogerstwcablecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a very good question. A common (but not necessarily good) use case= we run into is service multiplexing UNI's where multiple ELAN or ETREE ser= vices are handed off to the customer, and the S-VLAN is 'coordinated' with = the customer. Meaning we expect them to tag traffic for service X with S-t= ag X. I suppose that we would ask the customer to use the 'root' S-Tag at the roo= t site, and the 'leaf' at leaf sites, however this introduces a problem in = my mind, because I believe the 2VLAN method has been working under the mind= set of popping the s-tag off on UNI egress. In this situation where we wan= t to keep the s-tag in tact, we would require the s-tag to be kept on both = ingress at one end and egress at the other. (So things like PVST don't get= upset about being sent with one vlan received w/out it) This means that the customer would be expected to either, 1) send a frame w= ith one VLAN id from one site type, and expect to receive it with another a= t the other site types, and the operator sort of 'maps' between root/leaf s= -tags. Or 2) transmit one vlan on a UNI, and expect return traffic to be t= agged with the other vlan. Neither of which is a good/reasonable option. Is there some other way I ha= ven't considered here? -Josh From: Shahram Davari > To: Lizhong Jin >, "l2vpn@i= etf.org" >, "A= lexander.Vainshtein@ecitele.com" <= Alexander.Vainshtein@ecitele.com> Cc: "yuqun.cao@gmail.com" > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic alrea= dy has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com= Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L i= nformation, customer payload or PW? The customer payload will be always mod= ified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is access= ed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informati= on? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > > To: "Rogers, Josh" >, Lucy yong > >, Daniel Cohn <= DanielC@orckit.com>, Sam Cao > > > Cc: "l2vpn@ietf.org" > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, = but: > > IMO one of the advantages of the CW-based solution is that it is orthogon= al to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffi= c. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and,= in a more generic way, localization of effects of changes in the PE config= uration. > > In particular, adding a Leaf AC to a PE that previously has been only sup= porting Root ACs (or vice versa), removal of the last Leaf or last Root AC = from a PE that previously has been supporting a mix etc. affect only the PE= where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadva= ntage of the CW-based approach - I believe it strongly depends on specific = implementations. And some changes in the forwarding process are required in= any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounce= s@ietf.org] on behalf of Rogers, Josh [josh.= rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a more > complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become more > complex. > > Gile's comparison slide still concisely captures the differences between > these methods, in my opinion. I haven't seen any new ideas or thoughts > brought to the group in the past week or two on the subject. I would hat= e > for both proposed methods to die on the vine because we couldn't decide > between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may double >>all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the processing >>in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >>traffic coming from a root AC) >>[[LY]] Not that simple. You construct either two P2MP PWs to all other >>PEs and let egress PE performing filtering, or construct one P2MP PW to >>leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >>perform forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so don't >>feel terribly strong about this objection. Is this a real problem for >>others (now or in the future), or is this objection in the weeds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. I >>encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>>giles.heron@gmail.com; simon.delord@gmail.= com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com<= mailto:Vladimir.Kleiner@ecitele.com>; >>>Andrew.Sergeev@ecitele.com; Idan.Kasp= it@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Coh= en@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs after >>>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>>P2MP >>>PWs if need. There is no difference between P2MP or normal PW setup. But= , >>>can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>>both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; Alexander.Vainsht= ein@ecitele.com; Sam Cao >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com<= mailto:Vladimir.Kleiner@ecitele.com>; >>>Andrew.Sergeev@ecitele.com; Idan.Kasp= it@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Coh= en@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong [mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; simon.delord@gmail.= com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com<= mailto:Vladimir.Kleiner@ecitele.com>; >>>Andrew.Sergeev@ecitele.com; Idan.Kasp= it@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Coh= en@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, both >>>approaches can benefit from it. I was off for a while and captures some >>>discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues with >>>silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>>not clear on all the issues. Could you be more specific? As I mentioned >>>in below, two PW approach makes VPLS transport construction and packet >>>forwarding more complex, I can see potential backward compatibility >>>issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>>traffic, and some P2MP PWs for multicast traffic. It may double all of >>>them. >>> >>>E-tree is an Ethernet service and there is already VLAN based solution >>>in IEEE, can we just utilize it without complicating VPLS transport >>>construction? This also makes interworking with Eth only network easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vain= shtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.c= om'; >>>'Andrew.Sergeev@ecitele.com'; 'Idan.K= aspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are you >>>saying that you no longer are interested in that method in preference of >>>the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org [mailto:l2vp= n-bounces@ietf.org] On Behalf >>>Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; 'simon.delord= @gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.c= om'; >>>'Andrew.Sergeev@ecitele.com'; 'Idan.K= aspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron [mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord >= ; Alexander Vainshtein >>>> >>>Cc: l2vpn@ietf.org >; Vladimir Kleiner >>>>; And= rew Sergeev >>>>; Idan Ka= spit >; >>>Mishael Wexler >; Rotem Cohen >>>> >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly have >>>put in a third column on the CW approach. And hopefully the minutes >>>will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to be >>>forming around the two alternatives of two PWEs or two VLANs. I believe >>>three of the authors of the CW approach are also authors of the two VLAN >>>approach and one is also an author of the two PWE approach. So perhaps >>>it's best to let those four individuals say which approach they prefer >>>and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of various >>>> solution drafts off the mailing list. As far as I know, no consensus >>>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>>> think the CW approach has not been rejected by the WG yet, or the WG >>>> has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein > >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree approaches >>>>> based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in the >>>>> PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>>> wonder whether the WG has taken a decision to reject the approach >>>>> based on the CW usage? I do not remember any recent discussion of >>>>> this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and contains >>>>> information which is CONFIDENTIAL and which may be proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original and >>>>> all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action taken >>>in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use of the individual or entity to which it is addressed. If you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** --_000_CBB7245EAF1joshrogerstwcablecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This is a very good ques= tion.  A common (but not necessarily good) use case we run into is ser= vice multiplexing UNI's where multiple ELAN or ETREE services are handed of= f to the customer, and the S-VLAN is 'coordinated' with the customer.  = ;Meaning we expect them to tag traffic for service X with S-tag X. 

I suppose that we would ask the customer to use the = 'root' S-Tag at the root site, and the 'leaf' at leaf sites, however this i= ntroduces a problem in my mind, because I believe the 2VLAN method has been= working under the mindset of popping the s-tag off on UNI egress.  In= this situation where we want to keep the s-tag in tact, we would require t= he s-tag to be kept on both ingress at one end and egress at the other. &nb= sp;(So things like PVST don't get upset about being sent with one vlan rece= ived w/out it)

This means that the customer would = be expected to either, 1) send a frame with one VLAN id from one site type,= and expect to receive it with another at the other site types, and the ope= rator sort of 'maps' between root/leaf s-tags.  Or 2) transmit one vla= n on a UNI, and expect return traffic to be tagged with the other vlan.

Neither of which is a good/reasonable option.  I= s there some other way I haven't considered here?

= -Josh


=
From: Shahram Davari <davari@broadcom.com>
To: Lizhong Jin <lizho.jin@gmail.co= m>, "l2vpn@ietf.org" <l2vpn@ietf.org>, "Alexander.Vainshtein@ecitele.com" <Alexander.Vainshtein@ecit= ele.com>
Cc: "yuqun.cao@gmail.com" <yuqun.cao@gmail.com>
Subject: RE: The status of the approaches to the E-Tree = solution?

Hi,

 

I also h= ave a question regarding 2-VLAN. What if the customer traffic already has a= n S-VLAN? Do we need a 3rd VLAN to identify the L/R?<= /span>

 =

Thx

Shahram

 

From: l2vpn-bounc= es@ietf.org [mailto:l2vpn-bou= nces@ietf.org] On Behalf Of Lizhong Jin
Sent: Friday, April 20, 2012 9:38= AM
To: l2vpn@ietf.org; Alexander.Vainshtein@ecite= le.com
Cc: yuqun.cao@g= mail.com
Subject: RE: The status of the approaches to the E-T= ree solution?

 =

Hi, all,
The difference between 2-VLAN and CW approach is who will provide the R/L i= nformation, customer payload or PW? The customer payload will be always mod= ified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach.
I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is access= ed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informati= on?

Thanks
Lizhong

> ------------------------------
>
> Message: 2
> Date: Thu, 19 Apr 2012 04:38:36 +0000
> From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
> To: "Rogers, Josh" <josh= .rogers@twcable.com>, Lucy yong
>        <lucy.yong@huawei.com>, Daniel Cohn <DanielC@orckit.com>, Sam Cao
>        <= yuqun.cao@gmail.com>
> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
> Subject: RE: The status of the approaches to the E-Tree solution?
> Message-ID:
>        <F9336571731ADE42A5397FC831CEAA0= 2034192@FRIDWPPMB002.ecitele.com>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> Hi all,
> I fully understand that that what I am going to say is not very popula= r, but:
>
> IMO one of the advantages of the CW-based solution is that it is ortho= gonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN tra= ffic.
>
> Another advantage is preservation of full mesh of P2P PWs in a VPLS, a= nd, in a more generic way, localization of effects of changes in the PE con= figuration.
>
> In particular, adding a Leaf AC to a PE that previously has been only = supporting Root ACs (or vice versa), removal of the last Leaf or last Root = AC from a PE that previously has been supporting a mix etc. affect only the= PE where this operation happens and not the rest of the PEs.
>
> As for the need for HW changes that have been mentioned as a main disa= dvantage of the CW-based approach - I believe it strongly depends on specif= ic implementations. And some changes in the forwarding process are required= in any solution.
>
> My 2c,
>     Sasha
>
>
>
> ________________________________________
> From: l2vpn-bounces@ietf.org= [l2vpn-bounces@ietf.org]= on behalf of Rogers, Josh [josh= .rogers@twcable.com]
> Sent: Wednesday, April 18, 2012 9:57 PM
> To: Lucy yong; Daniel Cohn; Sam Cao
> Cc: l2vpn@ietf.org
> Subject: Re: The status of the approaches to the E-Tree solution?
>
> Again, the P2MP situation throws me.  Is this something that is u= sed
> commonly?
>
> I'm under the impression that adding P2MP to any model results in a mo= re
> complex model.  Wether outside s-tag is used to differentiate, or=
> dedicated pw's are used for the same purpose, it seems both become mor= e
> complex.
>
> Gile's comparison slide still concisely captures the differences betwe= en
> these methods, in my opinion.  I haven't seen any new ideas or th= oughts
> brought to the group in the past week or two on the subject.  I w= ould hate
> for both proposed methods to die on the vine because we couldn't decid= e
> between two methods that have nothing inherently wrong with either. >
> -Josh
>
>
> On 4/18/12 1:53 PM, "Lucy yong" <lucy.yong@huawei.com> wrote:
>
>>Send this again.
>>
>>Two PW approach can be complex too if the VPLS instance for E-Tree = uses
>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may do= uble
>>all of them.
>>
>>Lucy
>>
>>-----Original Message-----
>>From: Daniel Cohn [mailto:Dan= ielC@orckit.com]
>>Sent: Wednesday, April 18, 2012 1:42 PM
>>To: Lucy yong; Rogers, Josh; Sam Cao
>>Cc: l2vpn@ietf.org
>>Subject: RE: The status of the approaches to the E-Tree solution? >>
>>I think the first option its the natural way to go. How is the proc= essing
>>in this case more complex?
>>
>>Thumb typed - please be tolerant
>>
>>Lucy yong <lucy.yong@hua= wei.com> wrote:
>>
>>
>>
>>Snipped..
>>
>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P= 2MP PW
>>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (f= or
>>traffic coming from a root AC)
>>[[LY]] Not that simple. You construct either two P2MP PWs to all ot= her
>>PEs and let egress PE performing filtering, or construct one P2MP P= W to
>>leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress= PE
>>perform forwarding and filtering. Both make node process complex. >>
>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW f= or
>>delivering the frames to remote PEs. We should utilize them with th= e
>>minimized changes. Dual VLAN solution is simpler than Dual PW.
>>
>>Regards,
>>Lucy
>>
>>
>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. &n= bsp;I
>>haven't had any first hand experience with P2MP PW's, however, so d= on't
>>feel terribly strong about this objection.  Is this a real pro= blem for
>>others (now or in the future), or is this objection in the weeds? >>
>>I'm not sure the 'additional complexity' is notable, or even releva= nt.  I
>>encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for = it.
>>
>>Thanks,
>>Josh
>>
>>
>>
>>On 4/18/12 10:30 AM, "Lucy yong" <lucy.yong@huawei.com> wrote:
>>
>>>Please see inline.
>>>
>>>-----Original Message-----
>>>From: Sam Cao [mailto:yu= qun.cao@gmail.com]
>>>Sent: Tuesday, April 17, 2012 7:14 AM
>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim = (Wim)';
>>>giles.heron@gmail.com<= /a>; simon.delord@gmail.com;
>>>Alexander.V= ainshtein@ecitele.com
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com;
>>>Andrew.Sergeev@ec= itele.com; Idan.Kaspit@ecitele.com;
>>>Mishael.Wexler@ec= itele.com; Rotem.Cohen@ecitele.com
>>>Subject: RE: The status of the approaches to the E-Tree solutio= n?
>>>
>>>Yes, 2 pws are only needed between pes with both root and leaf = acs after
>>>improving Dual-PW approach. If consider P2MP, Dual-PW approach = setup 2
>>>P2MP
>>>PWs if need. There is no difference between P2MP or normal PW s= etup. But,
>>>can Leaf-ACs be bound to Root PE of P2MP PW?
>>>
>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE = with both
>>>root and leaf ACs set up two or one P2MP PW to other PEs (some = PE have
>>>both root and leaf AC and some only have leaf ACs)?
>>>Regards,
>>>Lucy
>>>
>>>Regards,
>>>
>>>Yuqun (Sam) Cao
>>>E-mail: Yuqun.cao@gmail.= com
>>>
>>>
>>>-----Original Message-----
>>>From: Daniel Cohn [mailto:DanielC@orckit.com]
>>>Sent: Tuesday, April 17, 2012 4:56 PM
>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim);
>>>giles.heron@gmail.com<= /a>;
>>>simon.delord@gmail.co= m; Alexander.Vainshtein@ecitele.com; Sam Cao
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com;
>>>Andrew.Sergeev@ec= itele.com; Idan.Kaspit@ecitele.com;
>>>Mishael.Wexler@ec= itele.com; Rotem.Cohen@ecitele.com
>>>Subject: RE: The status of the approaches to the E-Tree solutio= n?
>>>
>>>Adding Sam (as l2vpn@ is holding messages)
>>>
>>>DC
>>>
>>>-----Original Message-----
>>>From: Lucy yong [mailto:lucy.yong@huawei.com]
>>>Sent: Tuesday, April 17, 2012 12:39 AM
>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim);
>>>giles.heron@gmail.com<= /a>; simon.delord@gmail.com;
>>>Alexander.V= ainshtein@ecitele.com
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com;
>>>Andrew.Sergeev@ec= itele.com; Idan.Kaspit@ecitele.com;
>>>Mishael.Wexler@ec= itele.com; Rotem.Cohen@ecitele.com
>>>Subject: RE: The status of the approaches to the E-Tree solutio= n?
>>>
>>>
>>>Snipped,
>>>
>>>As we discussed extensively in the list, and as reflected in gi= les
>>>slide, 2 pws are only needed between pes with both root and lea= f acs,
>>>which will typically be a small minority.
>>>[[LY]] Don't know if the assumption is true. Even it is the cas= e, both
>>>approaches can benefit from it. I was off for a while and captu= res some
>>>discussions now.
>>>
>>>Also as per giles slide, dual vlan can have scalability issues = due to
>>>additional lookup and double use of vlans in internal emulated = lan
>>>interface. Also there are potential backward compatibility issu= es with
>>>silicon that doesn't support vlan mapping.
>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minu= tes. I am
>>>not clear on all the issues. Could you be more specific? As I m= entioned
>>>in below, two PW approach makes VPLS transport construction and= packet
>>>forwarding more complex, I can see potential backward compatibi= lity
>>>issues with 2 PW solution.
>>>
>>>Regards,
>>>Lucy
>>>
>>>Regards,
>>>
>>>Daniel
>>>
>>>Thumb typed - please be tolerant
>>>
>>>Lucy yong <lucy.yong= @huawei.com> wrote:
>>>
>>>In my mind, the VLAN approach means dual vlan method.
>>>
>>>The main concern for CW approach is hardware support.
>>>
>>>Two PW approach can be complex too if the VPLS instance for E-T= ree uses
>>>P2P PW for unicast traffic and P2MP PW for broadcast and unknow= n unicast
>>>traffic, and some P2MP PWs for multicast traffic. It may double= all of
>>>them.
>>>
>>>E-tree is an Ethernet service and there is already VLAN based s= olution
>>>in IEEE, can we just utilize it without complicating VPLS trans= port
>>>construction? This also makes interworking with Eth only networ= k easier.
>>>
>>>Cheers,
>>>Lucy
>>>
>>>-----Original Message-----
>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com]
>>>Sent: Monday, April 16, 2012 8:35 AM
>>>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com';
>>>'simon.delord@gmail.c= om'; 'Alexander.Vai= nshtein@ecitele.com'
>>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com<= /a>';
>>>'Andrew.Sergeev@e= citele.com'; 'Idan.Kaspit@ec= itele.com';
>>>'Mishael.Wexler@e= citele.com'; 'Rotem.Cohen@ec= itele.com'
>>>Subject: RE: The status of the approaches to the E-Tree solutio= n?
>>>
>>>I believe the initial question was in regard to the CW method. =  Are you
>>>saying that you no longer are interested in that method in pref= erence of
>>>the dual vlan method?
>>>
>>>
>>>
>>>Lucy yong <lucy.yong= @huawei.com> wrote:
>>>
>>>
>>>Agree with Wim. VLAN approach is the best solution for E-Tree.<= br> >>>
>>>Lucy
>>>
>>>-----Original Message-----
>>>From: l2vpn-bounces@i= etf.org [mailto:l2vpn-bounces= @ietf.org] On Behalf
>>>Of Henderickx, Wim (Wim)
>>>Sent: Thursday, April 12, 2012 2:03 AM
>>>To: 'giles.heron@gmail= .com'; 'simon.delord@gmail.co= m';
>>>'Alexander.= Vainshtein@ecitele.com'
>>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com<= /a>';
>>>'Andrew.Sergeev@e= citele.com'; 'Idan.Kaspit@ec= itele.com';
>>>'Mishael.Wexler@e= citele.com'; 'Rotem.Cohen@ec= itele.com'
>>>Subject: Re: The status of the approaches to the E-Tree solutio= n?
>>>
>>>The vlan approach is superior as it also works for eth only net= works,
>>>etc. On top some vendors indicate hw issues with the cw approac= h. As
>>>such we have dropped more or less the cw approach.
>>>
>>>Cheers,
>>>Wim
>>>_________________
>>>sent from blackberry
>>>
>>>----- Original Message -----
>>>From: Giles Heron [mailto:giles.heron@gmail.com]
>>>Sent: Thursday, April 12, 2012 08:22 AM
>>>To: Simon Delord <= simon.delord@gmail.com>; Alexander Vainshtein
>>><Alexand= er.Vainshtein@ecitele.com>
>>>Cc: l2vpn@ietf.org <l2vpn@ietf.org>; Vladimir Kleiner >>><Vladimir.Kl= einer@ecitele.com>; Andrew Sergeev
>>><Andrew.Sergee= v@ecitele.com>; Idan Kaspit <Idan.Kaspit@ecitele.com>;
>>>Mishael Wexler <Mishael.Wexler@ecitele.com>; Rotem Cohen
>>><Rotem.Cohen@ecit= ele.com>
>>>Subject: Re: The status of the approaches to the E-Tree solutio= n?
>>>
>>>Sorry - the "anonymous presentation" was mine.  I should p= ossibly have
>>>put in a third column on the CW approach.  And hopefully t= he minutes
>>>will be posted soon.
>>>
>>>We had various discussions, as Simon stated, and consensus seem= ed to be
>>>forming around the two alternatives of two PWEs or two VLANs. &= nbsp;I believe
>>>three of the authors of the CW approach are also authors of the= two VLAN
>>>approach and one is also an author of the two PWE approach. So = perhaps
>>>it's best to let those four individuals say which approach they= prefer
>>>and why?
>>>
>>>Giles
>>>
>>>On 10/04/2012 00:45, "Simon Delord" <simon.delord@gmail.com> wrote:
>>>
>>>> Hi Alexander,
>>>>
>>>> You are right, no discussion on the WG mailing list recent= ly, but
>>>> there have been substantial discussions among the authors = of various
>>>> solution drafts off the mailing list. As far as I know, no= consensus
>>>> yet before ietf83, not sure the progress in the Paris WG m= eeting. I
>>>> think the CW approach has not been rejected by the WG yet,= or the WG
>>>> has not yet decided on which one to adopt.
>>>>
>>>> Simon
>>>>
>>>> 2012/4/8 Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
>>>>
>>>>>  Hi all,
>>>>>
>>>>> Unfortunately I have not been able to attend the Paris= IETF.
>>>>>
>>>>> However, looking up the L2VPN proceedings, I've found = a short
>>>>> anonymous presentation called "E-Tree Update"  (<= br> >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx).
>>>>> This presentation discusses the differences of the E-T= ree approaches
>>>>> based on dedicated VLANs (as in
>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>>> ext=3D1) and multiple PWs between the PEs (as in
>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>>> clude_te
>>>>> xt=3D1)
>>>>> and completely ignores the solution based on usage of = the CW in the
>>>>> PWs connecting the PEs (as in
>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>>> ext=3D1
>>>>> ).
>>>>>
>>>>>
>>>>>
>>>>> The Minutes of the Paris L2VPN session are not yet ava= ilable, but I
>>>>> wonder whether the WG has taken a decision to reject t= he approach
>>>>> based on the CW usage? I do not remember any recent di= scussion of
>>>>> this topic on the WG mailing list.
>>>>>
>>>>>
>>>>>
>>>>> Regards, and lots of thanks in advance,
>>>>>
>>>>> Sasha
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This e-mail message is intended for the recipient only= and contains
>>>>> information which is CONFIDENTIAL and which may be pro= prietary to ECI
>>>
>>>>> Telecom. If you have received this transmission in err= or, please
>>>>> inform us by e-mail, phone or fax, and then delete the= original and
>>>>> all copies thereof.
>>>>>
>>>
>>>
>>>
>>>
>>>
>>>This E-mail and any of its attachments may contain Time Warner = Cable
>>>proprietary information, which is privileged, confidential, or = subject
>>>to copyright belonging to Time Warner Cable. This E-mail is int= ended
>>>solely for the use of the individual or entity to which it is a= ddressed.
>>>If you are not the intended recipient of this E-mail, you are h= ereby
>>>notified that any dissemination, distribution, copying, or acti= on taken
>>>in relation to the contents of and attachments to this E-mail i= s
>>>strictly prohibited and may be unlawful. If you have received t= his
>>>E-mail in error, please notify the sender immediately and perma= nently
>>>delete the original and any copy of this E-mail and any printou= t.
>>>
>>
>>
>>This E-mail and any of its attachments may contain Time Warner Cabl= e
>>proprietary information, which is privileged, confidential, or subj= ect to
>>copyright belonging to Time Warner Cable. This E-mail is intended s= olely
>>for the use of the individual or entity to which it is addressed. I= f you
>>are not the intended recipient of this E-mail, you are hereby notif= ied
>>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is stric= tly
>>prohibited and may be unlawful. If you have received this E-mail in=
>>error, please notify the sender immediately and permanently delete = the
>>original and any copy of this E-mail and any printout.
>
>
> This E-mail and any of its attachments may contain Time Warner Cable p= roprietary information, which is privileged, confidential, or subject to co= pyright belonging to Time Warner Cable. This E-mail is intended solely for = the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-= mail, you are hereby notified that any dissemination, distribution, copying= , or action taken in relation to the contents of and attachments to this E-= mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify = the sender immediately and permanently delete the original and any copy of = this E-mail and any printout.
> This e-mail message is intended for the recipient only and contains in= formation which is CONFIDENTIAL and which may be proprietary to ECI Telecom= . If you have received this transmission in error, please inform us by e-ma= il, phone or fax, and then delete the original and all copies thereof.
>
>
>
> ------------------------------
>
> _______________________________________________
> L2vpn mailing list
> L2vpn@ietf.org
> https://www.ie= tf.org/mailman/listinfo/l2vpn
>
>
> End of L2vpn Digest, Vol 95, Issue 25
> ***********************************

<= /span> --_000_CBB7245EAF1joshrogerstwcablecom_-- From lizho.jin@gmail.com Fri Apr 20 20:59:16 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0B511E809D for ; Fri, 20 Apr 2012 20:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 j2chcuTa4TPp for ; Fri, 20 Apr 2012 20:59:15 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8D85A11E8096 for ; Fri, 20 Apr 2012 20:59:15 -0700 (PDT) Received: by iazz13 with SMTP id z13so17320136iaz.31 for ; Fri, 20 Apr 2012 20:59:15 -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=JYmma2rUhU/pZkV74hM0EU3msjCbbsdb+Y9FPGRmDDI=; b=P9qUpfqlE0nFJUsjM3W6otVovXojKuS7Va0idIidWLvjyibtuLJR/M8p0XpTUTdxOo RTY7x0WkJH54wBLMhBjSLGgm2cpbXILoTVGY0tGCdeCQAh5DkcubqxJv6YaPrcdnKulZ budZqcimJHd302FQJyg/GaQhnx1BiL83BuK4GdKBGVKPVqW6KityqSmJkJDorI+g8FhA YJIBfbVEstae7933ccyn/iO+Vg4UaW6D/aRhlDFAIIW4GrHTNv+3JoriKHPOkaL3xO9B XzJRKuYiV6thmK/n79KR8EYoYyLn33ZU97EW6/O0OMuDgw0/2HdwW2ZSySfYvPtn/bgH T7yQ== MIME-Version: 1.0 Received: by 10.50.169.3 with SMTP id aa3mr854544igc.28.1334980755046; Fri, 20 Apr 2012 20:59:15 -0700 (PDT) Received: by 10.50.8.100 with HTTP; Fri, 20 Apr 2012 20:59:14 -0700 (PDT) In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6701296244C3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <14C7F4F06DB5814AB0DE29716C4F6D6701296244C3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Date: Sat, 21 Apr 2012 11:59:14 +0800 Message-ID: Subject: RE: The status of the approaches to the E-Tree solution? From: Lizhong Jin To: "Henderickx, Wim (Wim)" Content-Type: multipart/alternative; boundary=e89a8f234361afc29004be286de3 Cc: "l2vpn@ietf.org" , "yuqun.cao@gmail.com" X-BeenThere: l2vpn@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: Sat, 21 Apr 2012 03:59:17 -0000 --e89a8f234361afc29004be286de3 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Win, Thank you for the answers. In that case, PE-rs should configure the root/leaf properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, you could not figure out the accessing spoke PW is from PE-r of VPWS or MTU-s. Unless having some additional indication in NMS, you even don't know which spoke PW needs to do VLAN manipulation. I am not sure such R/L configuration could be accepted from operational view. Hope to see more comments. Regards Lizhong =D4=DA 2012=C4=EA4=D4=C221=C8=D5=D0=C7=C6=DA=C1=F9=A3=ACHenderickx, Wim (Wi= m) =D0=B4=B5=C0=A3=BA > The VPWS which terminates at the H-VPLS node is indicated to be root or leaf and the procedures associated will do the VLAN manipulation > > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin > Sent: vrijdag 20 april 2012 18:38 > To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com > Cc: yuqun.cao@gmail.com > Subject: RE: The status of the approaches to the E-Tree solution? > > > > Hi, all, > The difference between 2-VLAN and CW approach is who will provide the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW will carry R/L information for CW approach. > I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information? > > Thanks > Lizhong > >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 Apr 2012 04:38:36 +0000 >> From: Alexander Vainshtein >> To: "Rogers, Josh" , Lucy yong >> , Daniel Cohn , Sam Cao >> >> Cc: "l2vpn@ietf.org" >> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID: >> >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi all, >> I fully understand that that what I am going to say is not very popular, but: >> >> IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes in the PE configuration. >> >> In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root AC from a PE that previously has been supporting a mix etc. affect only the PE where this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a more >> complex model. Wether outside s-tag is used to differentiate, or >> dedicated pw's are used for the same purpose, it seems both become more >> complex. >> >> Gile's comparison slide still concisely captures the differences between >> these methods, in my opinion. I haven't seen any new ideas or thoughts >> brought to the group in the past week or two on the subject. I would hate >> for both proposed methods to die on the vine because we couldn't decide >> between two methods that have nothing inherently wrong with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" wrote: >> >>>Send this again. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>P2P PW fo --e89a8f234361afc29004be286de3 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Win,
Thank you for the answers. In that case, PE-rs should configure = the root/leaf properties of VPWS, not on the remote PE of VPWS. And usually= on PE-rs, you could not figure out the accessing spoke PW is from PE-r of = VPWS or MTU-s. Unless having some additional indication in NMS, you even do= n't know which spoke PW needs to do VLAN manipulation. I am not sure su= ch R/L configuration could be accepted from operational view. Hope to see m= ore comments.

Regards
Lizhong


=D4=DA 2012=C4=EA4=D4=C221=C8=D5=D0=C7=C6= =DA=C1=F9=A3=ACHenderickx, Wim (Wim) <wim.henderickx@alcatel-lucent.com> =D0=B4=B5=C0= =A3=BA
> The VPWS which terminates at the H-VPLS node is indicated to= be root or leaf and the procedures associated will do the VLAN manipulatio= n
>
>  
>
> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin
> Sen= t: vrijdag 20 april 2012 18:38
> To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com
> Cc: yuqun.cao@gmail.com
> Subject: RE: The status of the approaches to the E-Tree solution?
&= gt;
>  
>
> Hi, all,
> The difference between = 2-VLAN and CW approach is who will provide the R/L information, customer pa= yload or PW? The customer payload will be always modified to carry R/L info= rmation in 2-VLAN approach, while PW with CW will carry R/L information for= CW approach.
> I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is a= ccessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to = access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L info= rmation?
>
> Thanks
> Lizhong
>
>> -------------------= -----------
>>
>> Message: 2
>> Date: Thu, 19 Ap= r 2012 04:38:36 +0000
>> From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<= /a>>
>> To: "Rogers, Josh" <josh.rogers@twcable.com>, Lucy yong
>>   &nb= sp;    <lucy.yong@huaw= ei.com>, Daniel Cohn <Danie= lC@orckit.com>, Sam Cao
>>        <yuqun.cao@gmail.com>
>> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
>> Subject: RE: The status of the approaches to the E-Tree solution?<= br>>> Message-ID:
>>        <F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com> >> Content-Type: text/plain; charset=3D"us-ascii"
>&g= t;
>> Hi all,
>> I fully understand that that what I am g= oing to say is not very popular, but:
>>
>> IMO one of th= e advantages of the CW-based solution is that it is orthogonal to usage (or= non-usage) of P2MP PWs for effective delivery of BUN traffic.
>>
>> Another advantage is preservation of full mesh of P2P = PWs in a VPLS, and, in a more generic way, localization of effects of chang= es in the PE configuration.
>>
>> In particular, adding a= Leaf AC to a PE that previously has been only supporting Root ACs (or vice= versa), removal of the last Leaf or last Root AC from a PE that previously= has been supporting a mix etc. affect only the PE where this operation hap= pens and not the rest of the PEs.
>>
>> As for the need for HW changes that have been mentione= d as a main disadvantage of the CW-based approach - I believe it strongly d= epends on specific implementations. And some changes in the forwarding proc= ess are required in any solution.
>>
>> My 2c,
>>     Sasha
>>
= >>
>>
>> ________________________________________>> From: l2vpn-bounces@ie= tf.org [l2vpn-bounces@ietf.or= g] on behalf of Rogers, Josh [josh.rogers@twcable.com]
>> Sent: Wednesday, April 18, 2012 9:57 PM
>> To: Lucy yong;= Daniel Cohn; Sam Cao
>> Cc: l2v= pn@ietf.org
>> Subject: Re: The status of the approaches to th= e E-Tree solution?
>>
>> Again, the P2MP situation throws me.  Is this som= ething that is used
>> commonly?
>>
>> I'm u= nder the impression that adding P2MP to any model results in a more
>= > complex model.  Wether outside s-tag is used to differentiate, or=
>> dedicated pw's are used for the same purpose, it seems both be= come more
>> complex.
>>
>> Gile's compariso= n slide still concisely captures the differences between
>> these = methods, in my opinion.  I haven't seen any new ideas or thoughts<= br> >> brought to the group in the past week or two on the subject.  = ;I would hate
>> for both proposed methods to die on the vine beca= use we couldn't decide
>> between two methods that have nothin= g inherently wrong with either.
>>
>> -Josh
>>
>>
>> On 4/18/12 1= :53 PM, "Lucy yong" <l= ucy.yong@huawei.com> wrote:
>>
>>>Send this aga= in.
>>>
>>>Two PW approach can be complex too if the VPLS = instance for E-Tree uses
>>>P2P PW fo --e89a8f234361afc29004be286de3-- From wim.henderickx@alcatel-lucent.com Fri Apr 20 23:52:20 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DDF21F853C for ; Fri, 20 Apr 2012 23:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 8nw9bU6An75v for ; Fri, 20 Apr 2012 23:52:19 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC5E21F8542 for ; Fri, 20 Apr 2012 23:52:18 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3L6qCsb003100 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 21 Apr 2012 08:52:12 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sat, 21 Apr 2012 08:52:12 +0200 From: "Henderickx, Wim (Wim)" To: Lizhong Jin Date: Sat, 21 Apr 2012 08:52:08 +0200 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fcyBh28eQDlWXSDa8TXm+ZLxsgQAF7dQw Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6701296244EF@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <14C7F4F06DB5814AB0DE29716C4F6D6701296244C3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: multipart/alternative; boundary="_000_14C7F4F06DB5814AB0DE29716C4F6D6701296244EFFRMRSSXCHMBSB_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "l2vpn@ietf.org" , "yuqun.cao@gmail.com" X-BeenThere: l2vpn@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: Sat, 21 Apr 2012 06:52:20 -0000 --_000_14C7F4F06DB5814AB0DE29716C4F6D6701296244EFFRMRSSXCHMBSB_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Lizhong, You can also signal if the VPWS is root or leaf through a signalin= g protocol, but you need to configure something on the remote end or PE-rs,= so from an operational point of view something needs to be configured irre= spective where you do it. From: Lizhong Jin [mailto:lizho.jin@gmail.com] Sent: zaterdag 21 april 2012 5:59 To: Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi Win, Thank you for the answers. In that case, PE-rs should configure the root/le= af properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, = you could not figure out the accessing spoke PW is from PE-r of VPWS or MTU= -s. Unless having some additional indication in NMS, you even don't know wh= ich spoke PW needs to do VLAN manipulation. I am not sure such R/L configur= ation could be accepted from operational view. Hope to see more comments. Regards Lizhong =1B$B:_=1B(B 2012=1B$BG/=1B(B4=1B$B7n=1B(B21=1B$BF|@14|O;!$=1B(BHenderickx,= Wim (Wim) > =1B$B The VPWS which terminates at the H-VPLS node is indicated to be root or l= eaf and the procedures associated will do the VLAN manipulation > > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn= -bounces@ietf.org] On Behalf Of Lizhong Jin > Sent: vrijdag 20 april 2012 18:38 > To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.c= om > Cc: yuqun.cao@gmail.com > Subject: RE: The status of the approaches to the E-Tree solution? > > > > Hi, all, > The difference between 2-VLAN and CW approach is who will provide the R/L= information, customer payload or PW? The customer payload will be always m= odified to carry R/L information in 2-VLAN approach, while PW with CW will = carry R/L information for CW approach. > I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is acce= ssed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acc= ess H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informa= tion? > > Thanks > Lizhong > >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 Apr 2012 04:38:36 +0000 >> From: Alexander Vainshtein > >> To: "Rogers, Josh" >, Lucy yong >> >, Daniel Cohn = >, Sam Cao >> > >> Cc: "l2vpn@ietf.org" > >> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID: >> > >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi all, >> I fully understand that that what I am going to say is not very popular,= but: >> >> IMO one of the advantages of the CW-based solution is that it is orthogo= nal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traff= ic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, and= , in a more generic way, localization of effects of changes in the PE confi= guration. >> >> In particular, adding a Leaf AC to a PE that previously has been only su= pporting Root ACs (or vice versa), removal of the last Leaf or last Root AC= from a PE that previously has been supporting a mix etc. affect only the P= E where this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main disadv= antage of the CW-based approach - I believe it strongly depends on specific= implementations. And some changes in the forwarding process are required i= n any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounc= es@ietf.org] on behalf of Rogers, Josh [josh= .rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a more >> complex model. Wether outside s-tag is used to differentiate, or >> dedicated pw's are used for the same purpose, it seems both become more >> complex. >> >> Gile's comparison slide still concisely captures the differences between >> these methods, in my opinion. I haven't seen any new ideas or thoughts >> brought to the group in the past week or two on the subject. I would ha= te >> for both proposed methods to die on the vine because we couldn't decide >> between two methods that have nothing inherently wrong with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" > wrote: >> >>>Send this again. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>P2P PW fo --_000_14C7F4F06DB5814AB0DE29716C4F6D6701296244EFFRMRSSXCHMBSB_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Lizhong, = You can also signal if the VPWS is root or leaf through a signaling protoco= l, but you need to configure something on the remote end or PE-rs, so from = an operational point of view something needs to be configured irrespective = where you do it.

&nbs= p;

From: Lizhong Jin [mailto:li= zho.jin@gmail.com]
Sent: zaterdag 21 april 2012 5:59
To: Henderickx, Wim (Wim)
Cc: l2vpn@ietf.org; Alexander.Vainshtein= @ecitele.com; yuqun.cao@gmail.com
Subject: RE: The status of the = approaches to the E-Tree solution?

 

Hi Win,
Thank you for = the answers. In that case, PE-rs should configure the root/leaf properties = of VPWS, not on the remote PE of VPWS. And usually on PE-rs, you could not = figure out the accessing spoke PW is from PE-r of VPWS or MTU-s. Unless hav= ing some additional indication in NMS, you even don't know which spoke PW n= eeds to do VLAN manipulation. I am not sure such R/L configuration could be= accepted from operational view. Hope to see more comments.

Regards<= br>Lizhong


=1B$B:_=1B(J 2012=1B$BG/=1B(J4=1B$B7n=1B(J21=1B$BF|@14|O;!$=1B(JHenderickx, Wim (Wim) <wim.henderickx@alcatel-lucent= .com> =1B$B
> The VPWS wh= ich terminates at the H-VPLS node is indicated to be root or leaf and the p= rocedures associated will do the VLAN manipulation
>
>  
>
> Fr= om: l2vpn-bounces@ietf.org [m= ailto:l2vpn-bounces@ietf.org]= On Behalf Of Lizhong Jin
> Sent: vrijdag 20 april 2012 18:38
>= To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com> Cc: yuqun.cao@gmail.com> Subject: RE: The status of the approaches to the E-Tree solution?
= >
>  
>
> Hi, all,
> The difference between 2-VLAN and CW ap= proach is who will provide the R/L information, customer payload or PW? The= customer payload will be always modified to carry R/L information in 2-VLA= N approach, while PW with CW will carry R/L information for CW approach.> I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is = accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to= access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L inf= ormation?
>
> Thanks
> Lizhong
>
>> ------= ------------------------
>>
>> Message: 2
>> Dat= e: Thu, 19 Apr 2012 04:38:36 +0000
>> From: Alexander Vainshtein &= lt;Alexander.Vainshtein= @ecitele.com>
>> To: "Rogers, Josh" <josh.rogers@twcable.com>, Lucy y= ong
>>   <=1B(Jspan style=3D'font-family:"Calibri","sans-serif"'> =    <lucy.yong@huawei.com>, Daniel Cohn <DanielC@orckit.com>, Sam Cao
>= ;>        <yuqun.cao@gmail.com>
>> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
>> Subject: RE: The status of the appr= oaches to the E-Tree solution?
>> Message-ID:
>>        <F9336571731ADE42A5397FC831CEAA0203419= 2@FRIDWPPMB002.ecitele.com>
>> Content-Type: text/plain; ch= arset=3D"us-ascii"
>>
>> Hi all,
>> I = fully understand that that what I am going to say is not very popular, but:=
>>
>> IMO one of the advantages of the CW-based solution= is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective= delivery of BUN traffic.
>>
>> Another advantage is pres= ervation of full mesh of P2P PWs in a VPLS, and, in a more generic way, loc= alization of effects of changes in the PE configuration.
>>
>= ;> In particular, adding a Leaf AC to a PE that previously has been only= supporting Root ACs (or vice versa), removal of the last Leaf or last Root= AC from a PE that previously has been supporting a mix etc. affect only th= e PE where this operation happens and not the rest of the PEs.
>><= br>>> As for the need for HW changes that have been mentioned as a ma= in disadvantage of the CW-based approach - I believe it strongly depends on= specific implementations. And some changes in the forwarding process are r= equired in any solution.
>>
>> My 2c,
>>     Sasha
>>
>&g= t;
>>
>> ________________________________________
>= > From: l2vpn-bounces@ietf.org= [l2vpn-bounces@ietf.org]= on behalf of Rogers, Josh [josh= .rogers@twcable.com]
>> Sent: Wednesday, April 18, 2012 9:57 P= M
>> To: Lucy yong; Daniel Cohn; Sam Cao
>> Cc: l2vpn@ietf.org
>> Subject: Re: The = status of the approaches to the E-Tree solution?
>>
>> Ag= ain, the P2MP situation throws me.  Is this something that is used
>> commonly= ?
>>
>> I'm under the impression that adding P2MP to any = model results in a more
>> complex model.  Wether outside s-tag is used to dif= ferentiate, or
>> dedicated pw's are used for the same purpose, it= seems both become more
>> complex.
>>
>> Gile's= comparison slide still concisely captures the differences between
>&= gt; these methods, in my opinion.  I haven't seen any new ideas or thoughts
>>= brought to the group in the past week or two on the subject. =1B(J I would hate
&= gt;> for both proposed methods to die on the vine because we couldn't de= cide
>> between two methods that have nothing inherently wrong wit= h either.
>>
>> -Josh
>>
>>
>>= On 4/18/12 1:53 PM, "Lucy yong" <lucy.yong@huawei.com> wrote:
>>
>>>= Send this again.
>>>
>>>Two PW approach can be comp= lex too if the VPLS instance for E-Tree uses
>>>P2P PW fo =

= --_000_14C7F4F06DB5814AB0DE29716C4F6D6701296244EFFRMRSSXCHMBSB_-- From yuqun.cao@gmail.com Sat Apr 21 04:45:52 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC2D21F855A for ; Sat, 21 Apr 2012 04:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5+Qulah5oZp for ; Sat, 21 Apr 2012 04:45:45 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id C031A21F84EB for ; Sat, 21 Apr 2012 04:45:45 -0700 (PDT) Received: by dady13 with SMTP id y13so18902027dad.27 for ; Sat, 21 Apr 2012 04:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:subject:date:message-id:mime-version :content-type:x-mailer:in-reply-to:thread-index:x-mimeole; bh=GgnzS1p5m4NDpqz+xzumvj/kxCwlIHvgsM9KtVaAffE=; b=inR2JDARak8x8CNNhGt8AvqRdJ8qqcgn8iB+SKFe0CG5yI1CLZV/GiJ1pfwfcPjV2/ A5zAgN3GFEcD34cdj0Fr6YILyvK5/7mQWfBHZHi8OFbjBRHEfE1GaiewDiOQGxbX24Mr P+XQvGfgygPF8dvkbHV5lmH3VaIn37sWAtu/VK94GS0OcfF+21YO2ceb9reeYBiNjiui 4jhXxZJd9HGF+qrBEdXfb9WD8/EKv4Bs+u6nfAnXJhPJsmVM5CULvrrQGPiRaxlvXyNU 7UGiAkblpC5CbyKIbvX01+watzGrQapH/55ysoUfEmEk89NBQboSplIPw8moCo3Fo2EE BiQw== Received: by 10.68.195.232 with SMTP id ih8mr20402397pbc.118.1335008744893; Sat, 21 Apr 2012 04:45:44 -0700 (PDT) Received: from v2comsam ([36.248.16.95]) by mx.google.com with ESMTPS id wi8sm8253942pbc.11.2012.04.21.04.45.38 (version=SSLv3 cipher=OTHER); Sat, 21 Apr 2012 04:45:43 -0700 (PDT) From: "Sam Cao" To: "'Rogers, Josh'" , "'Shahram Davari'" , "'Lizhong Jin'" , , References: <4A6CE49E6084B141B15C0713B8993F28021737@SJEXCHMB12.corp.ad.broadcom.com> Subject: RE: The status of the approaches to the E-Tree solution? Date: Sat, 21 Apr 2012 19:45:42 +0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01CD1FF7.59568D00" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac0fJQNW6V0LmvcLTaO7yAMdZqeRCQAjTfcg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: l2vpn@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: Sat, 21 Apr 2012 11:45:52 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01CD1FF7.59568D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dual-VLAN does NOT coordinate outer S-VLAN ID with customer. The 2 S-VLAN ID is used to identify Root or Leaf, not for other. In fact, the 2 VLAN-IDs added by Dual-VLAN solution only have meaning between 2 PEs in E-Tree domain. Ingress PE pushes S-VLAN ID, and egress PE stripes them out. After egress PE stripes S-VLAN ID out (previous operation is to pop PW label out), the left is customer's frame, and then bridge will forward it in traditional way. Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com _____ From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Saturday, April 21, 2012 2:40 AM To: Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: Re: The status of the approaches to the E-Tree solution? This is a very good question. A common (but not necessarily good) use case we run into is service multiplexing UNI's where multiple ELAN or ETREE services are handed off to the customer, and the S-VLAN is 'coordinated' with the customer. Meaning we expect them to tag traffic for service X with S-tag X. I suppose that we would ask the customer to use the 'root' S-Tag at the root site, and the 'leaf' at leaf sites, however this introduces a problem in my mind, because I believe the 2VLAN method has been working under the mindset of popping the s-tag off on UNI egress. In this situation where we want to keep the s-tag in tact, we would require the s-tag to be kept on both ingress at one end and egress at the other. (So things like PVST don't get upset about being sent with one vlan received w/out it) This means that the customer would be expected to either, 1) send a frame with one VLAN id from one site type, and expect to receive it with another at the other site types, and the operator sort of 'maps' between root/leaf s-tags. Or 2) transmit one vlan on a UNI, and expect return traffic to be tagged with the other vlan. Neither of which is a good/reasonable option. Is there some other way I haven't considered here? -Josh From: Shahram Davari To: Lizhong Jin , "l2vpn@ietf.org" , "Alexander.Vainshtein@ecitele.com" Cc: "yuqun.cao@gmail.com" Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW will carry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > To: "Rogers, Josh" , Lucy yong > , Daniel Cohn , Sam Cao > > Cc: "l2vpn@ietf.org" > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, but: > > IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes in the PE configuration. > > In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root AC from a PE that previously has been supporting a mix etc. affect only the PE where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a more > complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become more > complex. > > Gile's comparison slide still concisely captures the differences between > these methods, in my opinion. I haven't seen any new ideas or thoughts > brought to the group in the past week or two on the subject. I would hate > for both proposed methods to die on the vine because we couldn't decide > between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may double >>all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the processing >>in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >>traffic coming from a root AC) >>[[LY]] Not that simple. You construct either two P2MP PWs to all other >>PEs and let egress PE performing filtering, or construct one P2MP PW to >>leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >>perform forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so don't >>feel terribly strong about this objection. Is this a real problem for >>others (now or in the future), or is this objection in the weeds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. I >>encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>>giles.heron@gmail.com; simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs after >>>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>>P2MP >>>PWs if need. There is no difference between P2MP or normal PW setup. But, >>>can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>>both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong [mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, both >>>approaches can benefit from it. I was off for a while and captures some >>>discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues with >>>silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>>not clear on all the issues. Could you be more specific? As I mentioned >>>in below, two PW approach makes VPLS transport construction and packet >>>forwarding more complex, I can see potential backward compatibility >>>issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>>traffic, and some P2MP PWs for multicast traffic. It may double all of >>>them. >>> >>>E-tree is an Ethernet service and there is already VLAN based solution >>>in IEEE, can we just utilize it without complicating VPLS transport >>>construction? This also makes interworking with Eth only network easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are you >>>saying that you no longer are interested in that method in preference of >>>the dual vlan method? >>> >>> >>> >>>Lucy yong wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron [mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord ; Alexander Vainshtein >>> >>>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>>; Andrew Sergeev >>>; Idan Kaspit ; >>>Mishael Wexler ; Rotem Cohen >>> >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly have >>>put in a third column on the CW approach. And hopefully the minutes >>>will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to be >>>forming around the two alternatives of two PWEs or two VLANs. I believe >>>three of the authors of the CW approach are also authors of the two VLAN >>>approach and one is also an author of the two PWE approach. So perhaps >>>it's best to let those four individuals say which approach they prefer >>>and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of various >>>> solution drafts off the mailing list. As far as I know, no consensus >>>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>>> think the CW approach has not been rejected by the WG yet, or the WG >>>> has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree approaches >>>>> based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>>> ext=1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>>> clude_te >>>>> xt=1) >>>>> and completely ignores the solution based on usage of the CW in the >>>>> PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>>> ext=1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>>> wonder whether the WG has taken a decision to reject the approach >>>>> based on the CW usage? I do not remember any recent discussion of >>>>> this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and contains >>>>> information which is CONFIDENTIAL and which may be proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original and >>>>> all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action taken >>>in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use of the individual or entity to which it is addressed. If you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** ------=_NextPart_000_0006_01CD1FF7.59568D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dual-VLAN does = NOT coordinate outer S-VLAN ID with customer.  The 2 S-VLAN ID is used to identify = Root or Leaf, not for other.

 <= /span>

In fact, the 2 = VLAN-IDs added by Dual-VLAN solution only have meaning between 2 PEs in E-Tree domain. = Ingress PE pushes S-VLAN ID, and egress PE stripes them out. After egress PE = stripes S-VLAN ID out (previous operation is to pop PW label out), the left is = customer’s frame, and then bridge will forward it in traditional way. =

 <= /span>

Regards,

 

=

Yuqun (Sam) = Cao

E-mail: Yuqun.cao@gmail.com =

 

From: Rogers, Josh [mailto:josh.rogers@twcable.com]
Sent: Saturday, April 21, = 2012 2:40 AM
To: Shahram Davari; = Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com
Cc: = yuqun.cao@gmail.com
Subject: Re: The status = of the approaches to the E-Tree solution?

 

This is a = very good question.  A common (but not necessarily good) use case we run into = is service multiplexing UNI's where multiple ELAN or ETREE services are = handed off to the customer, and the S-VLAN is 'coordinated' with the customer. =  Meaning we expect them to tag traffic for service X with S-tag = X. 

 

I suppose = that we would ask the customer to use the 'root' S-Tag at the root site, and the = 'leaf' at leaf sites, however this introduces a problem in my mind, because I = believe the 2VLAN method has been working under the mindset of popping the s-tag = off on UNI egress.  In this situation where we want to keep the s-tag in = tact, we would require the s-tag to be kept on both ingress at one end and egress = at the other.  (So things like PVST don't get upset about being sent with = one vlan received w/out it)

 

This means = that the customer would be expected to either, 1) send a frame with one VLAN id = from one site type, and expect to receive it with another at the other site = types, and the operator sort of 'maps' between root/leaf s-tags.  Or 2) = transmit one vlan on a UNI, and expect return traffic to be tagged with the other = vlan.

 

Neither of = which is a good/reasonable option.  Is there some other way I haven't = considered here?

 

-Josh

 

 

From: Shahram Davari <davari@broadcom.com>
To: Lizhong Jin <lizho.jin@gmail.com>, = "l2vpn@ietf.org" <l2vpn@ietf.org>, "Alexander.Vainshtein@eci= tele.com" <Alexander.Vainshtein@eci= tele.com>
Cc: "yuqun.cao@gmail.com" <yuqun.cao@gmail.com>
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Hi,

 =

I also have = a question regarding 2-VLAN. What if the customer traffic already has an = S-VLAN? Do we need a 3rd VLAN to identify the = L/R?

 =

Thx

Shahram

 =

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]= On Behalf Of Lizhong Jin
Sent: Friday, April 20, = 2012 9:38 AM
To: l2vpn@ietf.org; Alexander.Vainshtein@eci= tele.com
Cc: yuqun.cao@gmail.com
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Hi, all,
The difference between 2-VLAN and CW approach is who will provide the = R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW = will carry R/L information for CW approach.
I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is = accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds = VLAN to indicate R/L information?

Thanks
Lizhong

> ------------------------------
>
> Message: 2
> Date: Thu, 19 Apr 2012 04:38:36 +0000
> From: Alexander Vainshtein <Alexander.Vainshtein@eci= tele.com>
> To: "Rogers, Josh" <josh.rogers@twcable.com>, Lucy yong
>        <lucy.yong@huawei.com>, Daniel Cohn <DanielC@orckit.com>, Sam Cao
>        <yuqun.cao@gmail.com>
> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
> Subject: RE: The status of the approaches to the E-Tree = solution?
> Message-ID:
>        <F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> Hi all,
> I fully understand that that what I am going to say is not very = popular, but:
>
> IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic.
>
> Another advantage is preservation of full mesh of P2P PWs in a = VPLS, and, in a more generic way, localization of effects of changes in the PE configuration.
>
> In particular, adding a Leaf AC to a PE that previously has been = only supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect only the = PE where this operation happens and not the rest of the PEs.
>
> As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution.
>
> My 2c,
>     Sasha
>
>
>
> ________________________________________
> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on = behalf of Rogers, Josh [josh.rogers@twcable.com]
> Sent: Wednesday, April 18, 2012 9:57 PM
> To: Lucy yong; Daniel Cohn; Sam Cao
> Cc: l2vpn@ietf.org
> Subject: Re: The status of the approaches to the E-Tree = solution?
>
> Again, the P2MP situation throws me.  Is this something that = is used
> commonly?
>
> I'm under the impression that adding P2MP to any model results in a = more
> complex model.  Wether outside s-tag is used to differentiate, = or
> dedicated pw's are used for the same purpose, it seems both become = more
> complex.
>
> Gile's comparison slide still concisely captures the differences = between
> these methods, in my opinion.  I haven't seen any new ideas or thoughts
> brought to the group in the past week or two on the subject. =  I would hate
> for both proposed methods to die on the vine because we couldn't = decide
> between two methods that have nothing inherently wrong with = either.
>
> -Josh
>
>
> On 4/18/12 1:53 PM, "Lucy yong" <lucy.yong@huawei.com> = wrote:
>
>>Send this again.
>>
>>Two PW approach can be complex too if the VPLS instance for = E-Tree uses
>>P2P PW for unicast traffic and P2MP PW for broadcast and = unknown
>>unicast traffic, and some P2MP PWs for multicast traffic. It may = double
>>all of them.
>>
>>Lucy
>>
>>-----Original Message-----
>>From: Daniel Cohn [mailto:DanielC@orckit.com]
>>Sent: Wednesday, April 18, 2012 1:42 PM
>>To: Lucy yong; Rogers, Josh; Sam Cao
>>Cc: l2vpn@ietf.org
>>Subject: RE: The status of the approaches to the E-Tree = solution?
>>
>>I think the first option its the natural way to go. How is the processing
>>in this case more complex?
>>
>>Thumb typed - please be tolerant
>>
>>Lucy yong <lucy.yong@huawei.com> wrote:
>>
>>
>>
>>Snipped..
>>
>>Multi-PW - On ingress PE, frame is placed onto either a = Leaf-only P2MP PW
>>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW = (for
>>traffic coming from a root AC)
>>[[LY]] Not that simple. You construct either two P2MP PWs to all = other
>>PEs and let egress PE performing filtering, or construct one = P2MP PW to
>>leaf-only PEs and two P2MP PWs to root and leaf PEs and let = ingress PE
>>perform forwarding and filtering. Both make node process = complex.
>>
>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP = PW for
>>delivering the frames to remote PEs. We should utilize them with = the
>>minimized changes. Dual VLAN solution is simpler than Dual = PW.
>>
>>Regards,
>>Lucy
>>
>>
>>I see how 2VLAN is simpler when P2MP PW's are involved, I think.  I
>>haven't had any first hand experience with P2MP PW's, however, = so don't
>>feel terribly strong about this objection.  Is this a real = problem for
>>others (now or in the future), or is this objection in the = weeds?
>>
>>I'm not sure the 'additional complexity' is notable, or even = relevant.  I
>>encourage others to speak up if they disagree, as P2MP PW is = only
>>conceptual to me, and I am unfamiliar with real-life use cases = for it.
>>
>>Thanks,
>>Josh
>>
>>
>>
>>On 4/18/12 10:30 AM, "Lucy yong" <lucy.yong@huawei.com> = wrote:
>>
>>>Please see inline.
>>>
>>>-----Original Message-----
>>>From: Sam Cao [mailto:yuqun.cao@gmail.com]
>>>Sent: Tuesday, April 17, 2012 7:14 AM
>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, = Wim (Wim)';
>>>giles.heron@gmail.com; simon.delord@gmail.com;
>>>Alexander.Vainshtein@eci= tele.com
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com= ;
>>>Andrew.Sergeev@ecitele.com= ; Idan.Kaspit@ecitele.com;
>>>Mishael.Wexler@ecitele.com= ; Rotem.Cohen@ecitele.com
>>>Subject: RE: The status of the approaches to the E-Tree = solution?
>>>
>>>Yes, 2 pws are only needed between pes with both root and = leaf acs after
>>>improving Dual-PW approach. If consider P2MP, Dual-PW = approach setup 2
>>>P2MP
>>>PWs if need. There is no difference between P2MP or normal = PW setup. But,
>>>can Leaf-ACs be bound to Root PE of P2MP PW?
>>>
>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a = PE with both
>>>root and leaf ACs set up two or one P2MP PW to other PEs = (some PE have
>>>both root and leaf AC and some only have leaf ACs)?
>>>Regards,
>>>Lucy
>>>
>>>Regards,
>>>
>>>Yuqun (Sam) Cao
>>>E-mail: Yuqun.cao@gmail.com
>>>
>>>
>>>-----Original Message-----
>>>From: Daniel Cohn [mailto:DanielC@orckit.com]
>>>Sent: Tuesday, April 17, 2012 4:56 PM
>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim);
>>>giles.heron@gmail.com;
>>>simon.delord@gmail.com; Alexander.Vainshtein@eci= tele.com; Sam Cao
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com= ;
>>>Andrew.Sergeev@ecitele.com= ; Idan.Kaspit@ecitele.com;
>>>Mishael.Wexler@ecitele.com= ; Rotem.Cohen@ecitele.com
>>>Subject: RE: The status of the approaches to the E-Tree = solution?
>>>
>>>Adding Sam (as l2vpn@ is holding messages)
>>>
>>>DC
>>>
>>>-----Original Message-----
>>>From: Lucy yong [mailto:lucy.yong@huawei.com]
>>>Sent: Tuesday, April 17, 2012 12:39 AM
>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim);
>>>giles.heron@gmail.com; simon.delord@gmail.com;
>>>Alexander.Vainshtein@eci= tele.com
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com= ;
>>>Andrew.Sergeev@ecitele.com= ; Idan.Kaspit@ecitele.com;
>>>Mishael.Wexler@ecitele.com= ; Rotem.Cohen@ecitele.com
>>>Subject: RE: The status of the approaches to the E-Tree = solution?
>>>
>>>
>>>Snipped,
>>>
>>>As we discussed extensively in the list, and as reflected in = giles
>>>slide, 2 pws are only needed between pes with both root and = leaf acs,
>>>which will typically be a small minority.
>>>[[LY]] Don't know if the assumption is true. Even it is the = case, both
>>>approaches can benefit from it. I was off for a while and = captures some
>>>discussions now.
>>>
>>>Also as per giles slide, dual vlan can have scalability = issues due to
>>>additional lookup and double use of vlans in internal = emulated lan
>>>interface. Also there are potential backward compatibility = issues with
>>>silicon that doesn't support vlan mapping.
>>>[[LY]] I was not in IETF83 meeting and wait on the meeting = minutes. I am
>>>not clear on all the issues. Could you be more specific? As = I mentioned
>>>in below, two PW approach makes VPLS transport construction = and packet
>>>forwarding more complex, I can see potential backward = compatibility
>>>issues with 2 PW solution.
>>>
>>>Regards,
>>>Lucy
>>>
>>>Regards,
>>>
>>>Daniel
>>>
>>>Thumb typed - please be tolerant
>>>
>>>Lucy yong <lucy.yong@huawei.com> wrote:
>>>
>>>In my mind, the VLAN approach means dual vlan method.
>>>
>>>The main concern for CW approach is hardware support.
>>>
>>>Two PW approach can be complex too if the VPLS instance for = E-Tree uses
>>>P2P PW for unicast traffic and P2MP PW for broadcast and = unknown unicast
>>>traffic, and some P2MP PWs for multicast traffic. It may = double all of
>>>them.
>>>
>>>E-tree is an Ethernet service and there is already VLAN = based solution
>>>in IEEE, can we just utilize it without complicating VPLS = transport
>>>construction? This also makes interworking with Eth only = network easier.
>>>
>>>Cheers,
>>>Lucy
>>>
>>>-----Original Message-----
>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com]
>>>Sent: Monday, April 16, 2012 8:35 AM
>>>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com';
>>>'simon.delord@gmail.com'; 'Alexander.Vainshtein@eci= tele.com'
>>>Cc: 'l2vpn@ietf.org'; = 'Vladimir.Kleiner@ecitele.com= ';
>>>'Andrew.Sergeev@ecitele.com= '; 'Idan.Kaspit@ecitele.com';
= >>>'Mishael.Wexler@ecitele.com= '; 'Rotem.Cohen@ecitele.com'
>>>Subject: RE: The status of the approaches to the E-Tree = solution?
>>>
>>>I believe the initial question was in regard to the CW = method.  Are you
>>>saying that you no longer are interested in that method in preference of
>>>the dual vlan method?
>>>
>>>
>>>
>>>Lucy yong <lucy.yong@huawei.com> wrote:
>>>
>>>
>>>Agree with Wim. VLAN approach is the best solution for = E-Tree.
>>>
>>>Lucy
>>>
>>>-----Original Message-----
>>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf
>>>Of Henderickx, Wim (Wim)
>>>Sent: Thursday, April 12, 2012 2:03 AM
>>>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com';
>>>'Alexander.Vainshtein@eci= tele.com'
>>>Cc: 'l2vpn@ietf.org'; = 'Vladimir.Kleiner@ecitele.com= ';
>>>'Andrew.Sergeev@ecitele.com= '; 'Idan.Kaspit@ecitele.com';
= >>>'Mishael.Wexler@ecitele.com= '; 'Rotem.Cohen@ecitele.com'
>>>Subject: Re: The status of the approaches to the E-Tree = solution?
>>>
>>>The vlan approach is superior as it also works for eth only networks,
>>>etc. On top some vendors indicate hw issues with the cw = approach. As
>>>such we have dropped more or less the cw approach.
>>>
>>>Cheers,
>>>Wim
>>>_________________
>>>sent from blackberry
>>>
>>>----- Original Message -----
>>>From: Giles Heron [mailto:giles.heron@gmail.com]
>>>Sent: Thursday, April 12, 2012 08:22 AM
>>>To: Simon Delord <simon.delord@gmail.com>; Alexander Vainshtein
>>><Alexander.Vainshtein@eci= tele.com>
>>>Cc: l2vpn@ietf.org = <l2vpn@ietf.org>; Vladimir = Kleiner
>>><Vladimir.Kleiner@ecitele.com= >; Andrew Sergeev
>>><Andrew.Sergeev@ecitele.com= >; Idan Kaspit <Idan.Kaspit@ecitele.com>;<= br> >>>Mishael Wexler <Mishael.Wexler@ecitele.com= >; Rotem Cohen
>>><Rotem.Cohen@ecitele.com> >>>Subject: Re: The status of the approaches to the E-Tree = solution?
>>>
>>>Sorry - the "anonymous presentation" was mine. =  I should possibly have
>>>put in a third column on the CW approach.  And = hopefully the minutes
>>>will be posted soon.
>>>
>>>We had various discussions, as Simon stated, and consensus = seemed to be
>>>forming around the two alternatives of two PWEs or two = VLANs.  I believe
>>>three of the authors of the CW approach are also authors of = the two VLAN
>>>approach and one is also an author of the two PWE approach. = So perhaps
>>>it's best to let those four individuals say which approach = they prefer
>>>and why?
>>>
>>>Giles
>>>
>>>On 10/04/2012 00:45, "Simon Delord" <simon.delord@gmail.com> = wrote:
>>>
>>>> Hi Alexander,
>>>>
>>>> You are right, no discussion on the WG mailing list = recently, but
>>>> there have been substantial discussions among the = authors of various
>>>> solution drafts off the mailing list. As far as I know, = no consensus
>>>> yet before ietf83, not sure the progress in the Paris = WG meeting. I
>>>> think the CW approach has not been rejected by the WG = yet, or the WG
>>>> has not yet decided on which one to adopt.
>>>>
>>>> Simon
>>>>
>>>> 2012/4/8 Alexander = Vainshtein <Alexander.Vainshtein@eci= tele.com>
>>>>
>>>>>  Hi all,
>>>>>
>>>>> Unfortunately I have not been able to attend the = Paris IETF.
>>>>>
>>>>> However, looking up the L2VPN proceedings, I've = found a short
>>>>> anonymous presentation called "E-Tree = Update"  (
>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the = E-Tree approaches
>>>>> based on dedicated VLANs (as in
>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include= _t
>>>>> ext=3D1) and multiple PWs between the PEs (as = in
>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?= in
>>>>> clude_te
>>>>> xt=3D1)
>>>>> and completely ignores the solution based on usage = of the CW in the
>>>>> PWs connecting the PEs (as in
>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include= _t
>>>>> ext=3D1
>>>>> ).
>>>>>
>>>>>
>>>>>
>>>>> The Minutes of the Paris L2VPN session are not yet available, but I
>>>>> wonder whether the WG has taken a decision to = reject the approach
>>>>> based on the CW usage? I do not remember any recent discussion of
>>>>> this topic on the WG mailing list.
>>>>>
>>>>>
>>>>>
>>>>> Regards, and lots of thanks in advance,
>>>>>
>>>>> Sasha
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This e-mail message is intended for the recipient = only and contains
>>>>> information which is CONFIDENTIAL and which may be proprietary to ECI
>>>
>>>>> Telecom. If you have received this transmission in = error, please
>>>>> inform us by e-mail, phone or fax, and then delete = the original and
>>>>> all copies thereof.
>>>>>
>>>
>>>
>>>
>>>
>>>
>>>This E-mail and any of its attachments may contain Time = Warner Cable
>>>proprietary information, which is privileged, confidential, = or subject
>>>to copyright belonging to Time Warner Cable. This E-mail is intended
>>>solely for the use of the individual or entity to which it = is addressed.
>>>If you are not the intended recipient of this E-mail, you = are hereby
>>>notified that any dissemination, distribution, copying, or = action taken
>>>in relation to the contents of and attachments to this = E-mail is
>>>strictly prohibited and may be unlawful. If you have = received this
>>>E-mail in error, please notify the sender immediately and permanently
>>>delete the original and any copy of this E-mail and any = printout.
>>>
>>
>>
>>This E-mail and any of its attachments may contain Time Warner = Cable
>>proprietary information, which is privileged, confidential, or = subject to
>>copyright belonging to Time Warner Cable. This E-mail is = intended solely
>>for the use of the individual or entity to which it is = addressed. If you
>>are not the intended recipient of this E-mail, you are hereby = notified
>>that any dissemination, distribution, copying, or action taken = in
>>relation to the contents of and attachments to this E-mail is = strictly
>>prohibited and may be unlawful. If you have received this E-mail = in
>>error, please notify the sender immediately and permanently = delete the
>>original and any copy of this E-mail and any printout.
>
>
> This E-mail and any of its attachments may contain Time Warner = Cable proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended solely = for the use of the individual or entity to which it is addressed. If you are = not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and = may be unlawful. If you have received this E-mail in error, please notify the = sender immediately and permanently delete the original and any copy of this = E-mail and any printout.
> This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform us by = e-mail, phone or fax, and then delete the original and all copies thereof.
>
>
>
> ------------------------------
>
> _______________________________________________
> L2vpn mailing list
> L2vpn@ietf.org
> https://www.ietf.org= /mailman/listinfo/l2vpn
>
>
> End of L2vpn Digest, Vol 95, Issue 25
> *********************************** =

------=_NextPart_000_0006_01CD1FF7.59568D00-- From yuqun.cao@gmail.com Sat Apr 21 06:20:26 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8DB21F85E7 for ; Sat, 21 Apr 2012 06:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=-1.667, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 XBKPXwKRx9+9 for ; Sat, 21 Apr 2012 06:20:25 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id F26CB21F85AE for ; Sat, 21 Apr 2012 06:20:24 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so2126828pbb.31 for ; Sat, 21 Apr 2012 06:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:x-mailer:in-reply-to:thread-index:x-mimeole; bh=v9IjOj6dtX5LLeuJFIbj1oz++cM6hMXK78BNjTOGve0=; b=ylJU2qukhmBR1gzQcDhwTzEgH5OXwlkznPAZp/VW4X1sORK1+nNGGPWPC12R2n3vhu VEmpPyY6NDbPfrLO+JMiWo4IRy6qlEOiqIDuhRyvTjjJcCHtWFZ4nSLAfCD0REOzVk0Q A4eZwVc4TSCVwfjH+V7h/WFDN+nRZdpGWW/ydiH13CakjAZlVZxfnfHd4StG23hFZy1d KUTS8St56gFIUYElHPGaxIEWWw1D4fwx2gmud13oP5qORhnnm+9ZkYz8gldezoWdEP6c i9RTSYO9gPnUrgQBqOY4CSWSONBiccyy2HE5KwswnY1BtNqi1Fn6EgHidZSkBi7X9ELV Vq/w== Received: by 10.68.200.68 with SMTP id jq4mr3972547pbc.42.1335014424441; Sat, 21 Apr 2012 06:20:24 -0700 (PDT) Received: from v2comsam ([36.248.16.95]) by mx.google.com with ESMTPS id tq6sm8431301pbc.73.2012.04.21.06.20.19 (version=SSLv3 cipher=OTHER); Sat, 21 Apr 2012 06:20:23 -0700 (PDT) From: "Sam Cao" To: "'Lizhong Jin'" , "'Henderickx, Wim \(Wim\)'" References: <14C7F4F06DB5814AB0DE29716C4F6D6701296244C3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Subject: RE: The status of the approaches to the E-Tree solution? Date: Sat, 21 Apr 2012 21:20:22 +0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01CD2004.92DA9910" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac0fcx6tlnmtYO6ESBGd/Ct1B51r5gARqiew X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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: Sat, 21 Apr 2012 13:20:26 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000A_01CD2004.92DA9910 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Lizhong and all, =20 We discussed HVPLS in another thread, but don=A1=AFt start second = thought. This is one good question.=20 =20 If we consider VPWS, It is reasonable to configure Root/Leaf on PE-rs. = As you know, VPWS is point-to-point. So VPWS PW is thought as one VIRTUAL = AC or extension to remote attachment circuit. Please refer to Fig. 4 in RFC = 4762, say, we can configure PW1 between PE-r and PE-rs as Root on PE-rs, which means CE-1 access is Root. PE-rs does VLAN manipulation. This seems reasonable for me. =20 If you are talking about Fig. 3 in RFC 4762, it is not VPWS PW between = MTU-s and PE-rs. On both side, PW1 is taken as Spoke PW of VPLS instance. In = this case, MTU-s supports l2 switching, and we can configure Root/Leaf on = MTU-s (on the remote PE of VPWS in your mail, I think). If so, MTU-S will add Root-VLAN ID or Leaf-VLAN ID, and PE-rs can NOT do VLAN manipulation. = This confuse me, on PE-rs, it should configure AC type in one case, but can = NOT in another case. In addition, it should operate in Tag mode, otherwise = PE-rs will remove S-VLAN ID (we also raised raw-mode before). =20 Lizhong, thank you again for your information. =20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 _____ =20 From: Lizhong Jin [mailto:lizho.jin@gmail.com]=20 Sent: Saturday, April 21, 2012 11:59 AM To: Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; = yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? =20 Hi Win, Thank you for the answers. In that case, PE-rs should configure the root/leaf properties of VPWS, not on the remote PE of VPWS. And usually = on PE-rs, you could not figure out the accessing spoke PW is from PE-r of = VPWS or MTU-s. Unless having some additional indication in NMS, you even = don't know which spoke PW needs to do VLAN manipulation. I am not sure such = R/L configuration could be accepted from operational view. Hope to see more comments. Regards Lizhong =D4=DA 2012=C4=EA4=D4=C221=C8=D5=D0=C7=C6=DA=C1=F9=A3=ACHenderickx, Wim = (Wim) =D0=B4=B5=C0=A3=BA > The VPWS which terminates at the H-VPLS node is indicated to be root = or leaf and the procedures associated will do the VLAN manipulation > > =20 > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Lizhong Jin > Sent: vrijdag 20 april 2012 18:38 > To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com > Cc: yuqun.cao@gmail.com > Subject: RE: The status of the approaches to the E-Tree solution? > > =20 > > Hi, all, > The difference between 2-VLAN and CW approach is who will provide the = R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW = will carry R/L information for CW approach. > I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used = to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information? > > Thanks > Lizhong > >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 Apr 2012 04:38:36 +0000 >> From: Alexander Vainshtein >> To: "Rogers, Josh" , Lucy yong >> , Daniel Cohn , Sam = Cao >> >> Cc: "l2vpn@ietf.org" >> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID: >> = >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi all, >> I fully understand that that what I am going to say is not very = popular, but: >> >> IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, = and, in a more generic way, localization of effects of changes in the PE configuration. >> >> In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect only = the PE where this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a = more >> complex model. Wether outside s-tag is used to differentiate, or >> dedicated pw's are used for the same purpose, it seems both become = more >> complex. >> >> Gile's comparison slide still concisely captures the differences = between >> these methods, in my opinion. I haven't seen any new ideas or = thoughts >> brought to the group in the past week or two on the subject. I would hate >> for both proposed methods to die on the vine because we couldn't = decide >> between two methods that have nothing inherently wrong with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" wrote: >> >>>Send this again. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree = uses >>>P2P PW fo=20 ------=_NextPart_000_000A_01CD2004.92DA9910 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Lizhong and = all,

 <= /span>

We discussed = HVPLS in another thread, but don=A1=AFt start second thought. This is one good = question.

 <= /span>

If we consider = VPWS, It is reasonable to configure Root/Leaf on PE-rs. As you know, VPWS is point-to-point. So VPWS PW is thought as one VIRTUAL AC or extension to = remote attachment circuit. Please refer to Fig. 4 in RFC 4762, say, we can configure PW1 between PE-r and PE-rs as Root on = PE-rs, which means CE-1 access is Root. PE-rs does VLAN manipulation. This = seems reasonable for me.

 <= /span>

If you are = talking about Fig. 3 in RFC = 4762, it is not VPWS PW between MTU-s and PE-rs. On both side, PW1 is taken as Spoke PW = of VPLS instance. In this case, MTU-s supports l2 switching, and we can = configure Root/Leaf on MTU-s (on the remote PE of VPWS in your mail, I think). If so, MTU-S = will add Root-VLAN ID or Leaf-VLAN ID, and PE-rs can NOT do VLAN = manipulation. This confuse me, on PE-rs, it should configure AC type in one case, but can = NOT in another case. In addition, it should operate in Tag mode, otherwise = PE-rs will remove S-VLAN ID (we also raised raw-mode = before).

 <= /span>

Lizhong, thank = you again for your information.

 <= /span>

Regards,

 

=

Yuqun (Sam) Cao

E-mail: Yuqun.cao@gmail.com

 

From: Lizhong Jin [mailto:lizho.jin@gmail.com]
Sent: Saturday, April 21, = 2012 11:59 AM
To: Henderickx, Wim = (Wim)
Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; yuqun.cao@gmail.com
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Hi Win,
Thank you for the answers. In that case, PE-rs should configure the = root/leaf properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, = you could not figure out the accessing spoke PW is from PE-r of VPWS or = MTU-s. Unless having some additional indication in NMS, you even don't know = which spoke PW needs to do VLAN manipulation. I am not sure such R/L = configuration could be accepted from operational view. Hope to see more comments.

Regards
Lizhong


=D4=DA 2012=C4=EA4=D4=C221=C8=D5=D0=C7=C6=DA=C1=F9=A3=ACHenderickx, Wim (Wim) <wim.henderickx@alcatel-= lucent.com> =D0=B4=B5=C0=A3=BA
> The VPWS which terminates at the H-VPLS node is indicated to be = root or leaf and the procedures associated will do the VLAN manipulation
>
>  
>
> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin
> Sent: vrijdag 20 april 2012 18:38
> To: l2vpn@ietf.org; Alexander.Vainshtein@eci= tele.com
> Cc: yuqun.cao@gmail.com
> Subject: RE: The status of the approaches to the E-Tree = solution?
>
>  
>
> Hi, all,
> The difference between 2-VLAN and CW approach is who will provide = the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW = will carry R/L information for CW approach.
> I have a question with the 2-VLAN approach in H-VPLS where H-VPLS = is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds = VLAN to indicate R/L information?
>
> Thanks
> Lizhong
>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 19 Apr 2012 04:38:36 +0000
>> From: Alexander Vainshtein <Alexander.Vainshtein@eci= tele.com>
>> To: "Rogers, Josh" <josh.rogers@twcable.com>, = Lucy yong
>>        <lucy.yong@huawei.com>, Daniel Cohn <DanielC@orckit.com>, Sam Cao
>>        <yuqun.cao@gmail.com>
>> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
>> Subject: RE: The status of the approaches to the E-Tree = solution?
>> Message-ID:
>>        <F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>
>> Content-Type: text/plain; charset=3D"us-ascii"
>>
>> Hi all,
>> I fully understand that that what I am going to say is not very popular, but:
>>
>> IMO one of the advantages of the CW-based solution is that it = is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic.
>>
>> Another advantage is preservation of full mesh of P2P PWs in a = VPLS, and, in a more generic way, localization of effects of changes in the PE configuration.
>>
>> In particular, adding a Leaf AC to a PE that previously has = been only supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect only the = PE where this operation happens and not the rest of the PEs.
>>
>> As for the need for HW changes that have been mentioned as a = main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution.
>>
>> My 2c,
>>     Sasha
>>
>>
>>
>> ________________________________________
>> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] = on behalf of Rogers, Josh [josh.rogers@twcable.com]
>> Sent: Wednesday, April 18, 2012 9:57 PM
>> To: Lucy yong; Daniel Cohn; Sam Cao
>> Cc: l2vpn@ietf.org
>> Subject: Re: The status of the approaches to the E-Tree = solution?
>>
>> Again, the P2MP situation throws me.  Is this something = that is used
>> commonly?
>>
>> I'm under the impression that adding P2MP to any model results = in a more
>> complex model.  Wether outside s-tag is used to = differentiate, or
>> dedicated pw's are used for the same purpose, it seems both = become more
>> complex.
>>
>> Gile's comparison slide still concisely captures the = differences between
>> these methods, in my opinion.  I haven't seen any new = ideas or thoughts
>> brought to the group in the past week or two on the subject. =  I would hate
>> for both proposed methods to die on the vine because we = couldn't decide
>> between two methods that have nothing inherently wrong with = either.
>>
>> -Josh
>>
>>
>> On 4/18/12 1:53 PM, "Lucy yong" <lucy.yong@huawei.com> = wrote:
>>
>>>Send this again.
>>>
>>>Two PW approach can be complex too if the VPLS instance for = E-Tree uses
>>>P2P PW fo

------=_NextPart_000_000A_01CD2004.92DA9910-- From yuqun.cao@gmail.com Sat Apr 21 06:41:56 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1539A21F8567 for ; Sat, 21 Apr 2012 06:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.181 X-Spam-Level: X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNKohGDRsExu for ; Sat, 21 Apr 2012 06:41:51 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D610121F8554 for ; Sat, 21 Apr 2012 06:41:51 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so2139967pbb.31 for ; Sat, 21 Apr 2012 06:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=4inDbiT1Te1qPEA45JR0mj6neubrK4eDMkpKCi+PbzY=; b=ixVCZxCczyKkafqiQISLudugUr7A7ebuP1T+yFnirdabF5FisjYT0BiySbzzvb7mNN 3UXj325wnVdzCk7i5q/sAuOklWYZsXBzh5le2C9iUgD0YWAPyO4LNEGWqeSU8bmqG3TC H0FfNBvLhO1vIa3W+jeTTpvJLKl7yGYPSjjHtGJJjPnQYfvSfUmYJNV4a+fqVjBMogsS QmB+sLQOt6YlhcifinmJh6BOnTjf2uAlcX5wo1l0kMblHeDRJ+b3V24STGpi4XvCm3ej oSwwZrNTjxQAIuckU1wLg/6MI9jD5xxoiaSaxbYrm9F2GAbnZrJrMwbgP98SblCk5AaT sOfA== Received: by 10.68.221.10 with SMTP id qa10mr20791270pbc.139.1335015711228; Sat, 21 Apr 2012 06:41:51 -0700 (PDT) Received: from v2comsam ([36.248.16.95]) by mx.google.com with ESMTPS id qs6sm8491720pbb.29.2012.04.21.06.41.46 (version=SSLv3 cipher=OTHER); Sat, 21 Apr 2012 06:41:50 -0700 (PDT) From: "Sam Cao" To: "'Alexander Vainshtein'" References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, , <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Subject: RE: The status of the approaches to the E-Tree solution? Date: Sat, 21 Apr 2012 21:41:49 +0800 Message-ID: <8BD23518D42D4E0CB8E67B5CF7CD3EA8@v2comsam> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdiov//4SRIP//A88g//rZ1YA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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: Sat, 21 Apr 2012 13:41:56 -0000 Sasha, Thank you for your comments. Multi-PW can support BGP-AD, RFC 4761 or RFC 6074. BTW, can we work together on issues list? I will list some cases we discussed before. Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Thursday, April 19, 2012 9:19 PM To: Sam Cao Cc: l2vpn@ietf.org; 'Daniel Cohn'; 'Henderickx, Wim (Wim)'; 'Rogers, Josh'; 'Lucy yong' Subject: RE: The status of the approaches to the E-Tree solution? Sam (hope this is the appropriate form of address and my apologies if not), I am actually trying to build a list of operational (not implementation-driven) issues that must be addressed by a reasonable E-tree solution. Then we could compare multiple approaches. As for setting up/tearing PWs with multiple peers just because your local configuration has changed, I am not sure this is reasonable from the operational point of view. E.g., consider the case of a Leaf-only PE migrating to a Mixed PE. To the best of my understanding, PWs between Leaf-only PWs are not ever set, so our original Leaf PE could be unaware about existence of other Leaf-only PEs (or, even worse, its list of Leaf-only peers could be not matching the current situation) - and this would not affect traffic in any way. Once it suddenly becomes a Mix PE, it must set up PWs with all the Leaf-only PEs have been ignored before, and they must agree to this... IMHO and FWIW, unless you use a very elaborate auto-discovery mechanism, this process has all the potential to become an operational nightmare. My 2c, Sasha > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Thursday, April 19, 2012 3:50 PM > To: Alexander Vainshtein; 'Henderickx, Wim (Wim)'; 'Rogers, Josh'; 'Lucy > yong'; 'Daniel Cohn' > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Sasha, > > We have discussed this case before. While configuration is changed in fly, > it is reasonable to establish or teardown PW. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Thursday, April 19, 2012 1:31 PM > To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Wim, > Lots of thanks for a prompt response. > > I think that operational aspects of the VLAN approach (e.g., how is the > Global VID selected and distributed) should be examined in more detail. > > At the same time it seems that the double PW approach carries with it too > many operational problems. > E.g., no PWs are set up between Leaf-only PEs, but once one of these > becomes > a Mix PE, all the Leaf-only PEs must now recognize it as a valid peer. And > if a Mix PE reverts to a Leaf only one, all its Leaf-only peers must drop it > and shut down the relevant PWs... > > My 2c, > Sasha > > ________________________________________ > From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] > Sent: Thursday, April 19, 2012 7:21 AM > To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Sasha, the VLAN approach allows for a similar operation as the CW does. It > is orthogonal to the underlying PW deployment of VPLS. > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of > Alexander Vainshtein > Sent: donderdag 19 april 2012 6:39 > To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Hi all, > I fully understand that that what I am going to say is not very popular, > but: > > IMO one of the advantages of the CW-based solution is that it is orthogonal > to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in > a more generic way, localization of effects of changes in the PE > configuration. > > In particular, adding a Leaf AC to a PE that previously has been only > supporting Root ACs (or vice versa), removal of the last Leaf or last Root > AC from a PE that previously has been supporting a mix etc. affect only the > PE where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main > disadvantage of the CW-based approach - I believe it strongly depends on > specific implementations. And some changes in the forwarding process are > required in any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of > Rogers, > Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a more > complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become more > complex. > > Gile's comparison slide still concisely captures the differences between > these methods, in my opinion. I haven't seen any new ideas or thoughts > brought to the group in the past week or two on the subject. I would hate > for both proposed methods to die on the vine because we couldn't decide > between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" wrote: > > >Send this again. > > > >Two PW approach can be complex too if the VPLS instance for E-Tree uses > >P2P PW for unicast traffic and P2MP PW for broadcast and unknown > >unicast traffic, and some P2MP PWs for multicast traffic. It may double > >all of them. > > > >Lucy > > > >-----Original Message----- > >From: Daniel Cohn [mailto:DanielC@orckit.com] > >Sent: Wednesday, April 18, 2012 1:42 PM > >To: Lucy yong; Rogers, Josh; Sam Cao > >Cc: l2vpn@ietf.org > >Subject: RE: The status of the approaches to the E-Tree solution? > > > >I think the first option its the natural way to go. How is the processing > >in this case more complex? > > > >Thumb typed - please be tolerant > > > >Lucy yong wrote: > > > > > > > >Snipped.. > > > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW > >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for > >traffic coming from a root AC) > >[[LY]] Not that simple. You construct either two P2MP PWs to all other > >PEs and let egress PE performing filtering, or construct one P2MP PW to > >leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE > >perform forwarding and filtering. Both make node process complex. > > > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for > >delivering the frames to remote PEs. We should utilize them with the > >minimized changes. Dual VLAN solution is simpler than Dual PW. > > > >Regards, > >Lucy > > > > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I > >haven't had any first hand experience with P2MP PW's, however, so don't > >feel terribly strong about this objection. Is this a real problem for > >others (now or in the future), or is this objection in the weeds? > > > >I'm not sure the 'additional complexity' is notable, or even relevant. I > >encourage others to speak up if they disagree, as P2MP PW is only > >conceptual to me, and I am unfamiliar with real-life use cases for it. > > > >Thanks, > >Josh > > > > > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > > > >>Please see inline. > >> > >>-----Original Message----- > >>From: Sam Cao [mailto:yuqun.cao@gmail.com] > >>Sent: Tuesday, April 17, 2012 7:14 AM > >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; > >>giles.heron@gmail.com; simon.delord@gmail.com; > >>Alexander.Vainshtein@ecitele.com > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > >>Subject: RE: The status of the approaches to the E-Tree solution? > >> > >>Yes, 2 pws are only needed between pes with both root and leaf acs after > >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup > 2 > >>P2MP > >>PWs if need. There is no difference between P2MP or normal PW setup. > But, > >>can Leaf-ACs be bound to Root PE of P2MP PW? > >> > >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both > >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have > >>both root and leaf AC and some only have leaf ACs)? > >>Regards, > >>Lucy > >> > >>Regards, > >> > >>Yuqun (Sam) Cao > >>E-mail: Yuqun.cao@gmail.com > >> > >> > >>-----Original Message----- > >>From: Daniel Cohn [mailto:DanielC@orckit.com] > >>Sent: Tuesday, April 17, 2012 4:56 PM > >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); > >>giles.heron@gmail.com; > >>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > >>Subject: RE: The status of the approaches to the E-Tree solution? > >> > >>Adding Sam (as l2vpn@ is holding messages) > >> > >>DC > >> > >>-----Original Message----- > >>From: Lucy yong [mailto:lucy.yong@huawei.com] > >>Sent: Tuesday, April 17, 2012 12:39 AM > >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); > >>giles.heron@gmail.com; simon.delord@gmail.com; > >>Alexander.Vainshtein@ecitele.com > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > >>Subject: RE: The status of the approaches to the E-Tree solution? > >> > >> > >>Snipped, > >> > >>As we discussed extensively in the list, and as reflected in giles > >>slide, 2 pws are only needed between pes with both root and leaf acs, > >>which will typically be a small minority. > >>[[LY]] Don't know if the assumption is true. Even it is the case, both > >>approaches can benefit from it. I was off for a while and captures some > >>discussions now. > >> > >>Also as per giles slide, dual vlan can have scalability issues due to > >>additional lookup and double use of vlans in internal emulated lan > >>interface. Also there are potential backward compatibility issues with > >>silicon that doesn't support vlan mapping. > >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am > >>not clear on all the issues. Could you be more specific? As I mentioned > >>in below, two PW approach makes VPLS transport construction and packet > >>forwarding more complex, I can see potential backward compatibility > >>issues with 2 PW solution. > >> > >>Regards, > >>Lucy > >> > >>Regards, > >> > >>Daniel > >> > >>Thumb typed - please be tolerant > >> > >>Lucy yong wrote: > >> > >>In my mind, the VLAN approach means dual vlan method. > >> > >>The main concern for CW approach is hardware support. > >> > >>Two PW approach can be complex too if the VPLS instance for E-Tree uses > >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown > unicast > >>traffic, and some P2MP PWs for multicast traffic. It may double all of > >>them. > >> > >>E-tree is an Ethernet service and there is already VLAN based solution > >>in IEEE, can we just utilize it without complicating VPLS transport > >>construction? This also makes interworking with Eth only network easier. > >> > >>Cheers, > >>Lucy > >> > >>-----Original Message----- > >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] > >>Sent: Monday, April 16, 2012 8:35 AM > >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; > >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' > >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; > >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; > >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' > >>Subject: RE: The status of the approaches to the E-Tree solution? > >> > >>I believe the initial question was in regard to the CW method. Are you > >>saying that you no longer are interested in that method in preference of > >>the dual vlan method? > >> > >> > >> > >>Lucy yong wrote: > >> > >> > >>Agree with Wim. VLAN approach is the best solution for E-Tree. > >> > >>Lucy > >> > >>-----Original Message----- > >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > >>Of Henderickx, Wim (Wim) > >>Sent: Thursday, April 12, 2012 2:03 AM > >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; > >>'Alexander.Vainshtein@ecitele.com' > >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; > >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; > >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' > >>Subject: Re: The status of the approaches to the E-Tree solution? > >> > >>The vlan approach is superior as it also works for eth only networks, > >>etc. On top some vendors indicate hw issues with the cw approach. As > >>such we have dropped more or less the cw approach. > >> > >>Cheers, > >>Wim > >>_________________ > >>sent from blackberry > >> > >>----- Original Message ----- > >>From: Giles Heron [mailto:giles.heron@gmail.com] > >>Sent: Thursday, April 12, 2012 08:22 AM > >>To: Simon Delord ; Alexander Vainshtein > >> > >>Cc: l2vpn@ietf.org ; Vladimir Kleiner > >>; Andrew Sergeev > >>; Idan Kaspit ; > >>Mishael Wexler ; Rotem Cohen > >> > >>Subject: Re: The status of the approaches to the E-Tree solution? > >> > >>Sorry - the "anonymous presentation" was mine. I should possibly have > >>put in a third column on the CW approach. And hopefully the minutes > >>will be posted soon. > >> > >>We had various discussions, as Simon stated, and consensus seemed to > be > >>forming around the two alternatives of two PWEs or two VLANs. I believe > >>three of the authors of the CW approach are also authors of the two VLAN > >>approach and one is also an author of the two PWE approach. So perhaps > >>it's best to let those four individuals say which approach they prefer > >>and why? > >> > >>Giles > >> > >>On 10/04/2012 00:45, "Simon Delord" wrote: > >> > >>> Hi Alexander, > >>> > >>> You are right, no discussion on the WG mailing list recently, but > >>> there have been substantial discussions among the authors of various > >>> solution drafts off the mailing list. As far as I know, no consensus > >>> yet before ietf83, not sure the progress in the Paris WG meeting. I > >>> think the CW approach has not been rejected by the WG yet, or the WG > >>> has not yet decided on which one to adopt. > >>> > >>> Simon > >>> > >>> 2012/4/8 Alexander Vainshtein > >>> > >>>> Hi all, > >>>> > >>>> Unfortunately I have not been able to attend the Paris IETF. > >>>> > >>>> However, looking up the L2VPN proceedings, I've found a short > >>>> anonymous presentation called "E-Tree Update" ( > >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). > >>>> This presentation discusses the differences of the E-Tree approaches > >>>> based on dedicated VLANs (as in > >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t > >>>> ext=1) and multiple PWs between the PEs (as in > >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple- > pw/?in > >>>> clude_te > >>>> xt=1) > >>>> and completely ignores the solution based on usage of the CW in the > >>>> PWs connecting the PEs (as in > >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t > >>>> ext=1 > >>>> ). > >>>> > >>>> > >>>> > >>>> The Minutes of the Paris L2VPN session are not yet available, but I > >>>> wonder whether the WG has taken a decision to reject the approach > >>>> based on the CW usage? I do not remember any recent discussion of > >>>> this topic on the WG mailing list. > >>>> > >>>> > >>>> > >>>> Regards, and lots of thanks in advance, > >>>> > >>>> Sasha > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> This e-mail message is intended for the recipient only and contains > >>>> information which is CONFIDENTIAL and which may be proprietary to > ECI > >> > >>>> Telecom. If you have received this transmission in error, please > >>>> inform us by e-mail, phone or fax, and then delete the original and > >>>> all copies thereof. > >>>> > >> > >> > >> > >> > >> > >>This E-mail and any of its attachments may contain Time Warner Cable > >>proprietary information, which is privileged, confidential, or subject > >>to copyright belonging to Time Warner Cable. This E-mail is intended > >>solely for the use of the individual or entity to which it is addressed. > >>If you are not the intended recipient of this E-mail, you are hereby > >>notified that any dissemination, distribution, copying, or action taken > >>in relation to the contents of and attachments to this E-mail is > >>strictly prohibited and may be unlawful. If you have received this > >>E-mail in error, please notify the sender immediately and permanently > >>delete the original and any copy of this E-mail and any printout. > >> > > > > > >This E-mail and any of its attachments may contain Time Warner Cable > >proprietary information, which is privileged, confidential, or subject to > >copyright belonging to Time Warner Cable. This E-mail is intended solely > >for the use of the individual or entity to which it is addressed. If you > >are not the intended recipient of this E-mail, you are hereby notified > >that any dissemination, distribution, copying, or action taken in > >relation to the contents of and attachments to this E-mail is strictly > >prohibited and may be unlawful. If you have received this E-mail in > >error, please notify the sender immediately and permanently delete the > >original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely for > the use of the individual or entity to which it is addressed. If you are not > the intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify the > sender immediately and permanently delete the original and any copy of > this > E-mail and any printout. > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us > by e-mail, phone or fax, and then delete the original and all copies > thereof. > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us > by e-mail, phone or fax, and then delete the original and all copies > thereof. > This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. From yuqun.cao@gmail.com Sat Apr 21 07:51:34 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F12921F85D2 for ; Sat, 21 Apr 2012 07:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 QzOclI9yTk6f for ; Sat, 21 Apr 2012 07:51:33 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D045221F85C3 for ; Sat, 21 Apr 2012 07:51:32 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so2181915pbb.31 for ; Sat, 21 Apr 2012 07:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:x-mailer:in-reply-to:thread-index:x-mimeole; bh=IyPm8oMz4u4wsjJyKUCJPJpy076S+LyGMEIEBG3xs7s=; b=ztiwiKtky3v+d47+0jQdE1nSiZ9P6xVwZ7B8VXijxisHDXXIBNj0TJDaqA7ZJNFjBt zEPYbiFOFuotQk6RBNUZnftU+5hy61TNIs6h16D5n/H3/QNaXmeZomed1P6SuEVU3cN6 klpveGjAyGYW9wGGd52V6lfAODJLxMtCRg78jjEi/XN6MPkfLtms7BBKILe9Hkr8T+mx n1R2CA8OXP5P87x+K/wUZDqQfwJviUnFgcfUmMtSQBagH3qfeNuWbSAz4Y8IxDgFs7Di 75g82rICIESbU63KrRVn3785btH441PVlfIdgRgtpWmHmtlC6eWxBUjGOPQxmQCONX2O BqQA== Received: by 10.68.219.34 with SMTP id pl2mr15517806pbc.56.1335019892234; Sat, 21 Apr 2012 07:51:32 -0700 (PDT) Received: from v2comsam ([36.248.16.95]) by mx.google.com with ESMTPS id r10sm8638224pbf.22.2012.04.21.07.51.25 (version=SSLv3 cipher=OTHER); Sat, 21 Apr 2012 07:51:30 -0700 (PDT) From: "Sam Cao" To: "'Lizhong Jin'" , "'Henderickx, Wim \(Wim\)'" References: <14C7F4F06DB5814AB0DE29716C4F6D6701296244C3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Subject: RE: The status of the approaches to the E-Tree solution? Date: Sat, 21 Apr 2012 22:51:28 +0800 Message-ID: <1B88357C808B432E871CA9D678305B7C@v2comsam> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0068_01CD2011.4D3E8C10" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac0fcx6tlnmtYO6ESBGd/Ct1B51r5gAQWyQg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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: Sat, 21 Apr 2012 14:51:35 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0068_01CD2011.4D3E8C10 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi all, =20 We reach an impasse:-). BTW, Meeting minutes is ready now. We can get E-tree summary from IETF site. =20 Today I collected all items we discussed before. They are, =20 1) Silicon issue or chip limit; 2) Network efficiency; 3) Encapsulation mode, tag or raw; 4) H-VPLS; 5) Backwards compatibility, especially legacy PE or Non-supporting = PE with IEEE E-tree support joins E-Tree domain; 6) Configuration change in operation, for example, Leaf-only -> Root-Leaf-Mixed; 7) S-VLAN preservation support; 8) Multi-segment PW; 9) VLAN ID allocation (Only for Dual-VLAN); 10) Multi-AS deployment; 11) ECMP; 12) P2MP-PW; 13) Ethernet OAM; =20 If we review the mail-list, CW approach has the following limits: 1) Chip limit. Please read reply from Giles and Wim; 2) Network efficiency: There are garbage fames which will be = dropped on egress PE since only egress PE can decide forward or drop frames = while it receives frames. Ingress PE can not decide forward or not. Yes, current solution can support Hub-Spoke configuration, but as we know, the configuration is not easy if the network is big. Dual-VLAN or Multi-PW approach can break communication between Leaf-Only PEs via signaling. 3) Backwards compatibility: Not all PEs supports control word. If = one can not support control word, it will not join E-Tree domain; =20 Dual VLAN has following limits: 1) Chip limit: As we know, we need to push one VLAN into frames = before MPLS encapsulation on ingress PE and stripe it out on egress PE. This is non-standard operation. Wait for confirmation from chip vendor; 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, but can NOT configure it at all in Spoke PW case; 3) Multi-PW: Rafi figures this out, but we don=A1=AFt think this = over at that time. I think that it also has same problem as H-VPLS has. 4) Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will stripe = S-VLAN ID; 5) Backward Compatibility: Just as Daniel mentioned, there is compatibility issue if legacy PE joins E-Tree domain. For me, I = don=A1=AFt get clear response from co-authors of Dual-VLAN. =20 For all approaches, we don=A1=AFt cover ECMP / Ethernet OAM till now.=20 =20 Is there anything missed?=20 =20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 _____ =20 From: Lizhong Jin [mailto:lizho.jin@gmail.com]=20 Sent: Saturday, April 21, 2012 11:59 AM To: Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; = yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? =20 Hi Win, Thank you for the answers. In that case, PE-rs should configure the root/leaf properties of VPWS, not on the remote PE of VPWS. And usually = on PE-rs, you could not figure out the accessing spoke PW is from PE-r of = VPWS or MTU-s. Unless having some additional indication in NMS, you even = don't know which spoke PW needs to do VLAN manipulation. I am not sure such = R/L configuration could be accepted from operational view. Hope to see more comments. Regards Lizhong =D4=DA 2012=C4=EA4=D4=C221=C8=D5=D0=C7=C6=DA=C1=F9=A3=ACHenderickx, Wim = (Wim) =D0=B4=B5=C0=A3=BA > The VPWS which terminates at the H-VPLS node is indicated to be root = or leaf and the procedures associated will do the VLAN manipulation > > =20 > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Lizhong Jin > Sent: vrijdag 20 april 2012 18:38 > To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com > Cc: yuqun.cao@gmail.com > Subject: RE: The status of the approaches to the E-Tree solution? > > =20 > > Hi, all, > The difference between 2-VLAN and CW approach is who will provide the = R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW = will carry R/L information for CW approach. > I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used = to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information? > > Thanks > Lizhong > >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 Apr 2012 04:38:36 +0000 >> From: Alexander Vainshtein >> To: "Rogers, Josh" , Lucy yong >> , Daniel Cohn , Sam = Cao >> >> Cc: "l2vpn@ietf.org" >> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID: >> = >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi all, >> I fully understand that that what I am going to say is not very = popular, but: >> >> IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, = and, in a more generic way, localization of effects of changes in the PE configuration. >> >> In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect only = the PE where this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a = more >> complex model. Wether outside s-tag is used to differentiate, or >> dedicated pw's are used for the same purpose, it seems both become = more >> complex. >> >> Gile's comparison slide still concisely captures the differences = between >> these methods, in my opinion. I haven't seen any new ideas or = thoughts >> brought to the group in the past week or two on the subject. I would hate >> for both proposed methods to die on the vine because we couldn't = decide >> between two methods that have nothing inherently wrong with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" wrote: >> >>>Send this again. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree = uses >>>P2P PW fo=20 ------=_NextPart_000_0068_01CD2011.4D3E8C10 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We reach an impasseJ.  BTW, Meeting minutes is ready now. We can get E-tree summary from IETF = site.

 

Today I collected all items we discussed = before. They are,

 

1)       = Silicon issue or chip limit;

2)       = Network efficiency;

3)       = Encapsulation mode, tag or raw;

4)       = H-VPLS;

5)       = Backwards compatibility, especially legacy PE or Non-supporting PE with IEEE = E-tree support joins E-Tree domain;

6)       = Configuration change in operation, for example, Leaf-only -> = Root-Leaf-Mixed;

=

7)       = S-VLAN preservation support;

8)       = Multi-segment PW;

9)       = VLAN ID allocation (Only for Dual-VLAN);

10)   = Multi-AS deployment;

11)   = ECMP;

12)   = P2MP-PW;

13)   = Ethernet OAM;

 <= /span>

If we review the mail-list, CW approach has the following = limits:

1)       Chip limit. Please read reply from Giles and = Wim;

2)       Network efficiency: There are garbage fames which will be = dropped on egress PE since only egress PE can decide forward or drop frames = while it receives frames. Ingress PE can not decide forward or not. = Yes, current solution can support Hub-Spoke configuration, but as we know, = the configuration is not easy if the network is big. Dual-VLAN or Multi-PW = approach can break communication between Leaf-Only PEs via = signaling.

3)       Backwards compatibility: Not all PEs supports control word. = If one can not support control word, it will not join E-Tree = domain;

 <= /span>

Dual VLAN has = following limits:

1)       Chip limit: As we know, we need to push one VLAN into frames = before MPLS encapsulation on ingress PE and stripe it out on egress PE. This is non-standard operation. Wait for confirmation from chip = vendor;

2)       HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, but can = NOT configure it at all in Spoke PW case;

3)       Multi-PW: Rafi figures this out, but we don=A1=AFt think = this over at that time. I think that it also has same problem as H-VPLS = has.

4)       Encapsulation mode: If deploy GVPLS with Spoke PW mode, = PE-rs should work in tagged mode, otherwise PE-rs or egress PE will stripe = S-VLAN ID;

5)       Backward Compatibility: Just as Daniel mentioned, there is compatibility issue if legacy PE joins E-Tree domain. For me, I = don=A1=AFt get clear response from co-authors of Dual-VLAN.

 <= /span>

For all = approaches, we don=A1=AFt cover ECMP / Ethernet OAM till now.

 <= /span>

Is there anything = missed?

 <= /span>

Regards,

 

=

Yuqun (Sam) Cao

E-mail: Yuqun.cao@gmail.com

 

From: Lizhong Jin [mailto:lizho.jin@gmail.com]
Sent: Saturday, April 21, = 2012 11:59 AM
To: Henderickx, Wim = (Wim)
Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; yuqun.cao@gmail.com
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Hi Win,
Thank you for the answers. In that case, PE-rs should configure the = root/leaf properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, = you could not figure out the accessing spoke PW is from PE-r of VPWS or = MTU-s. Unless having some additional indication in NMS, you even don't know = which spoke PW needs to do VLAN manipulation. I am not sure such R/L = configuration could be accepted from operational view. Hope to see more comments.

Regards
Lizhong


=D4=DA 2012=C4=EA4=D4=C221=C8=D5=D0=C7=C6=DA=C1=F9=A3=ACHenderickx, Wim (Wim) <wim.henderickx@alcatel-= lucent.com> =D0=B4=B5=C0=A3=BA
> The VPWS which terminates at the H-VPLS node is indicated to be = root or leaf and the procedures associated will do the VLAN manipulation
>
>  
>
> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin
> Sent: vrijdag 20 april 2012 18:38
> To: l2vpn@ietf.org; Alexander.Vainshtein@eci= tele.com
> Cc: yuqun.cao@gmail.com
> Subject: RE: The status of the approaches to the E-Tree = solution?
>
>  
>
> Hi, all,
> The difference between 2-VLAN and CW approach is who will provide = the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW = will carry R/L information for CW approach.
> I have a question with the 2-VLAN approach in H-VPLS where H-VPLS = is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds = VLAN to indicate R/L information?
>
> Thanks
> Lizhong
>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 19 Apr 2012 04:38:36 +0000
>> From: Alexander Vainshtein <Alexander.Vainshtein@eci= tele.com>
>> To: "Rogers, Josh" <josh.rogers@twcable.com>, = Lucy yong
>>        <lucy.yong@huawei.com>, Daniel Cohn <DanielC@orckit.com>, Sam Cao
>>        <yuqun.cao@gmail.com>
>> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
>> Subject: RE: The status of the approaches to the E-Tree = solution?
>> Message-ID:
>>        <F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>
>> Content-Type: text/plain; charset=3D"us-ascii"
>>
>> Hi all,
>> I fully understand that that what I am going to say is not very popular, but:
>>
>> IMO one of the advantages of the CW-based solution is that it = is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic.
>>
>> Another advantage is preservation of full mesh of P2P PWs in a = VPLS, and, in a more generic way, localization of effects of changes in the PE configuration.
>>
>> In particular, adding a Leaf AC to a PE that previously has = been only supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect only the = PE where this operation happens and not the rest of the PEs.
>>
>> As for the need for HW changes that have been mentioned as a = main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution.
>>
>> My 2c,
>>     Sasha
>>
>>
>>
>> ________________________________________
>> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] = on behalf of Rogers, Josh [josh.rogers@twcable.com]
>> Sent: Wednesday, April 18, 2012 9:57 PM
>> To: Lucy yong; Daniel Cohn; Sam Cao
>> Cc: l2vpn@ietf.org
>> Subject: Re: The status of the approaches to the E-Tree = solution?
>>
>> Again, the P2MP situation throws me.  Is this something = that is used
>> commonly?
>>
>> I'm under the impression that adding P2MP to any model results = in a more
>> complex model.  Wether outside s-tag is used to = differentiate, or
>> dedicated pw's are used for the same purpose, it seems both = become more
>> complex.
>>
>> Gile's comparison slide still concisely captures the = differences between
>> these methods, in my opinion.  I haven't seen any new = ideas or thoughts
>> brought to the group in the past week or two on the subject. =  I would hate
>> for both proposed methods to die on the vine because we = couldn't decide
>> between two methods that have nothing inherently wrong with = either.
>>
>> -Josh
>>
>>
>> On 4/18/12 1:53 PM, "Lucy yong" <lucy.yong@huawei.com> = wrote:
>>
>>>Send this again.
>>>
>>>Two PW approach can be complex too if the VPLS instance for = E-Tree uses
>>>P2P PW fo

------=_NextPart_000_0068_01CD2011.4D3E8C10-- From josh.rogers@twcable.com Sat Apr 21 08:03:16 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C55221F85C7 for ; Sat, 21 Apr 2012 08:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.12 X-Spam-Level: X-Spam-Status: No, score=-0.12 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WR6FP9uXsaB for ; Sat, 21 Apr 2012 08:03:14 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 50B1921F85AA for ; Sat, 21 Apr 2012 08:03:14 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,459,1330923600"; d="scan'208,217";a="370774356" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 21 Apr 2012 11:02:18 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Sat, 21 Apr 2012 11:03:09 -0400 From: "Rogers, Josh" To: Sam Cao , 'Lizhong Jin' , "'Henderickx, Wim (Wim)'" Date: Sat, 21 Apr 2012 11:02:51 -0400 Subject: Re: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fz91fQqD0AjinQOKPx+HMMlhYSg== Message-ID: In-Reply-To: <1B88357C808B432E871CA9D678305B7C@v2comsam> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBB83462C03joshrogerstwcablecom_" MIME-Version: 1.0 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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: Sat, 21 Apr 2012 15:03:16 -0000 --_000_CBB83462C03joshrogerstwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2FtPyAgV2hlcmUgaXMgdGhlIGxpc3QgZm9yIG11bHRpLVBXIG1ldGhvZD8NCg0KT25lIGl0ZW0g SSBkb24ndCB0aGluayBpcyBjb3ZlcmVkIGluIHlvdXIgMlZMQU4gbGlzdCwgaXMgd2hlcmUgc2Vy dmljZSBtdWx0aXBsZXhlZCBVTkkncyBhcmUgaW52b2x2ZWQsIG9yIGFueSB0aW1lIHRoZXJlIGlz IGEgbGF5ZXIgMiBDUEUgYmV0d2VlbiBQRSBhbmQgQ0UsIHRoZXNlIGRldmljZXMgdXN1YWxseSBl eHBlY3QgYSBzaW5nbGUsIGJpZGlyZWN0aW9uYWwgcy10YWcsIGFuZCBhY2NvcmRpbmcgdG8geW91 ciBleHBsYW5hdGlvbiB0aGlzIG1vcm5pbmcsIGNvb3JkaW5hdGluZyB0aGUgUy1UYWdzIHVzZWQg Zm9yIEVUUkVFIHdpdGggdGhlIGN1c3RvbWVyIFNIT1VMRCBOT1QgdG8gYmUgZG9uZSwgdGhlcmVm b3IgdGhlcmUgbXVzdCBiZSBhbiAnaW5uZXIgUy1UYWcnIG9uIHRoZSBBQywgYW5kIGFuICdvdXRl ciBTLVRhZycgaW4gdGhlIFBXLg0KDQpXaGlsZSBpbnNpZGUgdGhlIFBXLCBhIDJWTEFOIG1ldGhv ZCBmcmFtZSB3b3VsZCBsb29rIGxpa2U6DQoNCistLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0t LS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0rDQp8TVBMUyBMYWJlbCB8IFIvTCBTLVRh ZyB8IEFDIFMtVGFnIHwgQy10YWcgfCBMYXllciAyIFBheWxvYWQgfA0KKy0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSsNCg0KQ29ycmVj dD8NCg0KV291bGQgeW91IGNvbnNpZGVyIHRoaXMgYW4gJ2lzc3VlJyBvciBqdXN0IGEgJ2NvbXBs aWNhdGlvbicgPw0KDQpBIGxvdCBvZiB0aGUgJ3BybyAyVkxBTicgYXJndW1lbnQgaGFzIGJlZW4g Y2VudGVyZWQgYXJvdW5kIGV4aXN0aW5nIElFRUUgc3RhbmRhcmQsIGFuZCBhdCBmaXJzdCBpdCBz b3VuZGVkIGxpa2UgdGhpcyB3YXMgYmV0dGVyL3Byb3Bvc2VkIGZvciB0aGUgYWJpbGl0eSB0byBl eHRlbmQgdGhlIFIvTCBTLXRhZyBiZXlvbmQgdGhlIFBXLCBidXQgaXQgc291bmRzIGxpa2UgdGhh dCBpc24ndCByZWFsbHkgYW4gb3B0aW9uLCBzbyBJJ20gbm90IHN1cmUgdGhhdCBpcyBhIHZhbGlk IGJlbmVmaXQvZHJpdmVyLg0KDQpUaGFua3MgbXVjaCwNCkpvc2gNCg0KRnJvbTogU2FtIENhbyA8 eXVxdW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbT4+DQpUbzogJ0xp emhvbmcgSmluJyA8bGl6aG8uamluQGdtYWlsLmNvbTxtYWlsdG86bGl6aG8uamluQGdtYWlsLmNv bT4+LCAiJ0hlbmRlcmlja3gsIFdpbSAoV2ltKSciIDx3aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1 Y2VudC5jb208bWFpbHRvOndpbS5oZW5kZXJpY2t4QGFsY2F0ZWwtbHVjZW50LmNvbT4+DQpDYzog ImwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4iIDxsMnZwbkBpZXRmLm9yZzxt YWlsdG86bDJ2cG5AaWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFw cHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCg0KSGkgYWxsLA0KDQpXZSByZWFjaCBh biBpbXBhc3Nl4pi6LiAgQlRXLCBNZWV0aW5nIG1pbnV0ZXMgaXMgcmVhZHkgbm93LiBXZSBjYW4g Z2V0IEUtdHJlZSBzdW1tYXJ5IGZyb20gSUVURiBzaXRlLg0KDQpUb2RheSBJIGNvbGxlY3RlZCBh bGwgaXRlbXMgd2UgZGlzY3Vzc2VkIGJlZm9yZS4gVGhleSBhcmUsDQoNCjEpICAgICAgIFNpbGlj b24gaXNzdWUgb3IgY2hpcCBsaW1pdDsNCjIpICAgICAgIE5ldHdvcmsgZWZmaWNpZW5jeTsNCjMp ICAgICAgIEVuY2Fwc3VsYXRpb24gbW9kZSwgdGFnIG9yIHJhdzsNCjQpICAgICAgIEgtVlBMUzsN CjUpICAgICAgIEJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LCBlc3BlY2lhbGx5IGxlZ2FjeSBQRSBv ciBOb24tc3VwcG9ydGluZyBQRSB3aXRoIElFRUUgRS10cmVlIHN1cHBvcnQgam9pbnMgRS1UcmVl IGRvbWFpbjsNCjYpICAgICAgIENvbmZpZ3VyYXRpb24gY2hhbmdlIGluIG9wZXJhdGlvbiwgZm9y IGV4YW1wbGUsIExlYWYtb25seSAtPiBSb290LUxlYWYtTWl4ZWQ7DQo3KSAgICAgICBTLVZMQU4g cHJlc2VydmF0aW9uIHN1cHBvcnQ7DQo4KSAgICAgICBNdWx0aS1zZWdtZW50IFBXOw0KOSkgICAg ICAgVkxBTiBJRCBhbGxvY2F0aW9uIChPbmx5IGZvciBEdWFsLVZMQU4pOw0KMTApICAgTXVsdGkt QVMgZGVwbG95bWVudDsNCjExKSAgIEVDTVA7DQoxMikgICBQMk1QLVBXOw0KMTMpICAgRXRoZXJu ZXQgT0FNOw0KDQpJZiB3ZSByZXZpZXcgdGhlIG1haWwtbGlzdCwgQ1cgYXBwcm9hY2ggaGFzIHRo ZSBmb2xsb3dpbmcgbGltaXRzOg0KMSkgICAgICAgQ2hpcCBsaW1pdC4gUGxlYXNlIHJlYWQgcmVw bHkgZnJvbSBHaWxlcyBhbmQgV2ltOw0KMikgICAgICAgTmV0d29yayBlZmZpY2llbmN5OiBUaGVy ZSBhcmUgZ2FyYmFnZSBmYW1lcyB3aGljaCB3aWxsIGJlIGRyb3BwZWQgb24gZWdyZXNzIFBFIHNp bmNlIG9ubHkgZWdyZXNzIFBFIGNhbiBkZWNpZGUgZm9yd2FyZCBvciBkcm9wIGZyYW1lcyB3aGls ZSBpdCByZWNlaXZlcyBmcmFtZXMuIEluZ3Jlc3MgUEUgY2FuIG5vdCBkZWNpZGUgZm9yd2FyZCBv ciBub3QuIFllcywgY3VycmVudCBzb2x1dGlvbiBjYW4gc3VwcG9ydCBIdWItU3Bva2UgY29uZmln dXJhdGlvbiwgYnV0IGFzIHdlIGtub3csIHRoZSBjb25maWd1cmF0aW9uIGlzIG5vdCBlYXN5IGlm IHRoZSBuZXR3b3JrIGlzIGJpZy4gRHVhbC1WTEFOIG9yIE11bHRpLVBXIGFwcHJvYWNoIGNhbiBi cmVhayBjb21tdW5pY2F0aW9uIGJldHdlZW4gTGVhZi1Pbmx5IFBFcyB2aWEgc2lnbmFsaW5nLg0K MykgICAgICAgQmFja3dhcmRzIGNvbXBhdGliaWxpdHk6IE5vdCBhbGwgUEVzIHN1cHBvcnRzIGNv bnRyb2wgd29yZC4gSWYgb25lIGNhbiBub3Qgc3VwcG9ydCBjb250cm9sIHdvcmQsIGl0IHdpbGwg bm90IGpvaW4gRS1UcmVlIGRvbWFpbjsNCg0KRHVhbCBWTEFOIGhhcyBmb2xsb3dpbmcgbGltaXRz Og0KMSkgICAgICAgQ2hpcCBsaW1pdDogQXMgd2Uga25vdywgd2UgbmVlZCB0byBwdXNoIG9uZSBW TEFOIGludG8gZnJhbWVzIGJlZm9yZSBNUExTIGVuY2Fwc3VsYXRpb24gb24gaW5ncmVzcyBQRSBh bmQgc3RyaXBlIGl0IG91dCBvbiBlZ3Jlc3MgUEUuIFRoaXMgaXMgbm9uLXN0YW5kYXJkIG9wZXJh dGlvbi4gV2FpdCBmb3IgY29uZmlybWF0aW9uIGZyb20gY2hpcCB2ZW5kb3I7DQoyKSAgICAgICBI VlBMUzogSWYgd2UgZm9sbG93IEZpZyAzIG9yIEZpZyA0IGluIFJGQyA0NzYyIHRvIGRlcGxveSBI VlBMUywgUEUtcnMgd29ya3MgaW4gZGlmZmVyZW50IG1hbm5lciwgUEUtcnMgc2hvdWxkIGZpZ3Vy ZSBvdXQgQUMgdHlwZSBpbiBWUFdTIGNhc2UsIGJ1dCBjYW4gTk9UIGNvbmZpZ3VyZSBpdCBhdCBh bGwgaW4gU3Bva2UgUFcgY2FzZTsNCjMpICAgICAgIE11bHRpLVBXOiBSYWZpIGZpZ3VyZXMgdGhp cyBvdXQsIGJ1dCB3ZSBkb27igJl0IHRoaW5rIHRoaXMgb3ZlciBhdCB0aGF0IHRpbWUuIEkgdGhp bmsgdGhhdCBpdCBhbHNvIGhhcyBzYW1lIHByb2JsZW0gYXMgSC1WUExTIGhhcy4NCjQpICAgICAg IEVuY2Fwc3VsYXRpb24gbW9kZTogSWYgZGVwbG95IEdWUExTIHdpdGggU3Bva2UgUFcgbW9kZSwg UEUtcnMgc2hvdWxkIHdvcmsgaW4gdGFnZ2VkIG1vZGUsIG90aGVyd2lzZSBQRS1ycyBvciBlZ3Jl c3MgUEUgd2lsbCBzdHJpcGUgUy1WTEFOIElEOw0KNSkgICAgICAgQmFja3dhcmQgQ29tcGF0aWJp bGl0eTogSnVzdCBhcyBEYW5pZWwgbWVudGlvbmVkLCB0aGVyZSBpcyBjb21wYXRpYmlsaXR5IGlz c3VlIGlmIGxlZ2FjeSBQRSBqb2lucyBFLVRyZWUgZG9tYWluLiBGb3IgbWUsIEkgZG9u4oCZdCBn ZXQgY2xlYXIgcmVzcG9uc2UgZnJvbSBjby1hdXRob3JzIG9mIER1YWwtVkxBTi4NCg0KRm9yIGFs bCBhcHByb2FjaGVzLCB3ZSBkb27igJl0IGNvdmVyIEVDTVAgLyBFdGhlcm5ldCBPQU0gdGlsbCBu b3cuDQoNCklzIHRoZXJlIGFueXRoaW5nIG1pc3NlZD8NCg0KUmVnYXJkcywNCg0KWXVxdW4gKFNh bSkgQ2FvDQpFLW1haWw6IFl1cXVuLmNhb0BnbWFpbC5jb208bWFpbHRvOll1cXVuLmNhb0BnbWFp bC5jb20+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBMaXpob25n IEppbiBbbWFpbHRvOmxpemhvLmppbkBnbWFpbC5jb21dDQpTZW50OiBTYXR1cmRheSwgQXByaWwg MjEsIDIwMTIgMTE6NTkgQU0NClRvOiBIZW5kZXJpY2t4LCBXaW0gKFdpbSkNCkNjOiBsMnZwbkBp ZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0 ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+OyB5dXF1bi5j YW9AZ21haWwuY29tPG1haWx0bzp5dXF1bi5jYW9AZ21haWwuY29tPg0KU3ViamVjdDogUkU6IFRo ZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCg0KSGkg V2luLA0KVGhhbmsgeW91IGZvciB0aGUgYW5zd2Vycy4gSW4gdGhhdCBjYXNlLCBQRS1ycyBzaG91 bGQgY29uZmlndXJlIHRoZSByb290L2xlYWYgcHJvcGVydGllcyBvZiBWUFdTLCBub3Qgb24gdGhl IHJlbW90ZSBQRSBvZiBWUFdTLiBBbmQgdXN1YWxseSBvbiBQRS1ycywgeW91IGNvdWxkIG5vdCBm aWd1cmUgb3V0IHRoZSBhY2Nlc3Npbmcgc3Bva2UgUFcgaXMgZnJvbSBQRS1yIG9mIFZQV1Mgb3Ig TVRVLXMuIFVubGVzcyBoYXZpbmcgc29tZSBhZGRpdGlvbmFsIGluZGljYXRpb24gaW4gTk1TLCB5 b3UgZXZlbiBkb24ndCBrbm93IHdoaWNoIHNwb2tlIFBXIG5lZWRzIHRvIGRvIFZMQU4gbWFuaXB1 bGF0aW9uLiBJIGFtIG5vdCBzdXJlIHN1Y2ggUi9MIGNvbmZpZ3VyYXRpb24gY291bGQgYmUgYWNj ZXB0ZWQgZnJvbSBvcGVyYXRpb25hbCB2aWV3LiBIb3BlIHRvIHNlZSBtb3JlIGNvbW1lbnRzLg0K DQpSZWdhcmRzDQpMaXpob25nDQoNCg0K5ZyoIDIwMTLlubQ05pyIMjHml6XmmJ/mnJ/lha3vvIxI ZW5kZXJpY2t4LCBXaW0gKFdpbSkgPHdpbS5oZW5kZXJpY2t4QGFsY2F0ZWwtbHVjZW50LmNvbTxt YWlsdG86d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29tPj4g5YaZ6YGT77yaDQo+IFRo ZSBWUFdTIHdoaWNoIHRlcm1pbmF0ZXMgYXQgdGhlIEgtVlBMUyBub2RlIGlzIGluZGljYXRlZCB0 byBiZSByb290IG9yIGxlYWYgYW5kIHRoZSBwcm9jZWR1cmVzIGFzc29jaWF0ZWQgd2lsbCBkbyB0 aGUgVkxBTiBtYW5pcHVsYXRpb24NCj4NCj4NCj4NCj4gRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpsMnZwbi1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIExp emhvbmcgSmluDQo+IFNlbnQ6IHZyaWpkYWcgMjAgYXByaWwgMjAxMiAxODozOA0KPiBUbzogbDJ2 cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPjsgQWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPg0KPiBD YzogeXVxdW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbT4NCj4gU3Vi amVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1 dGlvbj8NCj4NCj4NCj4NCj4gSGksIGFsbCwNCj4gVGhlIGRpZmZlcmVuY2UgYmV0d2VlbiAyLVZM QU4gYW5kIENXIGFwcHJvYWNoIGlzIHdobyB3aWxsIHByb3ZpZGUgdGhlIFIvTCBpbmZvcm1hdGlv biwgY3VzdG9tZXIgcGF5bG9hZCBvciBQVz8gVGhlIGN1c3RvbWVyIHBheWxvYWQgd2lsbCBiZSBh bHdheXMgbW9kaWZpZWQgdG8gY2FycnkgUi9MIGluZm9ybWF0aW9uIGluIDItVkxBTiBhcHByb2Fj aCwgd2hpbGUgUFcgd2l0aCBDVyB3aWxsIGNhcnJ5IFIvTCBpbmZvcm1hdGlvbiBmb3IgQ1cgYXBw cm9hY2guDQo+IEkgaGF2ZSBhIHF1ZXN0aW9uIHdpdGggdGhlIDItVkxBTiBhcHByb2FjaCBpbiBI LVZQTFMgd2hlcmUgSC1WUExTIGlzIGFjY2Vzc2VkIGJ5IFZQV1MgYXMgZGVzY3JpYmVkIGluIFJG QzQ2NzIgc2VjdGlvbiAxMC4xLjMuIElmIFZQV1MgaXMgdXNlZCB0byBhY2Nlc3MgSC1WUExTLCBo b3cgY291bGQgdGhlIFBFIG9uIFZQV1Mgc2lkZSBhZGRzIFZMQU4gdG8gaW5kaWNhdGUgUi9MIGlu Zm9ybWF0aW9uPw0KPg0KPiBUaGFua3MNCj4gTGl6aG9uZw0KPg0KPj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+Pg0KPj4gTWVzc2FnZTogMg0KPj4gRGF0ZTogVGh1LCAxOSBBcHIg MjAxMiAwNDozODozNiArMDAwMA0KPj4gRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbT4+DQo+PiBUbzogIlJvZ2VycywgSm9zaCIgPGpvc2gucm9nZXJzQHR3Y2FibGUu Y29tPG1haWx0bzpqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbT4+LCBMdWN5IHlvbmcNCj4+ICAgICAg ICA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4sIERh bmllbCBDb2huIDxEYW5pZWxDQG9yY2tpdC5jb208bWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbT4+ LCBTYW0gQ2FvDQo+PiAgICAgICAgPHl1cXVuLmNhb0BnbWFpbC5jb208bWFpbHRvOnl1cXVuLmNh b0BnbWFpbC5jb20+Pg0KPj4gQ2M6ICJsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5v cmc+IiA8bDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPj4NCj4+IFN1YmplY3Q6 IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/ DQo+PiBNZXNzYWdlLUlEOg0KPj4gICAgICAgIDxGOTMzNjU3MTczMUFERTQyQTUzOTdGQzgzMUNF QUEwMjAzNDE5MkBGUklEV1BQTUIwMDIuZWNpdGVsZS5jb208bWFpbHRvOkY5MzM2NTcxNzMxQURF NDJBNTM5N0ZDODMxQ0VBQTAyMDM0MTkyQEZSSURXUFBNQjAwMi5lY2l0ZWxlLmNvbT4+DQo+PiBD b250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9InVzLWFzY2lpIg0KPj4NCj4+IEhpIGFs bCwNCj4+IEkgZnVsbHkgdW5kZXJzdGFuZCB0aGF0IHRoYXQgd2hhdCBJIGFtIGdvaW5nIHRvIHNh eSBpcyBub3QgdmVyeSBwb3B1bGFyLCBidXQ6DQo+Pg0KPj4gSU1PIG9uZSBvZiB0aGUgYWR2YW50 YWdlcyBvZiB0aGUgQ1ctYmFzZWQgc29sdXRpb24gaXMgdGhhdCBpdCBpcyBvcnRob2dvbmFsIHRv IHVzYWdlIChvciBub24tdXNhZ2UpIG9mIFAyTVAgUFdzIGZvciBlZmZlY3RpdmUgZGVsaXZlcnkg b2YgQlVOIHRyYWZmaWMuDQo+Pg0KPj4gQW5vdGhlciBhZHZhbnRhZ2UgaXMgcHJlc2VydmF0aW9u IG9mIGZ1bGwgbWVzaCBvZiBQMlAgUFdzIGluIGEgVlBMUywgYW5kLCBpbiBhIG1vcmUgZ2VuZXJp YyB3YXksIGxvY2FsaXphdGlvbiBvZiBlZmZlY3RzIG9mIGNoYW5nZXMgaW4gdGhlIFBFIGNvbmZp Z3VyYXRpb24uDQo+Pg0KPj4gSW4gcGFydGljdWxhciwgYWRkaW5nIGEgTGVhZiBBQyB0byBhIFBF IHRoYXQgcHJldmlvdXNseSBoYXMgYmVlbiBvbmx5IHN1cHBvcnRpbmcgUm9vdCBBQ3MgKG9yIHZp Y2UgdmVyc2EpLCByZW1vdmFsIG9mIHRoZSBsYXN0IExlYWYgb3IgbGFzdCBSb290IEFDIGZyb20g YSBQRSB0aGF0IHByZXZpb3VzbHkgaGFzIGJlZW4gc3VwcG9ydGluZyBhIG1peCBldGMuIGFmZmVj dCBvbmx5IHRoZSBQRSB3aGVyZSB0aGlzIG9wZXJhdGlvbiBoYXBwZW5zIGFuZCBub3QgdGhlIHJl c3Qgb2YgdGhlIFBFcy4NCj4+DQo+PiBBcyBmb3IgdGhlIG5lZWQgZm9yIEhXIGNoYW5nZXMgdGhh dCBoYXZlIGJlZW4gbWVudGlvbmVkIGFzIGEgbWFpbiBkaXNhZHZhbnRhZ2Ugb2YgdGhlIENXLWJh c2VkIGFwcHJvYWNoIC0gSSBiZWxpZXZlIGl0IHN0cm9uZ2x5IGRlcGVuZHMgb24gc3BlY2lmaWMg aW1wbGVtZW50YXRpb25zLiBBbmQgc29tZSBjaGFuZ2VzIGluIHRoZSBmb3J3YXJkaW5nIHByb2Nl c3MgYXJlIHJlcXVpcmVkIGluIGFueSBzb2x1dGlvbi4NCj4+DQo+PiBNeSAyYywNCj4+ICAgICBT YXNoYQ0KPj4NCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bDJ2cG4tYm91bmNl c0BpZXRmLm9yZz4gW2wydnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJvdW5jZXNA aWV0Zi5vcmc+XSBvbiBiZWhhbGYgb2YgUm9nZXJzLCBKb3NoIFtqb3NoLnJvZ2Vyc0B0d2NhYmxl LmNvbTxtYWlsdG86am9zaC5yb2dlcnNAdHdjYWJsZS5jb20+XQ0KPj4gU2VudDogV2VkbmVzZGF5 LCBBcHJpbCAxOCwgMjAxMiA5OjU3IFBNDQo+PiBUbzogTHVjeSB5b25nOyBEYW5pZWwgQ29objsg U2FtIENhbw0KPj4gQ2M6IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4NCj4+ IFN1YmplY3Q6IFJlOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUg c29sdXRpb24/DQo+Pg0KPj4gQWdhaW4sIHRoZSBQMk1QIHNpdHVhdGlvbiB0aHJvd3MgbWUuICBJ cyB0aGlzIHNvbWV0aGluZyB0aGF0IGlzIHVzZWQNCj4+IGNvbW1vbmx5Pw0KPj4NCj4+IEknbSB1 bmRlciB0aGUgaW1wcmVzc2lvbiB0aGF0IGFkZGluZyBQMk1QIHRvIGFueSBtb2RlbCByZXN1bHRz IGluIGEgbW9yZQ0KPj4gY29tcGxleCBtb2RlbC4gIFdldGhlciBvdXRzaWRlIHMtdGFnIGlzIHVz ZWQgdG8gZGlmZmVyZW50aWF0ZSwgb3INCj4+IGRlZGljYXRlZCBwdydzIGFyZSB1c2VkIGZvciB0 aGUgc2FtZSBwdXJwb3NlLCBpdCBzZWVtcyBib3RoIGJlY29tZSBtb3JlDQo+PiBjb21wbGV4Lg0K Pj4NCj4+IEdpbGUncyBjb21wYXJpc29uIHNsaWRlIHN0aWxsIGNvbmNpc2VseSBjYXB0dXJlcyB0 aGUgZGlmZmVyZW5jZXMgYmV0d2Vlbg0KPj4gdGhlc2UgbWV0aG9kcywgaW4gbXkgb3Bpbmlvbi4g IEkgaGF2ZW4ndCBzZWVuIGFueSBuZXcgaWRlYXMgb3IgdGhvdWdodHMNCj4+IGJyb3VnaHQgdG8g dGhlIGdyb3VwIGluIHRoZSBwYXN0IHdlZWsgb3IgdHdvIG9uIHRoZSBzdWJqZWN0LiAgSSB3b3Vs ZCBoYXRlDQo+PiBmb3IgYm90aCBwcm9wb3NlZCBtZXRob2RzIHRvIGRpZSBvbiB0aGUgdmluZSBi ZWNhdXNlIHdlIGNvdWxkbid0IGRlY2lkZQ0KPj4gYmV0d2VlbiB0d28gbWV0aG9kcyB0aGF0IGhh dmUgbm90aGluZyBpbmhlcmVudGx5IHdyb25nIHdpdGggZWl0aGVyLg0KPj4NCj4+IC1Kb3NoDQo+ Pg0KPj4NCj4+IE9uIDQvMTgvMTIgMTo1MyBQTSwgIkx1Y3kgeW9uZyIgPGx1Y3kueW9uZ0BodWF3 ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KPj4NCj4+PlNlbmQg dGhpcyBhZ2Fpbi4NCj4+Pg0KPj4+VHdvIFBXIGFwcHJvYWNoIGNhbiBiZSBjb21wbGV4IHRvbyBp ZiB0aGUgVlBMUyBpbnN0YW5jZSBmb3IgRS1UcmVlIHVzZXMNCj4+PlAyUCBQVyBmbw0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5m b3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0 byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBp cyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5 IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkg ZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4g cmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFp bCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg aW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBj b3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= --_000_CBB83462C03joshrogerstwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyAiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+ U2FtPyAmbmJzcDtXaGVyZSBpcyB0aGUgbGlzdCBmb3IgbXVsdGktUFcgbWV0aG9kPyAmbmJzcDs8 L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPjxi cj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 ICI+T25lIGl0ZW0gSSBkb24ndCB0aGluayBpcyBjb3ZlcmVkIGluIHlvdXIgMlZMQU4gbGlzdCwg aXMgd2hlcmUgc2VydmljZSBtdWx0aXBsZXhlZCBVTkkncyBhcmUgaW52b2x2ZWQsIG9yIGFueSB0 aW1lIHRoZXJlIGlzIGEgbGF5ZXIgMiBDUEUgYmV0d2VlbiBQRSBhbmQgQ0UsIHRoZXNlIGRldmlj ZXMgdXN1YWxseSBleHBlY3QgYSBzaW5nbGUsIGJpZGlyZWN0aW9uYWwNCiBzLXRhZywgYW5kIGFj Y29yZGluZyB0byB5b3VyIGV4cGxhbmF0aW9uIHRoaXMgbW9ybmluZywgY29vcmRpbmF0aW5nIHRo ZSBTLVRhZ3MgdXNlZCBmb3IgRVRSRUUgd2l0aCB0aGUgY3VzdG9tZXIgU0hPVUxEIE5PVCB0byBi ZSBkb25lLCB0aGVyZWZvciB0aGVyZSBtdXN0IGJlIGFuICdpbm5lciBTLVRhZycgb24gdGhlIEFD LCBhbmQgYW4gJ291dGVyIFMtVGFnJyBpbiB0aGUgUFcuICZuYnNwOzwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+PGJyPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj5XaGlsZSBpbnNpZGUg dGhlIFBXLCBhIDJWTEFOIG1ldGhvZCBmcmFtZSB3b3VsZCBsb29rIGxpa2U6PC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj48YnI+DQo8L2Rpdj4N CjxkaXY+PGZvbnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIGZhY2U9IkNvbnNvbGFzIj4mIzQz Oy0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLSYjNDM7LS0tLS0tLSYj NDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQzOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY2xhc3M9 IkFwcGxlLXN0eWxlLXNwYW4iIGZhY2U9IkNvbnNvbGFzIj58TVBMUyBMYWJlbCB8IFIvTCBTLVRh ZyB8IEFDIFMtVGFnIHwgQy10YWcgfCBMYXllciAyIFBheWxvYWQgfDwvZm9udD48L2Rpdj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPjxzcGFuIGNsYXNz PSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmk7ICI+DQo8ZGl2 Pjxmb250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBmYWNlPSJDb25zb2xhcyI+JiM0MzstLS0t LS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0mIzQzOy0tLS0tLS0mIzQzOy0t LS0tLS0tLS0tLS0tLS0tJiM0Mzs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGNsYXNzPSJBcHBs ZS1zdHlsZS1zcGFuIiBmYWNlPSJDb25zb2xhcyI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj48 Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iQ29uc29sYXMiPkNvcnJlY3Q/PC9m b250PjwvZGl2Pg0KPGRpdj48Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iQ29u c29sYXMiPjxicj4NCjwvZm9udD48L2Rpdj4NCjwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5 bGUtc3BhbiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyAiPg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+V291bGQgeW91IGNvbnNpZGVyIHRoaXMg YW4gJ2lzc3VlJyBvciBqdXN0IGEgJ2NvbXBsaWNhdGlvbicgPzwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+QSBsb3Qgb2YgdGhlICdwcm8gMlZMQU4nIGFyZ3VtZW50IGhhcyBiZWVuIGNl bnRlcmVkIGFyb3VuZCBleGlzdGluZyBJRUVFIHN0YW5kYXJkLCBhbmQgYXQgZmlyc3QgaXQgc291 bmRlZCBsaWtlIHRoaXMgd2FzIGJldHRlci9wcm9wb3NlZCBmb3IgdGhlIGFiaWxpdHkgdG8gZXh0 ZW5kIHRoZSBSL0wgUy10YWcgYmV5b25kIHRoZSBQVywgYnV0IGl0IHNvdW5kcyBsaWtlIHRoYXQg aXNuJ3QgcmVhbGx5IGFuIG9wdGlvbiwgc28gSSdtIG5vdCBzdXJlDQogdGhhdCBpcyBhIHZhbGlk IGJlbmVmaXQvZHJpdmVyLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzIG11 Y2gsPC9kaXY+DQo8ZGl2Pkpvc2g8L2Rpdj4NCjwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5 bGUtc3BhbiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyAiPg0KPGRpdj48Zm9udCBjbGFz cz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iQ29uc29sYXMiPjxicj4NCjwvZm9udD48L2Rpdj4N Cjwvc3Bhbj48L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7 IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBB RERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47 IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25l OyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9t OiA8L3NwYW4+U2FtIENhbyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnl1cXVuLmNhb0BnbWFpbC5jb20i Pnl1cXVuLmNhb0BnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5UbzogPC9zcGFuPidMaXpob25nIEppbicgJmx0OzxhIGhyZWY9Im1haWx0bzpsaXpo by5qaW5AZ21haWwuY29tIj5saXpoby5qaW5AZ21haWwuY29tPC9hPiZndDssICZxdW90OydIZW5k ZXJpY2t4LCBXaW0gKFdpbSknJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86d2ltLmhlbmRlcmlj a3hAYWxjYXRlbC1sdWNlbnQuY29tIj53aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5jb208 L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZx dW90OzxhIGhyZWY9Im1haWx0bzpsMnZwbkBpZXRmLm9yZyI+bDJ2cG5AaWV0Zi5vcmc8L2E+JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bDJ2cG5AaWV0Zi5vcmciPmwydnBuQGlldGYub3JnPC9h PiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFu PlJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/ PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1h cy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpv ZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3 b3JkIiB4bWxuczpzdDE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFn cyIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMSAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8IS0tW2lmICFtc29dPg0KPHN0eWxlPg0Kdlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZN TCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6 dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9 DQo8L3N0eWxlPg0KPCFbZW5kaWZdLS0+PG86c21hcnR0YWd0eXBlIG5hbWVzcGFjZXVyaT0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIiBuYW1lPSJTdGF0ZSI+PG86 c21hcnR0YWd0eXBlIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6c21hcnR0YWdzIiBuYW1lPSJDaXR5Ij48bzpzbWFydHRhZ3R5cGUgbmFtZXNwYWNldXJpPSJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiIG5hbWU9InBsYWNlIj48 bzpzbWFydHRhZ3R5cGUgbmFtZXNwYWNldXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9m ZmljZTpzbWFydHRhZ3MiIG5hbWU9ImNoc2RhdGUiPjxvOnNtYXJ0dGFndHlwZSBuYW1lc3BhY2V1 cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyIgbmFtZT0iY2ht ZXRjbnYiPjwhLS1baWYgIW1zb10+DQo8c3R5bGU+DQpzdDFcOip7YmVoYXZpb3I6dXJsKCNkZWZh dWx0I2llb291aSkgfQ0KPC9zdHlsZT4NCjwhW2VuZGlmXS0tPjxzdHlsZT4NCjwhLS0NCiAvKiBG b250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7 DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAw IDMgMSAxIDEgMSAxO30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpBcmlhbDsNCglj b2xvcjpuYXZ5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NTk1LjNwdCA4NDEuOXB0Ow0KCW1h cmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6 U2VjdGlvbjE7fQ0KIC8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCiBAbGlzdCBsMA0KCXttc28tbGlz dC1pZDo3NDYwNzU0MjI7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi01MzIyNTA5NDIgMTQ2OTI0MDA0OCA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2 NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDoxOC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE4LjBw dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjk0MzIy Mzg2MjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEy MzcwNTY0NjIgLTE0ODQ5MjY3NiA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2 NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7 bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDoxOC4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE4LjBwdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjE4MDQyNzE5NjE7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMTEyMTA0OTMw IDcxMTI0Njc0OCA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2 NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVs LXRleHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDoxOC4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE4LjBwdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206 MGNtO30NCi0tPg0KPC9zdHlsZT4NCjxkaXYgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5r PSJibHVlIj4NCjxkaXYgY2xhc3M9IlNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjEiIGZhY2U9IkFyaWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToNCjkuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj5IaSBhbGwsPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjEiIGZhY2U9IkFy aWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToNCjkuMHB0O2ZvbnQtZmFt aWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMSIgZmFjZT0iQXJpYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOg0KOS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPldlIHJlYWNoIGFu IGltcGFzc2U8L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjEiIGZhY2U9IldpbmdkaW5ncyI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2Rp bmdzIj5KPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIxIiBmYWNlPSJBcmlhbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPi4NCiAm bmJzcDtCVFcsIE1lZXRpbmcgbWludXRlcyBpcyByZWFkeSBub3cuIFdlIGNhbiBnZXQgRS10cmVl IHN1bW1hcnkgZnJvbSBJRVRGIHNpdGUuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjEiIGZhY2U9IkFyaWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToNCjkuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMSIgZmFjZT0iQXJpYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOg0KOS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPlRvZGF5IEkgY29sbGVjdGVkIGFsbCBpdGVt cyB3ZSBkaXNjdXNzZWQgYmVmb3JlLiBUaGV5IGFyZSw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMSIgZmFjZT0iQXJpYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOg0KOS4wcHQ7Zm9udC1mYW1pbHk6QXJp YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxp c3Q6bDIgbGV2ZWwxIGxmbzEiPg0KPCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxmb250IHNpemU9 IjEiIGZhY2U9IkFyaWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpBcmlhbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MSk8Zm9u dCBzaXplPSIxIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250PjwhLS1bZW5kaWZd LS0+PGZvbnQgc2l6ZT0iMSIgZmFjZT0iQXJpYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj5TaWxpY29uIGlzc3VlIG9yIGNoaXAg bGltaXQ7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MiBsZXZlbDEgbGZvMSI+DQo8IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0+PGZvbnQgc2l6ZT0iMSIg ZmFjZT0iQXJpYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OkFyaWFsIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yKTxmb250IHNp emU9IjEiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PCEtLVtlbmRpZl0tLT48 Zm9udCBzaXplPSIxIiBmYWNlPSJBcmlhbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPk5ldHdvcmsgZWZmaWNpZW5jeTs8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwyIGxldmVsMSBsZm8x Ij4NCjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48Zm9udCBzaXplPSIxIiBmYWNlPSJBcmlhbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6QXJp YWwiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMpPGZvbnQgc2l6ZT0iMSIgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu PjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48IS0tW2VuZGlmXS0tPjxmb250IHNpemU9IjEi IGZhY2U9IkFyaWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTpBcmlhbCI+RW5jYXBzdWxhdGlvbiBtb2RlLCB0YWcgb3IgcmF3OzxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzEi Pg0KPCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxmb250IHNpemU9IjEiIGZhY2U9IkFyaWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpBcmlh bCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+NCk8Zm9udCBzaXplPSIxIiBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250PjwhLS1bZW5kaWZdLS0+PGZvbnQgc2l6ZT0iMSIg ZmFjZT0iQXJpYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OkFyaWFsIj5ILVZQTFM7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMiBsZXZlbDEgbGZvMSI+DQo8IS0tW2lmICFzdXBwb3J0TGlzdHNd LS0+PGZvbnQgc2l6ZT0iMSIgZmFjZT0iQXJpYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj41KTxmb250IHNpemU9IjEiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2Zv bnQ+PCEtLVtlbmRpZl0tLT48Zm9udCBzaXplPSIxIiBmYWNlPSJBcmlhbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPkJhY2t3YXJk cyBjb21wYXRpYmlsaXR5LCBlc3BlY2lhbGx5IGxlZ2FjeSBQRSBvciBOb24tc3VwcG9ydGluZyBQ RSB3aXRoIElFRUUgRS10cmVlIHN1cHBvcnQgam9pbnMgRS1UcmVlIGRvbWFpbjs8bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwyIGxldmVsMSBsZm8xIj4N CjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48Zm9udCBzaXplPSIxIiBmYWNlPSJBcmlhbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjYpPGZvbnQgc2l6ZT0iMSIgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv Zm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48IS0tW2VuZGlmXS0tPjxmb250IHNpemU9IjEiIGZh Y2U9IkFyaWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTpBcmlhbCI+Q29uZmlndXJhdGlvbiBjaGFuZ2UgaW4gb3BlcmF0aW9uLCBmb3IgZXhh bXBsZSwgTGVhZi1vbmx5IC0mZ3Q7IFJvb3QtTGVhZi1NaXhlZDs8L3NwYW4+PC9mb250Pjxmb250 IHNpemU9IjEiIGZhY2U9IkFyaWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTpBcmlhbCI+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRl bnQ6LTE4LjBwdDttc28tbGlzdDpsMiBsZXZlbDEgbGZvMSI+DQo8IS0tW2lmICFzdXBwb3J0TGlz dHNdLS0+PGZvbnQgc2l6ZT0iMSIgZmFjZT0iQXJpYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj43KTxmb250IHNpemU9IjEiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48 L2ZvbnQ+PCEtLVtlbmRpZl0tLT48Zm9udCBzaXplPSIxIiBmYWNlPSJBcmlhbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPlMtVkxB TiBwcmVzZXJ2YXRpb24gc3VwcG9ydDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDot MTguMHB0O21zby1saXN0OmwyIGxldmVsMSBsZm8xIj4NCjwhLS1baWYgIXN1cHBvcnRMaXN0c10t LT48Zm9udCBzaXplPSIxIiBmYWNlPSJBcmlhbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPjgpPGZvbnQgc2l6ZT0iMSIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9u dD48IS0tW2VuZGlmXS0tPjxmb250IHNpemU9IjEiIGZhY2U9IkFyaWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpBcmlhbCI+TXVsdGktc2Vn bWVudCBQVzs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0 OmwyIGxldmVsMSBsZm8xIj4NCjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48Zm9udCBzaXplPSIx IiBmYWNlPSJBcmlhbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6QXJpYWwiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjkpPGZvbnQg c2l6ZT0iMSIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48IS0tW2VuZGlmXS0t Pjxmb250IHNpemU9IjEiIGZhY2U9IkFyaWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpBcmlhbCI+VkxBTiBJRCBhbGxvY2F0aW9uIChPbmx5 IGZvciBEdWFsLVZMQU4pOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzEiPg0KPCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxmb250 IHNpemU9IjEiIGZhY2U9IkFyaWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTpBcmlhbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ MTApPGZvbnQgc2l6ZT0iMSIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFu PjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48IS0tW2VuZGlmXS0tPjxmb250IHNpemU9IjEi IGZhY2U9IkFyaWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTpBcmlhbCI+TXVsdGktQVMgZGVwbG95bWVudDs8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBw dDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwyIGxldmVsMSBsZm8xIj4NCjwhLS1baWYg IXN1cHBvcnRMaXN0c10tLT48Zm9udCBzaXplPSIxIiBmYWNlPSJBcmlhbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPjExKTxmb250IHNpemU9IjEiIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PCEtLVtl bmRpZl0tLT48Zm9udCBzaXplPSIxIiBmYWNlPSJBcmlhbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPkVDTVA7PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDoxOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMiBsZXZlbDEgbGZvMSI+DQo8 IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0+PGZvbnQgc2l6ZT0iMSIgZmFjZT0iQXJpYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xMik8Zm9udCBzaXplPSIxIiBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250 PjwhLS1bZW5kaWZdLS0+PGZvbnQgc2l6ZT0iMSIgZmFjZT0iQXJpYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj5QMk1QLVBXOzxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwx IGxmbzEiPg0KPCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxmb250IHNpemU9IjEiIGZhY2U9IkFy aWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTpBcmlhbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MTMpPGZvbnQgc2l6ZT0iMSIg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48L3NwYW4+PC9z cGFuPjwvZm9udD48IS0tW2VuZGlmXS0tPjxmb250IHNpemU9IjEiIGZhY2U9IkFyaWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpBcmlhbCI+ RXRoZXJuZXQgT0FNOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIxIiBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9y Om5hdnkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIxIiBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9y Om5hdnkiPklmIHdlIHJldmlldyB0aGUgbWFpbC1saXN0LCBDVyBhcHByb2FjaCBoYXMgdGhlIGZv bGxvd2luZyBsaW1pdHM6PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0+PGZvbnQg c2l6ZT0iMSIgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnkiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEpPGZvbnQgc2l6ZT0iMSIgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48 L3NwYW4+PC9zcGFuPjwvZm9udD48IS0tW2VuZGlmXS0tPjxmb250IHNpemU9IjEiIGNvbG9yPSJu YXZ5IiBmYWNlPSJBcmlhbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6QXJpYWw7DQpjb2xvcjpuYXZ5Ij5DaGlwIGxpbWl0LiBQbGVhc2UgcmVh ZCByZXBseSBmcm9tIEdpbGVzIGFuZCBXaW07PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRl bnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IS0tW2lmICFzdXBwb3J0TGlz dHNdLS0+PGZvbnQgc2l6ZT0iMSIgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsO2NvbG9y Om5hdnkiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIpPGZvbnQgc2l6ZT0iMSIgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48IS0tW2VuZGlmXS0tPjxmb250IHNpemU9 IjEiIGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7DQpjb2xvcjpuYXZ5Ij5OZXR3b3JrIGVm ZmljaWVuY3k6IFRoZXJlIGFyZSBnYXJiYWdlIGZhbWVzIHdoaWNoIHdpbGwgYmUgZHJvcHBlZCBv biBlZ3Jlc3MgUEUgc2luY2Ugb25seSBlZ3Jlc3MNCiBQRSBjYW4gZGVjaWRlIGZvcndhcmQgb3Ig ZHJvcCBmcmFtZXMgd2hpbGUgaXQgcmVjZWl2ZXMgZnJhbWVzLiA8c3QxOnBsYWNlIHc6c3Q9Im9u Ij4NCjxzdDE6Y2l0eSB3OnN0PSJvbiI+SW5ncmVzczwvc3QxOmNpdHk+IDxzdDE6c3RhdGUgdzpz dD0ib24iPlBFPC9zdDE6c3RhdGU+PC9zdDE6cGxhY2U+IGNhbiBub3QgZGVjaWRlIGZvcndhcmQg b3Igbm90LiBZZXMsIGN1cnJlbnQgc29sdXRpb24gY2FuIHN1cHBvcnQgSHViLVNwb2tlIGNvbmZp Z3VyYXRpb24sIGJ1dCBhcyB3ZSBrbm93LCB0aGUgY29uZmlndXJhdGlvbiBpcyBub3QgZWFzeSBp ZiB0aGUgbmV0d29yayBpcyBiaWcuIER1YWwtVkxBTiBvcg0KIE11bHRpLVBXIGFwcHJvYWNoIGNh biBicmVhayBjb21tdW5pY2F0aW9uIGJldHdlZW4gTGVhZi1Pbmx5IFBFcyB2aWEgc2lnbmFsaW5n LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzIiPg0KPCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxmb250IHNpemU9IjEiIGNvbG9y PSJuYXZ5IiBmYWNlPSJBcmlhbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7DQpmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Ij48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj4zKTxmb250IHNpemU9IjEiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48 L2ZvbnQ+PCEtLVtlbmRpZl0tLT48Zm9udCBzaXplPSIxIiBjb2xvcj0ibmF2eSIgZmFjZT0iQXJp YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OkFyaWFsOw0KY29sb3I6bmF2eSI+QmFja3dhcmRzIGNvbXBhdGliaWxpdHk6IE5vdCBhbGwgUEVz IHN1cHBvcnRzIGNvbnRyb2wgd29yZC4gSWYgb25lIGNhbiBub3Qgc3VwcG9ydCBjb250cm9sIHdv cmQsDQogaXQgd2lsbCBub3Qgam9pbiBFLVRyZWUgZG9tYWluOzxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIxIiBjb2xvcj0ibmF2 eSIgZmFjZT0iQXJpYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIxIiBjb2xvcj0ibmF2 eSIgZmFjZT0iQXJpYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnkiPkR1YWwgVkxBTiBoYXMgZm9sbG93aW5nIGxp bWl0czo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omwx IGxldmVsMSBsZm8zIj4NCjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48Zm9udCBzaXplPSIxIiBj b2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjkuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+MSk8Zm9udCBzaXplPSIxIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3Nw YW4+PC9mb250PjwhLS1bZW5kaWZdLS0+PGZvbnQgc2l6ZT0iMSIgY29sb3I9Im5hdnkiIGZhY2U9 IkFyaWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTpBcmlhbDsNCmNvbG9yOm5hdnkiPkNoaXAgbGltaXQ6IEFzIHdlIGtub3csIHdlIG5lZWQg dG8gcHVzaCBvbmUgVkxBTiBpbnRvIGZyYW1lcyBiZWZvcmUgTVBMUyBlbmNhcHN1bGF0aW9uIG9u IGluZ3Jlc3MNCiBQRSBhbmQgc3RyaXBlIGl0IG91dCBvbiBlZ3Jlc3MgUEUuIFRoaXMgaXMgbm9u LXN0YW5kYXJkIG9wZXJhdGlvbi4gV2FpdCBmb3IgY29uZmlybWF0aW9uIGZyb20gY2hpcCB2ZW5k b3I7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBs ZXZlbDEgbGZvMyI+DQo8IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0+PGZvbnQgc2l6ZT0iMSIgY29s b3I9Im5hdnkiIGZhY2U9IkFyaWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnkiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPjIpPGZvbnQgc2l6ZT0iMSIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48L3NwYW4+PC9zcGFu PjwvZm9udD48IS0tW2VuZGlmXS0tPjxmb250IHNpemU9IjEiIGNvbG9yPSJuYXZ5IiBmYWNlPSJB cmlhbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6QXJpYWw7DQpjb2xvcjpuYXZ5Ij5IVlBMUzogSWYgd2UgZm9sbG93IEZpZyAzIG9yIEZpZw0K PHN0MTpjaG1ldGNudiB0Y3NjPSIwIiBudW1iZXJ0eXBlPSIxIiBuZWdhdGl2ZT0iRmFsc2UiIGhh c3NwYWNlPSJUcnVlIiBzb3VyY2V2YWx1ZT0iNCIgdW5pdG5hbWU9ImluIiB3OnN0PSJvbiI+DQo0 IGluPC9zdDE6Y2htZXRjbnY+IFJGQyA0NzYyIHRvIGRlcGxveSBIVlBMUywgUEUtcnMgd29ya3Mg aW4gZGlmZmVyZW50IG1hbm5lciwgUEUtcnMgc2hvdWxkIGZpZ3VyZSBvdXQgQUMgdHlwZSBpbiBW UFdTIGNhc2UsIGJ1dCBjYW4gTk9UIGNvbmZpZ3VyZSBpdCBhdCBhbGwgaW4gU3Bva2UgUFcgY2Fz ZTs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxl dmVsMSBsZm8zIj4NCjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48Zm9udCBzaXplPSIxIiBjb2xv cj0ibmF2eSIgZmFjZT0iQXJpYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+Myk8Zm9udCBzaXplPSIxIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+ PC9mb250PjwhLS1bZW5kaWZdLS0+PGZvbnQgc2l6ZT0iMSIgY29sb3I9Im5hdnkiIGZhY2U9IkFy aWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTpBcmlhbDsNCmNvbG9yOm5hdnkiPk11bHRpLVBXOiBSYWZpIGZpZ3VyZXMgdGhpcyBvdXQsIGJ1 dCB3ZSBkb27igJl0IHRoaW5rIHRoaXMgb3ZlciBhdCB0aGF0IHRpbWUuIEkgdGhpbmsgdGhhdCBp dCBhbHNvDQogaGFzIHNhbWUgcHJvYmxlbSBhcyBILVZQTFMgaGFzLjxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTgu MHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPg0KPCEtLVtp ZiAhc3VwcG9ydExpc3RzXS0tPjxmb250IHNpemU9IjEiIGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlh bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7DQpmb250LWZhbWls eTpBcmlhbDtjb2xvcjpuYXZ5Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj40KTxmb250 IHNpemU9IjEiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PCEtLVtlbmRpZl0t LT48Zm9udCBzaXplPSIxIiBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsOw0KY29sb3I6bmF2 eSI+RW5jYXBzdWxhdGlvbiBtb2RlOiBJZiBkZXBsb3kgR1ZQTFMgd2l0aCBTcG9rZSBQVyBtb2Rl LCBQRS1ycyBzaG91bGQgd29yayBpbiB0YWdnZWQgbW9kZSwgb3RoZXJ3aXNlDQogUEUtcnMgb3Ig ZWdyZXNzIFBFIHdpbGwgc3RyaXBlIFMtVkxBTiBJRDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0 LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NCjwhLS1baWYgIXN1cHBv cnRMaXN0c10tLT48Zm9udCBzaXplPSIxIiBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWw7 Y29sb3I6bmF2eSI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+NSk8Zm9udCBzaXplPSIx IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250PjwhLS1bZW5kaWZdLS0+PGZvbnQg c2l6ZT0iMSIgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpBcmlhbDsNCmNvbG9yOm5hdnkiPkJhY2t3 YXJkIENvbXBhdGliaWxpdHk6IEp1c3QgYXMgRGFuaWVsIG1lbnRpb25lZCwgdGhlcmUgaXMgY29t cGF0aWJpbGl0eSBpc3N1ZSBpZiBsZWdhY3kgUEUgam9pbnMNCiBFLVRyZWUgZG9tYWluLiBGb3Ig bWUsIEkgZG9u4oCZdCBnZXQgY2xlYXIgcmVzcG9uc2UgZnJvbSBjby1hdXRob3JzIG9mIER1YWwt VkxBTi48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMSIgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMSIgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Ij5G b3IgYWxsIGFwcHJvYWNoZXMsIHdlIGRvbuKAmXQgY292ZXIgRUNNUCAvIEV0aGVybmV0IE9BTSB0 aWxsIG5vdy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIxIiBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5h dnkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIxIiBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5h dnkiPklzIHRoZXJlIGFueXRoaW5nIG1pc3NlZD8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIxIiBjb2xvcj0ibmF2eSIgZmFj ZT0iQXJpYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9Im5h dnkiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2NvbG9yOm5hdnkiPlJlZ2FyZHMsPC9zcGFuPjwvZm9udD48Zm9udCBjb2xvcj0ibmF2eSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpuYXZ5Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9Im5h dnkiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOm5hdnkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0ibmF2eSIgZmFjZT0i5a6L5L2T Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6bmF2eSI+ WXVxdW4gKFNhbSkgQ2FvPC9zcGFuPjwvZm9udD48Zm9udCBjb2xvcj0ibmF2eSI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpuYXZ5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9Im5hdnkiIGZhY2U9 IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9y Om5hdnkiPkUtbWFpbDoNCjxhIGhyZWY9Im1haWx0bzpZdXF1bi5jYW9AZ21haWwuY29tIj5ZdXF1 bi5jYW9AZ21haWwuY29tPC9hPiA8L3NwYW4+PC9mb250Pjxmb250IGNvbG9yPSJuYXZ5Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOm5hdnkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBjb2xvcj0ibmF2eSIg ZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6bmF2eSI+Jm5ic3A7PC9zcGFuPjwvZm9udD48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxmb250IHNpemU9IjMiIGZh Y2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4N CjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciIgdGFiaW5kZXg9Ii0xIj4N Cjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48Zm9udCBzaXpl PSIyIiBmYWNlPSJUYWhvbWEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpUYWhvbWE7Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTo8L3NwYW4+PC9m b250PjwvYj48Zm9udCBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWEiPiBMaXpob25nDQogSmlu IFs8YSBocmVmPSJtYWlsdG86bGl6aG8uamluQGdtYWlsLmNvbSI+bWFpbHRvOmxpemhvLmppbkBn bWFpbC5jb208L2E+XSA8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U2Vu dDo8L3NwYW4+PC9iPiBTYXR1cmRheSwgQXByaWwgMjEsIDIwMTIgMTE6NTkgQU08YnI+DQo8Yj48 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86PC9zcGFuPjwvYj4gSGVuZGVyaWNreCwg V2ltIChXaW0pPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOjwvc3Bh bj48L2I+IDxhIGhyZWY9Im1haWx0bzpsMnZwbkBpZXRmLm9yZyI+DQpsMnZwbkBpZXRmLm9yZzwv YT47IDxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbSI+QWxl eGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnl1cXVu LmNhb0BnbWFpbC5jb20iPnl1cXVuLmNhb0BnbWFpbC5jb208L2E+PGJyPg0KPGI+PHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFuPjwvYj4gUkU6IFRoZSBzdGF0dXMg b2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj88L3NwYW4+PC9mb250Pjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2T Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkhpIFdpbiw8YnI+ DQpUaGFuayB5b3UgZm9yIHRoZSBhbnN3ZXJzLiBJbiB0aGF0IGNhc2UsIFBFLXJzIHNob3VsZCBj b25maWd1cmUgdGhlIHJvb3QvbGVhZiBwcm9wZXJ0aWVzIG9mIFZQV1MsIG5vdCBvbiB0aGUgcmVt b3RlIFBFIG9mIFZQV1MuIEFuZCB1c3VhbGx5IG9uIFBFLXJzLCB5b3UgY291bGQgbm90IGZpZ3Vy ZSBvdXQgdGhlIGFjY2Vzc2luZyBzcG9rZSBQVyBpcyBmcm9tIFBFLXIgb2YgVlBXUyBvciBNVFUt cy4gVW5sZXNzIGhhdmluZyBzb21lIGFkZGl0aW9uYWwNCiBpbmRpY2F0aW9uIGluIE5NUywgeW91 IGV2ZW4gZG9uJ3Qga25vdyB3aGljaCBzcG9rZSBQVyBuZWVkcyB0byBkbyBWTEFOIG1hbmlwdWxh dGlvbi4gSSBhbSBub3Qgc3VyZSBzdWNoIFIvTCBjb25maWd1cmF0aW9uIGNvdWxkIGJlIGFjY2Vw dGVkIGZyb20gb3BlcmF0aW9uYWwgdmlldy4gSG9wZSB0byBzZWUgbW9yZSBjb21tZW50cy48YnI+ DQo8YnI+DQpSZWdhcmRzPGJyPg0KTGl6aG9uZzxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj7lnKg8 c3BhbiBsYW5nPSJFTi1VUyI+IDxzdDE6Y2hzZGF0ZSBpc3JvY2RhdGU9IkZhbHNlIiBpc2x1bmFy ZGF0ZT0iRmFsc2UiIGRheT0iMjEiIG1vbnRoPSI0IiB5ZWFyPSIyMDEyIiB3OnN0PSJvbiI+DQoy MDEyPHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFuIGxhbmc9IkVOLVVTIj7lubQ0PC9zcGFuPjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gbGFuZz0iRU4tVVMiPuaciDIxPC9zcGFuPjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gbGFuZz0iRU4tVVMiPuaXpTwvc3Bhbj48L3NwYW4+ PC9zdDE6Y2hzZGF0ZT48c3BhbiBsYW5nPSJFTi1VUyI+5pif5pyf5YWt77yMSGVuZGVyaWNreCwg V2ltIChXaW0pICZsdDs8YSBocmVmPSJtYWlsdG86d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNl bnQuY29tIj53aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5jb208L2E+Jmd0Ow0KPC9zcGFu Pjwvc3Bhbj7lhpnpgZPvvJo8c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KJmd0OyBUaGUgVlBXUyB3 aGljaCB0ZXJtaW5hdGVzIGF0IHRoZSBILVZQTFMgbm9kZSBpcyBpbmRpY2F0ZWQgdG8gYmUgcm9v dCBvciBsZWFmIGFuZCB0aGUgcHJvY2VkdXJlcyBhc3NvY2lhdGVkIHdpbGwgZG8gdGhlIFZMQU4g bWFuaXB1bGF0aW9uPGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0Ozxicj4NCiZn dDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmciPmwydnBuLWJv dW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmwydnBuLWJvdW5jZXNA aWV0Zi5vcmciPmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTGl6aG9u ZyBKaW48YnI+DQomZ3Q7IFNlbnQ6IHZyaWpkYWcgMjAgYXByaWwgMjAxMiAxODozODxicj4NCiZn dDsgVG86IDxhIGhyZWY9Im1haWx0bzpsMnZwbkBpZXRmLm9yZyI+bDJ2cG5AaWV0Zi5vcmc8L2E+ OyA8YSBocmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20iPg0KQWxl eGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+PGJyPg0KJmd0OyBDYzogPGEgaHJlZj0i bWFpbHRvOnl1cXVuLmNhb0BnbWFpbC5jb20iPnl1cXVuLmNhb0BnbWFpbC5jb208L2E+PGJyPg0K Jmd0OyBTdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1U cmVlIHNvbHV0aW9uPzxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDs8YnI+DQom Z3Q7IEhpLCBhbGwsPGJyPg0KJmd0OyBUaGUgZGlmZmVyZW5jZSBiZXR3ZWVuIDItVkxBTiBhbmQg Q1cgYXBwcm9hY2ggaXMgd2hvIHdpbGwgcHJvdmlkZSB0aGUgUi9MIGluZm9ybWF0aW9uLCBjdXN0 b21lciBwYXlsb2FkIG9yIFBXPyBUaGUgY3VzdG9tZXIgcGF5bG9hZCB3aWxsIGJlIGFsd2F5cyBt b2RpZmllZCB0byBjYXJyeSBSL0wgaW5mb3JtYXRpb24gaW4gMi1WTEFOIGFwcHJvYWNoLCB3aGls ZSBQVyB3aXRoIENXIHdpbGwgY2FycnkgUi9MIGluZm9ybWF0aW9uIGZvciBDVyBhcHByb2FjaC48 YnI+DQomZ3Q7IEkgaGF2ZSBhIHF1ZXN0aW9uIHdpdGggdGhlIDItVkxBTiBhcHByb2FjaCBpbiBI LVZQTFMgd2hlcmUgSC1WUExTIGlzIGFjY2Vzc2VkIGJ5IFZQV1MgYXMgZGVzY3JpYmVkIGluIFJG QzQ2NzIgc2VjdGlvbg0KPHN0MTpjaHNkYXRlIGlzcm9jZGF0ZT0iRmFsc2UiIGlzbHVuYXJkYXRl PSJGYWxzZSIgZGF5PSIzMCIgbW9udGg9IjEyIiB5ZWFyPSIxODk5IiB3OnN0PSJvbiI+DQoxMC4x LjM8L3N0MTpjaHNkYXRlPi4gSWYgVlBXUyBpcyB1c2VkIHRvIGFjY2VzcyBILVZQTFMsIGhvdyBj b3VsZCB0aGUgUEUgb24gVlBXUyBzaWRlIGFkZHMgVkxBTiB0byBpbmRpY2F0ZSBSL0wgaW5mb3Jt YXRpb24/PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzPGJyPg0KJmd0OyBMaXpob25nPGJyPg0K Jmd0Ozxicj4NCiZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgTWVzc2FnZTogMjxicj4NCiZndDsmZ3Q7IERhdGU6IFRodSwg MTkgQXByIDIwMTIgMDQ6Mzg6MzYgJiM0MzswMDAwPGJyPg0KJmd0OyZndDsgRnJvbTogQWxleGFu ZGVyIFZhaW5zaHRlaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbSI+QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+Jmd0Ozxicj4N CiZndDsmZ3Q7IFRvOiAmcXVvdDtSb2dlcnMsIEpvc2gmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbSI+am9zaC5yb2dlcnNAdHdjYWJsZS5jb208L2E+Jmd0 OywgTHVjeSB5b25nPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0 OzxhIGhyZWY9Im1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbSI+bHVjeS55b25nQGh1YXdlaS5j b208L2E+Jmd0OywgRGFuaWVsIENvaG4gJmx0OzxhIGhyZWY9Im1haWx0bzpEYW5pZWxDQG9yY2tp dC5jb20iPkRhbmllbENAb3Jja2l0LmNvbTwvYT4mZ3Q7LCBTYW0gQ2FvPGJyPg0KJmd0OyZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0OzxhIGhyZWY9Im1haWx0bzp5dXF1bi5jYW9A Z21haWwuY29tIj55dXF1bi5jYW9AZ21haWwuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyBDYzog JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmwydnBuQGlldGYub3JnIj5sMnZwbkBpZXRmLm9yZzwvYT4m cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpsMnZwbkBpZXRmLm9yZyI+bDJ2cG5AaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHBy b2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/PGJyPg0KJmd0OyZndDsgTWVzc2FnZS1JRDo8 YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7PGEgaHJlZj0ibWFp bHRvOkY5MzM2NTcxNzMxQURFNDJBNTM5N0ZDODMxQ0VBQTAyMDM0MTkyQEZSSURXUFBNQjAwMi5l Y2l0ZWxlLmNvbSI+RjkzMzY1NzE3MzFBREU0MkE1Mzk3RkM4MzFDRUFBMDIwMzQxOTJARlJJRFdQ UE1CMDAyLmVjaXRlbGUuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyBDb250ZW50LVR5cGU6IHRl eHQvcGxhaW47IGNoYXJzZXQ9JnF1b3Q7dXMtYXNjaWkmcXVvdDs8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7Jmd0OyBJIGZ1bGx5IHVuZGVyc3RhbmQgdGhhdCB0 aGF0IHdoYXQgSSBhbSBnb2luZyB0byBzYXkgaXMgbm90IHZlcnkgcG9wdWxhciwgYnV0Ojxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSU1PIG9uZSBvZiB0aGUgYWR2YW50YWdlcyBvZiB0aGUg Q1ctYmFzZWQgc29sdXRpb24gaXMgdGhhdCBpdCBpcyBvcnRob2dvbmFsIHRvIHVzYWdlIChvciBu b24tdXNhZ2UpIG9mIFAyTVAgUFdzIGZvciBlZmZlY3RpdmUgZGVsaXZlcnkgb2YgQlVOIHRyYWZm aWMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBBbm90aGVyIGFkdmFudGFnZSBpcyBwcmVz ZXJ2YXRpb24gb2YgZnVsbCBtZXNoIG9mIFAyUCBQV3MgaW4gYSBWUExTLCBhbmQsIGluIGEgbW9y ZSBnZW5lcmljIHdheSwgbG9jYWxpemF0aW9uIG9mIGVmZmVjdHMgb2YgY2hhbmdlcyBpbiB0aGUg UEUgY29uZmlndXJhdGlvbi48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEluIHBhcnRpY3Vs YXIsIGFkZGluZyBhIExlYWYgQUMgdG8gYSBQRSB0aGF0IHByZXZpb3VzbHkgaGFzIGJlZW4gb25s eSBzdXBwb3J0aW5nIFJvb3QgQUNzIChvciB2aWNlIHZlcnNhKSwgcmVtb3ZhbCBvZiB0aGUgbGFz dCBMZWFmIG9yIGxhc3QgUm9vdCBBQyBmcm9tIGEgUEUgdGhhdCBwcmV2aW91c2x5IGhhcyBiZWVu IHN1cHBvcnRpbmcgYSBtaXggZXRjLiBhZmZlY3Qgb25seSB0aGUgUEUgd2hlcmUgdGhpcyBvcGVy YXRpb24gaGFwcGVucyBhbmQNCiBub3QgdGhlIHJlc3Qgb2YgdGhlIFBFcy48YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IEFzIGZvciB0aGUgbmVlZCBmb3IgSFcgY2hhbmdlcyB0aGF0IGhhdmUg YmVlbiBtZW50aW9uZWQgYXMgYSBtYWluIGRpc2FkdmFudGFnZSBvZiB0aGUgQ1ctYmFzZWQgYXBw cm9hY2ggLSBJIGJlbGlldmUgaXQgc3Ryb25nbHkgZGVwZW5kcyBvbiBzcGVjaWZpYyBpbXBsZW1l bnRhdGlvbnMuIEFuZCBzb21lIGNoYW5nZXMgaW4gdGhlIGZvcndhcmRpbmcgcHJvY2VzcyBhcmUg cmVxdWlyZWQgaW4gYW55IHNvbHV0aW9uLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgTXkg PHN0MTpjaG1ldGNudiB0Y3NjPSIwIiBudW1iZXJ0eXBlPSIxIiBuZWdhdGl2ZT0iRmFsc2UiIGhh c3NwYWNlPSJGYWxzZSIgc291cmNldmFsdWU9IjIiIHVuaXRuYW1lPSJDIiB3OnN0PSJvbiI+DQoy Yzwvc3QxOmNobWV0Y252Piw8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7IFNhc2hhPGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IEZyb206IDxh IGhyZWY9Im1haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnIj5sMnZwbi1ib3VuY2VzQGlldGYu b3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmciPmwydnBuLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XSBvbiBiZWhhbGYgb2YgUm9nZXJzLCBKb3NoIFs8YSBocmVmPSJt YWlsdG86am9zaC5yb2dlcnNAdHdjYWJsZS5jb20iPmpvc2gucm9nZXJzQHR3Y2FibGUuY29tPC9h Pl08YnI+DQomZ3Q7Jmd0OyBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDE4LCAyMDEyIDk6NTcgUE08 YnI+DQomZ3Q7Jmd0OyBUbzogTHVjeSB5b25nOyBEYW5pZWwgQ29objsgU2FtIENhbzxicj4NCiZn dDsmZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86bDJ2cG5AaWV0Zi5vcmciPmwydnBuQGlldGYub3Jn PC9hPjxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2Fj aGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBB Z2FpbiwgdGhlIFAyTVAgc2l0dWF0aW9uIHRocm93cyBtZS4gJm5ic3A7SXMgdGhpcyBzb21ldGhp bmcgdGhhdCBpcyB1c2VkPGJyPg0KJmd0OyZndDsgY29tbW9ubHk/PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyBJJ20gdW5kZXIgdGhlIGltcHJlc3Npb24gdGhhdCBhZGRpbmcgUDJNUCB0byBh bnkgbW9kZWwgcmVzdWx0cyBpbiBhIG1vcmU8YnI+DQomZ3Q7Jmd0OyBjb21wbGV4IG1vZGVsLiAm bmJzcDtXZXRoZXIgb3V0c2lkZSBzLXRhZyBpcyB1c2VkIHRvIGRpZmZlcmVudGlhdGUsIG9yPGJy Pg0KJmd0OyZndDsgZGVkaWNhdGVkIHB3J3MgYXJlIHVzZWQgZm9yIHRoZSBzYW1lIHB1cnBvc2Us IGl0IHNlZW1zIGJvdGggYmVjb21lIG1vcmU8YnI+DQomZ3Q7Jmd0OyBjb21wbGV4Ljxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgR2lsZSdzIGNvbXBhcmlzb24gc2xpZGUgc3RpbGwgY29uY2lz ZWx5IGNhcHR1cmVzIHRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVuPGJyPg0KJmd0OyZndDsgdGhlc2Ug bWV0aG9kcywgaW4gbXkgb3Bpbmlvbi4gJm5ic3A7SSBoYXZlbid0IHNlZW4gYW55IG5ldyBpZGVh cyBvciB0aG91Z2h0czxicj4NCiZndDsmZ3Q7IGJyb3VnaHQgdG8gdGhlIGdyb3VwIGluIHRoZSBw YXN0IHdlZWsgb3IgdHdvIG9uIHRoZSBzdWJqZWN0LiAmbmJzcDtJIHdvdWxkIGhhdGU8YnI+DQom Z3Q7Jmd0OyBmb3IgYm90aCBwcm9wb3NlZCBtZXRob2RzIHRvIGRpZSBvbiB0aGUgdmluZSBiZWNh dXNlIHdlIGNvdWxkbid0IGRlY2lkZTxicj4NCiZndDsmZ3Q7IGJldHdlZW4gdHdvIG1ldGhvZHMg dGhhdCBoYXZlIG5vdGhpbmcgaW5oZXJlbnRseSB3cm9uZyB3aXRoIGVpdGhlci48YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7IC1Kb3NoPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IE9uIDQvMTgvMTIgMTo1MyBQTSwgJnF1b3Q7THVjeSB5b25nJnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20iPmx1Y3kueW9uZ0BodWF3ZWkuY29t PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDtTZW5kIHRoaXMg YWdhaW4uPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7VHdvIFBXIGFwcHJvYWNo IGNhbiBiZSBjb21wbGV4IHRvbyBpZiB0aGUgVlBMUyBpbnN0YW5jZSBmb3IgRS1UcmVlIHVzZXM8 YnI+DQomZ3Q7Jmd0OyZndDtQMlAgUFcgZm8gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L286c21hcnR0YWd0eXBlPjwvbzpzbWFydHRhZ3R5cGU+PC9vOnNt YXJ0dGFndHlwZT48L286c21hcnR0YWd0eXBlPjwvbzpzbWFydHRhZ3R5cGU+PC9kaXY+DQo8L3Nw YW4+PGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBzaXplPSIxIj5U aGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdh cm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwg Y29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBX YXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseQ0KIGZvciB0aGUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBh cmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwg Y29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBh bmQgYXR0YWNobWVudHMgdG8NCiB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFu ZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5 IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkg cHJpbnRvdXQuPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CBB83462C03joshrogerstwcablecom_-- From raymond.key@hotmail.com Sat Apr 21 08:31:50 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2BF521F85D5 for ; Sat, 21 Apr 2012 08:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.714 X-Spam-Level: X-Spam-Status: No, score=-101.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=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 yhjeLYKLPgPi for ; Sat, 21 Apr 2012 08:31:46 -0700 (PDT) Received: from snt0-omc2-s8.snt0.hotmail.com (snt0-omc2-s8.snt0.hotmail.com [65.55.90.83]) by ietfa.amsl.com (Postfix) with ESMTP id D960121F85D2 for ; Sat, 21 Apr 2012 08:31:45 -0700 (PDT) Received: from SNT123-W11 ([65.55.90.73]) by snt0-omc2-s8.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 21 Apr 2012 08:31:44 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_697703a1-ea71-4e53-a4ad-67a3518ae3fd_" X-Originating-IP: [113.92.40.220] From: Raymond Key Sender: To: Subject: RE: The status of the approaches to the E-Tree solution? Date: Sun, 22 Apr 2012 02:01:44 +1030 Importance: Normal In-Reply-To: <1B88357C808B432E871CA9D678305B7C@v2comsam> References: , <14C7F4F06DB5814AB0DE29716C4F6D6701296244C3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>, , <1B88357C808B432E871CA9D678305B7C@v2comsam> MIME-Version: 1.0 X-OriginalArrivalTime: 21 Apr 2012 15:31:44.0988 (UTC) FILETIME=[DBCDF1C0:01CD1FD3] Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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: Sat, 21 Apr 2012 15:31:50 -0000 --_697703a1-ea71-4e53-a4ad-67a3518ae3fd_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Some clarifications [RK] inserted belowThanksRaymond KeyFrom: yuqun.cao@gmail.com To: lizho.jin@gmail.com; wim.henderickx@alcatel-lucent.com Subject: RE: The status of the approaches to the E-Tree solution? Date: Sat, 21 Apr 2012 22:51:28 +0800 CC: l2vpn@ietf.org Hi all, We reach an impasseJ. BTW, Meeting minutes is ready now. We can get E-tree summary from IETF site. Today I collected all items we discussed before. They are, 1) Silicon issue or chip limit; 2) Network efficiency; 3) Encapsulation mode, tag or raw; 4) H-VPLS; 5) Backwards compatibility, especially legacy PE or Non-supporting PE with IEEE E-tree support joins E-Tree domain; 6) Configuration change in operation, for example, Leaf-only -> Root-Leaf-Mixed; 7) S-VLAN preservation support; 8) Multi-segment PW; 9) VLAN ID allocation (Only for Dual-VLAN); 10) Multi-AS deployment; 11) ECMP; 12) P2MP-PW; 13) Ethernet OAM; If we review the mail-list, CW approach has the following limits: 1) Chip limit. Please read reply from Giles and Wim; 2) Network efficiency: There are garbage fames which will be dropped on egress PE since only egress PE can decide forward or drop frames while it receives frames. Ingress PE can not decide forward or not. Yes, current solution can support Hub-Spoke configuration, but as we know, the configuration is not easy if the network is big. Dual-VLAN or Multi-PW approach can break communication between Leaf-Only PEs via signaling. [RK] It seems to me this is not the case. Section 6 of the draft has some discussions on this. http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-6 6. Optional Enhancements for Leaf-only PE 6.1. No PW between Leaf-only PEs 6.2. Not Forward Frame from Leaf AC to Leaf-only PE 3) Backwards compatibility: Not all PEs supports control word. If one can not support control word, it will not join E-Tree domain; [RK] It seems to me this is not the case. Section 5 of the draft has some discussions on this. http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-5 5. Backward Compatibility 5.1. AC Type 5.2. Control Word 5.3. Additional Action in Data Forwarding 5.3.1. Ingress PE Supporting the Extension but Egress PE Not 5.3.2. Egress PE Supporting the Extension but Ingress PE Not Dual VLAN has following limits: 1) Chip limit: As we know, we need to push one VLAN into frames before MPLS encapsulation on ingress PE and stripe it out on egress PE. This is non-standard operation. Wait for confirmation from chip vendor; 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, but can NOT configure it at all in Spoke PW case; 3) Multi-PW: Rafi figures this out, but we don$B!G(Bt think this over at that time. I think that it also has same problem as H-VPLS has. 4) Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN ID; 5) Backward Compatibility: Just as Daniel mentioned, there is compatibility issue if legacy PE joins E-Tree domain. For me, I don$B!G(Bt get clear response from co-authors of Dual-VLAN. For all approaches, we don$B!G(Bt cover ECMP / Ethernet OAM till now. Is there anything missed? Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com From: Lizhong Jin [mailto:lizho.jin@gmail.com] Sent: Saturday, April 21, 2012 11:59 AM To: Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi Win, Thank you for the answers. In that case, PE-rs should configure the root/leaf properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, you could not figure out the accessing spoke PW is from PE-r of VPWS or MTU-s. Unless having some additional indication in NMS, you even don't know which spoke PW needs to do VLAN manipulation. I am not sure such R/L configuration could be accepted from operational view. Hope to see more comments. Regards Lizhong $B:_(B 2012$BG/(B4$B7n(B21$BF|@14|O;!$(BHenderickx, Wim (Wim) $B The VPWS which terminates at the H-VPLS node is indicated to be root or leaf and the procedures associated will do the VLAN manipulation > > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin > Sent: vrijdag 20 april 2012 18:38 > To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com > Cc: yuqun.cao@gmail.com > Subject: RE: The status of the approaches to the E-Tree solution? > > > > Hi, all, > The difference between 2-VLAN and CW approach is who will provide the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW will carry R/L information for CW approach. > I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information? > > Thanks > Lizhong > >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 Apr 2012 04:38:36 +0000 >> From: Alexander Vainshtein >> To: "Rogers, Josh" , Lucy yong >> , Daniel Cohn , Sam Cao >> >> Cc: "l2vpn@ietf.org" >> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID: >> >> Content-Type: text/plain; charset="us-ascii" >> >> Hi all, >> I fully understand that that what I am going to say is not very popular, but: >> >> IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes in the PE configuration. >> >> In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root AC from a PE that previously has been supporting a mix etc. affect only the PE where this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a more >> complex model. Wether outside s-tag is used to differentiate, or >> dedicated pw's are used for the same purpose, it seems both become more >> complex. >> >> Gile's comparison slide still concisely captures the differences between >> these methods, in my opinion. I haven't seen any new ideas or thoughts >> brought to the group in the past week or two on the subject. I would hate >> for both proposed methods to die on the vine because we couldn't decide >> between two methods that have nothing inherently wrong with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" wrote: >> >>>Send this again. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>P2P PW fo --_697703a1-ea71-4e53-a4ad-67a3518ae3fd_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit
Some clarifications [RK] inserted below
Thanks
Raymond Key
From: yuqun.cao@gmail.com
To: lizho.jin@gmail.com; wim.henderickx@alcatel-lucent.com
Subject: RE: The status of the approaches to the E-Tree solution?
Date: Sat, 21 Apr 2012 22:51:28 +0800
CC: l2vpn@ietf.org

Hi all,

 

We reach an impasseJ.  BTW, Meeting minutes is ready now. We can get E-tree summary from IETF site.

 

Today I collected all items we discussed before. They are,

 

1)       Silicon issue or chip limit;

2)       Network efficiency;

3)       Encapsulation mode, tag or raw;

4)       H-VPLS;

5)       Backwards compatibility, especially legacy PE or Non-supporting PE with IEEE E-tree support joins E-Tree domain;

6)       Configuration change in operation, for example, Leaf-only -> Root-Leaf-Mixed;

7)       S-VLAN preservation support;

8)       Multi-segment PW;

9)       VLAN ID allocation (Only for Dual-VLAN);

10)   Multi-AS deployment;

11)   ECMP;

12)   P2MP-PW;

13)   Ethernet OAM;

 

If we review the mail-list, CW approach has the following limits:

1)       Chip limit. Please read reply from Giles and Wim;

2)       Network efficiency: There are garbage fames which will be dropped on egress PE since only egress PE can decide forward or drop frames while it receives frames. Ingress PE can not decide forward or not. Yes, current solution can support Hub-Spoke configuration, but as we know, the configuration is not easy if the network is big. Dual-VLAN or Multi-PW approach can break communication between Leaf-Only PEs via signaling.

[RK] It seems to me this is not the case. Section 6 of the draft has some discussions on this.
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-6
6. Optional Enhancements for Leaf-only PE
6.1. No PW between Leaf-only PEs
6.2. Not Forward Frame from Leaf AC to Leaf-only PE

 

3)       Backwards compatibility: Not all PEs supports control word. If one can not support control word, it will not join E-Tree domain;

 

[RK] It seems to me this is not the case. Section 5 of the draft has some discussions on this.
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-5
5. Backward Compatibility
5.1. AC Type
5.2. Control Word
5.3. Additional Action in Data Forwarding
5.3.1. Ingress PE Supporting the Extension bu t Egress PE Not
5.3.2. Egress PE Supporting the Extension but Ingress PE Not

 

Dual VLAN has following limits:

1)       Chip limit: As we know, we need to push one VLAN into frames before MPLS encapsulation on ingress PE and stripe it out on egress PE. This is non-standard operation. Wait for confirmation from chip vendor;

2)       HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, but can NOT configure it at all in Spoke PW case;

3)       Multi-PW: Rafi figures this out, but we don$B!G(Bt think this over at that time. I think that it also has same problem as H-VPLS has.

4)       Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN ID;

5)       Backward Compatibility: Just as Daniel mentioned, there is compatibility issue if legacy PE joins E-Tree domain. For me, I don$B!G(Bt get clear response from co-authors of Dual-VLAN.

 

For all approaches, we don$B!G(Bt cover ECMP / Ethernet OAM till now.

 

Is there anything missed?

 

Regards,

 

Yuqun (Sam) Cao

E-mail: Yuqun.cao@gmail.com

 

From: Lizhong Jin [mailto:lizho.jin@gmail.com]
Sent: Saturday, April 21, 2012 11:59 AM
To: Henderickx, Wim (Wim)
Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; yuqun.cao@gmail.com
Subject: RE: The status of the approaches to the E-Tree solution?

 

Hi Win,
Thank you for the answers. In that case, PE-rs should configure the root/leaf properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, you could not figure out the accessing spoke PW is from PE-r of VPWS or MTU-s. Unless having some additional indication in NMS, you even don't know which spoke PW needs to do VLAN manipulation. I am not sure such R/L configuration could be accepted from operational view. Hope to see more comments.

Regards
Lizhong


$B:_(B 2012$BG/(B4$B7n(B21$BF|(B$B@14|O;!$(BHenderickx, Wim (Wim) <wim.henderickx@alcatel-lucent.com> $B
> The VPWS which terminates at the H-VPLS node is indicated to be root or leaf and the procedures associated will do the VLAN manipulation
>
>  
>
> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin
> Sent: vrijdag 20 april 2012 18:38
> To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com
> Cc: yuqun.cao@gmail.com
> Subject: RE: The status of the approaches to the E-Tree solution?
>
>  
>
> Hi, all,
> The difference between 2-VLAN and CW approach is who will provide the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW will carry R/L information for CW approach.
> I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information?
>
> Thanks
> Lizhong
>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 19 Apr 2012 04:38:36 +0000
>> From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
>> To: "Rogers, Josh" <josh.rogers@twcable.com>, Lucy yong
>>        <lucy.yong@huawei.com>, Daniel Cohn <DanielC@orckit.com>, Sam Cao
>>        <yuqun.cao@gmail.com>
>> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
>> Subject: RE: The status of the approaches to the E-Tree solution?
>> Message-ID:
>>        <F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> Hi all,
>> I fully understand that that what I am going to say is not very popular, but:
>>
>> IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic.
>>
>> Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes in the PE configuration.
>>
>> In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root AC from a PE that previously has been supporting a mix etc. affect only the PE where this operation happens and not the rest of the PEs.
>>
>> As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution.
>>
>> My 2c,
>>     Sasha
>>
>>
>>
>> ________________________________________
>> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com]
>> Sent: Wednesday, April 18, 2012 9:57 PM
>> To: Lucy yong; Daniel Cohn; Sam Cao
>> Cc: l2vpn@ietf.org
>> Subject: Re: The status of the approaches to the E-Tree solution?
>>
>> Again, the P2MP situation throws me.  Is this something that is used
>> commonly?
>>
>> I'm under the impression that adding P2MP to any model results in a more
>> complex model.  Wether outside s-tag is used to differentiate, or
>> dedicated pw's are used for the same purpose, it seems both become more
>> complex.
>>
>> Gile's comparison slide still concisely captures the differences between
>> these methods, in my opinion.  I haven't seen any new ideas or thoughts
>> brought to the group in the past week or two on the subject.  I would hate
>> for both proposed methods to die on the vine because we couldn't decide
>> between two methods that have nothing inherently wrong with either.
>>
>> -Josh
>>
>>
>> On 4/18/12 1:53 PM, "Lucy yong" <lucy.yong@huawei.com> wrote:
>>
>>>Send this again.
>>>
>>>Two PW approach can be complex too if the VPLS instance for E-Tree uses
>>>P2P PW fo

--_697703a1-ea71-4e53-a4ad-67a3518ae3fd_-- From Alexander.Vainshtein@ecitele.com Sun Apr 22 00:26:39 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F9021F85D6 for ; Sun, 22 Apr 2012 00:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[AWL=1.017, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, 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 wGnO3o2vwr3s for ; Sun, 22 Apr 2012 00:26:37 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id E8FE321F85A2 for ; Sun, 22 Apr 2012 00:26:35 -0700 (PDT) Received: from [85.158.138.51:19526] by server-3.bemta-3.messagelabs.com id 9C/C2-04048-AA2B39F4; Sun, 22 Apr 2012 07:26:34 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1335079593!12210943!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.7; banners=-,-,- Received: (qmail 3991 invoked from network); 22 Apr 2012 07:26:34 -0000 Received: from unknown (HELO fridlpvsb005.ecitele.com) (168.87.1.157) by server-13.tower-174.messagelabs.com with SMTP; 22 Apr 2012 07:26:34 -0000 X-AuditID: a8571406-b7fe86d0000037a2-da-4f93b2a47624 Received: from FRIDWPPCH001.ecitele.com (fridwppch001.ecitele.com [10.1.16.52]) by fridlpvsb005.ecitele.com (Symantec Messaging Gateway) with SMTP id 04.99.14242.4A2B39F4; Sun, 22 Apr 2012 09:26:28 +0200 (CEST) Received: from FRIDWPPMB002.ecitele.com ([169.254.4.167]) by FRIDWPPCH001.ecitele.com ([10.1.16.52]) with mapi id 14.01.0339.001; Sun, 22 Apr 2012 09:26:32 +0200 From: Alexander Vainshtein To: Sam Cao Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdiov//4SRIP//A88g//rZ1YD/9I0KwA== Date: Sun, 22 Apr 2012 07:26:31 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, , <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <8BD23518D42D4E0CB8E67B5CF7CD3EA8@v2comsam> In-Reply-To: <8BD23518D42D4E0CB8E67B5CF7CD3EA8@v2comsam> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2WTeUzTUBzHfW1XylxJmeiei5pZxcQDMlS0RkbwSqbRjKCJFwbr9tiqWzfX iWBisggmilFBEoUZgwpyqIjwB8FjieKR4B0DBi8SM88ZMR7xQERbq4ixf33f+35/7/N77a8U ri+JMVKCGEB+kXezpJbQgiHGpOrmMpt5z/7RXPBuFcYdquojuMinthiuqfcoyR2MfCG5Q4U3 yQzSuv15WGM9E3ocYy26/EZjra7+ill3nS7DrSdORolMclUQpPGi6A3wAWRyIMluYTP9Qh5v L2BNgsPCprAmn5u3Iw8SAxaW9/mQ6GDTtab/njQ5JogmJNq9DkF0WtiFS21JHJc6KymFTV/m EiQTSvLwgtvkQZLEO5FJ3lFuJTrWnsJd5Q1PMF+4FeQ33o9qgqC7FBSDWAoy02HT66hG1SPg ne5GshhoKT3TAeDVmgNAXRwD8HtPLa6kSMYCm088JhWdwIyF3e3dMYrGmUcA9n6bo+hhzBy4 +2UxUDNz4asHVbiqzwIYfoMpmmAS4c6GBjlDUTSzBNb1j1BZL3C4p/YioWRiGQ7u7bzziwXk 7j5fO4mpLAN88LQSU7tmYPX527iqh8NXkf7ftxkDt9V3/O5tCjx87j2p6smw5sjrX3maiYft FU8JNT8SXqzrIkqAITQIERpUHhpUHhpUfhgQxwHM9QsOty9PWmc2pyYjuxBAbpRs93qagTxR dcsTyFYQLEluAwwFWB2dMbPMptfweVKBpw2MpDB2OD1PHjh93Dqvo8DFS64c/yY3ktoApHA2 gf6QIHu0gy/YgvzePxYnv8RS3DjU7lW+ciBnmtn8z4I10I1Z6TY945RHbwNCPuT/UzqKolhI xynEeD9yovxcwR34a2NUrELWyeSJSoaWfLxHEpyqfw1Mpu59vNIBqB8t7R1AT4heERkN9Lsm OcooUdcmceC0KDDINx5G9ymuTh7IgXOiMgKTEWuz9ykI+QcZsIxBkJN7/3mRLm5+VicROppW Vz6RqjcTG3ckthqi63tqF8dqCrNnny4HS9ZcaKmAL61nvMb4F32VO3sjmV9Tb4178qlr95bS 8KWp47OzZhSG49kVq4f23+jZnKzZOy+yqLFoqa3TmJGofat7X6qFLbYJnq7KxGcrtmbkP2Su L/j2wbzSyBKSi0+ZhPsl/icnj4azIwQAAA== Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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: Sun, 22 Apr 2012 07:26:39 -0000 Sam, Lots of thanks for a prompt response. I will try to provide additional input for the issues list directly to you. I think that providing a mutually agreed upon list of issues would be an imp= ortant step forward: we may not be able to answer some questions we ask, but= the chance that the questions that have not be asked would somehow be answe= red is IMHO negligible:-). As for using BGP-AD with the dual-PW approach, there are three points IMO: 1. I do not understand how 4761 (that does not use PWs in the strict sense o= f the term) is applicable to the dual PW solution. Could you please elaborat= e? Can MP-BGP distribute two labels simultaneously? 2. The solution based on 6074 can work with the dual-PW mechanism, but it re= quires some extension (the PE type must be communicated) 3. In the past, at the early stages of VPLS standardization, the rationale f= or accepting two standard solutions for VPLS (4761 and 4762) has been the ne= ed to support VPLS over BGP-free domains. This is why I would prefer an E-Tr= ee solution that would not strongly depend on BGP-AD to take care of changes= that are local to a single PE. (You may call that a personal bias:-). Regards, Sasha > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Saturday, April 21, 2012 4:42 PM > To: Alexander Vainshtein > Cc: l2vpn@ietf.org; 'Daniel Cohn'; 'Henderickx, Wim (Wim)'; 'Rogers, Josh'= ; > 'Lucy yong' > Subject: RE: The status of the approaches to the E-Tree solution? > > Sasha, > > Thank you for your comments. > > Multi-PW can support BGP-AD, RFC 4761 or RFC 6074. BTW, can we work > together > on issues list? I will list some cases we discussed before. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Thursday, April 19, 2012 9:19 PM > To: Sam Cao > Cc: l2vpn@ietf.org; 'Daniel Cohn'; 'Henderickx, Wim (Wim)'; 'Rogers, Josh'= ; > 'Lucy yong' > Subject: RE: The status of the approaches to the E-Tree solution? > > Sam (hope this is the appropriate form of address and my apologies if not)= , > > I am actually trying to build a list of operational (not > implementation-driven) issues that must be addressed by a reasonable E- > tree > solution. > Then we could compare multiple approaches. > > As for setting up/tearing PWs with multiple peers just because your local > configuration has changed, I am not sure this is reasonable from the > operational point of view. > > E.g., consider the case of a Leaf-only PE migrating to a Mixed PE. > To the best of my understanding, PWs between Leaf-only PWs are not ever > set, > so our original Leaf PE could be unaware about existence of other Leaf-onl= y > PEs (or, even worse, its list of Leaf-only peers could be not matching the > current situation) - and this would not affect traffic in any way. > Once it suddenly becomes a Mix PE, it must set up PWs with all the Leaf- > only > PEs have been ignored before, and they must agree to this... > > IMHO and FWIW, unless you use a very elaborate auto-discovery > mechanism, > this process has all the potential to become an operational nightmare. > > My 2c, > Sasha > > > > -----Original Message----- > > From: Sam Cao [mailto:yuqun.cao@gmail.com] > > Sent: Thursday, April 19, 2012 3:50 PM > > To: Alexander Vainshtein; 'Henderickx, Wim (Wim)'; 'Rogers, Josh'; 'Lucy > > yong'; 'Daniel Cohn' > > Cc: l2vpn@ietf.org > > Subject: RE: The status of the approaches to the E-Tree solution? > > > > Sasha, > > > > We have discussed this case before. While configuration is changed in fl= y, > > it is reasonable to establish or teardown PW. > > > > Regards, > > > > Yuqun (Sam) Cao > > E-mail: Yuqun.cao@gmail.com > > > > > > -----Original Message----- > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > Sent: Thursday, April 19, 2012 1:31 PM > > To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam > Cao > > Cc: l2vpn@ietf.org > > Subject: RE: The status of the approaches to the E-Tree solution? > > > > Wim, > > Lots of thanks for a prompt response. > > > > I think that operational aspects of the VLAN approach (e.g., how is the > > Global VID selected and distributed) should be examined in more detail. > > > > At the same time it seems that the double PW approach carries with it to= o > > many operational problems. > > E.g., no PWs are set up between Leaf-only PEs, but once one of these > > becomes > > a Mix PE, all the Leaf-only PEs must now recognize it as a valid peer. A= nd > > if a Mix PE reverts to a Leaf only one, all its Leaf-only peers must dro= p > it > > and shut down the relevant PWs... > > > > My 2c, > > Sasha > > > > ________________________________________ > > From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] > > Sent: Thursday, April 19, 2012 7:21 AM > > To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao > > Cc: l2vpn@ietf.org > > Subject: RE: The status of the approaches to the E-Tree solution? > > > > Sasha, the VLAN approach allows for a similar operation as the CW does.= It > > is orthogonal to the underlying PW deployment of VPLS. > > > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > > Of > > Alexander Vainshtein > > Sent: donderdag 19 april 2012 6:39 > > To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao > > Cc: l2vpn@ietf.org > > Subject: RE: The status of the approaches to the E-Tree solution? > > > > Hi all, > > I fully understand that that what I am going to say is not very popular, > > but: > > > > IMO one of the advantages of the CW-based solution is that it is > orthogonal > > to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffi= c. > > > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and= , > in > > a more generic way, localization of effects of changes in the PE > > configuration. > > > > In particular, adding a Leaf AC to a PE that previously has been only > > supporting Root ACs (or vice versa), removal of the last Leaf or last Ro= ot > > AC from a PE that previously has been supporting a mix etc. affect only > the > > PE where this operation happens and not the rest of the PEs. > > > > As for the need for HW changes that have been mentioned as a main > > disadvantage of the CW-based approach - I believe it strongly depends on > > specific implementations. And some changes in the forwarding process > are > > required in any solution. > > > > My 2c, > > Sasha > > > > > > > > ________________________________________ > > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of > > Rogers, > > Josh [josh.rogers@twcable.com] > > Sent: Wednesday, April 18, 2012 9:57 PM > > To: Lucy yong; Daniel Cohn; Sam Cao > > Cc: l2vpn@ietf.org > > Subject: Re: The status of the approaches to the E-Tree solution? > > > > Again, the P2MP situation throws me. Is this something that is used > > commonly? > > > > I'm under the impression that adding P2MP to any model results in a more > > complex model. Wether outside s-tag is used to differentiate, or > > dedicated pw's are used for the same purpose, it seems both become > more > > complex. > > > > Gile's comparison slide still concisely captures the differences between > > these methods, in my opinion. I haven't seen any new ideas or thoughts > > brought to the group in the past week or two on the subject. I would ha= te > > for both proposed methods to die on the vine because we couldn't decide > > between two methods that have nothing inherently wrong with either. > > > > -Josh > > > > > > On 4/18/12 1:53 PM, "Lucy yong" wrote: > > > > >Send this again. > > > > > >Two PW approach can be complex too if the VPLS instance for E-Tree uses > > >P2P PW for unicast traffic and P2MP PW for broadcast and unknown > > >unicast traffic, and some P2MP PWs for multicast traffic. It may double > > >all of them. > > > > > >Lucy > > > > > >-----Original Message----- > > >From: Daniel Cohn [mailto:DanielC@orckit.com] > > >Sent: Wednesday, April 18, 2012 1:42 PM > > >To: Lucy yong; Rogers, Josh; Sam Cao > > >Cc: l2vpn@ietf.org > > >Subject: RE: The status of the approaches to the E-Tree solution? > > > > > >I think the first option its the natural way to go. How is the processi= ng > > >in this case more complex? > > > > > >Thumb typed - please be tolerant > > > > > >Lucy yong wrote: > > > > > > > > > > > >Snipped.. > > > > > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP > PW > > >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for > > >traffic coming from a root AC) > > >[[LY]] Not that simple. You construct either two P2MP PWs to all other > > >PEs and let egress PE performing filtering, or construct one P2MP PW to > > >leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE > > >perform forwarding and filtering. Both make node process complex. > > > > > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for > > >delivering the frames to remote PEs. We should utilize them with the > > >minimized changes. Dual VLAN solution is simpler than Dual PW. > > > > > >Regards, > > >Lucy > > > > > > > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I > > >haven't had any first hand experience with P2MP PW's, however, so don't > > >feel terribly strong about this objection. Is this a real problem for > > >others (now or in the future), or is this objection in the weeds? > > > > > >I'm not sure the 'additional complexity' is notable, or even relevant.= I > > >encourage others to speak up if they disagree, as P2MP PW is only > > >conceptual to me, and I am unfamiliar with real-life use cases for it. > > > > > >Thanks, > > >Josh > > > > > > > > > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > > > > > >>Please see inline. > > >> > > >>-----Original Message----- > > >>From: Sam Cao [mailto:yuqun.cao@gmail.com] > > >>Sent: Tuesday, April 17, 2012 7:14 AM > > >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; > > >>giles.heron@gmail.com; simon.delord@gmail.com; > > >>Alexander.Vainshtein@ecitele.com > > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > > >>Subject: RE: The status of the approaches to the E-Tree solution? > > >> > > >>Yes, 2 pws are only needed between pes with both root and leaf acs > after > > >>improving Dual-PW approach. If consider P2MP, Dual-PW approach > setup > > 2 > > >>P2MP > > >>PWs if need. There is no difference between P2MP or normal PW setup. > > But, > > >>can Leaf-ACs be bound to Root PE of P2MP PW? > > >> > > >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with > both > > >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE > have > > >>both root and leaf AC and some only have leaf ACs)? > > >>Regards, > > >>Lucy > > >> > > >>Regards, > > >> > > >>Yuqun (Sam) Cao > > >>E-mail: Yuqun.cao@gmail.com > > >> > > >> > > >>-----Original Message----- > > >>From: Daniel Cohn [mailto:DanielC@orckit.com] > > >>Sent: Tuesday, April 17, 2012 4:56 PM > > >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); > > >>giles.heron@gmail.com; > > >>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam > Cao > > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > > >>Subject: RE: The status of the approaches to the E-Tree solution? > > >> > > >>Adding Sam (as l2vpn@ is holding messages) > > >> > > >>DC > > >> > > >>-----Original Message----- > > >>From: Lucy yong [mailto:lucy.yong@huawei.com] > > >>Sent: Tuesday, April 17, 2012 12:39 AM > > >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); > > >>giles.heron@gmail.com; simon.delord@gmail.com; > > >>Alexander.Vainshtein@ecitele.com > > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > > >>Subject: RE: The status of the approaches to the E-Tree solution? > > >> > > >> > > >>Snipped, > > >> > > >>As we discussed extensively in the list, and as reflected in giles > > >>slide, 2 pws are only needed between pes with both root and leaf acs, > > >>which will typically be a small minority. > > >>[[LY]] Don't know if the assumption is true. Even it is the case, both > > >>approaches can benefit from it. I was off for a while and captures som= e > > >>discussions now. > > >> > > >>Also as per giles slide, dual vlan can have scalability issues due to > > >>additional lookup and double use of vlans in internal emulated lan > > >>interface. Also there are potential backward compatibility issues with > > >>silicon that doesn't support vlan mapping. > > >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I= am > > >>not clear on all the issues. Could you be more specific? As I mentione= d > > >>in below, two PW approach makes VPLS transport construction and > packet > > >>forwarding more complex, I can see potential backward compatibility > > >>issues with 2 PW solution. > > >> > > >>Regards, > > >>Lucy > > >> > > >>Regards, > > >> > > >>Daniel > > >> > > >>Thumb typed - please be tolerant > > >> > > >>Lucy yong wrote: > > >> > > >>In my mind, the VLAN approach means dual vlan method. > > >> > > >>The main concern for CW approach is hardware support. > > >> > > >>Two PW approach can be complex too if the VPLS instance for E-Tree > uses > > >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown > > unicast > > >>traffic, and some P2MP PWs for multicast traffic. It may double all of > > >>them. > > >> > > >>E-tree is an Ethernet service and there is already VLAN based solution > > >>in IEEE, can we just utilize it without complicating VPLS transport > > >>construction? This also makes interworking with Eth only network > easier. > > >> > > >>Cheers, > > >>Lucy > > >> > > >>-----Original Message----- > > >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] > > >>Sent: Monday, April 16, 2012 8:35 AM > > >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; > > >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' > > >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; > > >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; > > >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' > > >>Subject: RE: The status of the approaches to the E-Tree solution? > > >> > > >>I believe the initial question was in regard to the CW method. Are yo= u > > >>saying that you no longer are interested in that method in preference= of > > >>the dual vlan method? > > >> > > >> > > >> > > >>Lucy yong wrote: > > >> > > >> > > >>Agree with Wim. VLAN approach is the best solution for E-Tree. > > >> > > >>Lucy > > >> > > >>-----Original Message----- > > >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > > Behalf > > >>Of Henderickx, Wim (Wim) > > >>Sent: Thursday, April 12, 2012 2:03 AM > > >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; > > >>'Alexander.Vainshtein@ecitele.com' > > >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; > > >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; > > >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' > > >>Subject: Re: The status of the approaches to the E-Tree solution? > > >> > > >>The vlan approach is superior as it also works for eth only networks, > > >>etc. On top some vendors indicate hw issues with the cw approach. As > > >>such we have dropped more or less the cw approach. > > >> > > >>Cheers, > > >>Wim > > >>_________________ > > >>sent from blackberry > > >> > > >>----- Original Message ----- > > >>From: Giles Heron [mailto:giles.heron@gmail.com] > > >>Sent: Thursday, April 12, 2012 08:22 AM > > >>To: Simon Delord ; Alexander Vainshtein > > >> > > >>Cc: l2vpn@ietf.org ; Vladimir Kleiner > > >>; Andrew Sergeev > > >>; Idan Kaspit > ; > > >>Mishael Wexler ; Rotem Cohen > > >> > > >>Subject: Re: The status of the approaches to the E-Tree solution? > > >> > > >>Sorry - the "anonymous presentation" was mine. I should possibly have > > >>put in a third column on the CW approach. And hopefully the minutes > > >>will be posted soon. > > >> > > >>We had various discussions, as Simon stated, and consensus seemed to > > be > > >>forming around the two alternatives of two PWEs or two VLANs. I > believe > > >>three of the authors of the CW approach are also authors of the two > VLAN > > >>approach and one is also an author of the two PWE approach. So perhaps > > >>it's best to let those four individuals say which approach they prefer > > >>and why? > > >> > > >>Giles > > >> > > >>On 10/04/2012 00:45, "Simon Delord" > wrote: > > >> > > >>> Hi Alexander, > > >>> > > >>> You are right, no discussion on the WG mailing list recently, but > > >>> there have been substantial discussions among the authors of various > > >>> solution drafts off the mailing list. As far as I know, no consensus > > >>> yet before ietf83, not sure the progress in the Paris WG meeting. I > > >>> think the CW approach has not been rejected by the WG yet, or the > WG > > >>> has not yet decided on which one to adopt. > > >>> > > >>> Simon > > >>> > > >>> 2012/4/8 Alexander Vainshtein > > >>> > > >>>> Hi all, > > >>>> > > >>>> Unfortunately I have not been able to attend the Paris IETF. > > >>>> > > >>>> However, looking up the L2VPN proceedings, I've found a short > > >>>> anonymous presentation called "E-Tree Update" ( > > >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). > > >>>> This presentation discusses the differences of the E-Tree approache= s > > >>>> based on dedicated VLANs (as in > > >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls- > etree/?include_t > > >>>> ext=3D1) and multiple PWs between the PEs (as in > > >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple- > > pw/?in > > >>>> clude_te > > >>>> xt=3D1) > > >>>> and completely ignores the solution based on usage of the CW in the > > >>>> PWs connecting the PEs (as in > > >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls- > etree/?include_t > > >>>> ext=3D1 > > >>>> ). > > >>>> > > >>>> > > >>>> > > >>>> The Minutes of the Paris L2VPN session are not yet available, but I > > >>>> wonder whether the WG has taken a decision to reject the approach > > >>>> based on the CW usage? I do not remember any recent discussion of > > >>>> this topic on the WG mailing list. > > >>>> > > >>>> > > >>>> > > >>>> Regards, and lots of thanks in advance, > > >>>> > > >>>> Sasha > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> This e-mail message is intended for the recipient only and contains > > >>>> information which is CONFIDENTIAL and which may be proprietary to > > ECI > > >> > > >>>> Telecom. If you have received this transmission in error, please > > >>>> inform us by e-mail, phone or fax, and then delete the original and > > >>>> all copies thereof. > > >>>> > > >> > > >> > > >> > > >> > > >> > > >>This E-mail and any of its attachments may contain Time Warner Cable > > >>proprietary information, which is privileged, confidential, or subject > > >>to copyright belonging to Time Warner Cable. This E-mail is intended > > >>solely for the use of the individual or entity to which it is addresse= d. > > >>If you are not the intended recipient of this E-mail, you are hereby > > >>notified that any dissemination, distribution, copying, or action take= n > > >>in relation to the contents of and attachments to this E-mail is > > >>strictly prohibited and may be unlawful. If you have received this > > >>E-mail in error, please notify the sender immediately and permanently > > >>delete the original and any copy of this E-mail and any printout. > > >> > > > > > > > > >This E-mail and any of its attachments may contain Time Warner Cable > > >proprietary information, which is privileged, confidential, or subject= to > > >copyright belonging to Time Warner Cable. This E-mail is intended solel= y > > >for the use of the individual or entity to which it is addressed. If yo= u > > >are not the intended recipient of this E-mail, you are hereby notified > > >that any dissemination, distribution, copying, or action taken in > > >relation to the contents of and attachments to this E-mail is strictly > > >prohibited and may be unlawful. If you have received this E-mail in > > >error, please notify the sender immediately and permanently delete the > > >original and any copy of this E-mail and any printout. > > > > > > This E-mail and any of its attachments may contain Time Warner Cable > > proprietary information, which is privileged, confidential, or subject t= o > > copyright belonging to Time Warner Cable. This E-mail is intended solely > for > > the use of the individual or entity to which it is addressed. If you are > not > > the intended recipient of this E-mail, you are hereby notified that any > > dissemination, distribution, copying, or action taken in relation to the > > contents of and attachments to this E-mail is strictly prohibited and ma= y > be > > unlawful. If you have received this E-mail in error, please notify the > > sender immediately and permanently delete the original and any copy of > > this > > E-mail and any printout. > > This e-mail message is intended for the recipient only and contains > > information which is CONFIDENTIAL and which may be proprietary to ECI > > Telecom. If you have received this transmission in error, please inform= us > > by e-mail, phone or fax, and then delete the original and all copies > > thereof. > > This e-mail message is intended for the recipient only and contains > > information which is CONFIDENTIAL and which may be proprietary to ECI > > Telecom. If you have received this transmission in error, please inform= us > > by e-mail, phone or fax, and then delete the original and all copies > > thereof. > > > > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us > by e-mail, phone or fax, and then delete the original and all copies > thereof. > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From DanielC@orckit.com Sun Apr 22 01:34:09 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA7521F8639 for ; Sun, 22 Apr 2012 01:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599] 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 1bvI7cLBRZIY for ; Sun, 22 Apr 2012 01:34:07 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id E8ED221F8620 for ; Sun, 22 Apr 2012 01:34:06 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Date: Sun, 22 Apr 2012 11:36:16 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081307510E2C@tlvmail1> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdiov//4SRIP//A88g//rZ1YD/9I0KwP/pAnkg References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, , <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <8BD23518D42D4E0CB8E67B5CF7CD3EA8@v2comsam> From: "Daniel Cohn" To: "Alexander Vainshtein" , "Sam Cao" Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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: Sun, 22 Apr 2012 08:34:09 -0000 Hi Sasha, You can find answers to your questions #1 and #2 in the draft itself (http://tools.ietf.org/html/draft-ram-l2vpn-etree-multiple-pw-01) - sections 7 and 8 specify extensions to BGP to support RFC 4761/6074 VPLS. Regards, Daniel -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Sunday, April 22, 2012 10:27 AM To: Sam Cao Cc: l2vpn@ietf.org; Daniel Cohn; 'Henderickx, Wim (Wim)'; 'Rogers, Josh'; 'Lucy yong' Subject: RE: The status of the approaches to the E-Tree solution? Sam, Lots of thanks for a prompt response. I will try to provide additional input for the issues list directly to you. I think that providing a mutually agreed upon list of issues would be an important step forward: we may not be able to answer some questions we ask, but the chance that the questions that have not be asked would somehow be answered is IMHO negligible:-). As for using BGP-AD with the dual-PW approach, there are three points IMO: 1. I do not understand how 4761 (that does not use PWs in the strict sense of the term) is applicable to the dual PW solution. Could you please elaborate? Can MP-BGP distribute two labels simultaneously? 2. The solution based on 6074 can work with the dual-PW mechanism, but it requires some extension (the PE type must be communicated) 3. In the past, at the early stages of VPLS standardization, the rationale for accepting two standard solutions for VPLS (4761 and 4762) has been the need to support VPLS over BGP-free domains. This is why I would prefer an E-Tree solution that would not strongly depend on BGP-AD to take care of changes that are local to a single PE. (You may call that a personal bias:-). Regards, Sasha > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Saturday, April 21, 2012 4:42 PM > To: Alexander Vainshtein > Cc: l2vpn@ietf.org; 'Daniel Cohn'; 'Henderickx, Wim (Wim)'; 'Rogers,=20 > Josh'; 'Lucy yong' > Subject: RE: The status of the approaches to the E-Tree solution? >=20 > Sasha, >=20 > Thank you for your comments. >=20 > Multi-PW can support BGP-AD, RFC 4761 or RFC 6074. BTW, can we work=20 > together on issues list? I will list some cases we discussed before. >=20 > Regards, >=20 > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com >=20 > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Thursday, April 19, 2012 9:19 PM > To: Sam Cao > Cc: l2vpn@ietf.org; 'Daniel Cohn'; 'Henderickx, Wim (Wim)'; 'Rogers,=20 > Josh'; 'Lucy yong' > Subject: RE: The status of the approaches to the E-Tree solution? >=20 > Sam (hope this is the appropriate form of address and my apologies if=20 > not), >=20 > I am actually trying to build a list of operational (not > implementation-driven) issues that must be addressed by a reasonable=20 > E- tree solution. > Then we could compare multiple approaches. >=20 > As for setting up/tearing PWs with multiple peers just because your=20 > local configuration has changed, I am not sure this is reasonable from > the operational point of view. >=20 > E.g., consider the case of a Leaf-only PE migrating to a Mixed PE. > To the best of my understanding, PWs between Leaf-only PWs are not=20 > ever set, so our original Leaf PE could be unaware about existence of=20 > other Leaf-only PEs (or, even worse, its list of Leaf-only peers could > be not matching the current situation) - and this would not affect=20 > traffic in any way. > Once it suddenly becomes a Mix PE, it must set up PWs with all the=20 > Leaf- only PEs have been ignored before, and they must agree to=20 > this... >=20 > IMHO and FWIW, unless you use a very elaborate auto-discovery=20 > mechanism, this process has all the potential to become an operational > nightmare. >=20 > My 2c, > Sasha >=20 >=20 > > -----Original Message----- > > From: Sam Cao [mailto:yuqun.cao@gmail.com] > > Sent: Thursday, April 19, 2012 3:50 PM > > To: Alexander Vainshtein; 'Henderickx, Wim (Wim)'; 'Rogers, Josh';=20 > > 'Lucy yong'; 'Daniel Cohn' > > Cc: l2vpn@ietf.org > > Subject: RE: The status of the approaches to the E-Tree solution? > > > > Sasha, > > > > We have discussed this case before. While configuration is changed=20 > > in fly, it is reasonable to establish or teardown PW. > > > > Regards, > > > > Yuqun (Sam) Cao > > E-mail: Yuqun.cao@gmail.com > > > > > > -----Original Message----- > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > Sent: Thursday, April 19, 2012 1:31 PM > > To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam > Cao > > Cc: l2vpn@ietf.org > > Subject: RE: The status of the approaches to the E-Tree solution? > > > > Wim, > > Lots of thanks for a prompt response. > > > > I think that operational aspects of the VLAN approach (e.g., how is=20 > > the Global VID selected and distributed) should be examined in more detail. > > > > At the same time it seems that the double PW approach carries with=20 > > it too many operational problems. > > E.g., no PWs are set up between Leaf-only PEs, but once one of these > > becomes a Mix PE, all the Leaf-only PEs must now recognize it as a=20 > > valid peer. And if a Mix PE reverts to a Leaf only one, all its=20 > > Leaf-only peers must drop > it > > and shut down the relevant PWs... > > > > My 2c, > > Sasha > > > > ________________________________________ > > From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] > > Sent: Thursday, April 19, 2012 7:21 AM > > To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam=20 > > Cao > > Cc: l2vpn@ietf.org > > Subject: RE: The status of the approaches to the E-Tree solution? > > > > Sasha, the VLAN approach allows for a similar operation as the CW=20 > > does. It is orthogonal to the underlying PW deployment of VPLS. > > > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On=20 > > Behalf Of Alexander Vainshtein > > Sent: donderdag 19 april 2012 6:39 > > To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao > > Cc: l2vpn@ietf.org > > Subject: RE: The status of the approaches to the E-Tree solution? > > > > Hi all, > > I fully understand that that what I am going to say is not very=20 > > popular, > > but: > > > > IMO one of the advantages of the CW-based solution is that it is > orthogonal > > to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. > > > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, > > and, > in > > a more generic way, localization of effects of changes in the PE=20 > > configuration. > > > > In particular, adding a Leaf AC to a PE that previously has been=20 > > only supporting Root ACs (or vice versa), removal of the last Leaf=20 > > or last Root AC from a PE that previously has been supporting a mix=20 > > etc. affect only > the > > PE where this operation happens and not the rest of the PEs. > > > > As for the need for HW changes that have been mentioned as a main=20 > > disadvantage of the CW-based approach - I believe it strongly=20 > > depends on specific implementations. And some changes in the=20 > > forwarding process > are > > required in any solution. > > > > My 2c, > > Sasha > > > > > > > > ________________________________________ > > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of=20 > > Rogers, Josh [josh.rogers@twcable.com] > > Sent: Wednesday, April 18, 2012 9:57 PM > > To: Lucy yong; Daniel Cohn; Sam Cao > > Cc: l2vpn@ietf.org > > Subject: Re: The status of the approaches to the E-Tree solution? > > > > Again, the P2MP situation throws me. Is this something that is used > > commonly? > > > > I'm under the impression that adding P2MP to any model results in a=20 > > more complex model. Wether outside s-tag is used to differentiate,=20 > > or dedicated pw's are used for the same purpose, it seems both=20 > > become > more > > complex. > > > > Gile's comparison slide still concisely captures the differences=20 > > between these methods, in my opinion. I haven't seen any new ideas=20 > > or thoughts brought to the group in the past week or two on the=20 > > subject. I would hate for both proposed methods to die on the vine=20 > > because we couldn't decide between two methods that have nothing inherently wrong with either. > > > > -Josh > > > > > > On 4/18/12 1:53 PM, "Lucy yong" wrote: > > > > >Send this again. > > > > > >Two PW approach can be complex too if the VPLS instance for E-Tree=20 > > >uses P2P PW for unicast traffic and P2MP PW for broadcast and=20 > > >unknown unicast traffic, and some P2MP PWs for multicast traffic.=20 > > >It may double all of them. > > > > > >Lucy > > > > > >-----Original Message----- > > >From: Daniel Cohn [mailto:DanielC@orckit.com] > > >Sent: Wednesday, April 18, 2012 1:42 PM > > >To: Lucy yong; Rogers, Josh; Sam Cao > > >Cc: l2vpn@ietf.org > > >Subject: RE: The status of the approaches to the E-Tree solution? > > > > > >I think the first option its the natural way to go. How is the=20 > > >processing in this case more complex? > > > > > >Thumb typed - please be tolerant > > > > > >Lucy yong wrote: > > > > > > > > > > > >Snipped.. > > > > > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only=20 > > >P2MP > PW > > >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW=20 > > >(for traffic coming from a root AC) [[LY]] Not that simple. You=20 > > >construct either two P2MP PWs to all other PEs and let egress PE=20 > > >performing filtering, or construct one P2MP PW to leaf-only PEs and > > >two P2MP PWs to root and leaf PEs and let ingress PE perform=20 > > >forwarding and filtering. Both make node process complex. > > > > > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW=20 > > >for delivering the frames to remote PEs. We should utilize them=20 > > >with the minimized changes. Dual VLAN solution is simpler than Dual PW. > > > > > >Regards, > > >Lucy > > > > > > > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I > > >haven't had any first hand experience with P2MP PW's, however, so=20 > > >don't feel terribly strong about this objection. Is this a real=20 > > >problem for others (now or in the future), or is this objection in the weeds? > > > > > >I'm not sure the 'additional complexity' is notable, or even=20 > > >relevant. I encourage others to speak up if they disagree, as P2MP > > >PW is only conceptual to me, and I am unfamiliar with real-life use cases for it. > > > > > >Thanks, > > >Josh > > > > > > > > > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > > > > > >>Please see inline. > > >> > > >>-----Original Message----- > > >>From: Sam Cao [mailto:yuqun.cao@gmail.com] > > >>Sent: Tuesday, April 17, 2012 7:14 AM > > >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim=20 > > >>(Wim)'; giles.heron@gmail.com; simon.delord@gmail.com;=20 > > >>Alexander.Vainshtein@ecitele.com > > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com;=20 > > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com;=20 > > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > > >>Subject: RE: The status of the approaches to the E-Tree solution? > > >> > > >>Yes, 2 pws are only needed between pes with both root and leaf acs > after > > >>improving Dual-PW approach. If consider P2MP, Dual-PW approach > setup > > 2 > > >>P2MP > > >>PWs if need. There is no difference between P2MP or normal PW setup. > > But, > > >>can Leaf-ACs be bound to Root PE of P2MP PW? > > >> > > >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE=20 > > >>with > both > > >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE > have > > >>both root and leaf AC and some only have leaf ACs)? > > >>Regards, > > >>Lucy > > >> > > >>Regards, > > >> > > >>Yuqun (Sam) Cao > > >>E-mail: Yuqun.cao@gmail.com > > >> > > >> > > >>-----Original Message----- > > >>From: Daniel Cohn [mailto:DanielC@orckit.com] > > >>Sent: Tuesday, April 17, 2012 4:56 PM > > >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim);=20 > > >>giles.heron@gmail.com; simon.delord@gmail.com;=20 > > >>Alexander.Vainshtein@ecitele.com; Sam > Cao > > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com;=20 > > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com;=20 > > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > > >>Subject: RE: The status of the approaches to the E-Tree solution? > > >> > > >>Adding Sam (as l2vpn@ is holding messages) > > >> > > >>DC > > >> > > >>-----Original Message----- > > >>From: Lucy yong [mailto:lucy.yong@huawei.com] > > >>Sent: Tuesday, April 17, 2012 12:39 AM > > >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim);=20 > > >>giles.heron@gmail.com; simon.delord@gmail.com;=20 > > >>Alexander.Vainshtein@ecitele.com > > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com;=20 > > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com;=20 > > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > > >>Subject: RE: The status of the approaches to the E-Tree solution? > > >> > > >> > > >>Snipped, > > >> > > >>As we discussed extensively in the list, and as reflected in giles > > >>slide, 2 pws are only needed between pes with both root and leaf=20 > > >>acs, which will typically be a small minority. > > >>[[LY]] Don't know if the assumption is true. Even it is the case,=20 > > >>both approaches can benefit from it. I was off for a while and=20 > > >>captures some discussions now. > > >> > > >>Also as per giles slide, dual vlan can have scalability issues due > > >>to additional lookup and double use of vlans in internal emulated=20 > > >>lan interface. Also there are potential backward compatibility=20 > > >>issues with silicon that doesn't support vlan mapping. > > >>[[LY]] I was not in IETF83 meeting and wait on the meeting=20 > > >>minutes. I am not clear on all the issues. Could you be more=20 > > >>specific? As I mentioned in below, two PW approach makes VPLS=20 > > >>transport construction and > packet > > >>forwarding more complex, I can see potential backward=20 > > >>compatibility issues with 2 PW solution. > > >> > > >>Regards, > > >>Lucy > > >> > > >>Regards, > > >> > > >>Daniel > > >> > > >>Thumb typed - please be tolerant > > >> > > >>Lucy yong wrote: > > >> > > >>In my mind, the VLAN approach means dual vlan method. > > >> > > >>The main concern for CW approach is hardware support. > > >> > > >>Two PW approach can be complex too if the VPLS instance for E-Tree > uses > > >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown > > unicast > > >>traffic, and some P2MP PWs for multicast traffic. It may double=20 > > >>all of them. > > >> > > >>E-tree is an Ethernet service and there is already VLAN based=20 > > >>solution in IEEE, can we just utilize it without complicating VPLS > > >>transport construction? This also makes interworking with Eth only > > >>network > easier. > > >> > > >>Cheers, > > >>Lucy > > >> > > >>-----Original Message----- > > >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] > > >>Sent: Monday, April 16, 2012 8:35 AM > > >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com';=20 > > >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' > > >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com';=20 > > >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com';=20 > > >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' > > >>Subject: RE: The status of the approaches to the E-Tree solution? > > >> > > >>I believe the initial question was in regard to the CW method. =20 > > >>Are you saying that you no longer are interested in that method in > > >>preference of the dual vlan method? > > >> > > >> > > >> > > >>Lucy yong wrote: > > >> > > >> > > >>Agree with Wim. VLAN approach is the best solution for E-Tree. > > >> > > >>Lucy > > >> > > >>-----Original Message----- > > >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > > Behalf > > >>Of Henderickx, Wim (Wim) > > >>Sent: Thursday, April 12, 2012 2:03 AM > > >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com';=20 > > >>'Alexander.Vainshtein@ecitele.com' > > >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com';=20 > > >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com';=20 > > >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' > > >>Subject: Re: The status of the approaches to the E-Tree solution? > > >> > > >>The vlan approach is superior as it also works for eth only=20 > > >>networks, etc. On top some vendors indicate hw issues with the cw=20 > > >>approach. As such we have dropped more or less the cw approach. > > >> > > >>Cheers, > > >>Wim > > >>_________________ > > >>sent from blackberry > > >> > > >>----- Original Message ----- > > >>From: Giles Heron [mailto:giles.heron@gmail.com] > > >>Sent: Thursday, April 12, 2012 08:22 AM > > >>To: Simon Delord ; Alexander Vainshtein=20 > > >> > > >>Cc: l2vpn@ietf.org ; Vladimir Kleiner=20 > > >>; Andrew Sergeev=20 > > >>; Idan Kaspit > ; > > >>Mishael Wexler ; Rotem Cohen=20 > > >> > > >>Subject: Re: The status of the approaches to the E-Tree solution? > > >> > > >>Sorry - the "anonymous presentation" was mine. I should possibly=20 > > >>have put in a third column on the CW approach. And hopefully the=20 > > >>minutes will be posted soon. > > >> > > >>We had various discussions, as Simon stated, and consensus seemed=20 > > >>to > > be > > >>forming around the two alternatives of two PWEs or two VLANs. I > believe > > >>three of the authors of the CW approach are also authors of the=20 > > >>two > VLAN > > >>approach and one is also an author of the two PWE approach. So=20 > > >>perhaps it's best to let those four individuals say which approach > > >>they prefer and why? > > >> > > >>Giles > > >> > > >>On 10/04/2012 00:45, "Simon Delord" > wrote: > > >> > > >>> Hi Alexander, > > >>> > > >>> You are right, no discussion on the WG mailing list recently,=20 > > >>> but there have been substantial discussions among the authors of > > >>> various solution drafts off the mailing list. As far as I know,=20 > > >>> no consensus yet before ietf83, not sure the progress in the=20 > > >>> Paris WG meeting. I think the CW approach has not been rejected=20 > > >>> by the WG yet, or the > WG > > >>> has not yet decided on which one to adopt. > > >>> > > >>> Simon > > >>> > > >>> 2012/4/8 Alexander Vainshtein > > >>> > > >>>> Hi all, > > >>>> > > >>>> Unfortunately I have not been able to attend the Paris IETF. > > >>>> > > >>>> However, looking up the L2VPN proceedings, I've found a short=20 > > >>>> anonymous presentation called "E-Tree Update" (=20 > > >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). > > >>>> This presentation discusses the differences of the E-Tree=20 > > >>>> approaches based on dedicated VLANs (as in > > >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls- > etree/?include_t > > >>>> ext=3D1) and multiple PWs between the PEs (as in > > >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple- > > pw/?in > > >>>> clude_te > > >>>> xt=3D1) > > >>>> and completely ignores the solution based on usage of the CW in > > >>>> the PWs connecting the PEs (as in > > >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls- > etree/?include_t > > >>>> ext=3D1 > > >>>> ). > > >>>> > > >>>> > > >>>> > > >>>> The Minutes of the Paris L2VPN session are not yet available,=20 > > >>>> but I wonder whether the WG has taken a decision to reject the=20 > > >>>> approach based on the CW usage? I do not remember any recent=20 > > >>>> discussion of this topic on the WG mailing list. > > >>>> > > >>>> > > >>>> > > >>>> Regards, and lots of thanks in advance, > > >>>> > > >>>> Sasha > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> This e-mail message is intended for the recipient only and=20 > > >>>> contains information which is CONFIDENTIAL and which may be=20 > > >>>> proprietary to > > ECI > > >> > > >>>> Telecom. If you have received this transmission in error,=20 > > >>>> please inform us by e-mail, phone or fax, and then delete the=20 > > >>>> original and all copies thereof. > > >>>> > > >> > > >> > > >> > > >> > > >> > > >>This E-mail and any of its attachments may contain Time Warner=20 > > >>Cable proprietary information, which is privileged, confidential,=20 > > >>or subject to copyright belonging to Time Warner Cable. This=20 > > >>E-mail is intended solely for the use of the individual or entity to which it is addressed. > > >>If you are not the intended recipient of this E-mail, you are=20 > > >>hereby notified that any dissemination, distribution, copying, or=20 > > >>action taken in relation to the contents of and attachments to=20 > > >>this E-mail is strictly prohibited and may be unlawful. If you=20 > > >>have received this E-mail in error, please notify the sender=20 > > >>immediately and permanently delete the original and any copy of this E-mail and any printout. > > >> > > > > > > > > >This E-mail and any of its attachments may contain Time Warner=20 > > >Cable proprietary information, which is privileged, confidential,=20 > > >or subject to copyright belonging to Time Warner Cable. This E-mail > > >is intended solely for the use of the individual or entity to which > > >it is addressed. If you are not the intended recipient of this=20 > > >E-mail, you are hereby notified that any dissemination,=20 > > >distribution, copying, or action taken in relation to the contents=20 > > >of and attachments to this E-mail is strictly prohibited and may be > > >unlawful. If you have received this E-mail in error, please notify=20 > > >the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > > > > > > This E-mail and any of its attachments may contain Time Warner Cable > > proprietary information, which is privileged, confidential, or=20 > > subject to copyright belonging to Time Warner Cable. This E-mail is=20 > > intended solely > for > > the use of the individual or entity to which it is addressed. If you > > are > not > > the intended recipient of this E-mail, you are hereby notified that=20 > > any dissemination, distribution, copying, or action taken in=20 > > relation to the contents of and attachments to this E-mail is=20 > > strictly prohibited and may > be > > unlawful. If you have received this E-mail in error, please notify=20 > > the sender immediately and permanently delete the original and any=20 > > copy of this E-mail and any printout. > > This e-mail message is intended for the recipient only and contains=20 > > information which is CONFIDENTIAL and which may be proprietary to=20 > > ECI Telecom. If you have received this transmission in error, please > > inform us by e-mail, phone or fax, and then delete the original and=20 > > all copies thereof. > > This e-mail message is intended for the recipient only and contains=20 > > information which is CONFIDENTIAL and which may be proprietary to=20 > > ECI Telecom. If you have received this transmission in error, please > > inform us by e-mail, phone or fax, and then delete the original and=20 > > all copies thereof. > > >=20 >=20 > This e-mail message is intended for the recipient only and contains=20 > information which is CONFIDENTIAL and which may be proprietary to ECI=20 > Telecom. If you have received this transmission in error, please=20 > inform us by e-mail, phone or fax, and then delete the original and=20 > all copies thereof. >=20 This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. From jiangyuanlong@huawei.com Sun Apr 22 02:26:16 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B38A21F860E for ; Sun, 22 Apr 2012 02:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] 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 Q6ayOkmaMX+s for ; Sun, 22 Apr 2012 02:26:15 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 47C8721F85ED for ; Sun, 22 Apr 2012 02:26:15 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFC73617; Sun, 22 Apr 2012 05:26:14 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 22 Apr 2012 02:25:29 -0700 Received: from SZXEML436-HUB.china.huawei.com (10.72.61.64) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 22 Apr 2012 02:25:28 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.137]) by szxeml436-hub.china.huawei.com ([10.72.61.64]) with mapi id 14.01.0323.003; Sun, 22 Apr 2012 17:25:25 +0800 From: Jiangyuanlong To: "Rogers, Josh" , Shahram Davari , "Alexander.Vainshtein@ecitele.com" Subject: SVLAN in the 2VLAN E-Tree solution Thread-Topic: SVLAN in the 2VLAN E-Tree solution Thread-Index: AQHNIGnYIGQiDdpMUE2tQ8riKysROg== Date: Sun, 22 Apr 2012 09:25:24 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E7C6@SZXEML508-MBS.china.huawei.com> References: 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.70.40.82] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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: Sun, 22 Apr 2012 09:26:16 -0000 SGkgSm9zaCBhbmQgU2hhaHJhbSwNCg0KUGxlYXNlIHNlZSBteSBjb21tZW50cyBpbiBsaW5lIHRh Z2dlZCB3aXRoIFtKWV0uDQpJIGFsc28gY2hhbmdlZCB0aGUgdGl0bGUgdG8gcmVmbGVjdCB0aGUg dG9waWMgaW4gZGlzY3Vzc2lvbi4NCg0KUmVnYXJkcw0KWXVhbmxvbmcNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cg0KRGF0ZTogRnJpLCAyMCBBcHIgMjAxMiAxNDo0MDowOSAtMDQwMA0KRnJvbTogIlJvZ2Vycywg Sm9zaCIgPGpvc2gucm9nZXJzQHR3Y2FibGUuY29tPg0KVG86IFNoYWhyYW0gRGF2YXJpIDxkYXZh cmlAYnJvYWRjb20uY29tPiwgTGl6aG9uZyBKaW4NCgk8bGl6aG8uamluQGdtYWlsLmNvbT4sCSJs MnZwbkBpZXRmLm9yZyIgPGwydnBuQGlldGYub3JnPiwNCgkiQWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb20iCTxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4NCkNjOiAieXVx dW4uY2FvQGdtYWlsLmNvbSIgPHl1cXVuLmNhb0BnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogVGhl IHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KTWVzc2Fn ZS1JRDogPENCQjcyNDVFLkFGMSVqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbT4NCkNvbnRlbnQtVHlw ZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXMtYXNjaWkiDQoNClRoaXMgaXMgYSB2ZXJ5IGdvb2Qg cXVlc3Rpb24uICBBIGNvbW1vbiAoYnV0IG5vdCBuZWNlc3NhcmlseSBnb29kKSB1c2UgY2FzZSB3 ZSBydW4gaW50byBpcyBzZXJ2aWNlIG11bHRpcGxleGluZyBVTkkncyB3aGVyZSBtdWx0aXBsZSBF TEFOIG9yIEVUUkVFIHNlcnZpY2VzIGFyZSBoYW5kZWQgb2ZmIHRvIHRoZSBjdXN0b21lciwgYW5k IHRoZSBTLVZMQU4gaXMgJ2Nvb3JkaW5hdGVkJyB3aXRoIHRoZSBjdXN0b21lci4gIE1lYW5pbmcg d2UgZXhwZWN0IHRoZW0gdG8gdGFnIHRyYWZmaWMgZm9yIHNlcnZpY2UgWCB3aXRoIFMtdGFnIFgu DQpbSlldIElmIEVMQU4gb3IgRVRSRUUgaXMgdGhlIHNhbWUgc2VydmljZSBhcyBkZWZpbmVkIGlu IE1FRiwgb25seSBDLVZMQU5zIG1heSBleGlzdCBpbiB0aGUgVU5JIGFzIHNlcnZpY2UgZGUtbXVs dGlwbGV4ZXIuIFMtVkxBTiBtYXkgb25seSBhcHBlYXIgaW4gdGhlIEUtTk5JLCBpZiB0aGlzIGlz IHRoZSBjYXNlLCB0aGUgUy1WTEFOIHNob3VsZCBiZSAnY29vcmRpbmF0ZWQnIHdpdGggdGhlIGV4 dGVybmFsIG5ldHdvcmsgKG1heWJlIEV0aGVybmV0IGl0c2VsZikuDQoNCkkgc3VwcG9zZSB0aGF0 IHdlIHdvdWxkIGFzayB0aGUgY3VzdG9tZXIgdG8gdXNlIHRoZSAncm9vdCcgUy1UYWcgYXQgdGhl IHJvb3Qgc2l0ZSwgYW5kIHRoZSAnbGVhZicgYXQgbGVhZiBzaXRlcywgaG93ZXZlciB0aGlzIGlu dHJvZHVjZXMgYSBwcm9ibGVtIGluIG15IG1pbmQsIGJlY2F1c2UgSSBiZWxpZXZlIHRoZSAyVkxB TiBtZXRob2QgaGFzIGJlZW4gd29ya2luZyB1bmRlciB0aGUgbWluZHNldCBvZiBwb3BwaW5nIHRo ZSBzLXRhZyBvZmYgb24gVU5JIGVncmVzcy4gIEluIHRoaXMgc2l0dWF0aW9uIHdoZXJlIHdlIHdh bnQgdG8ga2VlcCB0aGUgcy10YWcgaW4gdGFjdCwgd2Ugd291bGQgcmVxdWlyZSB0aGUgcy10YWcg dG8gYmUga2VwdCBvbiBib3RoIGluZ3Jlc3MgYXQgb25lIGVuZCBhbmQgZWdyZXNzIGF0IHRoZSBv dGhlci4gIChTbyB0aGluZ3MgbGlrZSBQVlNUIGRvbid0IGdldCB1cHNldCBhYm91dCBiZWluZyBz ZW50IHdpdGggb25lIHZsYW4gcmVjZWl2ZWQgdy9vdXQgaXQpDQpbSlldIElmIHRoZSBjdXN0b21l ciBpcyBhIG5ldHdvcmsgcHJvdmlkZXIsIEkgdGhpbmsgaXQgaXMgYSBwb3NzaWJsZSBjYXNlLiBC dXQgdGhlIFMtVEFHIG5lZWQgbm90IGJlIHBvcHBlZCBvZmYgaW4gdGhpcyBjYXNlIHNpbmNlIGl0 IGlzIG5vdCBhIEUtVHJlZSBVTkkgd2l0aCB0aGUgZW5kIGN1c3RvbWVyLCBidXQgYSBOTkkgd2l0 aCBhbm90aGVyIGNhcnJpZXIgKGN1c3RvbWVyIGFzIGEgbmV0d29yayBwcm92aWRlcikuDQoNClRo aXMgbWVhbnMgdGhhdCB0aGUgY3VzdG9tZXIgd291bGQgYmUgZXhwZWN0ZWQgdG8gZWl0aGVyLCAx KSBzZW5kIGEgZnJhbWUgd2l0aCBvbmUgVkxBTiBpZCBmcm9tIG9uZSBzaXRlIHR5cGUsIGFuZCBl eHBlY3QgdG8gcmVjZWl2ZSBpdCB3aXRoIGFub3RoZXIgYXQgdGhlIG90aGVyIHNpdGUgdHlwZXMs IGFuZCB0aGUgb3BlcmF0b3Igc29ydCBvZiAnbWFwcycgYmV0d2VlbiByb290L2xlYWYgcy10YWdz LiAgT3IgMikgdHJhbnNtaXQgb25lIHZsYW4gb24gYSBVTkksIGFuZCBleHBlY3QgcmV0dXJuIHRy YWZmaWMgdG8gYmUgdGFnZ2VkIHdpdGggdGhlIG90aGVyIHZsYW4uDQoNCk5laXRoZXIgb2Ygd2hp Y2ggaXMgYSBnb29kL3JlYXNvbmFibGUgb3B0aW9uLiAgSXMgdGhlcmUgc29tZSBvdGhlciB3YXkg SSBoYXZlbid0IGNvbnNpZGVyZWQgaGVyZT8NCg0KLUpvc2gNCg0KDQpGcm9tOiBTaGFocmFtIERh dmFyaSA8ZGF2YXJpQGJyb2FkY29tLmNvbTxtYWlsdG86ZGF2YXJpQGJyb2FkY29tLmNvbT4+DQpU bzogTGl6aG9uZyBKaW4gPGxpemhvLmppbkBnbWFpbC5jb208bWFpbHRvOmxpemhvLmppbkBnbWFp bC5jb20+PiwgImwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4iIDxsMnZwbkBp ZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+PiwgIkFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4iIDxBbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb20+Pg0KQ2M6ICJ5dXF1bi5jYW9AZ21haWwuY29tPG1haWx0bzp5dXF1bi5jYW9A Z21haWwuY29tPiIgPHl1cXVuLmNhb0BnbWFpbC5jb208bWFpbHRvOnl1cXVuLmNhb0BnbWFpbC5j b20+Pg0KU3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUt VHJlZSBzb2x1dGlvbj8NCg0KSGksDQoNCkkgYWxzbyBoYXZlIGEgcXVlc3Rpb24gcmVnYXJkaW5n IDItVkxBTi4gV2hhdCBpZiB0aGUgY3VzdG9tZXIgdHJhZmZpYyBhbHJlYWR5IGhhcyBhbiBTLVZM QU4/IERvIHdlIG5lZWQgYSAzcmQgVkxBTiB0byBpZGVudGlmeSB0aGUgTC9SPw0KDQpUaHgNClNo YWhyYW0NCg== From jiangyuanlong@huawei.com Sun Apr 22 02:43:53 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E10521F85DF for ; Sun, 22 Apr 2012 02:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.861 X-Spam-Level: X-Spam-Status: No, score=-1.861 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, J_CHICKENPOX_31=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 vlI-FWgRncTK for ; Sun, 22 Apr 2012 02:43:50 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A45D721F857D for ; Sun, 22 Apr 2012 02:43:50 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFK77148; Sun, 22 Apr 2012 05:43:50 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 22 Apr 2012 02:42:59 -0700 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 22 Apr 2012 02:42:58 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.137]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Sun, 22 Apr 2012 17:42:51 +0800 From: Jiangyuanlong To: Sam Cao Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNIGxIkTBdljOSQkeqvNTqsF/qWQ== Date: Sun, 22 Apr 2012 09:42:51 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E7DD@SZXEML508-MBS.china.huawei.com> References: 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.70.40.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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: Sun, 22 Apr 2012 09:43:53 -0000 Hi Sam, Please see my comments in line with [JY]. Regards, Yuanlong ---------------------------------------------------------------------- Message: 1 Date: Sat, 21 Apr 2012 22:51:28 +0800 From: "Sam Cao" To: "'Lizhong Jin'" , "'Henderickx, Wim \(Wim\)'" Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <1B88357C808B432E871CA9D678305B7C@v2comsam> Content-Type: text/plain; charset=3D"gb2312" Hi all, =20 We reach an impasse:-). BTW, Meeting minutes is ready now. We can get E-tree summary from IETF site. =20 Today I collected all items we discussed before. They are, =20 1) Silicon issue or chip limit; 2) Network efficiency; 3) Encapsulation mode, tag or raw; 4) H-VPLS; 5) Backwards compatibility, especially legacy PE or Non-supporting PE with IEEE E-tree support joins E-Tree domain; 6) Configuration change in operation, for example, Leaf-only -> Root-Leaf-Mixed; 7) S-VLAN preservation support; 8) Multi-segment PW; 9) VLAN ID allocation (Only for Dual-VLAN); 10) Multi-AS deployment; 11) ECMP; 12) P2MP-PW; 13) Ethernet OAM; =20 If we review the mail-list, CW approach has the following limits: 1) Chip limit. Please read reply from Giles and Wim; 2) Network efficiency: There are garbage fames which will be dropped on egress PE since only egress PE can decide forward or drop frames while i= t receives frames. Ingress PE can not decide forward or not. Yes, current solution can support Hub-Spoke configuration, but as we know, the configuration is not easy if the network is big. Dual-VLAN or Multi-PW approach can break communication between Leaf-Only PEs via signaling. 3) Backwards compatibility: Not all PEs supports control word. If one can not support control word, it will not join E-Tree domain; =20 Dual VLAN has following limits: 1) Chip limit: As we know, we need to push one VLAN into frames befor= e MPLS encapsulation on ingress PE and stripe it out on egress PE. This is non-standard operation. Wait for confirmation from chip vendor; [JY] Do you really consider tagged PW as non-standard? 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, but can NOT configure it at all in Spoke PW case; [JY] In the first place, why PE-rs need to figure out the AC type for a spo= ke? The VLAN should be processed in the MTU, not in the PE-rs. 3) Multi-PW: Rafi figures this out, but we don?t think this over at that time. I think that it also has same problem as H-VPLS has. [JY] The same as above, only T-PE will deal with VLAN, S-PE only switches P= W label, so I can't see what is the problem.=20 4) Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN ID; [JY] Is anything not working with tagged PW mode? 5) Backward Compatibility: Just as Daniel mentioned, there is compatibility issue if legacy PE joins E-Tree domain. For me, I don?t get clear response from co-authors of Dual-VLAN. [JY] Could you elaborate a little more what is the compatibility issue?=20 =20 For all approaches, we don?t cover ECMP / Ethernet OAM till now.=20 =20 Is there anything missed?=20 =20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 _____ =20 From: Lizhong Jin [mailto:lizho.jin@gmail.com]=20 Sent: Saturday, April 21, 2012 11:59 AM To: Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? =20 Hi Win, Thank you for the answers. In that case, PE-rs should configure the root/leaf properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, you could not figure out the accessing spoke PW is from PE-r of VPWS or MTU-s. Unless having some additional indication in NMS, you even don't know which spoke PW needs to do VLAN manipulation. I am not sure such R/L configuration could be accepted from operational view. Hope to see more comments. Regards Lizhong ? 2012?4?21?????Henderickx, Wim (Wim) ??? > The VPWS which terminates at the H-VPLS node is indicated to be root or leaf and the procedures associated will do the VLAN manipulation > > =20 > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin > Sent: vrijdag 20 april 2012 18:38 > To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com > Cc: yuqun.cao@gmail.com > Subject: RE: The status of the approaches to the E-Tree solution? > > =20 > > Hi, all, > The difference between 2-VLAN and CW approach is who will provide the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW will carry R/L information for CW approach. > I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information? > > Thanks > Lizhong > >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 Apr 2012 04:38:36 +0000 >> From: Alexander Vainshtein >> To: "Rogers, Josh" , Lucy yong >> , Daniel Cohn , Sam Cao >> >> Cc: "l2vpn@ietf.org" >> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID: >> >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi all, >> I fully understand that that what I am going to say is not very popular, but: >> >> IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BU= N traffic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, and= , in a more generic way, localization of effects of changes in the PE configuration. >> >> In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root AC from a PE that previously has been supporting a mix etc. affect only the PE where this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a more >> complex model. Wether outside s-tag is used to differentiate, or >> dedicated pw's are used for the same purpose, it seems both become more >> complex. >> >> Gile's comparison slide still concisely captures the differences between >> these methods, in my opinion. I haven't seen any new ideas or thoughts >> brought to the group in the past week or two on the subject. I would hate >> for both proposed methods to die on the vine because we couldn't decide >> between two methods that have nothing inherently wrong with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" wrote: >> >>>Send this again. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>P2P PW fo=20 -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 48 ************************************* From jiangyuanlong@huawei.com Sun Apr 22 02:50:35 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C7121F85CE for ; Sun, 22 Apr 2012 02:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, J_CHICKENPOX_31=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 c6Vr4VypQTRl for ; Sun, 22 Apr 2012 02:50:33 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A699221F860E for ; Sun, 22 Apr 2012 02:50:30 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFC74459; Sun, 22 Apr 2012 05:50:30 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 22 Apr 2012 02:50:29 -0700 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 22 Apr 2012 02:50:29 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.137]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Sun, 22 Apr 2012 17:50:26 +0800 From: Jiangyuanlong To: "Rogers, Josh" Subject: Re: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNIG1YAoueT+sDq0uK84SGF/aOXQ== Date: Sun, 22 Apr 2012 09:50:26 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E7ED@SZXEML508-MBS.china.huawei.com> References: 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.70.40.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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: Sun, 22 Apr 2012 09:50:35 -0000 Hi Josh, Wish the last email on "SVLAN in the 2VLAN E-Tree solution" covered this is= sue. BTW, a 2VLAN encapsulated frame is not in the format as described. A single= S-tag is usually enough. Thanks Yuanlong ---------------------------------------------------------------------- Message: 1 Date: Sat, 21 Apr 2012 11:02:51 -0400 From: "Rogers, Josh" To: Sam Cao , 'Lizhong Jin' , "'Henderickx, Wim (Wim)'" Cc: "l2vpn@ietf.org" Subject: Re: The status of the approaches to the E-Tree solution? Message-ID: Content-Type: text/plain; charset=3D"utf-8" Sam? Where is the list for multi-PW method? One item I don't think is covered in your 2VLAN list, is where service mult= iplexed UNI's are involved, or any time there is a layer 2 CPE between PE a= nd CE, these devices usually expect a single, bidirectional s-tag, and acco= rding to your explanation this morning, coordinating the S-Tags used for ET= REE with the customer SHOULD NOT to be done, therefor there must be an 'inn= er S-Tag' on the AC, and an 'outer S-Tag' in the PW. While inside the PW, a 2VLAN method frame would look like: +-----------+-----------+----------+-------+-----------------+ |MPLS Label | R/L S-Tag | AC S-Tag | C-tag | Layer 2 Payload | +-----------+-----------+----------+-------+-----------------+ Correct? Would you consider this an 'issue' or just a 'complication' ? A lot of the 'pro 2VLAN' argument has been centered around existing IEEE st= andard, and at first it sounded like this was better/proposed for the abili= ty to extend the R/L S-tag beyond the PW, but it sounds like that isn't rea= lly an option, so I'm not sure that is a valid benefit/driver. Thanks much, Josh From: Sam Cao > To: 'Lizhong Jin' >, "'Hend= erickx, Wim (Wim)'" > Cc: "l2vpn@ietf.org" > Subject: RE: The status of the approaches to the E-Tree solution? Hi all, We reach an impasse?. BTW, Meeting minutes is ready now. We can get E-tree= summary from IETF site. Today I collected all items we discussed before. They are, 1) Silicon issue or chip limit; 2) Network efficiency; 3) Encapsulation mode, tag or raw; 4) H-VPLS; 5) Backwards compatibility, especially legacy PE or Non-supporting PE= with IEEE E-tree support joins E-Tree domain; 6) Configuration change in operation, for example, Leaf-only -> Root-= Leaf-Mixed; 7) S-VLAN preservation support; 8) Multi-segment PW; 9) VLAN ID allocation (Only for Dual-VLAN); 10) Multi-AS deployment; 11) ECMP; 12) P2MP-PW; 13) Ethernet OAM; If we review the mail-list, CW approach has the following limits: 1) Chip limit. Please read reply from Giles and Wim; 2) Network efficiency: There are garbage fames which will be dropped = on egress PE since only egress PE can decide forward or drop frames while i= t receives frames. Ingress PE can not decide forward or not. Yes, current s= olution can support Hub-Spoke configuration, but as we know, the configurat= ion is not easy if the network is big. Dual-VLAN or Multi-PW approach can b= reak communication between Leaf-Only PEs via signaling. 3) Backwards compatibility: Not all PEs supports control word. If one= can not support control word, it will not join E-Tree domain; Dual VLAN has following limits: 1) Chip limit: As we know, we need to push one VLAN into frames befor= e MPLS encapsulation on ingress PE and stripe it out on egress PE. This is = non-standard operation. Wait for confirmation from chip vendor; 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE= -rs works in different manner, PE-rs should figure out AC type in VPWS case= , but can NOT configure it at all in Spoke PW case; 3) Multi-PW: Rafi figures this out, but we don?t think this over at t= hat time. I think that it also has same problem as H-VPLS has. 4) Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs shou= ld work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN ID; 5) Backward Compatibility: Just as Daniel mentioned, there is compati= bility issue if legacy PE joins E-Tree domain. For me, I don?t get clear re= sponse from co-authors of Dual-VLAN. For all approaches, we don?t cover ECMP / Ethernet OAM till now. Is there anything missed? Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com ________________________________ From: Lizhong Jin [mailto:lizho.jin@gmail.com] Sent: Saturday, April 21, 2012 11:59 AM To: Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com= ; yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi Win, Thank you for the answers. In that case, PE-rs should configure the root/le= af properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, = you could not figure out the accessing spoke PW is from PE-r of VPWS or MTU= -s. Unless having some additional indication in NMS, you even don't know wh= ich spoke PW needs to do VLAN manipulation. I am not sure such R/L configur= ation could be accepted from operational view. Hope to see more comments. Regards Lizhong ? 2012?4?21?????Henderickx, Wim (Wim) > ??? > The VPWS which terminates at the H-VPLS node is indicated to be root or l= eaf and the procedures associated will do the VLAN manipulation > > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn= -bounces@ietf.org] On Behalf Of Lizhong Jin > Sent: vrijdag 20 april 2012 18:38 > To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.c= om > Cc: yuqun.cao@gmail.com > Subject: RE: The status of the approaches to the E-Tree solution? > > > > Hi, all, > The difference between 2-VLAN and CW approach is who will provide the R/L= information, customer payload or PW? The customer payload will be always m= odified to carry R/L information in 2-VLAN approach, while PW with CW will = carry R/L information for CW approach. > I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is acce= ssed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acc= ess H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informa= tion? > > Thanks > Lizhong > >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 Apr 2012 04:38:36 +0000 >> From: Alexander Vainshtein > >> To: "Rogers, Josh" >, Lucy yong >> >, Daniel Cohn = >, Sam Cao >> > >> Cc: "l2vpn@ietf.org" > >> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID: >> > >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi all, >> I fully understand that that what I am going to say is not very popular,= but: >> >> IMO one of the advantages of the CW-based solution is that it is orthogo= nal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traff= ic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, and= , in a more generic way, localization of effects of changes in the PE confi= guration. >> >> In particular, adding a Leaf AC to a PE that previously has been only su= pporting Root ACs (or vice versa), removal of the last Leaf or last Root AC= from a PE that previously has been supporting a mix etc. affect only the P= E where this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main disadv= antage of the CW-based approach - I believe it strongly depends on specific= implementations. And some changes in the forwarding process are required i= n any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounc= es@ietf.org] on behalf of Rogers, Josh [josh= .rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a more >> complex model. Wether outside s-tag is used to differentiate, or >> dedicated pw's are used for the same purpose, it seems both become more >> complex. >> >> Gile's comparison slide still concisely captures the differences between >> these methods, in my opinion. I haven't seen any new ideas or thoughts >> brought to the group in the past week or two on the subject. I would ha= te >> for both proposed methods to die on the vine because we couldn't decide >> between two methods that have nothing inherently wrong with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" > wrote: >> >>>Send this again. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>P2P PW fo ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 49 ************************************* From yuqun.cao@gmail.com Sun Apr 22 05:22:36 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4642821F859F for ; Sun, 22 Apr 2012 05:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.043 X-Spam-Level: X-Spam-Status: No, score=-3.043 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdXNqHEYSUBd for ; Sun, 22 Apr 2012 05:22:23 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7691521F856D for ; Sun, 22 Apr 2012 05:22:23 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so2815720pbb.31 for ; Sun, 22 Apr 2012 05:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :in-reply-to:x-mimeole; bh=NLbrooU6vpqKKx4HTH7qnsY5WC50zfGXgWdllN3QtAk=; b=bfrcxzFpEGYkD6/MysKUJcKrXJK/x9m2HMKdiBkTroW/9LLNbFnMIUGGL3q65U9fn1 KsbfDNoWQlJk/YbyqjET0/TPk+23Jf6K6SMRRv3YuHsx4RdtUoK9AMMf4SgFmVnYlM/+ CtsG1hXwwnVhXgrPkzM4AEFbvsLxVQ4JmrzMDoGoZtyaNSwp7da22UexUoRAVl/mknF7 4rkd6ONAVQWA1tVvoplkq9bN/DWMOc9N1b+LXUgNwDLImVdkdOqD9GNe39Ff9cTeVZqE aWigO3HMc8jIybqiQ0Fz0uu06NNLpmcM8Pd1uoTyCVsAvE92hAUVz9iUUajgBYqD5ieW YT7A== Received: by 10.68.240.135 with SMTP id wa7mr28132210pbc.7.1335097342575; Sun, 22 Apr 2012 05:22:22 -0700 (PDT) Received: from v2comsam ([36.248.16.95]) by mx.google.com with ESMTPS id ry4sm9689569pbc.27.2012.04.22.05.22.15 (version=SSLv3 cipher=OTHER); Sun, 22 Apr 2012 05:22:20 -0700 (PDT) From: "Sam Cao" To: "'Alexander Vainshtein'" References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, , <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <8BD23518D42D4E0CB8E67B5CF7CD3EA8@v2comsam> Subject: RE: The status of the approaches to the E-Tree solution? Date: Sun, 22 Apr 2012 20:22:19 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdiov//4SRIP//A88g//rZ1YD/9I0KwP/oyfwg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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: Sun, 22 Apr 2012 12:22:37 -0000 Hi Sasha, Thank you very much for your comments. I gave my answers to your questions below. [Sasha] 1. I do not understand how 4761 (that does not use PWs in the strict sense of the term) is applicable to the dual PW solution. Could you please elaborate? Can MP-BGP distribute two labels simultaneously? [Sam] I know what you mean, but there are 2 VPLS BGP NLRIs, one is for Root and another is for Leaf. So we really distribute 2 labels (different label blocks) simultaneously if need. [Sasha] 2. The solution based on 6074 can work with the dual-PW mechanism, but it requires some extension (the PE type must be communicated) [Sam] I agree. Multi-PW approach has extended it. Please refer to Multi-PW draft. [Sasha] 3. In the past, at the early stages of VPLS standardization, the rationale for accepting two standard solutions for VPLS (4761 and 4762) has been the need to support VPLS over BGP-free domains. This is why I would prefer an E-Tree solution that would not strongly depend on BGP-AD to take care of changes that are local to a single PE. (You may call that a personal bias:-). [Sam] Maybe E-Tree approach should support RFC 4761, RFC 6074 and RFC 4762. You can find that Multi-PW approach supports E-tree deployment over BGP-free domain, but it also supports E-Tree deployment over BGP domain. Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Sunday, April 22, 2012 3:27 PM To: Sam Cao Cc: l2vpn@ietf.org; 'Daniel Cohn'; 'Henderickx, Wim (Wim)'; 'Rogers, Josh'; 'Lucy yong' Subject: RE: The status of the approaches to the E-Tree solution? Sam, Lots of thanks for a prompt response. I will try to provide additional input for the issues list directly to you. I think that providing a mutually agreed upon list of issues would be an important step forward: we may not be able to answer some questions we ask, but the chance that the questions that have not be asked would somehow be answered is IMHO negligible:-). As for using BGP-AD with the dual-PW approach, there are three points IMO: 1. I do not understand how 4761 (that does not use PWs in the strict sense of the term) is applicable to the dual PW solution. Could you please elaborate? Can MP-BGP distribute two labels simultaneously? 2. The solution based on 6074 can work with the dual-PW mechanism, but it requires some extension (the PE type must be communicated) 3. In the past, at the early stages of VPLS standardization, the rationale for accepting two standard solutions for VPLS (4761 and 4762) has been the need to support VPLS over BGP-free domains. This is why I would prefer an E-Tree solution that would not strongly depend on BGP-AD to take care of changes that are local to a single PE. (You may call that a personal bias:-). Regards, Sasha > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Saturday, April 21, 2012 4:42 PM > To: Alexander Vainshtein > Cc: l2vpn@ietf.org; 'Daniel Cohn'; 'Henderickx, Wim (Wim)'; 'Rogers, Josh'; > 'Lucy yong' > Subject: RE: The status of the approaches to the E-Tree solution? > > Sasha, > > Thank you for your comments. > > Multi-PW can support BGP-AD, RFC 4761 or RFC 6074. BTW, can we work > together > on issues list? I will list some cases we discussed before. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Thursday, April 19, 2012 9:19 PM > To: Sam Cao > Cc: l2vpn@ietf.org; 'Daniel Cohn'; 'Henderickx, Wim (Wim)'; 'Rogers, Josh'; > 'Lucy yong' > Subject: RE: The status of the approaches to the E-Tree solution? > > Sam (hope this is the appropriate form of address and my apologies if not), > > I am actually trying to build a list of operational (not > implementation-driven) issues that must be addressed by a reasonable E- > tree > solution. > Then we could compare multiple approaches. > > As for setting up/tearing PWs with multiple peers just because your local > configuration has changed, I am not sure this is reasonable from the > operational point of view. > > E.g., consider the case of a Leaf-only PE migrating to a Mixed PE. > To the best of my understanding, PWs between Leaf-only PWs are not ever > set, > so our original Leaf PE could be unaware about existence of other Leaf-only > PEs (or, even worse, its list of Leaf-only peers could be not matching the > current situation) - and this would not affect traffic in any way. > Once it suddenly becomes a Mix PE, it must set up PWs with all the Leaf- > only > PEs have been ignored before, and they must agree to this... > > IMHO and FWIW, unless you use a very elaborate auto-discovery > mechanism, > this process has all the potential to become an operational nightmare. > > My 2c, > Sasha > > > > -----Original Message----- > > From: Sam Cao [mailto:yuqun.cao@gmail.com] > > Sent: Thursday, April 19, 2012 3:50 PM > > To: Alexander Vainshtein; 'Henderickx, Wim (Wim)'; 'Rogers, Josh'; 'Lucy > > yong'; 'Daniel Cohn' > > Cc: l2vpn@ietf.org > > Subject: RE: The status of the approaches to the E-Tree solution? > > > > Sasha, > > > > We have discussed this case before. While configuration is changed in fly, > > it is reasonable to establish or teardown PW. > > > > Regards, > > > > Yuqun (Sam) Cao > > E-mail: Yuqun.cao@gmail.com > > > > > > -----Original Message----- > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > Sent: Thursday, April 19, 2012 1:31 PM > > To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam > Cao > > Cc: l2vpn@ietf.org > > Subject: RE: The status of the approaches to the E-Tree solution? > > > > Wim, > > Lots of thanks for a prompt response. > > > > I think that operational aspects of the VLAN approach (e.g., how is the > > Global VID selected and distributed) should be examined in more detail. > > > > At the same time it seems that the double PW approach carries with it too > > many operational problems. > > E.g., no PWs are set up between Leaf-only PEs, but once one of these > > becomes > > a Mix PE, all the Leaf-only PEs must now recognize it as a valid peer. And > > if a Mix PE reverts to a Leaf only one, all its Leaf-only peers must drop > it > > and shut down the relevant PWs... > > > > My 2c, > > Sasha > > > > ________________________________________ > > From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] > > Sent: Thursday, April 19, 2012 7:21 AM > > To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao > > Cc: l2vpn@ietf.org > > Subject: RE: The status of the approaches to the E-Tree solution? > > > > Sasha, the VLAN approach allows for a similar operation as the CW does. It > > is orthogonal to the underlying PW deployment of VPLS. > > > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > > Of > > Alexander Vainshtein > > Sent: donderdag 19 april 2012 6:39 > > To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao > > Cc: l2vpn@ietf.org > > Subject: RE: The status of the approaches to the E-Tree solution? > > > > Hi all, > > I fully understand that that what I am going to say is not very popular, > > but: > > > > IMO one of the advantages of the CW-based solution is that it is > orthogonal > > to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. > > > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, > in > > a more generic way, localization of effects of changes in the PE > > configuration. > > > > In particular, adding a Leaf AC to a PE that previously has been only > > supporting Root ACs (or vice versa), removal of the last Leaf or last Root > > AC from a PE that previously has been supporting a mix etc. affect only > the > > PE where this operation happens and not the rest of the PEs. > > > > As for the need for HW changes that have been mentioned as a main > > disadvantage of the CW-based approach - I believe it strongly depends on > > specific implementations. And some changes in the forwarding process > are > > required in any solution. > > > > My 2c, > > Sasha > > > > > > > > ________________________________________ > > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of > > Rogers, > > Josh [josh.rogers@twcable.com] > > Sent: Wednesday, April 18, 2012 9:57 PM > > To: Lucy yong; Daniel Cohn; Sam Cao > > Cc: l2vpn@ietf.org > > Subject: Re: The status of the approaches to the E-Tree solution? > > > > Again, the P2MP situation throws me. Is this something that is used > > commonly? > > > > I'm under the impression that adding P2MP to any model results in a more > > complex model. Wether outside s-tag is used to differentiate, or > > dedicated pw's are used for the same purpose, it seems both become > more > > complex. > > > > Gile's comparison slide still concisely captures the differences between > > these methods, in my opinion. I haven't seen any new ideas or thoughts > > brought to the group in the past week or two on the subject. I would hate > > for both proposed methods to die on the vine because we couldn't decide > > between two methods that have nothing inherently wrong with either. > > > > -Josh > > > > > > On 4/18/12 1:53 PM, "Lucy yong" wrote: > > > > >Send this again. > > > > > >Two PW approach can be complex too if the VPLS instance for E-Tree uses > > >P2P PW for unicast traffic and P2MP PW for broadcast and unknown > > >unicast traffic, and some P2MP PWs for multicast traffic. It may double > > >all of them. > > > > > >Lucy > > > > > >-----Original Message----- > > >From: Daniel Cohn [mailto:DanielC@orckit.com] > > >Sent: Wednesday, April 18, 2012 1:42 PM > > >To: Lucy yong; Rogers, Josh; Sam Cao > > >Cc: l2vpn@ietf.org > > >Subject: RE: The status of the approaches to the E-Tree solution? > > > > > >I think the first option its the natural way to go. How is the processing > > >in this case more complex? > > > > > >Thumb typed - please be tolerant > > > > > >Lucy yong wrote: > > > > > > > > > > > >Snipped.. > > > > > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP > PW > > >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for > > >traffic coming from a root AC) > > >[[LY]] Not that simple. You construct either two P2MP PWs to all other > > >PEs and let egress PE performing filtering, or construct one P2MP PW to > > >leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE > > >perform forwarding and filtering. Both make node process complex. > > > > > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for > > >delivering the frames to remote PEs. We should utilize them with the > > >minimized changes. Dual VLAN solution is simpler than Dual PW. > > > > > >Regards, > > >Lucy > > > > > > > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I > > >haven't had any first hand experience with P2MP PW's, however, so don't > > >feel terribly strong about this objection. Is this a real problem for > > >others (now or in the future), or is this objection in the weeds? > > > > > >I'm not sure the 'additional complexity' is notable, or even relevant. I > > >encourage others to speak up if they disagree, as P2MP PW is only > > >conceptual to me, and I am unfamiliar with real-life use cases for it. > > > > > >Thanks, > > >Josh > > > > > > > > > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > > > > > >>Please see inline. > > >> > > >>-----Original Message----- > > >>From: Sam Cao [mailto:yuqun.cao@gmail.com] > > >>Sent: Tuesday, April 17, 2012 7:14 AM > > >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; > > >>giles.heron@gmail.com; simon.delord@gmail.com; > > >>Alexander.Vainshtein@ecitele.com > > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > > >>Subject: RE: The status of the approaches to the E-Tree solution? > > >> > > >>Yes, 2 pws are only needed between pes with both root and leaf acs > after > > >>improving Dual-PW approach. If consider P2MP, Dual-PW approach > setup > > 2 > > >>P2MP > > >>PWs if need. There is no difference between P2MP or normal PW setup. > > But, > > >>can Leaf-ACs be bound to Root PE of P2MP PW? > > >> > > >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with > both > > >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE > have > > >>both root and leaf AC and some only have leaf ACs)? > > >>Regards, > > >>Lucy > > >> > > >>Regards, > > >> > > >>Yuqun (Sam) Cao > > >>E-mail: Yuqun.cao@gmail.com > > >> > > >> > > >>-----Original Message----- > > >>From: Daniel Cohn [mailto:DanielC@orckit.com] > > >>Sent: Tuesday, April 17, 2012 4:56 PM > > >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); > > >>giles.heron@gmail.com; > > >>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam > Cao > > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > > >>Subject: RE: The status of the approaches to the E-Tree solution? > > >> > > >>Adding Sam (as l2vpn@ is holding messages) > > >> > > >>DC > > >> > > >>-----Original Message----- > > >>From: Lucy yong [mailto:lucy.yong@huawei.com] > > >>Sent: Tuesday, April 17, 2012 12:39 AM > > >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); > > >>giles.heron@gmail.com; simon.delord@gmail.com; > > >>Alexander.Vainshtein@ecitele.com > > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > > >>Subject: RE: The status of the approaches to the E-Tree solution? > > >> > > >> > > >>Snipped, > > >> > > >>As we discussed extensively in the list, and as reflected in giles > > >>slide, 2 pws are only needed between pes with both root and leaf acs, > > >>which will typically be a small minority. > > >>[[LY]] Don't know if the assumption is true. Even it is the case, both > > >>approaches can benefit from it. I was off for a while and captures some > > >>discussions now. > > >> > > >>Also as per giles slide, dual vlan can have scalability issues due to > > >>additional lookup and double use of vlans in internal emulated lan > > >>interface. Also there are potential backward compatibility issues with > > >>silicon that doesn't support vlan mapping. > > >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am > > >>not clear on all the issues. Could you be more specific? As I mentioned > > >>in below, two PW approach makes VPLS transport construction and > packet > > >>forwarding more complex, I can see potential backward compatibility > > >>issues with 2 PW solution. > > >> > > >>Regards, > > >>Lucy > > >> > > >>Regards, > > >> > > >>Daniel > > >> > > >>Thumb typed - please be tolerant > > >> > > >>Lucy yong wrote: > > >> > > >>In my mind, the VLAN approach means dual vlan method. > > >> > > >>The main concern for CW approach is hardware support. > > >> > > >>Two PW approach can be complex too if the VPLS instance for E-Tree > uses > > >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown > > unicast > > >>traffic, and some P2MP PWs for multicast traffic. It may double all of > > >>them. > > >> > > >>E-tree is an Ethernet service and there is already VLAN based solution > > >>in IEEE, can we just utilize it without complicating VPLS transport > > >>construction? This also makes interworking with Eth only network > easier. > > >> > > >>Cheers, > > >>Lucy > > >> > > >>-----Original Message----- > > >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] > > >>Sent: Monday, April 16, 2012 8:35 AM > > >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; > > >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' > > >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; > > >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; > > >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' > > >>Subject: RE: The status of the approaches to the E-Tree solution? > > >> > > >>I believe the initial question was in regard to the CW method. Are you > > >>saying that you no longer are interested in that method in preference of > > >>the dual vlan method? > > >> > > >> > > >> > > >>Lucy yong wrote: > > >> > > >> > > >>Agree with Wim. VLAN approach is the best solution for E-Tree. > > >> > > >>Lucy > > >> > > >>-----Original Message----- > > >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > > Behalf > > >>Of Henderickx, Wim (Wim) > > >>Sent: Thursday, April 12, 2012 2:03 AM > > >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; > > >>'Alexander.Vainshtein@ecitele.com' > > >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; > > >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; > > >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' > > >>Subject: Re: The status of the approaches to the E-Tree solution? > > >> > > >>The vlan approach is superior as it also works for eth only networks, > > >>etc. On top some vendors indicate hw issues with the cw approach. As > > >>such we have dropped more or less the cw approach. > > >> > > >>Cheers, > > >>Wim > > >>_________________ > > >>sent from blackberry > > >> > > >>----- Original Message ----- > > >>From: Giles Heron [mailto:giles.heron@gmail.com] > > >>Sent: Thursday, April 12, 2012 08:22 AM > > >>To: Simon Delord ; Alexander Vainshtein > > >> > > >>Cc: l2vpn@ietf.org ; Vladimir Kleiner > > >>; Andrew Sergeev > > >>; Idan Kaspit > ; > > >>Mishael Wexler ; Rotem Cohen > > >> > > >>Subject: Re: The status of the approaches to the E-Tree solution? > > >> > > >>Sorry - the "anonymous presentation" was mine. I should possibly have > > >>put in a third column on the CW approach. And hopefully the minutes > > >>will be posted soon. > > >> > > >>We had various discussions, as Simon stated, and consensus seemed to > > be > > >>forming around the two alternatives of two PWEs or two VLANs. I > believe > > >>three of the authors of the CW approach are also authors of the two > VLAN > > >>approach and one is also an author of the two PWE approach. So perhaps > > >>it's best to let those four individuals say which approach they prefer > > >>and why? > > >> > > >>Giles > > >> > > >>On 10/04/2012 00:45, "Simon Delord" > wrote: > > >> > > >>> Hi Alexander, > > >>> > > >>> You are right, no discussion on the WG mailing list recently, but > > >>> there have been substantial discussions among the authors of various > > >>> solution drafts off the mailing list. As far as I know, no consensus > > >>> yet before ietf83, not sure the progress in the Paris WG meeting. I > > >>> think the CW approach has not been rejected by the WG yet, or the > WG > > >>> has not yet decided on which one to adopt. > > >>> > > >>> Simon > > >>> > > >>> 2012/4/8 Alexander Vainshtein > > >>> > > >>>> Hi all, > > >>>> > > >>>> Unfortunately I have not been able to attend the Paris IETF. > > >>>> > > >>>> However, looking up the L2VPN proceedings, I've found a short > > >>>> anonymous presentation called "E-Tree Update" ( > > >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). > > >>>> This presentation discusses the differences of the E-Tree approaches > > >>>> based on dedicated VLANs (as in > > >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls- > etree/?include_t > > >>>> ext=1) and multiple PWs between the PEs (as in > > >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple- > > pw/?in > > >>>> clude_te > > >>>> xt=1) > > >>>> and completely ignores the solution based on usage of the CW in the > > >>>> PWs connecting the PEs (as in > > >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls- > etree/?include_t > > >>>> ext=1 > > >>>> ). > > >>>> > > >>>> > > >>>> > > >>>> The Minutes of the Paris L2VPN session are not yet available, but I > > >>>> wonder whether the WG has taken a decision to reject the approach > > >>>> based on the CW usage? I do not remember any recent discussion of > > >>>> this topic on the WG mailing list. > > >>>> > > >>>> > > >>>> > > >>>> Regards, and lots of thanks in advance, > > >>>> > > >>>> Sasha > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> This e-mail message is intended for the recipient only and contains > > >>>> information which is CONFIDENTIAL and which may be proprietary to > > ECI > > >> > > >>>> Telecom. If you have received this transmission in error, please > > >>>> inform us by e-mail, phone or fax, and then delete the original and > > >>>> all copies thereof. > > >>>> > > >> > > >> > > >> > > >> > > >> > > >>This E-mail and any of its attachments may contain Time Warner Cable > > >>proprietary information, which is privileged, confidential, or subject > > >>to copyright belonging to Time Warner Cable. This E-mail is intended > > >>solely for the use of the individual or entity to which it is addressed. > > >>If you are not the intended recipient of this E-mail, you are hereby > > >>notified that any dissemination, distribution, copying, or action taken > > >>in relation to the contents of and attachments to this E-mail is > > >>strictly prohibited and may be unlawful. If you have received this > > >>E-mail in error, please notify the sender immediately and permanently > > >>delete the original and any copy of this E-mail and any printout. > > >> > > > > > > > > >This E-mail and any of its attachments may contain Time Warner Cable > > >proprietary information, which is privileged, confidential, or subject to > > >copyright belonging to Time Warner Cable. This E-mail is intended solely > > >for the use of the individual or entity to which it is addressed. If you > > >are not the intended recipient of this E-mail, you are hereby notified > > >that any dissemination, distribution, copying, or action taken in > > >relation to the contents of and attachments to this E-mail is strictly > > >prohibited and may be unlawful. If you have received this E-mail in > > >error, please notify the sender immediately and permanently delete the > > >original and any copy of this E-mail and any printout. > > > > > > This E-mail and any of its attachments may contain Time Warner Cable > > proprietary information, which is privileged, confidential, or subject to > > copyright belonging to Time Warner Cable. This E-mail is intended solely > for > > the use of the individual or entity to which it is addressed. If you are > not > > the intended recipient of this E-mail, you are hereby notified that any > > dissemination, distribution, copying, or action taken in relation to the > > contents of and attachments to this E-mail is strictly prohibited and may > be > > unlawful. If you have received this E-mail in error, please notify the > > sender immediately and permanently delete the original and any copy of > > this > > E-mail and any printout. > > This e-mail message is intended for the recipient only and contains > > information which is CONFIDENTIAL and which may be proprietary to ECI > > Telecom. If you have received this transmission in error, please inform us > > by e-mail, phone or fax, and then delete the original and all copies > > thereof. > > This e-mail message is intended for the recipient only and contains > > information which is CONFIDENTIAL and which may be proprietary to ECI > > Telecom. If you have received this transmission in error, please inform us > > by e-mail, phone or fax, and then delete the original and all copies > > thereof. > > > > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us > by e-mail, phone or fax, and then delete the original and all copies > thereof. > This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. From DanielC@orckit.com Sun Apr 22 05:34:30 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D618521F85CF for ; Sun, 22 Apr 2012 05:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=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 u+LTe0pcq05n for ; Sun, 22 Apr 2012 05:34:03 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id AB68A21F85BB for ; Sun, 22 Apr 2012 05:34:02 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD2084.7FCFE129" Subject: RE: The status of the approaches to the E-Tree solution? Date: Sun, 22 Apr 2012 15:33:57 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130777C3C1@tlvmail1> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNW6V0LmvcLTaO7yAMdZqeRCQBXtrWA References: <4A6CE49E6084B141B15C0713B8993F28021737@SJEXCHMB12.corp.ad.broadcom.com> From: "Daniel Cohn" To: "Rogers, Josh" , "Shahram Davari" , "Lizhong Jin" , , Cc: yuqun.cao@gmail.com X-BeenThere: l2vpn@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: Sun, 22 Apr 2012 12:34:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2084.7FCFE129 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Shahram and all, =20 This question already came up in our discussions - is it safe to assume that the VLAN tags at the E-NNI will always be according to the current MEF model? Or should we try to be as transparent as possible to user VLAN encapsulation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case VLAN tag) to signal VPLS information (in this case root/leaf origin) is necessarily tied to specific assumptions on user payload encapsulation (in this case, that S-VLAN tag is "available" to encode root/leaf). I don't think this is a future-proof assumption, it's very likely that other network models will come up that require S-VLAN preservation, which in the 2-VLAN approach would necessitate adding a third VLAN-ID. =20 Daniel =20 From: Shahram Davari To: Lizhong Jin , "l2vpn@ietf.org" , "Alexander.Vainshtein@ecitele.com" Cc: "yuqun.cao@gmail.com" Subject: RE: The status of the approaches to the E-Tree solution? =20 Hi, =20 I also have a question regarding 2-VLAN. What if the customer traffic already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? =20 Thx Shahram =20 From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? =20 Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW will carry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > To: "Rogers, Josh" , Lucy yong > , Daniel Cohn , Sam Cao > > Cc: "l2vpn@ietf.org" > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, but: > > IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes in the PE configuration. > > In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root AC from a PE that previously has been supporting a mix etc. affect only the PE where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a more > complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become more > complex. > > Gile's comparison slide still concisely captures the differences between > these methods, in my opinion. I haven't seen any new ideas or thoughts > brought to the group in the past week or two on the subject. I would hate > for both proposed methods to die on the vine because we couldn't decide > between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may double >>all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the processing >>in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >>traffic coming from a root AC) >>[[LY]] Not that simple. You construct either two P2MP PWs to all other >>PEs and let egress PE performing filtering, or construct one P2MP PW to >>leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >>perform forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so don't >>feel terribly strong about this objection. Is this a real problem for >>others (now or in the future), or is this objection in the weeds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. I >>encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>>giles.heron@gmail.com; simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs after >>>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>>P2MP >>>PWs if need. There is no difference between P2MP or normal PW setup. But, >>>can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>>both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong [mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, both >>>approaches can benefit from it. I was off for a while and captures some >>>discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues with >>>silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>>not clear on all the issues. Could you be more specific? As I mentioned >>>in below, two PW approach makes VPLS transport construction and packet >>>forwarding more complex, I can see potential backward compatibility >>>issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>>traffic, and some P2MP PWs for multicast traffic. It may double all of >>>them. >>> >>>E-tree is an Ethernet service and there is already VLAN based solution >>>in IEEE, can we just utilize it without complicating VPLS transport >>>construction? This also makes interworking with Eth only network easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are you >>>saying that you no longer are interested in that method in preference of >>>the dual vlan method? >>> >>> >>> >>>Lucy yong wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron [mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord ; Alexander Vainshtein >>> >>>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>>; Andrew Sergeev >>>; Idan Kaspit ; >>>Mishael Wexler ; Rotem Cohen >>> >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly have >>>put in a third column on the CW approach. And hopefully the minutes >>>will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to be >>>forming around the two alternatives of two PWEs or two VLANs. I believe >>>three of the authors of the CW approach are also authors of the two VLAN >>>approach and one is also an author of the two PWE approach. So perhaps >>>it's best to let those four individuals say which approach they prefer >>>and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of various >>>> solution drafts off the mailing list. As far as I know, no consensus >>>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>>> think the CW approach has not been rejected by the WG yet, or the WG >>>> has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree approaches >>>>> based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in the >>>>> PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>>> wonder whether the WG has taken a decision to reject the approach >>>>> based on the CW usage? I do not remember any recent discussion of >>>>> this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and contains >>>>> information which is CONFIDENTIAL and which may be proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original and >>>>> all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action taken >>>in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use of the individual or entity to which it is addressed. If you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > ***********************************=20 ------_=_NextPart_001_01CD2084.7FCFE129 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Shahram and all,

 

This question already came up in our discussions - is it safe to = assume that the VLAN tags at the E-NNI will always be according to the = current MEF model? Or should we try to be as transparent as possible to = user VLAN encapsulation at the E-NNI, to accommodate future = frameworks?

I believe that any approach that looks at user payload (in this case = VLAN tag) to signal VPLS information (in this case root/leaf origin) is = necessarily tied to specific assumptions on user payload encapsulation = (in this case, that S-VLAN tag is “available” to encode = root/leaf). I don’t think this is a future-proof assumption, = it’s very likely that other network models will come up that = require S-VLAN preservation, which in the 2-VLAN approach would = necessitate adding a third VLAN-ID.

 

Daniel

 

From: Shahram Davari <davari@broadcom.com>
To:= Lizhong Jin <lizho.jin@gmail.com>, = "l2vpn@ietf.org" <l2vpn@ietf.org>, "Alexander.Vainshtein@eci= tele.com" <Alexander.Vainshtein@eci= tele.com>
Cc: "yuqun.cao@gmail.com" <yuqun.cao@gmail.com>
Sub= ject: RE: The status of the approaches to the E-Tree = solution?

 

Hi,

 

I also have a question regarding 2-VLAN. What if the customer traffic = already has an S-VLAN? Do we need a 3rd VLAN to identify the = L/R?

 

Thx

Shahram

 

= From:= l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org]= On Behalf Of Lizhong Jin
Sent: Friday, April 20, 2012 = 9:38 AM
To: l2vpn@ietf.org; Alexander.Vainshtein@eci= tele.com
Cc: yuqun.cao@gmail.com
Subject= : RE: The status of the approaches to the E-Tree = solution?

 

Hi, all,
The difference = between 2-VLAN and CW approach is who will provide the R/L information, = customer payload or PW? The customer payload will be always modified to = carry R/L information in 2-VLAN approach, while PW with CW will carry = R/L information for CW approach.
I have a question with the 2-VLAN = approach in H-VPLS where H-VPLS is accessed by VPWS as described in = RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the = PE on VPWS side adds VLAN to indicate R/L = information?

Thanks
Lizhong

> = ------------------------------
>
> Message: 2
> Date: = Thu, 19 Apr 2012 04:38:36 +0000
> From: Alexander Vainshtein = <Alexander.Vainshtein@eci= tele.com>
> To: "Rogers, Josh" <josh.rogers@twcable.com>, = Lucy yong
>        <lucy.yong@huawei.com>, = Daniel Cohn <DanielC@orckit.com>, Sam = Cao
>        <yuqun.cao@gmail.com>
> = Cc: "l2vpn@ietf.org" = <l2vpn@ietf.org>
> = Subject: RE: The status of the approaches to the E-Tree = solution?
> Message-ID:
>        <F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>
> Content-Type: text/plain; = charset=3D"us-ascii"
>
> Hi all,
> I fully = understand that that what I am going to say is not very popular, = but:
>
> IMO one of the advantages of the CW-based solution = is that it is orthogonal to usage (or non-usage) of P2MP PWs for = effective delivery of BUN traffic.
>
> Another advantage is = preservation of full mesh of P2P PWs in a VPLS, and, in a more generic = way, localization of effects of changes in the PE = configuration.
>
> In particular, adding a Leaf AC to a PE = that previously has been only supporting Root ACs (or vice versa), = removal of the last Leaf or last Root AC from a PE that previously has = been supporting a mix etc. affect only the PE where this operation = happens and not the rest of the PEs.
>
> As for the need for = HW changes that have been mentioned as a main disadvantage of the = CW-based approach - I believe it strongly depends on specific = implementations. And some changes in the forwarding process are required = in any solution.
>
> My 2c,
>     = Sasha
>
>
>
> = ________________________________________
> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on = behalf of Rogers, Josh [josh.rogers@twcable.com]
&= gt; Sent: Wednesday, April 18, 2012 9:57 PM
> To: Lucy yong; = Daniel Cohn; Sam Cao
> Cc: l2vpn@ietf.org
> Subject: Re: = The status of the approaches to the E-Tree solution?
>
> = Again, the P2MP situation throws me.  Is this something that is = used
> commonly?
>
> I'm under the impression that = adding P2MP to any model results in a more
> complex model. =  Wether outside s-tag is used to differentiate, or
> = dedicated pw's are used for the same purpose, it seems both become = more
> complex.
>
> Gile's comparison slide still = concisely captures the differences between
> these methods, in my = opinion.  I haven't seen any new ideas or thoughts
> brought = to the group in the past week or two on the subject.  I would = hate
> for both proposed methods to die on the vine because we = couldn't decide
> between two methods that have nothing inherently = wrong with either.
>
> -Josh
>
>
> On = 4/18/12 1:53 PM, "Lucy yong" <lucy.yong@huawei.com> = wrote:
>
>>Send this again.
>>
>>Two PW = approach can be complex too if the VPLS instance for E-Tree = uses
>>P2P PW for unicast traffic and P2MP PW for broadcast and = unknown
>>unicast traffic, and some P2MP PWs for multicast = traffic. It may double
>>all of = them.
>>
>>Lucy
>>
>>-----Original = Message-----
>>From: Daniel Cohn [mailto:DanielC@orckit.com]
>>Sen= t: Wednesday, April 18, 2012 1:42 PM
>>To: Lucy yong; Rogers, = Josh; Sam Cao
>>Cc: l2vpn@ietf.org
>>Subject: = RE: The status of the approaches to the E-Tree = solution?
>>
>>I think the first option its the = natural way to go. How is the processing
>>in this case more = complex?
>>
>>Thumb typed - please be = tolerant
>>
>>Lucy yong <lucy.yong@huawei.com> = wrote:
>>
>>
>>
>>Snipped..
>&g= t;
>>Multi-PW - On ingress PE, frame is placed onto either a = Leaf-only P2MP PW
>>(for traffic coming from a leaf AC), or = onto a Root/Leaf P2MP PW (for
>>traffic coming from a root = AC)
>>[[LY]] Not that simple. You construct either two P2MP PWs = to all other
>>PEs and let egress PE performing filtering, or = construct one P2MP PW to
>>leaf-only PEs and two P2MP PWs to = root and leaf PEs and let ingress PE
>>perform forwarding and = filtering. Both make node process complex.
>>
>>[[LY]] = VPLS is built with the mechanism utilizing P2P and P2MP PW = for
>>delivering the frames to remote PEs. We should utilize = them with the
>>minimized changes. Dual VLAN solution is = simpler than Dual = PW.
>>
>>Regards,
>>Lucy
>>
>&g= t;
>>I see how 2VLAN is simpler when P2MP PW's are involved, I = think.  I
>>haven't had any first hand experience with = P2MP PW's, however, so don't
>>feel terribly strong about this = objection.  Is this a real problem for
>>others (now or in = the future), or is this objection in the = weeds?
>>
>>I'm not sure the 'additional complexity' = is notable, or even relevant.  I
>>encourage others to = speak up if they disagree, as P2MP PW is only
>>conceptual to = me, and I am unfamiliar with real-life use cases for = it.
>>
>>Thanks,
>>Josh
>>
>>= ;
>>
>>On 4/18/12 10:30 AM, "Lucy yong" = <lucy.yong@huawei.com> = wrote:
>>
>>>Please see = inline.
>>>
>>>-----Original = Message-----
>>>From: Sam Cao [mailto:yuqun.cao@gmail.com]
>>&= gt;Sent: Tuesday, April 17, 2012 7:14 AM
>>>To: 'Daniel = Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim = (Wim)';
>>>giles.heron@gmail.com; simon.delord@gmail.com;
>= ;>>Alexander.Vainshtein@eci= tele.com
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com= ;
>>>Andrew.Sergeev@ecitele.com= ; Idan.Kaspit@ecitele.com;
&= gt;>>Mishael.Wexler@ecitele.com= ; Rotem.Cohen@ecitele.com
&g= t;>>Subject: RE: The status of the approaches to the E-Tree = solution?
>>>
>>>Yes, 2 pws are only needed = between pes with both root and leaf acs after
>>>improving = Dual-PW approach. If consider P2MP, Dual-PW approach setup = 2
>>>P2MP
>>>PWs if need. There is no difference = between P2MP or normal PW setup. But,
>>>can Leaf-ACs be = bound to Root PE of P2MP PW?
>>>
>>>[[LY]] No, = it makes complex in setting up P2MP PW. Should a PE with = both
>>>root and leaf ACs set up two or one P2MP PW to other = PEs (some PE have
>>>both root and leaf AC and some only = have leaf = ACs)?
>>>Regards,
>>>Lucy
>>>
>= >>Regards,
>>>
>>>Yuqun (Sam) = Cao
>>>E-mail: Yuqun.cao@gmail.com
>>&g= t;
>>>
>>>-----Original = Message-----
>>>From: Daniel Cohn [mailto:DanielC@orckit.com]
>>>= ;Sent: Tuesday, April 17, 2012 4:56 PM
>>>To: Lucy yong; = Rogers, Josh; Henderickx, Wim (Wim);
>>>giles.heron@gmail.com;
>&= gt;>simon.delord@gmail.com; Alexander.Vainshtein@eci= tele.com; Sam Cao
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com= ;
>>>Andrew.Sergeev@ecitele.com= ; Idan.Kaspit@ecitele.com;
&= gt;>>Mishael.Wexler@ecitele.com= ; Rotem.Cohen@ecitele.com
&g= t;>>Subject: RE: The status of the approaches to the E-Tree = solution?
>>>
>>>Adding Sam (as l2vpn@ is = holding = messages)
>>>
>>>DC
>>>
>>&g= t;-----Original Message-----
>>>From: Lucy yong [mailto:lucy.yong@huawei.com]
>>= ;>Sent: Tuesday, April 17, 2012 12:39 AM
>>>To: Daniel = Cohn; Rogers, Josh; Henderickx, Wim (Wim);
>>>giles.heron@gmail.com; simon.delord@gmail.com;
>= ;>>Alexander.Vainshtein@eci= tele.com
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com= ;
>>>Andrew.Sergeev@ecitele.com= ; Idan.Kaspit@ecitele.com;
&= gt;>>Mishael.Wexler@ecitele.com= ; Rotem.Cohen@ecitele.com
&g= t;>>Subject: RE: The status of the approaches to the E-Tree = solution?
>>>
>>>
>>>Snipped,
>= >>
>>>As we discussed extensively in the list, and as = reflected in giles
>>>slide, 2 pws are only needed between = pes with both root and leaf acs,
>>>which will typically be = a small minority.
>>>[[LY]] Don't know if the assumption is = true. Even it is the case, both
>>>approaches can benefit = from it. I was off for a while and captures = some
>>>discussions now.
>>>
>>>Also = as per giles slide, dual vlan can have scalability issues due = to
>>>additional lookup and double use of vlans in internal = emulated lan
>>>interface. Also there are potential backward = compatibility issues with
>>>silicon that doesn't support = vlan mapping.
>>>[[LY]] I was not in IETF83 meeting and wait = on the meeting minutes. I am
>>>not clear on all the issues. = Could you be more specific? As I mentioned
>>>in below, two = PW approach makes VPLS transport construction and = packet
>>>forwarding more complex, I can see potential = backward compatibility
>>>issues with 2 PW = solution.
>>>
>>>Regards,
>>>Lucy
= >>>
>>>Regards,
>>>
>>>Danie= l
>>>
>>>Thumb typed - please be = tolerant
>>>
>>>Lucy yong <lucy.yong@huawei.com> = wrote:
>>>
>>>In my mind, the VLAN approach = means dual vlan method.
>>>
>>>The main concern = for CW approach is hardware support.
>>>
>>>Two = PW approach can be complex too if the VPLS instance for E-Tree = uses
>>>P2P PW for unicast traffic and P2MP PW for broadcast = and unknown unicast
>>>traffic, and some P2MP PWs for = multicast traffic. It may double all = of
>>>them.
>>>
>>>E-tree is an = Ethernet service and there is already VLAN based = solution
>>>in IEEE, can we just utilize it without = complicating VPLS transport
>>>construction? This also makes = interworking with Eth only network = easier.
>>>
>>>Cheers,
>>>Lucy
>= ;>>
>>>-----Original Message-----
>>>From: = Rogers, Josh [mailto:josh.rogers@twcable.com]
&= gt;>>Sent: Monday, April 16, 2012 8:35 AM
>>>To: Lucy = yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com';
>= >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@eci= tele.com'
>>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com= ';
>>>'Andrew.Sergeev@ecitele.com= '; 'Idan.Kaspit@ecitele.com';
= >>>'Mishael.Wexler@ecitele.com= '; 'Rotem.Cohen@ecitele.com'
&= gt;>>Subject: RE: The status of the approaches to the E-Tree = solution?
>>>
>>>I believe the initial question = was in regard to the CW method.  Are you
>>>saying that = you no longer are interested in that method in preference = of
>>>the dual vlan = method?
>>>
>>>
>>>
>>>Lu= cy yong <lucy.yong@huawei.com> = wrote:
>>>
>>>
>>>Agree with Wim. = VLAN approach is the best solution for = E-Tree.
>>>
>>>Lucy
>>>
>>&g= t;-----Original Message-----
>>>From: l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org] On = Behalf
>>>Of Henderickx, Wim (Wim)
>>>Sent: = Thursday, April 12, 2012 2:03 AM
>>>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com';
&g= t;>>'Alexander.Vainshtein@eci= tele.com'
>>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com= ';
>>>'Andrew.Sergeev@ecitele.com= '; 'Idan.Kaspit@ecitele.com';
= >>>'Mishael.Wexler@ecitele.com= '; 'Rotem.Cohen@ecitele.com'
&= gt;>>Subject: Re: The status of the approaches to the E-Tree = solution?
>>>
>>>The vlan approach is superior = as it also works for eth only networks,
>>>etc. On top some = vendors indicate hw issues with the cw approach. As
>>>such = we have dropped more or less the cw = approach.
>>>
>>>Cheers,
>>>Wim
&g= t;>>_________________
>>>sent from = blackberry
>>>
>>>----- Original Message = -----
>>>From: Giles Heron [mailto:giles.heron@gmail.com]
>&= gt;>Sent: Thursday, April 12, 2012 08:22 AM
>>>To: Simon = Delord <simon.delord@gmail.com>; = Alexander Vainshtein
>>><Alexander.Vainshtein@eci= tele.com>
>>>Cc: l2vpn@ietf.org <l2vpn@ietf.org>; Vladimir = Kleiner
>>><Vladimir.Kleiner@ecitele.com= >; Andrew Sergeev
>>><Andrew.Sergeev@ecitele.com= >; Idan Kaspit <Idan.Kaspit@ecitele.com>;<= br>>>>Mishael Wexler <Mishael.Wexler@ecitele.com= >; Rotem Cohen
>>><Rotem.Cohen@ecitele.com>>>>Subject: Re: The status of the approaches to the E-Tree = solution?
>>>
>>>Sorry - the "anonymous = presentation" was mine.  I should possibly = have
>>>put in a third column on the CW approach.  And = hopefully the minutes
>>>will be posted = soon.
>>>
>>>We had various discussions, as = Simon stated, and consensus seemed to be
>>>forming around = the two alternatives of two PWEs or two VLANs.  I = believe
>>>three of the authors of the CW approach are also = authors of the two VLAN
>>>approach and one is also an = author of the two PWE approach. So perhaps
>>>it's best to = let those four individuals say which approach they = prefer
>>>and = why?
>>>
>>>Giles
>>>
>>>= On 10/04/2012 00:45, "Simon Delord" <simon.delord@gmail.com> = wrote:
>>>
>>>> Hi = Alexander,
>>>>
>>>> You are right, no = discussion on the WG mailing list recently, but
>>>> = there have been substantial discussions among the authors of = various
>>>> solution drafts off the mailing list. As far = as I know, no consensus
>>>> yet before ietf83, not sure = the progress in the Paris WG meeting. I
>>>> think the CW = approach has not been rejected by the WG yet, or the = WG
>>>> has not yet decided on which one to = adopt.
>>>>
>>>> = Simon
>>>>
>>>> 2012/4/8 Alexander = Vainshtein <Alexander.Vainshtein@eci= tele.com>
>>>>
>>>>>  Hi = all,
>>>>>
>>>>> Unfortunately I = have not been able to attend the Paris = IETF.
>>>>>
>>>>> However, looking = up the L2VPN proceedings, I've found a short
>>>>> = anonymous presentation called "E-Tree Update" =  (
>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx).>>>>> This presentation discusses the differences of = the E-Tree approaches
>>>>> based on dedicated VLANs = (as in
>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include= _t
>>>>> ext=3D1) and multiple PWs between the PEs = (as in
>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?= in
>>>>> clude_te
>>>>> = xt=3D1)
>>>>> and completely ignores the solution = based on usage of the CW in the
>>>>> PWs connecting = the PEs (as in
>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include= _t
>>>>> ext=3D1
>>>>> = ).
>>>>>
>>>>>
>>>>>= ;
>>>>> The Minutes of the Paris L2VPN session are not = yet available, but I
>>>>> wonder whether the WG has = taken a decision to reject the approach
>>>>> based on = the CW usage? I do not remember any recent discussion = of
>>>>> this topic on the WG mailing = list.
>>>>>
>>>>>
>>>>= >
>>>>> Regards, and lots of thanks in = advance,
>>>>>
>>>>> = Sasha
>>>>>
>>>>>
>>>>= >
>>>>>
>>>>>
>>>>&= gt; This e-mail message is intended for the recipient only and = contains
>>>>> information which is CONFIDENTIAL and = which may be proprietary to ECI
>>>
>>>>> = Telecom. If you have received this transmission in error, = please
>>>>> inform us by e-mail, phone or fax, and = then delete the original and
>>>>> all copies = thereof.
>>>>>
>>>
>>>
>&= gt;>
>>>
>>>
>>>This E-mail and = any of its attachments may contain Time Warner = Cable
>>>proprietary information, which is privileged, = confidential, or subject
>>>to copyright belonging to Time = Warner Cable. This E-mail is intended
>>>solely for the use = of the individual or entity to which it is addressed.
>>>If = you are not the intended recipient of this E-mail, you are = hereby
>>>notified that any dissemination, distribution, = copying, or action taken
>>>in relation to the contents of = and attachments to this E-mail is
>>>strictly prohibited and = may be unlawful. If you have received this
>>>E-mail in = error, please notify the sender immediately and = permanently
>>>delete the original and any copy of this = E-mail and any = printout.
>>>
>>
>>
>>This E-mail = and any of its attachments may contain Time Warner = Cable
>>proprietary information, which is privileged, = confidential, or subject to
>>copyright belonging to Time = Warner Cable. This E-mail is intended solely
>>for the use of = the individual or entity to which it is addressed. If you
>>are = not the intended recipient of this E-mail, you are hereby = notified
>>that any dissemination, distribution, copying, or = action taken in
>>relation to the contents of and attachments = to this E-mail is strictly
>>prohibited and may be unlawful. If = you have received this E-mail in
>>error, please notify the = sender immediately and permanently delete the
>>original and = any copy of this E-mail and any printout.
>
>
> This = E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any = printout.
> This e-mail message is intended for the recipient only = and contains information which is CONFIDENTIAL and which may be = proprietary to ECI Telecom. If you have received this transmission in = error, please inform us by e-mail, phone or fax, and then delete the = original and all copies thereof.
>
>
>
> = ------------------------------
>
> = _______________________________________________
> L2vpn mailing = list
> L2vpn@ietf.org
> https://www.ietf.org= /mailman/listinfo/l2vpn
>
>
> End of L2vpn Digest, = Vol 95, Issue 25
> *********************************** =

------_=_NextPart_001_01CD2084.7FCFE129-- From Alexander.Vainshtein@ecitele.com Sun Apr 22 05:42:31 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BAF21F85E4 for ; Sun, 22 Apr 2012 05:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.887 X-Spam-Level: X-Spam-Status: No, score=-2.887 tagged_above=-999 required=5 tests=[AWL=-0.687, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, 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 lAoFsG9Z-k9T for ; Sun, 22 Apr 2012 05:42:27 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 53AC821F85D4 for ; Sun, 22 Apr 2012 05:42:26 -0700 (PDT) Received: from [85.158.143.35:2283] by server-1.bemta-4.messagelabs.com id E0/9E-20925-1BCF39F4; Sun, 22 Apr 2012 12:42:25 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1335098544!6050349!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.7; banners=-,-,- Received: (qmail 367 invoked from network); 22 Apr 2012 12:42:24 -0000 Received: from unknown (HELO fridlpvsb005.ecitele.com) (168.87.1.157) by server-9.tower-21.messagelabs.com with SMTP; 22 Apr 2012 12:42:24 -0000 X-AuditID: a8571406-b7fe86d0000037a2-30-4f93fca95ce8 Received: from FRIDWPPCH001.ecitele.com (fridwppch001.ecitele.com [10.1.16.52]) by fridlpvsb005.ecitele.com (Symantec Messaging Gateway) with SMTP id 9D.A9.14242.9ACF39F4; Sun, 22 Apr 2012 14:42:17 +0200 (CEST) Received: from FRIDWPPMB002.ecitele.com ([169.254.4.167]) by FRIDWPPCH001.ecitele.com ([10.1.16.52]) with mapi id 14.01.0339.001; Sun, 22 Apr 2012 14:42:22 +0200 From: Alexander Vainshtein To: Daniel Cohn Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNHxPnvCW4Idac1kehO7tUxP5nzJaj50AAgAADF4CAAr5ZgIAAI2Xg Date: Sun, 22 Apr 2012 12:42:20 +0000 Message-ID: References: <4A6CE49E6084B141B15C0713B8993F28021737@SJEXCHMB12.corp.ad.broadcom.com> <44F4E579A764584EA9BDFD07D0CA08130777C3C1@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130777C3C1@tlvmail1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA02034CD1FRIDWPPMB002ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTfUwTZxz27bXXA3vmtXz0tQPSHeOfbcXix6zTdqjB1T8MRjQuxkTP3mt7 2t7d7iqB/dUMjQnEyOw0sYZQxseQEnEQxcVlCsmiqPiJiiRoYo2R6j41cyb1464FJFm8v577 Pc/7PL/fe7+jCHOH0UrxQgjLAhtgyGx9NphltXelIpWO5w3QGb7RqnP27F/jbGpN6Z2JfweN zs5LjwhnU90wWU56oveHSc/P0XGjp63tpc7TcCJCeOLdSf06w+YwWM4KghhiQ9jGYcXrYtbJ fDXrrWVsPOdiyhibFGC9OIiFkIthJQkLHOPOtv3vWa7KeMGGBa/I8YLPxaypqrQ7nYuX2ssY 9wY/r9iwPcjyAVsQKwrrwza1os0jcNuOE/5b4V5S6rhD1IxM7AyDA1GiHmRRCC5CP55P6DI4 H12710PWg2zKDEcAath7gdQIM2wH6NkfH2iYhC7UGx9P13PhR+in238btQMEHAKocfi8QSNy 4Aq0/3E9yIhWoomxVjWNUvFqNBDntLIelqDLqVQ6mIZrUSr+aDK4D6C6e3+miSxYjg4ffZHu FKjdvbjYna4T0ILGHjZPdg1R2y9XJ6fJQxOJ14YMLkLfHhsxarkEFFHznbxM1lw0dOShPiOZ hwY6R/WNID86wzX67kR0xomM5FMUO/MPmcGfoI6WJ8QUvnwuoZtZjwFjF0A7ZJ4LSNXKdodj cSn28iEcwKVeMdgL1AXr3JRLngbhxtJBACnAmOjyJZFKs4GtVmqDg2AepWPyaIO6f+Y520Wu 1s8q/q3y7gBWBgGiCCaXfparcjTH1n6DZXGKqlDv9jvCOtsrap8+tHWhw/H+F8ZC96x3V5qh T13OXRhLWJ7yKaAoBtFfavFzZezDNTv4QOgdraOytDZMahsFmoZWJDao8L4MfxGUUG9ODY0A s14QBWy10As0EdRE/t3CtE8SWNTBc2i7xprUZZ12SKrmOtV825aDmrn680xT1jAo+GLZf1fG VlUtMyTaTVd/6G5BbWdSSizWb3r1a/944e+Ov+4+7/68WLcvfOjB8Yqv+xz5kbPhm+4Fn9Wd nb/5w1idUPh9IVv89E1qz6b2/tHfuh4M1Awplir30YqipuLmrwr2Ra5LS1dtjIvWlqKDwwc2 jrZIe8tBcpaDeSrLyZyTjF7xs2UfE7LCvgUhbMSMOQQAAA== Cc: "l2vpn@ietf.org" , "yuqun.cao@gmail.com" , Lizhong Jin X-BeenThere: l2vpn@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: Sun, 22 Apr 2012 12:42:32 -0000 --_000_F9336571731ADE42A5397FC831CEAA02034CD1FRIDWPPMB002ecite_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Dan and all, It seems that interaction with PBB (when S-VLAN is replaced by an I-Tag at E= -NNI) makes your question even more relevant. Regards, Sasha From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Sunday, April 22, 2012 3:34 PM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander Vai= nshtein Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume that= the VLAN tags at the E-NNI will always be according to the current MEF mode= l? Or should we try to be as transparent as possible to user VLAN encapsulat= ion at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case VLAN ta= g) to signal VPLS information (in this case root/leaf origin) is necessarily= tied to specific assumptions on user payload encapsulation (in this case, t= hat S-VLAN tag is "available" to encode root/leaf). I don't think this is a= future-proof assumption, it's very likely that other network models will co= me up that require S-VLAN preservation, which in the 2-VLAN approach would n= ecessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, "l2vpn@ie= tf.org" >, "Ale= xander.Vainshtein@ecitele.com" > Cc: "yuqun.cao@gmail.com" > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic alread= y has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-bo= unces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com<= mailto:Alexander.Vainshtein@ecitele.com> Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L in= formation, customer payload or PW? The customer payload will be always modif= ied to carry R/L information in 2-VLAN approach, while PW with CW will carry= R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accesse= d by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access= H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information= ? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > > To: "Rogers, Josh" >, Lucy yong > >, Daniel Cohn >, Sam Cao > > > Cc: "l2vpn@ietf.org" > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, b= ut: > > IMO one of the advantages of the CW-based solution is that it is orthogona= l to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and,= in a more generic way, localization of effects of changes in the PE configu= ration. > > In particular, adding a Leaf AC to a PE that previously has been only supp= orting Root ACs (or vice versa), removal of the last Leaf or last Root AC fr= om a PE that previously has been supporting a mix etc. affect only the PE wh= ere this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadvan= tage of the CW-based approach - I believe it strongly depends on specific im= plementations. And some changes in the forwarding process are required in an= y solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces= @ietf.org] on behalf of Rogers, Josh [josh.ro= gers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a more > complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become more > complex. > > Gile's comparison slide still concisely captures the differences between > these methods, in my opinion. I haven't seen any new ideas or thoughts > brought to the group in the past week or two on the subject. I would hate > for both proposed methods to die on the vine because we couldn't decide > between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may double >>all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the processing >>in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >>traffic coming from a root AC) >>[[LY]] Not that simple. You construct either two P2MP PWs to all other >>PEs and let egress PE performing filtering, or construct one P2MP PW to >>leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >>perform forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so don't >>feel terribly strong about this objection. Is this a real problem for >>others (now or in the future), or is this objection in the weeds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. I >>encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>>giles.heron@gmail.com; simon.delord@gmail.c= om; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; Idan.Kaspi= t@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Cohe= n@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs after >>>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>>P2MP >>>PWs if need. There is no difference between P2MP or normal PW setup. But, >>>can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>>both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; Alexander.Vainshte= in@ecitele.com; Sam Cao >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; Idan.Kaspi= t@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Cohe= n@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong [mailto:lucy.yong@huawei.com= ] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; simon.delord@gmail.c= om; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; Idan.Kaspi= t@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Cohe= n@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, both >>>approaches can benefit from it. I was off for a while and captures some >>>discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues with >>>silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>>not clear on all the issues. Could you be more specific? As I mentioned >>>in below, two PW approach makes VPLS transport construction and packet >>>forwarding more complex, I can see potential backward compatibility >>>issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>>traffic, and some P2MP PWs for multicast traffic. It may double all of >>>them. >>> >>>E-tree is an Ethernet service and there is already VLAN based solution >>>in IEEE, can we just utilize it without complicating VPLS transport >>>construction? This also makes interworking with Eth only network easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vains= htein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.co= m'; >>>'Andrew.Sergeev@ecitele.com'; 'Idan.Ka= spit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.C= ohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are you >>>saying that you no longer are interested in that method in preference of >>>the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org [mailto:l2vpn= -bounces@ietf.org] On Behalf >>>Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; 'simon.delord@= gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.co= m'; >>>'Andrew.Sergeev@ecitele.com'; 'Idan.Ka= spit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.C= ohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron [mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord >;= Alexander Vainshtein >>>> >>>Cc: l2vpn@ietf.org >; Vladimir Kleiner >>>>; Andr= ew Sergeev >>>>; Idan Kas= pit >; >>>Mishael Wexler >; Rotem Cohen >>>> >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly have >>>put in a third column on the CW approach. And hopefully the minutes >>>will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to be >>>forming around the two alternatives of two PWEs or two VLANs. I believe >>>three of the authors of the CW approach are also authors of the two VLAN >>>approach and one is also an author of the two PWE approach. So perhaps >>>it's best to let those four individuals say which approach they prefer >>>and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of various >>>> solution drafts off the mailing list. As far as I know, no consensus >>>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>>> think the CW approach has not been rejected by the WG yet, or the WG >>>> has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein > >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree approaches >>>>> based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in the >>>>> PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>>> wonder whether the WG has taken a decision to reject the approach >>>>> based on the CW usage? I do not remember any recent discussion of >>>>> this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and contains >>>>> information which is CONFIDENTIAL and which may be proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original and >>>>> all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action taken >>>in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use of the individual or entity to which it is addressed. If you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable propr= ietary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the us= e of the individual or entity to which it is addressed. If you are not the i= ntended recipient of this E-mail, you are hereby notified that any dissemina= tion, distribution, copying, or action taken in relation to the contents of= and attachments to this E-mail is strictly prohibited and may be unlawful.= If you have received this E-mail in error, please notify the sender immedia= tely and permanently delete the original and any copy of this E-mail and any= printout. > This e-mail message is intended for the recipient only and contains inform= ation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA02034CD1FRIDWPPMB002ecite_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Dan and all,

It seems that interaction w= ith PBB (when S-VLAN is replaced by an I-Tag at E-NNI) makes your question e= ven more relevant.

 

Regards,<= /p>

     Sa= sha

 

From: Daniel Cohn= [mailto:DanielC@orckit.com]
Sent: Sunday, April 22, 2012 3:34 PM
To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexan= der Vainshtein
Cc: yuqun.cao@gmail.com
Subject: RE: The status of the approaches to the E-Tree solution?

 

Shahram and all,=

 

This question already came= up in our discussions - is it safe to assume that the VLAN tags at the E-NN= I will always be according to the current MEF model? Or should we try to be as transparent as possible to user VLAN encapsulation a= t the E-NNI, to accommodate future frameworks?

I believe that any approach= that looks at user payload (in this case VLAN tag) to signal VPLS informati= on (in this case root/leaf origin) is necessarily tied to specific assumptions on user payload encapsulation (in this case, that S= -VLAN tag is “available” to encode root/leaf). I don’t thi= nk this is a future-proof assumption, it’s very likely that other netw= ork models will come up that require S-VLAN preservation, which in the 2-VLAN approach would necessitate adding a third VLAN-ID.=

 

Daniel

 

From: Shahram Davari <davari@broadcom.com>
To: Lizhong Jin <lizho.jin@= gmail.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>, "= Alexander.Vainshtein@eci= tele.com" <Alexander.Vainshtei= n@ecitele.com>
Cc: "yuqun.cao@gmail.com<= /a>" <yuqun.cao@gmail.com= >
Subject: RE: The status of the approaches to the E-Tree solution?

 

Hi,

 

I also have a question rega= rding 2-VLAN. What if the customer traffic already has an S-VLAN? Do we need= a 3rd VLAN to identify the L/R?

 

Thx

Shahram

 

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin
Sent: Friday, April 20, 2012 9:38 AM
To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com
Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution?

 <= /p>

Hi, all,
The difference between 2-VLAN and CW approach is who will provide the R/L in= formation, customer payload or PW? The customer payload will be always modif= ied to carry R/L information in 2-VLAN approach, while PW with CW will carry= R/L information for CW approach.
I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accesse= d by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access= H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information= ?

Thanks
Lizhong

> ------------------------------
>
> Message: 2
> Date: Thu, 19 Apr 2012 04:38:36 +0000
> From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
> To: "Rogers, Josh" <josh.rogers@twcable.com>, Lucy yong
>        <= lucy.yong@huawei.com>, Daniel Cohn <DanielC@orckit.com>, Sam Cao
>        <y= uqun.cao@gmail.com>
> Cc: "l2vpn@ietf.org" &l= t;l2vpn@ietf.org>
> Subject: RE: The status of the approaches to the E-Tree solution?
> Message-ID:
>        <F9336571731ADE42A5397FC831CEAA020= 34192@FRIDWPPMB002.ecitele.com>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> Hi all,
> I fully understand that that what I am going to say is not very popular= , but:
>
> IMO one of the advantages of the CW-based solution is that it is orthog= onal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traff= ic.
>
> Another advantage is preservation of full mesh of P2P PWs in a VPLS, an= d, in a more generic way, localization of effects of changes in the PE confi= guration.
>
> In particular, adding a Leaf AC to a PE that previously has been only s= upporting Root ACs (or vice versa), removal of the last Leaf or last Root AC= from a PE that previously has been supporting a mix etc. affect only the PE= where this operation happens and not the rest of the PEs.
>
> As for the need for HW changes that have been mentioned as a main disad= vantage of the CW-based approach - I believe it strongly depends on specific= implementations. And some changes in the forwarding process are required in= any solution.
>
> My 2c,
>     Sasha
>
>
>
> ________________________________________
> From: l2vpn-bounces@ietf.org<= /a> [l2vpn-bounces@ietf.org] o= n behalf of Rogers, Josh [josh.ro= gers@twcable.com]
> Sent: Wednesday, April 18, 2012 9:57 PM
> To: Lucy yong; Daniel Cohn; Sam Cao
> Cc: l2vpn@ietf.org
> Subject: Re: The status of the approaches to the E-Tree solution?
>
> Again, the P2MP situation throws me.  Is this something that is us= ed
> commonly?
>
> I'm under the impression that adding P2MP to any model results in a mor= e
> complex model.  Wether outside s-tag is used to differentiate, or<= br> > dedicated pw's are used for the same purpose, it seems both become more=
> complex.
>
> Gile's comparison slide still concisely captures the differences betwee= n
> these methods, in my opinion.  I haven't seen any new ideas or tho= ughts
> brought to the group in the past week or two on the subject.  I wo= uld hate
> for both proposed methods to die on the vine because we couldn't decide=
> between two methods that have nothing inherently wrong with either.
>
> -Josh
>
>
> On 4/18/12 1:53 PM, "Lucy yong" <lucy.yong@huawei.com> wrote:
>
>>Send this again.
>>
>>Two PW approach can be complex too if the VPLS instance for E-Tree u= ses
>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown
>>unicast traffic, and some P2MP PWs for multicast traffic. It may dou= ble
>>all of them.
>>
>>Lucy
>>
>>-----Original Message-----
>>From: Daniel Cohn [mailto:Dani= elC@orckit.com]
>>Sent: Wednesday, April 18, 2012 1:42 PM
>>To: Lucy yong; Rogers, Josh; Sam Cao
>>Cc: l2vpn@ietf.org
>>Subject: RE: The status of the approaches to the E-Tree solution? >>
>>I think the first option its the natural way to go. How is the proce= ssing
>>in this case more complex?
>>
>>Thumb typed - please be tolerant
>>
>>Lucy yong <lucy.yong@huaw= ei.com> wrote:
>>
>>
>>
>>Snipped..
>>
>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2= MP PW
>>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (fo= r
>>traffic coming from a root AC)
>>[[LY]] Not that simple. You construct either two P2MP PWs to all oth= er
>>PEs and let egress PE performing filtering, or construct one P2MP PW= to
>>leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress= PE
>>perform forwarding and filtering. Both make node process complex. >>
>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW fo= r
>>delivering the frames to remote PEs. We should utilize them with the=
>>minimized changes. Dual VLAN solution is simpler than Dual PW.
>>
>>Regards,
>>Lucy
>>
>>
>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. &nb= sp;I
>>haven't had any first hand experience with P2MP PW's, however, so do= n't
>>feel terribly strong about this objection.  Is this a real prob= lem for
>>others (now or in the future), or is this objection in the weeds? >>
>>I'm not sure the 'additional complexity' is notable, or even relevan= t.  I
>>encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for i= t.
>>
>>Thanks,
>>Josh
>>
>>
>>
>>On 4/18/12 10:30 AM, "Lucy yong" <lucy.yong@huawei.com> wrote:
>>
>>>Please see inline.
>>>
>>>-----Original Message-----
>>>From: Sam Cao [mailto:yuq= un.cao@gmail.com]
>>>Sent: Tuesday, April 17, 2012 7:14 AM
>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (= Wim)';
>>>giles.heron@gmail.com; simon.delord@gmail.com;
>>>Alexander.Va= inshtein@ecitele.com
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com;
>>>Andrew.Sergeev@eci= tele.com; Idan.Kaspit@ecitele.com;
>>>Mishael.Wexler@eci= tele.com; Rotem.Cohen@ecitele.com
>>>Subject: RE: The status of the approaches to the E-Tree solution= ?
>>>
>>>Yes, 2 pws are only needed between pes with both root and leaf a= cs after
>>>improving Dual-PW approach. If consider P2MP, Dual-PW approach s= etup 2
>>>P2MP
>>>PWs if need. There is no difference between P2MP or normal PW se= tup. But,
>>>can Leaf-ACs be bound to Root PE of P2MP PW?
>>>
>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE w= ith both
>>>root and leaf ACs set up two or one P2MP PW to other PEs (some P= E have
>>>both root and leaf AC and some only have leaf ACs)?
>>>Regards,
>>>Lucy
>>>
>>>Regards,
>>>
>>>Yuqun (Sam) Cao
>>>E-mail: Yuqun.cao@gmail.c= om
>>>
>>>
>>>-----Original Message-----
>>>From: Daniel Cohn [mailto:= DanielC@orckit.com]
>>>Sent: Tuesday, April 17, 2012 4:56 PM
>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim);
>>>giles.heron@gmail.com;
>>>simon.delord@gmail.com= ; Alexander.Vainshtein@ecitele.com; Sam Cao
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com;
>>>Andrew.Sergeev@eci= tele.com; Idan.Kaspit@ecitele.com;
>>>Mishael.Wexler@eci= tele.com; Rotem.Cohen@ecitele.com
>>>Subject: RE: The status of the approaches to the E-Tree solution= ?
>>>
>>>Adding Sam (as l2vpn@ is holding messages)
>>>
>>>DC
>>>
>>>-----Original Message-----
>>>From: Lucy yong [mailto:= lucy.yong@huawei.com]
>>>Sent: Tuesday, April 17, 2012 12:39 AM
>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim);
>>>giles.heron@gmail.com; simon.delord@gmail.com;
>>>Alexander.Va= inshtein@ecitele.com
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com;
>>>Andrew.Sergeev@eci= tele.com; Idan.Kaspit@ecitele.com;
>>>Mishael.Wexler@eci= tele.com; Rotem.Cohen@ecitele.com
>>>Subject: RE: The status of the approaches to the E-Tree solution= ?
>>>
>>>
>>>Snipped,
>>>
>>>As we discussed extensively in the list, and as reflected in gil= es
>>>slide, 2 pws are only needed between pes with both root and leaf= acs,
>>>which will typically be a small minority.
>>>[[LY]] Don't know if the assumption is true. Even it is the case= , both
>>>approaches can benefit from it. I was off for a while and captur= es some
>>>discussions now.
>>>
>>>Also as per giles slide, dual vlan can have scalability issues d= ue to
>>>additional lookup and double use of vlans in internal emulated l= an
>>>interface. Also there are potential backward compatibility issue= s with
>>>silicon that doesn't support vlan mapping.
>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minut= es. I am
>>>not clear on all the issues. Could you be more specific? As I me= ntioned
>>>in below, two PW approach makes VPLS transport construction and= packet
>>>forwarding more complex, I can see potential backward compatibil= ity
>>>issues with 2 PW solution.
>>>
>>>Regards,
>>>Lucy
>>>
>>>Regards,
>>>
>>>Daniel
>>>
>>>Thumb typed - please be tolerant
>>>
>>>Lucy yong <lucy.yong@= huawei.com> wrote:
>>>
>>>In my mind, the VLAN approach means dual vlan method.
>>>
>>>The main concern for CW approach is hardware support.
>>>
>>>Two PW approach can be complex too if the VPLS instance for E-Tr= ee uses
>>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown= unicast
>>>traffic, and some P2MP PWs for multicast traffic. It may double= all of
>>>them.
>>>
>>>E-tree is an Ethernet service and there is already VLAN based so= lution
>>>in IEEE, can we just utilize it without complicating VPLS transp= ort
>>>construction? This also makes interworking with Eth only network= easier.
>>>
>>>Cheers,
>>>Lucy
>>>
>>>-----Original Message-----
>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com]
>>>Sent: Monday, April 16, 2012 8:35 AM
>>>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com';
>>>'simon.delord@gmail.co= m'; 'Alexander.Vains= htein@ecitele.com'
>>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com';
>>>'Andrew.Sergeev@ec= itele.com'; 'Idan.Kaspit@ecit= ele.com';
>>>'Mishael.Wexler@ec= itele.com'; 'Rotem.Cohen@ecit= ele.com'
>>>Subject: RE: The status of the approaches to the E-Tree solution= ?
>>>
>>>I believe the initial question was in regard to the CW method. &= nbsp;Are you
>>>saying that you no longer are interested in that method in prefe= rence of
>>>the dual vlan method?
>>>
>>>
>>>
>>>Lucy yong <lucy.yong@= huawei.com> wrote:
>>>
>>>
>>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>>
>>>Lucy
>>>
>>>-----Original Message-----
>>>From: l2vpn-bounces@ie= tf.org [mailto:l2vpn-bounces@i= etf.org] On Behalf
>>>Of Henderickx, Wim (Wim)
>>>Sent: Thursday, April 12, 2012 2:03 AM
>>>To: 'giles.heron@gmail.= com'; 'simon.delord@gmail.com<= /a>';
>>>'Alexander.V= ainshtein@ecitele.com'
>>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com';
>>>'Andrew.Sergeev@ec= itele.com'; 'Idan.Kaspit@ecit= ele.com';
>>>'Mishael.Wexler@ec= itele.com'; 'Rotem.Cohen@ecit= ele.com'
>>>Subject: Re: The status of the approaches to the E-Tree solution= ?
>>>
>>>The vlan approach is superior as it also works for eth only netw= orks,
>>>etc. On top some vendors indicate hw issues with the cw approach= . As
>>>such we have dropped more or less the cw approach.
>>>
>>>Cheers,
>>>Wim
>>>_________________
>>>sent from blackberry
>>>
>>>----- Original Message -----
>>>From: Giles Heron [mailto:giles.heron@gmail.com]
>>>Sent: Thursday, April 12, 2012 08:22 AM
>>>To: Simon Delord <s= imon.delord@gmail.com>; Alexander Vainshtein
>>><Alexande= r.Vainshtein@ecitele.com>
>>>Cc: l2vpn@ietf.org <l2vpn@ietf.org>; Vladimir Kleiner
>>><Vladimir.Kle= iner@ecitele.com>; Andrew Sergeev
>>><Andrew.Sergeev= @ecitele.com>; Idan Kaspit <Idan.Kaspit@ecitele.com>;
>>>Mishael Wexler <Mishael.Wexler@ecitele.com>; Rotem Cohen
>>><Rotem.Cohen@ecite= le.com>
>>>Subject: Re: The status of the approaches to the E-Tree solution= ?
>>>
>>>Sorry - the "anonymous presentation" was mine.  I= should possibly have
>>>put in a third column on the CW approach.  And hopefully th= e minutes
>>>will be posted soon.
>>>
>>>We had various discussions, as Simon stated, and consensus seeme= d to be
>>>forming around the two alternatives of two PWEs or two VLANs. &n= bsp;I believe
>>>three of the authors of the CW approach are also authors of the= two VLAN
>>>approach and one is also an author of the two PWE approach. So p= erhaps
>>>it's best to let those four individuals say which approach they= prefer
>>>and why?
>>>
>>>Giles
>>>
>>>On 10/04/2012 00:45, "Simon Delord" <simon.delord@gmail.com> wrote:
>>>
>>>> Hi Alexander,
>>>>
>>>> You are right, no discussion on the WG mailing list recentl= y, but
>>>> there have been substantial discussions among the authors o= f various
>>>> solution drafts off the mailing list. As far as I know, no= consensus
>>>> yet before ietf83, not sure the progress in the Paris WG me= eting. I
>>>> think the CW approach has not been rejected by the WG yet,= or the WG
>>>> has not yet decided on which one to adopt.
>>>>
>>>> Simon
>>>>
>>>> 2012/4/8 Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
>>>>
>>>>>  Hi all,
>>>>>
>>>>> Unfortunately I have not been able to attend the Paris= IETF.
>>>>>
>>>>> However, looking up the L2VPN proceedings, I've found a= short
>>>>> anonymous presentation called "E-Tree Update"=  (
>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx).
>>>>> This presentation discusses the differences of the E-Tr= ee approaches
>>>>> based on dedicated VLANs (as in
>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>>> ext=3D1) and multiple PWs between the PEs (as in
>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>>> clude_te
>>>>> xt=3D1)
>>>>> and completely ignores the solution based on usage of t= he CW in the
>>>>> PWs connecting the PEs (as in
>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>>> ext=3D1
>>>>> ).
>>>>>
>>>>>
>>>>>
>>>>> The Minutes of the Paris L2VPN session are not yet avai= lable, but I
>>>>> wonder whether the WG has taken a decision to reject th= e approach
>>>>> based on the CW usage? I do not remember any recent dis= cussion of
>>>>> this topic on the WG mailing list.
>>>>>
>>>>>
>>>>>
>>>>> Regards, and lots of thanks in advance,
>>>>>
>>>>> Sasha
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This e-mail message is intended for the recipient only= and contains
>>>>> information which is CONFIDENTIAL and which may be prop= rietary to ECI
>>>
>>>>> Telecom. If you have received this transmission in erro= r, please
>>>>> inform us by e-mail, phone or fax, and then delete the= original and
>>>>> all copies thereof.
>>>>>
>>>
>>>
>>>
>>>
>>>
>>>This E-mail and any of its attachments may contain Time Warner C= able
>>>proprietary information, which is privileged, confidential, or s= ubject
>>>to copyright belonging to Time Warner Cable. This E-mail is inte= nded
>>>solely for the use of the individual or entity to which it is ad= dressed.
>>>If you are not the intended recipient of this E-mail, you are he= reby
>>>notified that any dissemination, distribution, copying, or actio= n taken
>>>in relation to the contents of and attachments to this E-mail is=
>>>strictly prohibited and may be unlawful. If you have received th= is
>>>E-mail in error, please notify the sender immediately and perman= ently
>>>delete the original and any copy of this E-mail and any printout= .
>>>
>>
>>
>>This E-mail and any of its attachments may contain Time Warner Cable=
>>proprietary information, which is privileged, confidential, or subje= ct to
>>copyright belonging to Time Warner Cable. This E-mail is intended so= lely
>>for the use of the individual or entity to which it is addressed. If= you
>>are not the intended recipient of this E-mail, you are hereby notifi= ed
>>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strict= ly
>>prohibited and may be unlawful. If you have received this E-mail in<= br> >>error, please notify the sender immediately and permanently delete t= he
>>original and any copy of this E-mail and any printout.
>
>
> This E-mail and any of its attachments may contain Time Warner Cable pr= oprietary information, which is privileged, confidential, or subject to copy= right belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-m= ail, you are hereby notified that any dissemination, distribution, copying,= or action taken in relation to the contents of and attachments to this E-ma= il is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify t= he sender immediately and permanently delete the original and any copy of th= is E-mail and any printout.
> This e-mail message is intended for the recipient only and contains inf= ormation which is CONFIDENTIAL and which may be proprietary to ECI Telecom.= If you have received this transmission in error, please inform us by e-mail= , phone or fax, and then delete the original and all copies thereof.
>
>
>
> ------------------------------
>
> _______________________________________________
> L2vpn mailing list
> L2vpn@ietf.org
> https://www.iet= f.org/mailman/listinfo/l2vpn
>
>
> End of L2vpn Digest, Vol 95, Issue 25
> ***********************************

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA02034CD1FRIDWPPMB002ecite_-- From yuqun.cao@gmail.com Sun Apr 22 05:50:25 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D1121F85D7 for ; Sun, 22 Apr 2012 05:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.455 X-Spam-Level: X-Spam-Status: No, score=-1.455 tagged_above=-999 required=5 tests=[AWL=-1.191, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 E+9gzfmddSgL for ; Sun, 22 Apr 2012 05:50:23 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 48A2E21F85D6 for ; Sun, 22 Apr 2012 05:50:23 -0700 (PDT) Received: by dady13 with SMTP id y13so20001787dad.27 for ; Sun, 22 Apr 2012 05:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:in-reply-to:x-mimeole; bh=jQDlqORr1ij+dkOinqeuil1wz/dRyU4zftXnXyhe3sI=; b=krKGgdBrApIUct/G3xyeB2KXNPVf3N9lD+uT8RxrUoi0mTrcoZaXw5gqjLFjd0N3Dn VacQnBQGESdbqrD45dmQYcaKRfkqAaDLThVbPF/AGZi44Z/aRQqmRSxVVz53994A7MNi QgzeKadwQhIf/xcEZnZeRW47A+X5QjDcr8S1pKGixaAdjMKlTG5EHrLGPn9CjWh3CGkq /KHtJc+SW2oEoCMtRs8YXFvcP1mrmx4XgyJ442oToeqxFngfOkVoJd1u3BivW9h+L3Vi 36C1SGnLKc7wkZgzaH9K2quVuuGJAd1TEHv8u+sdnapRE1qOtHRXcU8FhIz9Z7zLqBcP o+GA== Received: by 10.68.222.134 with SMTP id qm6mr11674947pbc.14.1335099022919; Sun, 22 Apr 2012 05:50:22 -0700 (PDT) Received: from v2comsam ([36.248.16.95]) by mx.google.com with ESMTPS id qb8sm11344539pbb.12.2012.04.22.05.50.15 (version=SSLv3 cipher=OTHER); Sun, 22 Apr 2012 05:50:21 -0700 (PDT) From: "Sam Cao" To: "'Rogers, Josh'" , "'Lizhong Jin'" , "'Henderickx, Wim \(Wim\)'" References: <1B88357C808B432E871CA9D678305B7C@v2comsam> Subject: RE: The status of the approaches to the E-Tree solution? Date: Sun, 22 Apr 2012 20:50:19 +0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01CD20C9.8B03A680" X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac0fz91fQqD0AjinQOKPx+HMMlhYSgAssfIg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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: Sun, 22 Apr 2012 12:50:25 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0009_01CD20C9.8B03A680 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Josh, =20 Yesterday I re-read all mail and pick out all issues we have discussed before. They are questions for all 3 approaches, and some are still questions for me till now. =20 I can not fully understand =A1=B0where is the list for multi-PW = method=A1=B1? Do you mean Multi-segment PW? Rafi raised this as objection to Dual-VLAN approach, and Yuanlong explained that switching-PW does not aware AC = type and just do label-swapping. It seems reasonable, but now it may not = cover all cases. In some special cases we should configure AC types on = switching PE. =20 +-----------+-----------+----------+-------+-----------------+ |MPLS Label | R/L S-Tag | AC S-Tag | C-tag | Layer 2 Payload | +-----------+-----------+----------+-------+-----------------+ =20 Yes, I think that it is correct. Maybe Yuanlong or other co-authors can correct it if it is wrong.=20 =20 =A1=B0The VLAN mode looks more like the MEF and IEEE approaches =A8C is = that a conclusive enough reason to prefer that approach?=A1=B1 (From meeting = minutes). For me, if it has no chip limit (wait for confirmation from chip = vendors) and compatible with current solutions, it will be better, but now=A1=AD=20 =20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 _____ =20 From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Saturday, April 21, 2012 11:03 PM To: Sam Cao; 'Lizhong Jin'; 'Henderickx, Wim (Wim)' Cc: l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? =20 Sam? Where is the list for multi-PW method? =20 =20 One item I don't think is covered in your 2VLAN list, is where service multiplexed UNI's are involved, or any time there is a layer 2 CPE = between PE and CE, these devices usually expect a single, bidirectional s-tag, = and according to your explanation this morning, coordinating the S-Tags used = for ETREE with the customer SHOULD NOT to be done, therefor there must be an 'inner S-Tag' on the AC, and an 'outer S-Tag' in the PW. =20 =20 While inside the PW, a 2VLAN method frame would look like: =20 +-----------+-----------+----------+-------+-----------------+ |MPLS Label | R/L S-Tag | AC S-Tag | C-tag | Layer 2 Payload | +-----------+-----------+----------+-------+-----------------+ =20 Correct? =20 Would you consider this an 'issue' or just a 'complication' ? =20 A lot of the 'pro 2VLAN' argument has been centered around existing IEEE standard, and at first it sounded like this was better/proposed for the ability to extend the R/L S-tag beyond the PW, but it sounds like that = isn't really an option, so I'm not sure that is a valid benefit/driver. =20 Thanks much, Josh =20 From: Sam Cao To: 'Lizhong Jin' , "'Henderickx, Wim (Wim)'" Cc: "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? =20 Hi all, =20 We reach an impasse:-). BTW, Meeting minutes is ready now. We can get E-tree summary from IETF site. =20 Today I collected all items we discussed before. They are, =20 1) Silicon issue or chip limit; 2) Network efficiency; 3) Encapsulation mode, tag or raw; 4) H-VPLS; 5) Backwards compatibility, especially legacy PE or Non-supporting PE with IEEE E-tree support joins E-Tree domain; 6) Configuration change in operation, for example, Leaf-only -> Root-Leaf-Mixed; 7) S-VLAN preservation support; 8) Multi-segment PW; 9) VLAN ID allocation (Only for Dual-VLAN); 10)Multi-AS deployment; 11)ECMP; 12)P2MP-PW; 13)Ethernet OAM; =20 If we review the mail-list, CW approach has the following limits: 1) Chip limit. Please read reply from Giles and Wim; 2) Network efficiency: There are garbage fames which will be dropped = on egress PE since only egress PE can decide forward or drop frames while = it receives frames. Ingress PE can not decide forward or not. Yes, current solution can support Hub-Spoke configuration, but as we know, the configuration is not easy if the network is big. Dual-VLAN or Multi-PW approach can break communication between Leaf-Only PEs via signaling. 3) Backwards compatibility: Not all PEs supports control word. If one = can not support control word, it will not join E-Tree domain; =20 Dual VLAN has following limits: 1) Chip limit: As we know, we need to push one VLAN into frames = before MPLS encapsulation on ingress PE and stripe it out on egress PE. This is non-standard operation. Wait for confirmation from chip vendor; 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, = PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, = but can NOT configure it at all in Spoke PW case; 3) Multi-PW: Rafi figures this out, but we don=A1=AFt think this over = at that time. I think that it also has same problem as H-VPLS has. 4) Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs = should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN ID; 5) Backward Compatibility: Just as Daniel mentioned, there is compatibility issue if legacy PE joins E-Tree domain. For me, I = don=A1=AFt get clear response from co-authors of Dual-VLAN. =20 For all approaches, we don=A1=AFt cover ECMP / Ethernet OAM till now.=20 =20 Is there anything missed?=20 =20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 _____ =20 From: Lizhong Jin [mailto:lizho.jin@gmail.com]=20 Sent: Saturday, April 21, 2012 11:59 AM To: Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; = yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? =20 Hi Win, Thank you for the answers. In that case, PE-rs should configure the root/leaf properties of VPWS, not on the remote PE of VPWS. And usually = on PE-rs, you could not figure out the accessing spoke PW is from PE-r of = VPWS or MTU-s. Unless having some additional indication in NMS, you even = don't know which spoke PW needs to do VLAN manipulation. I am not sure such = R/L configuration could be accepted from operational view. Hope to see more comments. Regards Lizhong =D4=DA 2012=C4=EA4=D4=C221=C8=D5=D0=C7=C6=DA=C1=F9=A3=ACHenderickx, Wim = (Wim) =D0=B4=B5=C0=A3=BA > The VPWS which terminates at the H-VPLS node is indicated to be root = or leaf and the procedures associated will do the VLAN manipulation > > =20 > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Lizhong Jin > Sent: vrijdag 20 april 2012 18:38 > To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com > Cc: yuqun.cao@gmail.com > Subject: RE: The status of the approaches to the E-Tree solution? > > =20 > > Hi, all, > The difference between 2-VLAN and CW approach is who will provide the = R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW = will carry R/L information for CW approach. > I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used = to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information? > > Thanks > Lizhong > >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 Apr 2012 04:38:36 +0000 >> From: Alexander Vainshtein >> To: "Rogers, Josh" , Lucy yong >> , Daniel Cohn , Sam = Cao >> >> Cc: "l2vpn@ietf.org" >> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID: >> = >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi all, >> I fully understand that that what I am going to say is not very = popular, but: >> >> IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, = and, in a more generic way, localization of effects of changes in the PE configuration. >> >> In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect only = the PE where this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a = more >> complex model. Wether outside s-tag is used to differentiate, or >> dedicated pw's are used for the same purpose, it seems both become = more >> complex. >> >> Gile's comparison slide still concisely captures the differences = between >> these methods, in my opinion. I haven't seen any new ideas or = thoughts >> brought to the group in the past week or two on the subject. I would hate >> for both proposed methods to die on the vine because we couldn't = decide >> between two methods that have nothing inherently wrong with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" wrote: >> >>>Send this again. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree = uses >>>P2P PW fo=20 =20 _____ =20 This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended solely = for the use of the individual or entity to which it is addressed. If you are = not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and = may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of = this E-mail and any printout. ------=_NextPart_000_0009_01CD20C9.8B03A680 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Josh,

 <= /span>

Yesterday I = re-read all mail and pick out all issues we have discussed before. They are = questions for all 3 approaches, and some are still questions for me till = now.

 <= /span>

 I can not = fully understand =A1=B0where is the list for multi-PW method=A1=B1? Do you = mean Multi-segment PW? Rafi raised this as objection to Dual-VLAN approach, and Yuanlong = explained that switching-PW does not aware AC type and just do label-swapping. It = seems reasonable, but now it may not cover all cases. In some special cases we = should configure AC types on switching PE.

 <= /span>

+-----------+= -----------+----------+-------+-----------------+

|MPLS Label = | R/L S-Tag | AC S-Tag | C-tag | Layer 2 Payload |

+-----------+= -----------+----------+-------+-----------------+

 <= /span>

Yes, I think that = it is correct.  Maybe Yuanlong or other co-authors can correct it if it = is wrong.

 <= /span>

=A1=B0The VLAN = mode looks more like the MEF and IEEE approaches =A8C is that a conclusive enough reason = to prefer that approach?=A1=B1 (From meeting minutes). For me, if it has no chip = limit (wait for confirmation from chip vendors) and compatible with current = solutions, it will be better, but now=A1=AD

 <= /span>

Regards,

 

=

Yuqun (Sam) Cao

E-mail: Yuqun.cao@gmail.com

 

From: Rogers, Josh [mailto:josh.rogers@twcable.com]
Sent: Saturday, April 21, = 2012 11:03 PM
To: Sam Cao; 'Lizhong = Jin'; 'Henderickx, Wim (Wim)'
Cc: l2vpn@ietf.org
Subject: Re: The status = of the approaches to the E-Tree solution?

 

Sam? =  Where is the list for multi-PW method?  

 

One item I = don't think is covered in your 2VLAN list, is where service multiplexed UNI's are = involved, or any time there is a layer 2 CPE between PE and CE, these devices = usually expect a single, bidirectional s-tag, and according to your explanation = this morning, coordinating the S-Tags used for ETREE with the customer SHOULD = NOT to be done, therefor there must be an 'inner S-Tag' on the AC, and an = 'outer S-Tag' in the PW.  

 

While inside = the PW, a 2VLAN method frame would look like:

 

+-----------+= -----------+----------+-------+-----------------+

|MPLS Label = | R/L S-Tag | AC S-Tag | C-tag | Layer 2 Payload |

+-----------+= -----------+----------+-------+-----------------+

 

Correct?

 

Would you = consider this an 'issue' or just a 'complication' ?

 

A lot of the = 'pro 2VLAN' argument has been centered around existing IEEE standard, and at = first it sounded like this was better/proposed for the ability to extend the = R/L S-tag beyond the PW, but it sounds like that isn't really an option, so = I'm not sure that is a valid benefit/driver.

 

Thanks = much,

Josh

 

From: Sam Cao <yuqun.cao@gmail.com>
To: 'Lizhong Jin' <lizho.jin@gmail.com>, "'Henderickx, Wim (Wim)'" <wim.henderickx@alcatel-= lucent.com>
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Hi = all,

 

We reach an = impasseJ.  BTW, Meeting minutes is ready now. We can get = E-tree summary from IETF site.

 

Today I = collected all items we discussed before. They are,

 

1)    = Silicon issue or chip = limit;

2)    = Network = efficiency;

3)    = Encapsulation mode, tag or = raw;

4)    = H-VPLS;

5)    = Backwards compatibility, especially = legacy PE or Non-supporting PE with IEEE E-tree support joins E-Tree = domain;

6)    = Configuration change in operation, for = example, Leaf-only -> Root-Leaf-Mixed;

7)    = S-VLAN preservation = support;

8)    = Multi-segment = PW;

9)    = VLAN ID allocation (Only for = Dual-VLAN);

10)Multi-AS deployment;

11)ECMP;

12)P2MP-PW;

13)Ethernet OAM;

 

If we review the mail-list, CW approach has the following = limits:

1)    = Chip limit. Please read reply from Giles = and Wim;

2)    = Network efficiency: There are garbage = fames which will be dropped on egress PE since only egress PE can decide forward or = drop frames while it receives frames. Ingress = PE can not = decide forward or not. Yes, current solution can support Hub-Spoke = configuration, but as we know, the configuration is not easy if the network is big. = Dual-VLAN or Multi-PW approach can break communication between Leaf-Only PEs via = signaling.

3)    = Backwards compatibility: Not all PEs = supports control word. If one can not support control word, it will not join = E-Tree domain;

 

Dual VLAN has = following limits:

1)    = Chip limit: As we know, we need to push = one VLAN into frames before MPLS encapsulation on ingress PE and stripe it out on = egress PE. This is non-standard operation. Wait for confirmation from chip = vendor;

2)    = HVPLS: If we follow Fig 3 or Fig = 4 in RFC 4762 = to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type = in VPWS case, but can NOT configure it at all in Spoke PW = case;

3)    = Multi-PW: Rafi figures this out, but we = don=A1=AFt think this over at that time. I think that it also has same problem as = H-VPLS has.

4)    = Encapsulation mode: If deploy GVPLS with = Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE = will stripe S-VLAN ID;

5)    = Backward Compatibility: Just as Daniel = mentioned, there is compatibility issue if legacy PE joins E-Tree domain. For me, I = don=A1=AFt get clear response from co-authors of = Dual-VLAN.

 

For all = approaches, we don=A1=AFt cover ECMP / Ethernet OAM till now.

 

Is there anything = missed?

 

Regards,

 

Yuqun (Sam) Cao

E-mail: Yuqun.cao@gmail.com

 

From: Lizhong Jin [mailto:lizho.jin@gmail.com]
Sent: Saturday, April 21, = 2012 11:59 AM
To: Henderickx, Wim = (Wim)
Cc: l2vpn@ietf.org; Alexander.Vainshtein@eci= tele.com; yuqun.cao@gmail.com
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Hi Win,
Thank you for the answers. In that case, PE-rs should configure the = root/leaf properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, = you could not figure out the accessing spoke PW is from PE-r of VPWS or = MTU-s. Unless having some additional indication in NMS, you even don't know = which spoke PW needs to do VLAN manipulation. I am not sure such R/L = configuration could be accepted from operational view. Hope to see more comments.

Regards
Lizhong


=D4=DA 2012=C4=EA4=D4=C221=C8=D5=D0=C7=C6=DA=C1=F9= =A3=ACHenderickx, Wim (Wim) <wim.henderickx@alcatel-= lucent.com> =D0=B4=B5=C0=A3=BA
> The VPWS which terminates at the H-VPLS node is indicated to be = root or leaf and the procedures associated will do the VLAN manipulation
>
>  
>
> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin
> Sent: vrijdag 20 april 2012 18:38
> To: l2vpn@ietf.org; Alexander.Vainshtein@eci= tele.com
> Cc: yuqun.cao@gmail.com
> Subject: RE: The status of the approaches to the E-Tree = solution?
>
>  
>
> Hi, all,
> The difference between 2-VLAN and CW approach is who will provide = the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW = will carry R/L information for CW approach.
> I have a question with the 2-VLAN approach in H-VPLS where H-VPLS = is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds = VLAN to indicate R/L information?
>
> Thanks
> Lizhong
>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 19 Apr 2012 04:38:36 +0000
>> From: Alexander Vainshtein <Alexander.Vainshtein@eci= tele.com>
>> To: "Rogers, Josh" <josh.rogers@twcable.com>, = Lucy yong
>>        <lucy.yong@huawei.com>, Daniel Cohn <DanielC@orckit.com>, Sam Cao
>>        <yuqun.cao@gmail.com>
>> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
>> Subject: RE: The status of the approaches to the E-Tree = solution?
>> Message-ID:
>>        <F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>
>> Content-Type: text/plain; charset=3D"us-ascii"
>>
>> Hi all,
>> I fully understand that that what I am going to say is not very popular, but:
>>
>> IMO one of the advantages of the CW-based solution is that it = is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic.
>>
>> Another advantage is preservation of full mesh of P2P PWs in a = VPLS, and, in a more generic way, localization of effects of changes in the PE configuration.
>>
>> In particular, adding a Leaf AC to a PE that previously has = been only supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect only the = PE where this operation happens and not the rest of the PEs.
>>
>> As for the need for HW changes that have been mentioned as a = main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are = required in any solution.
>>
>> My 2c,
>>     Sasha
>>
>>
>>
>> ________________________________________
>> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] = on behalf of Rogers, Josh [josh.rogers@twcable.com]
>> Sent: Wednesday, April 18, 2012 9:57 PM
>> To: Lucy yong; Daniel Cohn; Sam Cao
>> Cc: l2vpn@ietf.org
>> Subject: Re: The status of the approaches to the E-Tree = solution?
>>
>> Again, the P2MP situation throws me.  Is this something = that is used
>> commonly?
>>
>> I'm under the impression that adding P2MP to any model results = in a more
>> complex model.  Wether outside s-tag is used to = differentiate, or
>> dedicated pw's are used for the same purpose, it seems both = become more
>> complex.
>>
>> Gile's comparison slide still concisely captures the = differences between
>> these methods, in my opinion.  I haven't seen any new = ideas or thoughts
>> brought to the group in the past week or two on the subject. =  I would hate
>> for both proposed methods to die on the vine because we = couldn't decide
>> between two methods that have nothing inherently wrong with = either.
>>
>> -Josh
>>
>>
>> On 4/18/12 1:53 PM, "Lucy yong" <lucy.yong@huawei.com> = wrote:
>>
>>>Send this again.
>>>
>>>Two PW approach can be complex too if the VPLS instance for = E-Tree uses
>>>P2P PW fo

 

This E-mail and = any of its attachments may contain Time Warner Cable proprietary information, which = is privileged, confidential, or subject to copyright belonging to Time = Warner Cable. This E-mail is intended solely for the use of the individual or = entity to which it is addressed. If you are not the intended recipient of this = E-mail, you are hereby notified that any dissemination, distribution, copying, = or action taken in relation to the contents of and attachments to this = E-mail is strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently delete the = original and any copy of this E-mail and any printout.

------=_NextPart_000_0009_01CD20C9.8B03A680-- From yuqun.cao@gmail.com Sun Apr 22 06:40:41 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E5921F854C for ; Sun, 22 Apr 2012 06:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 6W3ujfkZUkii for ; Sun, 22 Apr 2012 06:40:39 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id D4E8021F854A for ; Sun, 22 Apr 2012 06:40:38 -0700 (PDT) Received: by dady13 with SMTP id y13so20043238dad.27 for ; Sun, 22 Apr 2012 06:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:in-reply-to:x-mimeole; bh=O8aAO/q6JywcrMf+AhA7FVXCPL+ddmduNUE1BXp/Zxw=; b=cFmHI6sPcg/7b/o9RWdI1+KSwZsG0J+OLtO0KnlLti4MyT9BN1DIG3fyyfB9DH9nA6 tUCfCDEZWlCwT79cRBgBTURmPNA1o3LCsfOhCLEsLOxo0D1oNhjK5YXSbCgySMl6UzBr O3zvW9brVTp7/UVhqwJ2KFOdYfx84lyofQsJZPFyqZdXQ2REueomrK1DOeUfjK0ywzqA tlFtwaS5Q7rb7gdXHMA0tmRocqv/Na3Dms3EiYzYoH4ZAWBbhVLo7O2VwLA8x8k5UnYO Jo3hC+kcEiHteRUUlzsoFF3lzKvxZyExPxqPoS3nhbw3BLuiu6MRB+6j0GnsUjpv50Wd OpBA== Received: by 10.68.219.34 with SMTP id pl2mr3751187pbc.56.1335102038364; Sun, 22 Apr 2012 06:40:38 -0700 (PDT) Received: from v2comsam ([36.248.16.95]) by mx.google.com with ESMTPS id i1sm11431951pbj.70.2012.04.22.06.40.31 (version=SSLv3 cipher=OTHER); Sun, 22 Apr 2012 06:40:36 -0700 (PDT) From: "Sam Cao" To: "'Raymond Key'" References: , <14C7F4F06DB5814AB0DE29716C4F6D6701296244C3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>, , <1B88357C808B432E871CA9D678305B7C@v2comsam> Subject: RE: The status of the approaches to the E-Tree solution? Date: Sun, 22 Apr 2012 21:40:34 +0800 Message-ID: <6F9ADEDA06A04AB98C247D303AFE93BE@v2comsam> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01CD20D0.90A018B0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac0f1C14N6sQqvEhTBukhDQ1jdAiqwAssUiw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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: Sun, 22 Apr 2012 13:40:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000D_01CD20D0.90A018B0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Raymond, =20 Network efficiency: [Sam] Leaf/Root configuration is local configuration, and PE can not = know remote AC type configuration. This is CW Fundamentals. So even if CW approach defines optional enhancement for Leaf-Only PE, but can not = signal it between Leaf-Only PEs, so there is no good way to support this. The possible solution is, manually configure hub-spoke topology, but if we = do like this, current solutions have support most E-Tree cases with = Hub-Spoke configuration. Lizhong mentioned this in one mail. =20 Backwards compatibility: [Sam] Yes, new draft considers backward compatibility, but it makes precondition: The PE which can not support Control word only works as Root-only PE. This does not make sense for me. If it only supports VPLS, = ok, it can work as Root-only, but why it can not work as Root-Leaf-Mixed or Leaf-only if it can not support CW? =20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 _____ =20 From: raymond.key@hotmail.com [mailto:raymond.key@hotmail.com] On Behalf = Of Raymond Key Sent: Saturday, April 21, 2012 11:32 PM To: yuqun.cao@gmail.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? =20 Some clarifications [RK] inserted below Thanks Raymond Key _____ =20 From: yuqun.cao@gmail.com To: lizho.jin@gmail.com; wim.henderickx@alcatel-lucent.com Subject: RE: The status of the approaches to the E-Tree solution? Date: Sat, 21 Apr 2012 22:51:28 +0800 CC: l2vpn@ietf.org Hi all, =20 We reach an impasse:-). BTW, Meeting minutes is ready now. We can get E-tree summary from IETF site. =20 Today I collected all items we discussed before. They are, =20 1) Silicon issue or chip limit; 2) Network efficiency; 3) Encapsulation mode, tag or raw; 4) H-VPLS; 5) Backwards compatibility, especially legacy PE or Non-supporting = PE with IEEE E-tree support joins E-Tree domain; 6) Configuration change in operation, for example, Leaf-only -> Root-Leaf-Mixed; 7) S-VLAN preservation support; 8) Multi-segment PW; 9) VLAN ID allocation (Only for Dual-VLAN); 10) Multi-AS deployment; 11) ECMP; 12) P2MP-PW; 13) Ethernet OAM; =20 If we review the mail-list, CW approach has the following limits: 1) Chip limit. Please read reply from Giles and Wim; 2) Network efficiency: There are garbage fames which will be = dropped on egress PE since only egress PE can decide forward or drop frames = while it receives frames. Ingress PE can not decide forward or not. Yes, current solution can support Hub-Spoke configuration, but as we know, the configuration is not easy if the network is big. Dual-VLAN or Multi-PW approach can break communication between Leaf-Only PEs via signaling. [RK] It seems to me this is not the case. Section 6 of the draft has = some discussions on this. http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-6 6. Optional Enhancements for Leaf-only PE 6.1. No PW between Leaf-only PEs 6.2. Not Forward Frame from Leaf AC to Leaf-only PE =20 3) Backwards compatibility: Not all PEs supports control word. If = one can not support control word, it will not join E-Tree domain; =20 [RK] It seems to me this is not the case. Section 5 of the draft has = some discussions on this. http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-5 5. Backward Compatibility 5.1. AC Type 5.2. Control Word 5.3. Additional Action in Data Forwarding 5.3.1. Ingress PE Supporting the Extension but Egress PE Not 5.3.2. Egress PE Supporting the Extension but Ingress PE Not =20 Dual VLAN has following limits: 1) Chip limit: As we know, we need to push one VLAN into frames = before MPLS encapsulation on ingress PE and stripe it out on egress PE. This is non-standard operation. Wait for confirmation from chip vendor; 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, but can NOT configure it at all in Spoke PW case; 3) Multi-PW: Rafi figures this out, but we don=A1=AFt think this = over at that time. I think that it also has same problem as H-VPLS has. 4) Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will stripe = S-VLAN ID; 5) Backward Compatibility: Just as Daniel mentioned, there is compatibility issue if legacy PE joins E-Tree domain. For me, I = don=A1=AFt get clear response from co-authors of Dual-VLAN. =20 For all approaches, we don=A1=AFt cover ECMP / Ethernet OAM till now.=20 =20 Is there anything missed?=20 =20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 _____ =20 From: Lizhong Jin [mailto:lizho.jin@gmail.com]=20 Sent: Saturday, April 21, 2012 11:59 AM To: Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; = yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? =20 Hi Win, Thank you for the answers. In that case, PE-rs should configure the root/leaf properties of VPWS, not on the remote PE of VPWS. And usually = on PE-rs, you could not figure out the accessing spoke PW is from PE-r of = VPWS or MTU-s. Unless having some additional indication in NMS, you even = don't know which spoke PW needs to do VLAN manipulation. I am not sure such = R/L configuration could be accepted from operational view. Hope to see more comments. Regards Lizhong =D4=DA 2012=C4=EA4=D4=C221=C8=D5=D0=C7=C6=DA=C1=F9=A3=ACHenderickx, Wim = (Wim) =D0=B4=B5=C0=A3=BA > The VPWS which terminates at the H-VPLS node is indicated to be root = or leaf and the procedures associated will do the VLAN manipulation > > =20 > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Lizhong Jin > Sent: vrijdag 20 april 2012 18:38 > To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com > Cc: yuqun.cao@gmail.com > Subject: RE: The status of the approaches to the E-Tree solution? > > =20 > > Hi, all, > The difference between 2-VLAN and CW approach is who will provide the = R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW = will carry R/L information for CW approach. > I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used = to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information? > > Thanks > Lizhong > >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 Apr 2012 04:38:36 +0000 >> From: Alexander Vainshtein >> To: "Rogers, Josh" , Lucy yong >> , Daniel Cohn , Sam = Cao >> >> Cc: "l2vpn@ietf.org" >> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID: >> = >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi all, >> I fully understand that that what I am going to say is not very = popular, but: >> >> IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, = and, in a more generic way, localization of effects of changes in the PE configuration. >> >> In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect only = the PE where this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a = more >> complex model. Wether outside s-tag is used to differentiate, or >> dedicated pw's are used for the same purpose, it seems both become = more >> complex. >> >> Gile's comparison slide still concisely captures the differences = between >> these methods, in my opinion. I haven't seen any new ideas or = thoughts >> brought to the group in the past week or two on the subject. I would hate >> for both proposed methods to die on the vine because we couldn't = decide >> between two methods that have nothing inherently wrong with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" wrote: >> >>>Send this again. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree = uses >>>P2P PW fo=20 ------=_NextPart_000_000D_01CD20D0.90A018B0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Raymond,

 <= /span>

Network = efficiency:

[Sam] Leaf/Root configuration is local configuration, and PE can not know remote AC type configuration. This is CW Fundamentals. So even if CW approach defines = optional enhancement for Leaf-Only PE, but can not signal it between Leaf-Only = PEs, so there is no good way to support this. The possible solution is, manually = configure hub-spoke topology, but if we do like this, current solutions have = support most E-Tree cases with Hub-Spoke configuration. Lizhong mentioned this in one = mail.

 <= /span>

Backwards = compatibility:

[Sam] Yes, new = draft considers backward compatibility, but it makes precondition: The PE = which can not support Control word only works as Root-only PE. This does not make = sense for me. If it only supports VPLS, ok, it can work as Root-only, but why it = can not work as Root-Leaf-Mixed or Leaf-only if it can not support = CW?

 <= /span>

Regards,

 

=

Yuqun (Sam) Cao

E-mail: Yuqun.cao@gmail.com

 

From: raymond.key@hotmail.com [mailto:raymond.key@hotmail.com] On Behalf Of Raymond Key
Sent: Saturday, April 21, = 2012 11:32 PM
To: = yuqun.cao@gmail.com
Cc: l2vpn@ietf.org
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Some clarifications [RK] inserted = below

Thanks

Raymond Key

From: yuqun.cao@gmail.com
To: lizho.jin@gmail.com; wim.henderickx@alcatel-lucent.com
Subject: RE: The status of the approaches to the E-Tree solution?
Date: Sat, 21 Apr 2012 22:51:28 +0800
CC: l2vpn@ietf.org

Hi all,

 

We reach an = impasseJ.  BTW, Meeting minutes is ready now. We can get E-tree summary from = IETF site.

 

Today I collected all items = we discussed before. They are,

 

1)       Silicon issue or chip limit;

2)       Network efficiency;

3)       Encapsulation mode, tag or = raw;

4)       H-VPLS;

5)       Backwards compatibility, especially legacy PE = or Non-supporting PE with IEEE E-tree support joins E-Tree = domain;

6)       Configuration change in operation, for example, Leaf-only -> Root-Leaf-Mixed;

7)       S-VLAN preservation support;

8)       Multi-segment PW;

9)       VLAN ID allocation (Only for = Dual-VLAN);

10)   Multi-AS deployment;

11)   ECMP;

12)   P2MP-PW;

13)   Ethernet OAM;

 

If we review the mail-list, CW approach has the following limits:

1)       Chip limit. = Please read reply from Giles and Wim;

2)       Network = efficiency: There are garbage fames which will be dropped on egress PE since only egress = PE can decide forward or drop frames while it receives frames. Ingress PE can not decide forward or not. Yes, current solution can support = Hub-Spoke configuration, but as we know, the configuration is not easy if the = network is big. Dual-VLAN or Multi-PW approach can break communication between = Leaf-Only PEs via signaling.

[RK] It seems to me this is not the case. = Section 6 of the draft has some discussions on this.
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-6=
6. Optional Enhancements for Leaf-only PE
6.1. No PW between Leaf-only PEs
6.2. Not Forward Frame from Leaf AC to Leaf-only PE

 

3)       Backwards = compatibility: Not all PEs supports control word. If one can not support control word, = it will not join E-Tree domain;

 

[RK] It seems to = me this is not the case. Section 5 of the draft has some discussions on = this.
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-5=
5. Backward Compatibility
5.1. AC Type
5.2. Control Word
5.3. Additional Action in Data Forwarding
5.3.1. Ingress PE Supporting the Extension but Egress PE Not
5.3.2. Egress PE Supporting the Extension but Ingress PE Not

 

Dual VLAN has = following limits:

1)       Chip limit: As we = know, we need to push one VLAN into frames before MPLS encapsulation on ingress = PE and stripe it out on egress PE. This is non-standard operation. Wait for confirmation from chip vendor;

2)       HVPLS: If we = follow Fig 3 or Fig 4 in RFC = 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type = in VPWS case, but can NOT configure it at all in Spoke PW = case;

3)       Multi-PW: Rafi = figures this out, but we don=A1=AFt think this over at that time. I think that = it also has same problem as H-VPLS has.

4)       Encapsulation = mode: If deploy GVPLS with Spoke PW mode, PE-rs should work in tagged mode, = otherwise PE-rs or egress PE will stripe S-VLAN ID;

5)       Backward = Compatibility: Just as Daniel mentioned, there is compatibility issue if legacy PE = joins E-Tree domain. For me, I don=A1=AFt get clear response from co-authors = of Dual-VLAN.

 

For all = approaches, we don=A1=AFt cover ECMP / Ethernet OAM till now.

 

Is there anything = missed?

 

Regards,

 

Yuqun = (Sam) Cao

E-mail: = Yuqun.cao@gmail.com =

 

From: Lizhong Jin [mailto:lizho.jin@gmail.com]
Sent: Saturday, April 21, = 2012 11:59 AM
To: Henderickx, Wim = (Wim)
Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; yuqun.cao@gmail.com
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Hi Win,
Thank you for the answers. In that case, PE-rs should configure the = root/leaf properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, = you could not figure out the accessing spoke PW is from PE-r of VPWS or = MTU-s. Unless having some additional indication in NMS, you even don't know = which spoke PW needs to do VLAN manipulation. I am not sure such R/L = configuration could be accepted from operational view. Hope to see more comments.

Regards
Lizhong


=D4=DA 2012=C4=EA4=D4=C221=C8=D5=D0=C7=C6=DA=C1=F9=A3=ACHenderickx, Wim (Wim) <wim.henderickx@alcatel-= lucent.com> =D0=B4=B5=C0=A3=BA
> The VPWS which terminates at the H-VPLS node is indicated to be = root or leaf and the procedures associated will do the VLAN manipulation
>
>  
>
> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin
> Sent: vrijdag 20 april 2012 18:38
> To: l2vpn@ietf.org; Alexander.Vainshtein@eci= tele.com
> Cc: yuqun.cao@gmail.com
> Subject: RE: The status of the approaches to the E-Tree = solution?
>
>  
>
> Hi, all,
> The difference between 2-VLAN and CW approach is who will provide = the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW = will carry R/L information for CW approach.
> I have a question with the 2-VLAN approach in H-VPLS where H-VPLS = is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds = VLAN to indicate R/L information?
>
> Thanks
> Lizhong
>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 19 Apr 2012 04:38:36 +0000
>> From: Alexander Vainshtein <Alexander.Vainshtein@eci= tele.com>
>> To: "Rogers, Josh" <josh.rogers@twcable.com>, = Lucy yong
>>        <lucy.yong@huawei.com>, Daniel Cohn <DanielC@orckit.com>, Sam Cao
>>        <yuqun.cao@gmail.com>
>> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
>> Subject: RE: The status of the approaches to the E-Tree = solution?
>> Message-ID:
>>        <F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>
>> Content-Type: text/plain; charset=3D"us-ascii"
>>
>> Hi all,
>> I fully understand that that what I am going to say is not very popular, but:
>>
>> IMO one of the advantages of the CW-based solution is that it = is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic.
>>
>> Another advantage is preservation of full mesh of P2P PWs in a = VPLS, and, in a more generic way, localization of effects of changes in the PE configuration.
>>
>> In particular, adding a Leaf AC to a PE that previously has = been only supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect only the = PE where this operation happens and not the rest of the PEs.
>>
>> As for the need for HW changes that have been mentioned as a = main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution.
>>
>> My 2c,
>>     Sasha
>>
>>
>>
>> ________________________________________
>> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] = on behalf of Rogers, Josh [josh.rogers@twcable.com]
>> Sent: Wednesday, April 18, 2012 9:57 PM
>> To: Lucy yong; Daniel Cohn; Sam Cao
>> Cc: l2vpn@ietf.org
>> Subject: Re: The status of the approaches to the E-Tree = solution?
>>
>> Again, the P2MP situation throws me.  Is this something = that is used
>> commonly?
>>
>> I'm under the impression that adding P2MP to any model results = in a more
>> complex model.  Wether outside s-tag is used to = differentiate, or
>> dedicated pw's are used for the same purpose, it seems both = become more
>> complex.
>>
>> Gile's comparison slide still concisely captures the = differences between
>> these methods, in my opinion.  I haven't seen any new = ideas or thoughts
>> brought to the group in the past week or two on the subject. =  I would hate
>> for both proposed methods to die on the vine because we = couldn't decide
>> between two methods that have nothing inherently wrong with = either.
>>
>> -Josh
>>
>>
>> On 4/18/12 1:53 PM, "Lucy yong" <lucy.yong@huawei.com> = wrote:
>>
>>>Send this again.
>>>
>>>Two PW approach can be complex too if the VPLS instance for = E-Tree uses
>>>P2P PW fo

------=_NextPart_000_000D_01CD20D0.90A018B0-- From Alexander.Vainshtein@ecitele.com Sun Apr 22 06:56:07 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBCE21F856F for ; Sun, 22 Apr 2012 06:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.773 X-Spam-Level: X-Spam-Status: No, score=-2.773 tagged_above=-999 required=5 tests=[AWL=-0.572, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, 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 nxIGUXzMazrE for ; Sun, 22 Apr 2012 06:56:05 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.98]) by ietfa.amsl.com (Postfix) with ESMTP id 89F5321F84F0 for ; Sun, 22 Apr 2012 06:56:04 -0700 (PDT) Received: from [193.109.254.147:7835] by server-10.bemta-14.messagelabs.com id B2/37-05847-3FD049F4; Sun, 22 Apr 2012 13:56:03 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1335102962!5743290!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.7; banners=-,-,- Received: (qmail 18473 invoked from network); 22 Apr 2012 13:56:02 -0000 Received: from unknown (HELO fridlpvsb003.ecitele.com) (168.87.1.157) by server-14.tower-27.messagelabs.com with SMTP; 22 Apr 2012 13:56:02 -0000 X-AuditID: a8571403-b7f566d0000048f9-44-4f940deb8505 Received: from FRGRWPVCH001.ecitele.com (frgrwpvch001.ecitele.com [10.1.18.35]) by fridlpvsb003.ecitele.com (Symantec Messaging Gateway) with SMTP id E5.68.18681.BED049F4; Sun, 22 Apr 2012 15:55:55 +0200 (CEST) Received: from FRIDWPPMB002.ecitele.com ([169.254.4.167]) by FRGRWPVCH001.ecitele.com ([10.1.18.35]) with mapi id 14.01.0339.001; Sun, 22 Apr 2012 15:56:01 +0200 From: Alexander Vainshtein To: Sam Cao Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNHxPnvCW4Idac1kehO7tUxP5nzJaj1eOAgACwqQCAALY7AIAAC0AAgAFzRgCAACHU8A== Date: Sun, 22 Apr 2012 13:56:00 +0000 Message-ID: References: , <14C7F4F06DB5814AB0DE29716C4F6D6701296244C3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>, , <1B88357C808B432E871CA9D678305B7C@v2comsam> <6F9ADEDA06A04AB98C247D303AFE93BE@v2comsam> In-Reply-To: <6F9ADEDA06A04AB98C247D303AFE93BE@v2comsam> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA02034D1CFRIDWPPMB002ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTfUgTYRz23c3tnF5c09zrknFdBanN5kexoJkJkRGxsC+KQM/tdbu63dZu idYfrTRRozQNSiP6WqF9WUJgIoQLKs1QMsqiFqiBH1FRURRm3e3UhOj+eu73PL/nfX7v/Q7H tOVqPc7yPuTlGY5WaZQaEKE3jhMnraZA/VLz0Leg2nz82w2l+WzZE1U2lnu38Y06911tpyI3 EPih2ITt9INVDM+7fYwPUXYk2Cz0Ji9bzNhKaYq1W+g0mvJwjA25EO+z0IzHg3g7naWh/nlW iTKWpxBvc9tZ3mGh12+2Gs3m5SuNaXTWFicrUMjoYliOciFBYByIEitSbt5ecBNz3ml6rPIM VGAlEy3flX7QOaCoBlE4JDPhj+FqpYzjYV+oRSVhLfkMwAt96dVAI+LLAHafawcSoSItsPXa m7AojlwAQ10htYQxcgP037iJSTiWXAOPjVQDWZMDR19dwmS8DfZ87g/3KsnFsOpihajBcYLc CJuHiuWzJhSwa/BD2DOKNMOe9tZwUCCG+959XSGfpYOvhs9NDUDCQEcvJuN5cHRoMlLGBni4 +dlUNjcMNtwJ5yHIubCrYXhq4ATY2TSgrAXxjbNsG2e1NM5qkevLYMeJ7imcAq9cGMdknApD bb8iZ9fPA/VVAIu8rJ3zFAuFJlNGKrKxPsShVJvb1QrEVWraHoe1ga81qUFA4oCOIUYz663a SKZYKHUFQQKuoOcRBs1Jq3ZOodte6mQEZ753H4eEIIA4RscRX+JEOWFnSvcjr3uaWite7glM H21zSx/fl59hMv3/hdYRLXlZVi3pENdzD0Ie5J32ScRxGhK7xUXXzvUiByopYjnfX1qBR0kx YsQYPklDCB7GJbAOme8GCXodYZAIUiKc+/iZ3jGgE4eNJbZKbIy4ojNdY6KhQjQs2FUnGYq/ zAyl94NYa9uZct3PxC2fPp7+OWmIJudnLVx3YHBxRK7B9falUdVVpwswZYk1oQfJwea2pPsd JqpqOO/liqT+1YcO9q/c0zv2lHu9w+1IquMquVrk9I+8yD7L713S++j07x0pLfcqmx9t2Jlz 9EisTbv/Yf3z99kL0k/FL6IjGpJu30qvy7tEKwUnk5aMeQXmD4UhkzkXBAAA Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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: Sun, 22 Apr 2012 13:56:07 -0000 --_000_F9336571731ADE42A5397FC831CEAA02034D1CFRIDWPPMB002ecite_ Content-Type: text/plain; charset="iso-2022-jp" content-transfer-encoding: quoted-printable Sam, You=1B$B!G=1B(Bve asked: If it only supports VPLS, ok, it can work as Root-only, but why it cannot wo= rk as Root-Leaf-Mixed or Leaf-only if it cannot support CW? IMHO and FWIW there is not too much you can expect from a true legacy PE (i.= e. a PE that did not change its forwarding behavior): 1. It can obviously support Root-only functionality 2. It can support Leaf-only functionality if there are no Mixed by pre= venting setup PW (by not setting up PWs to other Leaf-only PEs). Anything beyond that would be very much implementation-specific. E.g., I am= aware of legacy implementations that could support functionality of a Mixed= PE provided that it would be the only Mixed PE in the VPLS instance, and ot= her legacy implementations that are, as legacy, fully interoperable with the= se ones but could not support such functionality. My 2c, Sasha From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Sa= m Cao Sent: Sunday, April 22, 2012 4:41 PM To: 'Raymond Key' Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Raymond, Network efficiency: [Sam] Leaf/Root configuration is local configuration, and PE can not know re= mote AC type configuration. This is CW Fundamentals. So even if CW approach= defines optional enhancement for Leaf-Only PE, but can not signal it betwee= n Leaf-Only PEs, so there is no good way to support this. The possible solut= ion is, manually configure hub-spoke topology, but if we do like this, curre= nt solutions have support most E-Tree cases with Hub-Spoke configuration. Li= zhong mentioned this in one mail. Backwards compatibility: [Sam] Yes, new draft considers backward compatibility, but it makes precondi= tion: The PE which can not support Control word only works as Root-only PE.= This does not make sense for me. If it only supports VPLS, ok, it can work= as Root-only, but why it can not work as Root-Leaf-Mixed or Leaf-only if it= can not support CW? Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com ________________________________ From: raymond.key@hotmail.com [mailto:raymond.key@hotmail.com] On Behalf Of= Raymond Key Sent: Saturday, April 21, 2012 11:32 PM To: yuqun.cao@gmail.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Some clarifications [RK] inserted below Thanks Raymond Key ________________________________ From: yuqun.cao@gmail.com To: lizho.jin@gmail.com; wim.henderickx@alcatel-lucent.com Subject: RE: The status of the approaches to the E-Tree solution? Date: Sat, 21 Apr 2012 22:51:28 +0800 CC: l2vpn@ietf.org Hi all, We reach an impasse:). BTW, Meeting minutes is ready now. We can get E-tree= summary from IETF site. Today I collected all items we discussed before. They are, 1) Silicon issue or chip limit; 2) Network efficiency; 3) Encapsulation mode, tag or raw; 4) H-VPLS; 5) Backwards compatibility, especially legacy PE or Non-supporting PE= with IEEE E-tree support joins E-Tree domain; 6) Configuration change in operation, for example, Leaf-only -> Root-L= eaf-Mixed; 7) S-VLAN preservation support; 8) Multi-segment PW; 9) VLAN ID allocation (Only for Dual-VLAN); 10) Multi-AS deployment; 11) ECMP; 12) P2MP-PW; 13) Ethernet OAM; If we review the mail-list, CW approach has the following limits: 1) Chip limit. Please read reply from Giles and Wim; 2) Network efficiency: There are garbage fames which will be dropped o= n egress PE since only egress PE can decide forward or drop frames while it= receives frames. Ingress PE can not decide forward or not. Yes, current sol= ution can support Hub-Spoke configuration, but as we know, the configuration= is not easy if the network is big. Dual-VLAN or Multi-PW approach can break= communication between Leaf-Only PEs via signaling. [RK] It seems to me this is not the case. Section 6 of the draft has some di= scussions on this. http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-6 6. Optional Enhancements for Leaf-only PE 6.1. No PW between Leaf-only PEs 6.2. Not Forward Frame from Leaf AC to Leaf-only PE 3) Backwards compatibility: Not all PEs supports control word. If one= can not support control word, it will not join E-Tree domain; [RK] It seems to me this is not the case. Section 5 of the draft has some di= scussions on this. http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-5 5. Backward Compatibility 5.1. AC Type 5.2. Control Word 5.3. Additional Action in Data Forwarding 5.3.1. Ingress PE Supporting the Extension but Egress PE Not 5.3.2. Egress PE Supporting the Extension but Ingress PE Not Dual VLAN has following limits: 1) Chip limit: As we know, we need to push one VLAN into frames before= MPLS encapsulation on ingress PE and stripe it out on egress PE. This is no= n-standard operation. Wait for confirmation from chip vendor; 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-= rs works in different manner, PE-rs should figure out AC type in VPWS case,= but can NOT configure it at all in Spoke PW case; 3) Multi-PW: Rafi figures this out, but we don=1B$B!G=1B(Bt think this= over at that time. I think that it also has same problem as H-VPLS has. 4) Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs shoul= d work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN ID; 5) Backward Compatibility: Just as Daniel mentioned, there is compatib= ility issue if legacy PE joins E-Tree domain. For me, I don=1B$B!G=1B(Bt get= clear response from co-authors of Dual-VLAN. For all approaches, we don=1B$B!G=1B(Bt cover ECMP / Ethernet OAM till now. Is there anything missed? Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com ________________________________ From: Lizhong Jin [mailto:lizho.jin@gmail.com] Sent: Saturday, April 21, 2012 11:59 AM To: Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi Win, Thank you for the answers. In that case, PE-rs should configure the root/lea= f properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, yo= u could not figure out the accessing spoke PW is from PE-r of VPWS or MTU-s.= Unless having some additional indication in NMS, you even don't know which= spoke PW needs to do VLAN manipulation. I am not sure such R/L configuratio= n could be accepted from operational view. Hope to see more comments. Regards Lizhong =1B$B:_=1B(B 2012=1B$BG/=1B(B4=1B$B7n=1B(B21=1B$BF|@14|O;!$=1B(BHenderickx,= Wim (Wim) > =1B$B The VPWS which terminates at the H-VPLS node is indicated to be root or le= af and the procedures associated will do the VLAN manipulation > > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-= bounces@ietf.org] On Behalf Of Lizhong Jin > Sent: vrijdag 20 april 2012 18:38 > To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.co= m > Cc: yuqun.cao@gmail.com > Subject: RE: The status of the approaches to the E-Tree solution? > > > > Hi, all, > The difference between 2-VLAN and CW approach is who will provide the R/L= information, customer payload or PW? The customer payload will be always mo= dified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach. > I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is acces= sed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informatio= n? > > Thanks > Lizhong > >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 Apr 2012 04:38:36 +0000 >> From: Alexander Vainshtein > >> To: "Rogers, Josh" >, Lucy yong >> >, Daniel Cohn <= DanielC@orckit.com>, Sam Cao >> > >> Cc: "l2vpn@ietf.org" > >> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID: >> > >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi all, >> I fully understand that that what I am going to say is not very popular,= but: >> >> IMO one of the advantages of the CW-based solution is that it is orthogon= al to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic= . >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, and,= in a more generic way, localization of effects of changes in the PE configu= ration. >> >> In particular, adding a Leaf AC to a PE that previously has been only sup= porting Root ACs (or vice versa), removal of the last Leaf or last Root AC f= rom a PE that previously has been supporting a mix etc. affect only the PE w= here this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main disadva= ntage of the CW-based approach - I believe it strongly depends on specific i= mplementations. And some changes in the forwarding process are required in a= ny solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounce= s@ietf.org] on behalf of Rogers, Josh [josh.r= ogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a more >> complex model. Wether outside s-tag is used to differentiate, or >> dedicated pw's are used for the same purpose, it seems both become more >> complex. >> >> Gile's comparison slide still concisely captures the differences between >> these methods, in my opinion. I haven't seen any new ideas or thoughts >> brought to the group in the past week or two on the subject. I would hat= e >> for both proposed methods to die on the vine because we couldn't decide >> between two methods that have nothing inherently wrong with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" > wrote: >> >>>Send this again. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>P2P PW fo This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA02034D1CFRIDWPPMB002ecite_ Content-Type: text/html; charset="iso-2022-jp" content-transfer-encoding: quoted-printable

Sam,

You=1B$B!G=1B(Bve asked:

If it only supports VPLS, ok, it can work as Root-only, but why it cann= ot work as Root-Leaf-Mixed or Leaf-only if it cannot support CW?

IMHO and FWIW there is not= too much you can expect from a true legacy PE (i.e. a PE that did not chang= e its forwarding behavior):

1. &n= bsp;     It can obviously support Root-only functionality

2. &n= bsp;     It can support Leaf-only functionality if there are no Mixed by preven= ting setup PW (by not setting up PWs to other Leaf-only PEs).

Anything beyond that would= be very much implementation-specific. E.g., I am aware of legacy implementa= tions that could support functionality of a Mixed PE provided that it would be the only Mixed PE in the VPLS instance, and other legacy i= mplementations that are, as legacy, fully interoperable with these ones but= could not support such functionality.

 

= My 2c,

=      Sasha

 

From: l2vpn-bounc= es@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Sam Cao
Sent: Sunday, April 22, 2012 4:41 PM
To: 'Raymond Key'
Cc: l2vpn@ietf.org
Subject: RE: The status of the approaches to the E-Tree solution?

 

Raymond,

 

Network efficiency:

[Sam] Leaf/Root configuration is= local configuration, and PE can not know remote AC type configuration. This= is CW Fundamentals. So even if CW approach defines optional enhancement for Leaf-Only PE, but can not signal it between Leaf-Only PEs,= so there is no good way to support this. The possible solution is, manually= configure hub-spoke topology, but if we do like this, current solutions hav= e support most E-Tree cases with Hub-Spoke configuration. Lizhong mentioned this in one mail.

 

Backwards compatibility:

[Sam] Yes, new draft considers ba= ckward compatibility, but it makes precondition: The PE which can not suppor= t Control word only works as Root-only PE. This does not make sense for me. If it only supports VPLS, ok, it can work as Root-on= ly, but why it can not work as Root-Leaf-Mixed or Leaf-only if it can not su= pport CW?

 

Regards,<= /span>

 

Yuqun (Sa= m) Cao

E-mail: <= a href=3D"mailto:Yuqun.cao@gmail.com"> Yuqun.cao@gmail.com =

 

From: raymond.key= @hotmail.com [mailto:raymond.key@hotmail.com] On Behalf Of Raymond Key
Sent: Saturday, April 21, 2012 11:32 PM
To: yuqun.cao@gmail.com
Cc: l2vpn@ietf.org
Subject: RE: The status of the approaches to the E-Tree solution?

 

Some clarifications [RK] inserted below

Thanks

Raymond Key

From: yuqun.cao@gmail.= com
To: lizho.jin@gmail.com; wim.henderickx@alcatel-lucent.com
Subject: RE: The status of the approaches to the E-Tree solution?
Date: Sat, 21 Apr 2012 22:51:28 +0800
CC: l2vpn@ietf.org

Hi all,

 

We reach an impasseJ.  BTW, Meeting= minutes is ready now. We can get E-tree summary from IETF site.

 

Today I collected all items we discussed= before. They are,

 

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">1)       Silicon issue or chip limit;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">2)       Network efficiency;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">3)       Encapsulation mode, tag or raw;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">4)       H-VPLS;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">5)       Backwards compatibility, especially legacy PE or Non-support= ing PE with IEEE E-tree support joins E-Tree domain;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">6)       Configuration change in operation, for example, Leaf-only -&= gt; Root-Leaf-Mixed;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">7)       S-VLAN preservation support;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">8)       Multi-segment PW;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">9)       VLAN ID allocation (Only for Dual-VLAN);

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">10)   Multi-AS deployment;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">11)   ECMP;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">12)   P2MP-PW;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">13)   Ethernet OAM;

 

If we review the mail-list, CW= approach has the following limits:

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= ";color:navy">1)    = ;   Chip limit. Please read reply from Giles and Wim;=

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= ";color:navy">2)    = ;   Network efficiency: There are garbage fames which= will be dropped on egress PE since only egress PE can decide forward or dro= p frames while it receives frames. Ingress PE can not decide forward or not. Yes, current solution can support Hub-Spoke configur= ation, but as we know, the configuration is not easy if the network is big.= Dual-VLAN or Multi-PW approach can break communication between Leaf-Only PE= s via signaling.

<= span style=3D"font-family:"Arial","sans-serif";color:nav= y">[RK] It seems to me this is not the case. Section 6 of the draft has some= discussions on this.
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-6 6. Optional Enhancements for Leaf-only PE
6.1. No PW between Leaf-only PEs
6.2. Not Forward Frame from Leaf AC to Leaf-only PE

&= nbsp;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= ";color:navy">3)    = ;   Backwards compatibility: Not all PEs supports con= trol word. If one can not support control word, it will not join E-Tree doma= in;

 

[RK] It seems to me this is not the case. Sect= ion 5 of the draft has some discussions on this.
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-5 5. Backward Compatibility
5.1. AC Type
5.2. Control Word
5.3. Additional Action in Data Forwarding
5.3.1. Ingress PE Supporting the Extension but Egress PE Not
5.3.2. Egress PE Supporting the Extension but Ingress PE Not

 

Dual VLAN has following limits= :

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= ";color:navy">1)    = ;   Chip limit: As we know, we need to push one VLAN= into frames before MPLS encapsulation on ingress PE and stripe it out on eg= ress PE. This is non-standard operation. Wait for confirmation from chip vendor;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= ";color:navy">2)    = ;   HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to= deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC t= ype in VPWS case, but can NOT configure it at all in Spoke PW case;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= ";color:navy">3)    = ;   Multi-PW: Rafi figures this out, but we don=1B$B!= G=1B(Bt think this over at that time. I think that it also has same problem= as H-VPLS has.

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= ";color:navy">4)    = ;   Encapsulation mode: If deploy GVPLS with Spoke PW= mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will s= tripe S-VLAN ID;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= ";color:navy">5)    = ;   Backward Compatibility: Just as Daniel mentioned,= there is compatibility issue if legacy PE joins E-Tree domain. For me, I do= n=1B$B!G=1B(Bt get clear response from co-authors of Dual-VLAN.<= /o:p>

 

For all approaches, we don=1B$= B!G=1B(Bt cover ECMP / Ethernet OAM till now.

 

Is there anything missed?

 

Regards,

&nbs= p;

Yuqun (Sam) Cao

E-mail: Yuqun.cao@gmail.com <= /o:p>

&nbs= p;

From: Lizhong= Jin [mailto:lizho.jin@gmail.com]
Sent: Saturday, April 21, 2012 11:59 AM
To: Henderickx, Wim (Wim)
Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; yuqun.cao@gmail= .com
Subject: RE: The status of the approaches to the E-Tree solution?

 

Hi Win,
Thank you for the answers. In that case, PE-rs should configure the root/lea= f properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, yo= u could not figure out the accessing spoke PW is from PE-r of VPWS or MTU-s.= Unless having some additional indication in NMS, you even don't know which spoke PW needs to do VLAN mani= pulation. I am not sure such R/L configuration could be accepted from operat= ional view. Hope to see more comments.

Regards
Lizhong


=1B$B:_=1B(B 2012=1B$BG/=1B(B<= /span>4=1B$B7n=1B(B21=1B$BF|@14|O;!$=1B(BHenderickx, Wim (Wim) <wim.hend= erickx@alcatel-lucent.com> =1B$B
> The VPWS which terminates at the H-VPLS node is indicated to be root or= leaf and the procedures associated will do the VLAN manipulation
>
>  
>
> From: l2vpn-bounces@ietf.org<= /a> [mailto:l2vpn-bounces@ietf.org= ] On Behalf Of Lizhong Jin
> Sent: vrijdag 20 april 2012 18:38
> To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com
> Cc: yuqun.cao@gmail.com
> Subject: RE: The status of the approaches to the E-Tree solution?
>
>  
>
> Hi, all,
> The difference between 2-VLAN and CW approach is who will provide the R= /L information, customer payload or PW? The customer payload will be always= modified to carry R/L information in 2-VLAN approach, while PW with CW will= carry R/L information for CW approach.
> I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is ac= cessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to ac= cess H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informa= tion?
>
> Thanks
> Lizhong
>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 19 Apr 2012 04:38:36 +0000
>> From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
>> To: "Rogers, Josh" <josh.rogers@twcable.com>, Lucy yong
>>        <lucy.yong@huawei.com>, Daniel Cohn <DanielC@orckit.com>, Sam Cao
>>        <yuqun.cao@gmail.com>
>> Cc: "l2vpn@ietf.org"= ; <l2vpn@ietf.org>
>> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID:
>>        <F9336571731ADE42A5397FC831CEA= A02034192@FRIDWPPMB002.ecitele.com>
>> Content-Type: text/plain; charset=3D"us-ascii"
>>
>> Hi all,
>> I fully understand that that what I am going to say is not very pop= ular, but:
>>
>> IMO one of the advantages of the CW-based solution is that it is or= thogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN t= raffic.
>>
>> Another advantage is preservation of full mesh of P2P PWs in a VPLS= , and, in a more generic way, localization of effects of changes in the PE c= onfiguration.
>>
>> In particular, adding a Leaf AC to a PE that previously has been on= ly supporting Root ACs (or vice versa), removal of the last Leaf or last Roo= t AC from a PE that previously has been supporting a mix etc. affect only th= e PE where this operation happens and not the rest of the PEs.
>>
>> As for the need for HW changes that have been mentioned as a main d= isadvantage of the CW-based approach - I believe it strongly depends on spec= ific implementations. And some changes in the forwarding process are require= d in any solution.
>>
>> My 2c,
>>     Sasha
>>
>>
>>
>> ________________________________________
>> From: l2vpn-bounces@ietf.= org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [jos= h.rogers@twcable.com]
>> Sent: Wednesday, April 18, 2012 9:57 PM
>> To: Lucy yong; Daniel Cohn; Sam Cao
>> Cc: l2vpn@ietf.org
>> Subject: Re: The status of the approaches to the E-Tree solution? >>
>> Again, the P2MP situation throws me.  Is this something that i= s used
>> commonly?
>>
>> I'm under the impression that adding P2MP to any model results in a= more
>> complex model.  Wether outside s-tag is used to differentiate,= or
>> dedicated pw's are used for the same purpose, it seems both become= more
>> complex.
>>
>> Gile's comparison slide still concisely captures the differences be= tween
>> these methods, in my opinion.  I haven't seen any new ideas or= thoughts
>> brought to the group in the past week or two on the subject.  = I would hate
>> for both proposed methods to die on the vine because we couldn't de= cide
>> between two methods that have nothing inherently wrong with either.=
>>
>> -Josh
>>
>>
>> On 4/18/12 1:53 PM, "Lucy yong" <lucy.yong@huawei.com> wrote:
>>
>>>Send this again.
>>>
>>>Two PW approach can be complex too if the VPLS instance for E-Tr= ee uses
>>>P2P PW fo

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA02034D1CFRIDWPPMB002ecite_-- From yuqun.cao@gmail.com Sun Apr 22 07:04:00 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7708821F85DD for ; Sun, 22 Apr 2012 07:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, J_CHICKENPOX_31=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 Rz8Vp6xr9y7r for ; Sun, 22 Apr 2012 07:03:56 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD2D21F85D7 for ; Sun, 22 Apr 2012 07:03:56 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so2873077pbb.31 for ; Sun, 22 Apr 2012 07:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :in-reply-to:x-mimeole; bh=vvHru8OPATmk8lL+G6DKe6FlAPSIsGaxqjfr5hBKX8I=; b=0MiqbVNTN/e5iGRsk9uD3NILx74eASVhjdxZou+yp5DiOXf7FwNqiGSGdq01dMrN0b oMFXJ/kOTtM6nqSwEn4oCKKO6pDVTA1rZomuhrt+b3eu0c5ltqFNBx2JDQRlw/SsQWON 6xud/cPKvGBuUectb9sdeySwA07eLjh2cvGolMHsROAfSAkatJFrs7xvyD+isvtgT7Sc RbtZIh3fafNVmVSCxdOpT1YFZVL1XQjvD8GwodYJwdyVUx6cwTgWeczdPQSAHBsOmCIv 0ECe0SWCg3N+nK/3im8qKcHIgm16cz6mTpcLpRS9T+ezF4wrstMo13vMpmdKnuWMeSW4 h2kA== Received: by 10.68.216.10 with SMTP id om10mr1659869pbc.29.1335103433160; Sun, 22 Apr 2012 07:03:53 -0700 (PDT) Received: from v2comsam ([36.248.16.95]) by mx.google.com with ESMTPS id k9sm11471183pbf.65.2012.04.22.07.03.49 (version=SSLv3 cipher=OTHER); Sun, 22 Apr 2012 07:03:52 -0700 (PDT) From: "Sam Cao" To: "'Jiangyuanlong'" References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E7DD@SZXEML508-MBS.china.huawei.com> Subject: RE: The status of the approaches to the E-Tree solution? Date: Sun, 22 Apr 2012 22:03:52 +0800 Message-ID: <962A848896EF4678B17D76C826A7EAEF@v2comsam> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AQHNIGxIkTBdljOSQkeqvNTqsF/qWZam20qA In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E7DD@SZXEML508-MBS.china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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: Sun, 22 Apr 2012 14:04:01 -0000 Yuanlong, I just collect all issues we discussed before, and we still can not make agreement. I gave my comments on 2 items below. I will think other items over and give my comments tomorrow. 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, but can NOT configure it at all in Spoke PW case; [JY] In the first place, why PE-rs need to figure out the AC type for a spoke? The VLAN should be processed in the MTU, not in the PE-rs. [Sam] Yuanlong, I understand your idea. It does NOT make sense for me. First, Fig. 3 and Fig 4 in RFC 4762 are different cases. For VPWS (Fig. 3), we can take VPWS PW as one AC. You know, PE-rs is termination of VPWS, so it will add VLAN-ID to identify Root/Leaf. BTW, you will map several VLAN IDs into one Root-VLAN ID or Leaf-VLAN ID on PE-rs, so we need to configure Root/Leaf on PE-rs (Refer to your reply to Josh's comments). 4) Encapsulation mode: If deploy HVPLS with Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN ID; [JY] Is anything not working with tagged PW mode? [Sam] Tagged mode works. Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Sunday, April 22, 2012 5:43 PM To: Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Sam, Please see my comments in line with [JY]. Regards, Yuanlong ---------------------------------------------------------------------- Message: 1 Date: Sat, 21 Apr 2012 22:51:28 +0800 From: "Sam Cao" To: "'Lizhong Jin'" , "'Henderickx, Wim \(Wim\)'" Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <1B88357C808B432E871CA9D678305B7C@v2comsam> Content-Type: text/plain; charset="gb2312" Hi all, We reach an impasse:-). BTW, Meeting minutes is ready now. We can get E-tree summary from IETF site. Today I collected all items we discussed before. They are, 1) Silicon issue or chip limit; 2) Network efficiency; 3) Encapsulation mode, tag or raw; 4) H-VPLS; 5) Backwards compatibility, especially legacy PE or Non-supporting PE with IEEE E-tree support joins E-Tree domain; 6) Configuration change in operation, for example, Leaf-only -> Root-Leaf-Mixed; 7) S-VLAN preservation support; 8) Multi-segment PW; 9) VLAN ID allocation (Only for Dual-VLAN); 10) Multi-AS deployment; 11) ECMP; 12) P2MP-PW; 13) Ethernet OAM; If we review the mail-list, CW approach has the following limits: 1) Chip limit. Please read reply from Giles and Wim; 2) Network efficiency: There are garbage fames which will be dropped on egress PE since only egress PE can decide forward or drop frames while it receives frames. Ingress PE can not decide forward or not. Yes, current solution can support Hub-Spoke configuration, but as we know, the configuration is not easy if the network is big. Dual-VLAN or Multi-PW approach can break communication between Leaf-Only PEs via signaling. 3) Backwards compatibility: Not all PEs supports control word. If one can not support control word, it will not join E-Tree domain; Dual VLAN has following limits: 1) Chip limit: As we know, we need to push one VLAN into frames before MPLS encapsulation on ingress PE and stripe it out on egress PE. This is non-standard operation. Wait for confirmation from chip vendor; [JY] Do you really consider tagged PW as non-standard? 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, but can NOT configure it at all in Spoke PW case; [JY] In the first place, why PE-rs need to figure out the AC type for a spoke? The VLAN should be processed in the MTU, not in the PE-rs. 3) Multi-PW: Rafi figures this out, but we don?t think this over at that time. I think that it also has same problem as H-VPLS has. [JY] The same as above, only T-PE will deal with VLAN, S-PE only switches PW label, so I can't see what is the problem. 4) Encapsulation mode: If deploy HVPLS with Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN ID; [JY] Is anything not working with tagged PW mode? 5) Backward Compatibility: Just as Daniel mentioned, there is compatibility issue if legacy PE joins E-Tree domain. For me, I don?t get clear response from co-authors of Dual-VLAN. [JY] Could you elaborate a little more what is the compatibility issue? For all approaches, we don?t cover ECMP / Ethernet OAM till now. Is there anything missed? Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com _____ From: Lizhong Jin [mailto:lizho.jin@gmail.com] Sent: Saturday, April 21, 2012 11:59 AM To: Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi Win, Thank you for the answers. In that case, PE-rs should configure the root/leaf properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, you could not figure out the accessing spoke PW is from PE-r of VPWS or MTU-s. Unless having some additional indication in NMS, you even don't know which spoke PW needs to do VLAN manipulation. I am not sure such R/L configuration could be accepted from operational view. Hope to see more comments. Regards Lizhong ? 2012?4?21?????Henderickx, Wim (Wim) ??? > The VPWS which terminates at the H-VPLS node is indicated to be root or leaf and the procedures associated will do the VLAN manipulation > > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin > Sent: vrijdag 20 april 2012 18:38 > To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com > Cc: yuqun.cao@gmail.com > Subject: RE: The status of the approaches to the E-Tree solution? > > > > Hi, all, > The difference between 2-VLAN and CW approach is who will provide the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW will carry R/L information for CW approach. > I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information? > > Thanks > Lizhong > >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 Apr 2012 04:38:36 +0000 >> From: Alexander Vainshtein >> To: "Rogers, Josh" , Lucy yong >> , Daniel Cohn , Sam Cao >> >> Cc: "l2vpn@ietf.org" >> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID: >> >> Content-Type: text/plain; charset="us-ascii" >> >> Hi all, >> I fully understand that that what I am going to say is not very popular, but: >> >> IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes in the PE configuration. >> >> In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root AC from a PE that previously has been supporting a mix etc. affect only the PE where this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a more >> complex model. Wether outside s-tag is used to differentiate, or >> dedicated pw's are used for the same purpose, it seems both become more >> complex. >> >> Gile's comparison slide still concisely captures the differences between >> these methods, in my opinion. I haven't seen any new ideas or thoughts >> brought to the group in the past week or two on the subject. I would hate >> for both proposed methods to die on the vine because we couldn't decide >> between two methods that have nothing inherently wrong with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" wrote: >> >>>Send this again. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>P2P PW fo -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 48 ************************************* From yuqun.cao@gmail.com Sun Apr 22 07:06:04 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCA721F8547 for ; Sun, 22 Apr 2012 07:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.696, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UtUCDYdvJ8A for ; Sun, 22 Apr 2012 07:05:55 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D07CD21F853C for ; Sun, 22 Apr 2012 07:05:54 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so2874391pbb.31 for ; Sun, 22 Apr 2012 07:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:in-reply-to:x-mimeole; bh=tHwbHmC7suSbveTigOG479FC6KJqW0FTPMfbdecCDNQ=; b=RsFUEIbhoiL4G1jyJQGL9+lrTV+zcTGVm2QPg7YCEhG04sO0rP3kctvf49T8B7oPC4 UrGLhGUdWGA9yqQzWqbeuyiUgCjnmPBN+PY7O7HxVriQgaILbP+/lXwPBZUa+fKbxLBe HV+2NHGJMfQkqdNTDDJUn2m8rRm+ujYUrZW+UaYijhuKyQTMVUbEDZUW7yqJ+sWMAiUH UPRDmxYzuTk0Mkie5eXN4M0DO3SXk85RKSstBYnM0TzisMp6yqsiVXue4BJPUm9rq3Zn h05t5xvWSuheCzSmF1UukjW0p0KKu1u6d4GD7EENZ0MI01IEZ7r9ygIhtGiXWdAZ9wDt DJhg== Received: by 10.68.233.199 with SMTP id ty7mr1583972pbc.77.1335103554425; Sun, 22 Apr 2012 07:05:54 -0700 (PDT) Received: from v2comsam ([36.248.16.95]) by mx.google.com with ESMTPS id h3sm11471532pbn.71.2012.04.22.07.05.46 (version=SSLv3 cipher=OTHER); Sun, 22 Apr 2012 07:05:53 -0700 (PDT) From: "Sam Cao" To: "'Daniel Cohn'" , "'Rogers, Josh'" , "'Shahram Davari'" , "'Lizhong Jin'" , , References: <4A6CE49E6084B141B15C0713B8993F28021737@SJEXCHMB12.corp.ad.broadcom.com> <44F4E579A764584EA9BDFD07D0CA08130777C3C1@tlvmail1> Subject: RE: The status of the approaches to the E-Tree solution? Date: Sun, 22 Apr 2012 22:05:49 +0800 Message-ID: <68707FAC89BE467680C89EB7025ACEFE@v2comsam> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01CD20D4.182388F0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac0fJQNW6V0LmvcLTaO7yAMdZqeRCQBXtrWAAANCouA= In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130777C3C1@tlvmail1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: l2vpn@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: Sun, 22 Apr 2012 14:06:04 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0017_01CD20D4.182388F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I agree. Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com _____ From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Sunday, April 22, 2012 8:34 PM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume that the VLAN tags at the E-NNI will always be according to the current MEF model? Or should we try to be as transparent as possible to user VLAN encapsulation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case VLAN tag) to signal VPLS information (in this case root/leaf origin) is necessarily tied to specific assumptions on user payload encapsulation (in this case, that S-VLAN tag is "available" to encode root/leaf). I don't think this is a future-proof assumption, it's very likely that other network models will come up that require S-VLAN preservation, which in the 2-VLAN approach would necessitate adding a third VLAN-ID. Daniel From: Shahram Davari To: Lizhong Jin , "l2vpn@ietf.org" , "Alexander.Vainshtein@ecitele.com" Cc: "yuqun.cao@gmail.com" Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW will carry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > To: "Rogers, Josh" , Lucy yong > , Daniel Cohn , Sam Cao > > Cc: "l2vpn@ietf.org" > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, but: > > IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes in the PE configuration. > > In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root AC from a PE that previously has been supporting a mix etc. affect only the PE where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a more > complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become more > complex. > > Gile's comparison slide still concisely captures the differences between > these methods, in my opinion. I haven't seen any new ideas or thoughts > brought to the group in the past week or two on the subject. I would hate > for both proposed methods to die on the vine because we couldn't decide > between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may double >>all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the processing >>in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >>traffic coming from a root AC) >>[[LY]] Not that simple. You construct either two P2MP PWs to all other >>PEs and let egress PE performing filtering, or construct one P2MP PW to >>leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >>perform forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so don't >>feel terribly strong about this objection. Is this a real problem for >>others (now or in the future), or is this objection in the weeds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. I >>encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>>giles.heron@gmail.com; simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs after >>>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>>P2MP >>>PWs if need. There is no difference between P2MP or normal PW setup. But, >>>can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>>both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong [mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, both >>>approaches can benefit from it. I was off for a while and captures some >>>discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues with >>>silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>>not clear on all the issues. Could you be more specific? As I mentioned >>>in below, two PW approach makes VPLS transport construction and packet >>>forwarding more complex, I can see potential backward compatibility >>>issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>>traffic, and some P2MP PWs for multicast traffic. It may double all of >>>them. >>> >>>E-tree is an Ethernet service and there is already VLAN based solution >>>in IEEE, can we just utilize it without complicating VPLS transport >>>construction? This also makes interworking with Eth only network easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are you >>>saying that you no longer are interested in that method in preference of >>>the dual vlan method? >>> >>> >>> >>>Lucy yong wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron [mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord ; Alexander Vainshtein >>> >>>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>>; Andrew Sergeev >>>; Idan Kaspit ; >>>Mishael Wexler ; Rotem Cohen >>> >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly have >>>put in a third column on the CW approach. And hopefully the minutes >>>will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to be >>>forming around the two alternatives of two PWEs or two VLANs. I believe >>>three of the authors of the CW approach are also authors of the two VLAN >>>approach and one is also an author of the two PWE approach. So perhaps >>>it's best to let those four individuals say which approach they prefer >>>and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of various >>>> solution drafts off the mailing list. As far as I know, no consensus >>>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>>> think the CW approach has not been rejected by the WG yet, or the WG >>>> has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree approaches >>>>> based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>>> ext=1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>>> clude_te >>>>> xt=1) >>>>> and completely ignores the solution based on usage of the CW in the >>>>> PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>>> ext=1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>>> wonder whether the WG has taken a decision to reject the approach >>>>> based on the CW usage? I do not remember any recent discussion of >>>>> this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and contains >>>>> information which is CONFIDENTIAL and which may be proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original and >>>>> all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action taken >>>in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use of the individual or entity to which it is addressed. If you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** ------=_NextPart_000_0017_01CD20D4.182388F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree. =

 <= /span>

Regards,

 

=

Yuqun (Sam) = Cao

E-mail: Yuqun.cao@gmail.com =

 

From: Daniel Cohn [mailto:DanielC@orckit.com]
Sent: Sunday, April 22, = 2012 8:34 PM
To: Rogers, Josh; Shahram = Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com
Cc: = yuqun.cao@gmail.com
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Shahram and = all,

 <= /o:p>

This = question already came up in our discussions - is it safe to assume that the VLAN = tags at the E-NNI will always be according to the current MEF model? Or should = we try to be as transparent as possible to user VLAN encapsulation at the = E-NNI, to accommodate future frameworks?

I believe = that any approach that looks at user payload (in this case VLAN tag) to signal = VPLS information (in this case root/leaf origin) is necessarily tied to = specific assumptions on user payload encapsulation (in this case, that S-VLAN tag = is “available” to encode root/leaf). I don’t think this = is a future-proof assumption, it’s very likely that other network = models will come up that require S-VLAN preservation, which in the 2-VLAN approach = would necessitate adding a third VLAN-ID.

 <= /o:p>

Daniel

 

From: Shahram = Davari <davari@broadcom.com>
To: Lizhong Jin <lizho.jin@gmail.com>, = "l2vpn@ietf.org" <l2vpn@ietf.org>, "Alexander.Vainshtein@eci= tele.com" <Alexander.Vainshtein@eci= tele.com>
Cc: "yuqun.cao@gmail.com" <yuqun.cao@gmail.com>
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Hi,

 

I also have = a question regarding 2-VLAN. What if the customer traffic already has an = S-VLAN? Do we need a 3rd VLAN to identify the L/R?

 

Thx

Shahram

 

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]= On Behalf Of Lizhong Jin
Sent: Friday, April 20, = 2012 9:38 AM
To: l2vpn@ietf.org; Alexander.Vainshtein@eci= tele.com
Cc: yuqun.cao@gmail.com
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Hi, all,
The difference between 2-VLAN and CW approach is who will provide the = R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW = will carry R/L information for CW approach.
I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is = accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds = VLAN to indicate R/L information?

Thanks
Lizhong

> ------------------------------
>
> Message: 2
> Date: Thu, 19 Apr 2012 04:38:36 +0000
> From: Alexander Vainshtein <Alexander.Vainshtein@eci= tele.com>
> To: "Rogers, Josh" <josh.rogers@twcable.com>, Lucy yong
>        <lucy.yong@huawei.com>, Daniel Cohn <DanielC@orckit.com>, Sam Cao
>        <yuqun.cao@gmail.com>
> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
> Subject: RE: The status of the approaches to the E-Tree = solution?
> Message-ID:
>        <F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> Hi all,
> I fully understand that that what I am going to say is not very = popular, but:
>
> IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic.
>
> Another advantage is preservation of full mesh of P2P PWs in a = VPLS, and, in a more generic way, localization of effects of changes in the PE configuration.
>
> In particular, adding a Leaf AC to a PE that previously has been = only supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect only the = PE where this operation happens and not the rest of the PEs.
>
> As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution.
>
> My 2c,
>     Sasha
>
>
>
> ________________________________________
> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on = behalf of Rogers, Josh [josh.rogers@twcable.com]
> Sent: Wednesday, April 18, 2012 9:57 PM
> To: Lucy yong; Daniel Cohn; Sam Cao
> Cc: l2vpn@ietf.org
> Subject: Re: The status of the approaches to the E-Tree = solution?
>
> Again, the P2MP situation throws me.  Is this something that = is used
> commonly?
>
> I'm under the impression that adding P2MP to any model results in a = more
> complex model.  Wether outside s-tag is used to differentiate, = or
> dedicated pw's are used for the same purpose, it seems both become = more
> complex.
>
> Gile's comparison slide still concisely captures the differences = between
> these methods, in my opinion.  I haven't seen any new ideas or thoughts
> brought to the group in the past week or two on the subject. =  I would hate
> for both proposed methods to die on the vine because we couldn't = decide
> between two methods that have nothing inherently wrong with = either.
>
> -Josh
>
>
> On 4/18/12 1:53 PM, "Lucy yong" <lucy.yong@huawei.com> = wrote:
>
>>Send this again.
>>
>>Two PW approach can be complex too if the VPLS instance for = E-Tree uses
>>P2P PW for unicast traffic and P2MP PW for broadcast and = unknown
>>unicast traffic, and some P2MP PWs for multicast traffic. It may = double
>>all of them.
>>
>>Lucy
>>
>>-----Original Message-----
>>From: Daniel Cohn [mailto:DanielC@orckit.com]
>>Sent: Wednesday, April 18, 2012 1:42 PM
>>To: Lucy yong; Rogers, Josh; Sam Cao
>>Cc: l2vpn@ietf.org
>>Subject: RE: The status of the approaches to the E-Tree = solution?
>>
>>I think the first option its the natural way to go. How is the processing
>>in this case more complex?
>>
>>Thumb typed - please be tolerant
>>
>>Lucy yong <lucy.yong@huawei.com> wrote:
>>
>>
>>
>>Snipped..
>>
>>Multi-PW - On ingress PE, frame is placed onto either a = Leaf-only P2MP PW
>>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW = (for
>>traffic coming from a root AC)
>>[[LY]] Not that simple. You construct either two P2MP PWs to all = other
>>PEs and let egress PE performing filtering, or construct one = P2MP PW to
>>leaf-only PEs and two P2MP PWs to root and leaf PEs and let = ingress PE
>>perform forwarding and filtering. Both make node process = complex.
>>
>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP = PW for
>>delivering the frames to remote PEs. We should utilize them with = the
>>minimized changes. Dual VLAN solution is simpler than Dual = PW.
>>
>>Regards,
>>Lucy
>>
>>
>>I see how 2VLAN is simpler when P2MP PW's are involved, I think.  I
>>haven't had any first hand experience with P2MP PW's, however, = so don't
>>feel terribly strong about this objection.  Is this a real = problem for
>>others (now or in the future), or is this objection in the = weeds?
>>
>>I'm not sure the 'additional complexity' is notable, or even = relevant.  I
>>encourage others to speak up if they disagree, as P2MP PW is = only
>>conceptual to me, and I am unfamiliar with real-life use cases = for it.
>>
>>Thanks,
>>Josh
>>
>>
>>
>>On 4/18/12 10:30 AM, "Lucy yong" <lucy.yong@huawei.com> = wrote:
>>
>>>Please see inline.
>>>
>>>-----Original Message-----
>>>From: Sam Cao [mailto:yuqun.cao@gmail.com]
>>>Sent: Tuesday, April 17, 2012 7:14 AM
>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, = Wim (Wim)';
>>>giles.heron@gmail.com; simon.delord@gmail.com;
>>>Alexander.Vainshtein@eci= tele.com
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com= ;
>>>Andrew.Sergeev@ecitele.com= ; Idan.Kaspit@ecitele.com;
>>>Mishael.Wexler@ecitele.com= ; Rotem.Cohen@ecitele.com
>>>Subject: RE: The status of the approaches to the E-Tree = solution?
>>>
>>>Yes, 2 pws are only needed between pes with both root and = leaf acs after
>>>improving Dual-PW approach. If consider P2MP, Dual-PW = approach setup 2
>>>P2MP
>>>PWs if need. There is no difference between P2MP or normal = PW setup. But,
>>>can Leaf-ACs be bound to Root PE of P2MP PW?
>>>
>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a = PE with both
>>>root and leaf ACs set up two or one P2MP PW to other PEs = (some PE have
>>>both root and leaf AC and some only have leaf ACs)?
>>>Regards,
>>>Lucy
>>>
>>>Regards,
>>>
>>>Yuqun (Sam) Cao
>>>E-mail: Yuqun.cao@gmail.com
>>>
>>>
>>>-----Original Message-----
>>>From: Daniel Cohn [mailto:DanielC@orckit.com]
>>>Sent: Tuesday, April 17, 2012 4:56 PM
>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim);
>>>giles.heron@gmail.com;
>>>simon.delord@gmail.com; Alexander.Vainshtein@eci= tele.com; Sam Cao
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com= ;
>>>Andrew.Sergeev@ecitele.com= ; Idan.Kaspit@ecitele.com;
>>>Mishael.Wexler@ecitele.com= ; Rotem.Cohen@ecitele.com
>>>Subject: RE: The status of the approaches to the E-Tree = solution?
>>>
>>>Adding Sam (as l2vpn@ is holding messages)
>>>
>>>DC
>>>
>>>-----Original Message-----
>>>From: Lucy yong [mailto:lucy.yong@huawei.com]
>>>Sent: Tuesday, April 17, 2012 12:39 AM
>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim);
>>>giles.heron@gmail.com; simon.delord@gmail.com;
>>>Alexander.Vainshtein@eci= tele.com
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com= ;
>>>Andrew.Sergeev@ecitele.com= ; Idan.Kaspit@ecitele.com;
>>>Mishael.Wexler@ecitele.com= ; Rotem.Cohen@ecitele.com
>>>Subject: RE: The status of the approaches to the E-Tree = solution?
>>>
>>>
>>>Snipped,
>>>
>>>As we discussed extensively in the list, and as reflected in = giles
>>>slide, 2 pws are only needed between pes with both root and = leaf acs,
>>>which will typically be a small minority.
>>>[[LY]] Don't know if the assumption is true. Even it is the = case, both
>>>approaches can benefit from it. I was off for a while and = captures some
>>>discussions now.
>>>
>>>Also as per giles slide, dual vlan can have scalability = issues due to
>>>additional lookup and double use of vlans in internal = emulated lan
>>>interface. Also there are potential backward compatibility = issues with
>>>silicon that doesn't support vlan mapping.
>>>[[LY]] I was not in IETF83 meeting and wait on the meeting = minutes. I am
>>>not clear on all the issues. Could you be more specific? As = I mentioned
>>>in below, two PW approach makes VPLS transport construction = and packet
>>>forwarding more complex, I can see potential backward = compatibility
>>>issues with 2 PW solution.
>>>
>>>Regards,
>>>Lucy
>>>
>>>Regards,
>>>
>>>Daniel
>>>
>>>Thumb typed - please be tolerant
>>>
>>>Lucy yong <lucy.yong@huawei.com> wrote:
>>>
>>>In my mind, the VLAN approach means dual vlan method.
>>>
>>>The main concern for CW approach is hardware support.
>>>
>>>Two PW approach can be complex too if the VPLS instance for = E-Tree uses
>>>P2P PW for unicast traffic and P2MP PW for broadcast and = unknown unicast
>>>traffic, and some P2MP PWs for multicast traffic. It may = double all of
>>>them.
>>>
>>>E-tree is an Ethernet service and there is already VLAN = based solution
>>>in IEEE, can we just utilize it without complicating VPLS = transport
>>>construction? This also makes interworking with Eth only = network easier.
>>>
>>>Cheers,
>>>Lucy
>>>
>>>-----Original Message-----
>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com]
>>>Sent: Monday, April 16, 2012 8:35 AM
>>>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com';
>>>'simon.delord@gmail.com'; 'Alexander.Vainshtein@eci= tele.com'
>>>Cc: 'l2vpn@ietf.org'; = 'Vladimir.Kleiner@ecitele.com= ';
>>>'Andrew.Sergeev@ecitele.com= '; 'Idan.Kaspit@ecitele.com';
= >>>'Mishael.Wexler@ecitele.com= '; 'Rotem.Cohen@ecitele.com'
>>>Subject: RE: The status of the approaches to the E-Tree = solution?
>>>
>>>I believe the initial question was in regard to the CW = method.  Are you
>>>saying that you no longer are interested in that method in preference of
>>>the dual vlan method?
>>>
>>>
>>>
>>>Lucy yong <lucy.yong@huawei.com> wrote:
>>>
>>>
>>>Agree with Wim. VLAN approach is the best solution for = E-Tree.
>>>
>>>Lucy
>>>
>>>-----Original Message-----
>>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf
>>>Of Henderickx, Wim (Wim)
>>>Sent: Thursday, April 12, 2012 2:03 AM
>>>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com';
>>>'Alexander.Vainshtein@eci= tele.com'
>>>Cc: 'l2vpn@ietf.org'; = 'Vladimir.Kleiner@ecitele.com= ';
>>>'Andrew.Sergeev@ecitele.com= '; 'Idan.Kaspit@ecitele.com';
= >>>'Mishael.Wexler@ecitele.com= '; 'Rotem.Cohen@ecitele.com'
>>>Subject: Re: The status of the approaches to the E-Tree = solution?
>>>
>>>The vlan approach is superior as it also works for eth only networks,
>>>etc. On top some vendors indicate hw issues with the cw = approach. As
>>>such we have dropped more or less the cw approach.
>>>
>>>Cheers,
>>>Wim
>>>_________________
>>>sent from blackberry
>>>
>>>----- Original Message -----
>>>From: Giles Heron [mailto:giles.heron@gmail.com]
>>>Sent: Thursday, April 12, 2012 08:22 AM
>>>To: Simon Delord <simon.delord@gmail.com>; Alexander Vainshtein
>>><Alexander.Vainshtein@eci= tele.com>
>>>Cc: l2vpn@ietf.org = <l2vpn@ietf.org>; Vladimir = Kleiner
>>><Vladimir.Kleiner@ecitele.com= >; Andrew Sergeev
>>><Andrew.Sergeev@ecitele.com= >; Idan Kaspit <Idan.Kaspit@ecitele.com>;<= br> >>>Mishael Wexler <Mishael.Wexler@ecitele.com= >; Rotem Cohen
>>><Rotem.Cohen@ecitele.com> >>>Subject: Re: The status of the approaches to the E-Tree = solution?
>>>
>>>Sorry - the "anonymous presentation" was mine. =  I should possibly have
>>>put in a third column on the CW approach.  And = hopefully the minutes
>>>will be posted soon.
>>>
>>>We had various discussions, as Simon stated, and consensus = seemed to be
>>>forming around the two alternatives of two PWEs or two = VLANs.  I believe
>>>three of the authors of the CW approach are also authors of = the two VLAN
>>>approach and one is also an author of the two PWE approach. = So perhaps
>>>it's best to let those four individuals say which approach = they prefer
>>>and why?
>>>
>>>Giles
>>>
>>>On 10/04/2012 00:45, "Simon Delord" <simon.delord@gmail.com> = wrote:
>>>
>>>> Hi Alexander,
>>>>
>>>> You are right, no discussion on the WG mailing list = recently, but
>>>> there have been substantial discussions among the = authors of various
>>>> solution drafts off the mailing list. As far as I know, = no consensus
>>>> yet before ietf83, not sure the progress in the Paris = WG meeting. I
>>>> think the CW approach has not been rejected by the WG = yet, or the WG
>>>> has not yet decided on which one to adopt.
>>>>
>>>> Simon
>>>>
>>>> 2012/4/8 Alexander = Vainshtein <Alexander.Vainshtein@eci= tele.com>
>>>>
>>>>>  Hi all,
>>>>>
>>>>> Unfortunately I have not been able to attend the = Paris IETF.
>>>>>
>>>>> However, looking up the L2VPN proceedings, I've = found a short
>>>>> anonymous presentation called "E-Tree = Update"  (
>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the = E-Tree approaches
>>>>> based on dedicated VLANs (as in
>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include= _t
>>>>> ext=3D1) and multiple PWs between the PEs (as = in
>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?= in
>>>>> clude_te
>>>>> xt=3D1)
>>>>> and completely ignores the solution based on usage = of the CW in the
>>>>> PWs connecting the PEs (as in
>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include= _t
>>>>> ext=3D1
>>>>> ).
>>>>>
>>>>>
>>>>>
>>>>> The Minutes of the Paris L2VPN session are not yet available, but I
>>>>> wonder whether the WG has taken a decision to = reject the approach
>>>>> based on the CW usage? I do not remember any recent discussion of
>>>>> this topic on the WG mailing list.
>>>>>
>>>>>
>>>>>
>>>>> Regards, and lots of thanks in advance,
>>>>>
>>>>> Sasha
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This e-mail message is intended for the recipient = only and contains
>>>>> information which is CONFIDENTIAL and which may be proprietary to ECI
>>>
>>>>> Telecom. If you have received this transmission in = error, please
>>>>> inform us by e-mail, phone or fax, and then delete = the original and
>>>>> all copies thereof.
>>>>>
>>>
>>>
>>>
>>>
>>>
>>>This E-mail and any of its attachments may contain Time = Warner Cable
>>>proprietary information, which is privileged, confidential, = or subject
>>>to copyright belonging to Time Warner Cable. This E-mail is intended
>>>solely for the use of the individual or entity to which it = is addressed.
>>>If you are not the intended recipient of this E-mail, you = are hereby
>>>notified that any dissemination, distribution, copying, or = action taken
>>>in relation to the contents of and attachments to this = E-mail is
>>>strictly prohibited and may be unlawful. If you have = received this
>>>E-mail in error, please notify the sender immediately and permanently
>>>delete the original and any copy of this E-mail and any = printout.
>>>
>>
>>
>>This E-mail and any of its attachments may contain Time Warner = Cable
>>proprietary information, which is privileged, confidential, or = subject to
>>copyright belonging to Time Warner Cable. This E-mail is = intended solely
>>for the use of the individual or entity to which it is = addressed. If you
>>are not the intended recipient of this E-mail, you are hereby = notified
>>that any dissemination, distribution, copying, or action taken = in
>>relation to the contents of and attachments to this E-mail is = strictly
>>prohibited and may be unlawful. If you have received this E-mail = in
>>error, please notify the sender immediately and permanently = delete the
>>original and any copy of this E-mail and any printout.
>
>
> This E-mail and any of its attachments may contain Time Warner = Cable proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended solely = for the use of the individual or entity to which it is addressed. If you are = not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and = may be unlawful. If you have received this E-mail in error, please notify the = sender immediately and permanently delete the original and any copy of this = E-mail and any printout.
> This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform us by = e-mail, phone or fax, and then delete the original and all copies thereof.
>
>
>
> ------------------------------
>
> _______________________________________________
> L2vpn mailing list
> L2vpn@ietf.org
> https://www.ietf.org= /mailman/listinfo/l2vpn
>
>
> End of L2vpn Digest, Vol 95, Issue 25
> ***********************************

------=_NextPart_000_0017_01CD20D4.182388F0-- From yuqun.cao@gmail.com Sun Apr 22 07:22:32 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C349B21F8585 for ; Sun, 22 Apr 2012 07:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.034, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 pdescU-ijivL for ; Sun, 22 Apr 2012 07:22:30 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1A78C21F84D1 for ; Sun, 22 Apr 2012 07:22:30 -0700 (PDT) Received: by dady13 with SMTP id y13so20078858dad.27 for ; Sun, 22 Apr 2012 07:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:in-reply-to:x-mimeole; bh=KjvKQy4LjhkMEm/13kecLta/4wwJwqIRUcMf+rFVKOM=; b=sv/0HjI9c5OU4z9nsHG9hn8NSNZtNVMPGrHtKH6uV/HP4leZ3CxZsl8WoQgjIr8S6i 6jAjwFDbkuyvS8AjTohglIWUQFyfQvsKA/giFV/ISoBi+pRrZ2lCnzK3kZFB8modP/jJ YMsA08PCtww1v+8dN2Mc4PVl4A14vCv/owkjlOvyR2I0LDTkyaTwMt3jYNHC7g7DH/2a hv+KqyXK4qHYaUdf9E5h0Wv3hoIUzU3XhsyX33J//dsE0X3I9HAsTh55XhUjxU+PnLaR D7vhmhA/Y4c2JRDtnrKfw8HMzGrnNgkrRtG4nAJq2tI6p4Sjl8QJ8zV3JclNhjlIkVzv g9lA== Received: by 10.68.216.10 with SMTP id om10mr1783551pbc.29.1335104549484; Sun, 22 Apr 2012 07:22:29 -0700 (PDT) Received: from v2comsam ([36.248.16.95]) by mx.google.com with ESMTPS id k9sm11509386pbf.65.2012.04.22.07.22.22 (version=SSLv3 cipher=OTHER); Sun, 22 Apr 2012 07:22:28 -0700 (PDT) From: "Sam Cao" To: "'Alexander Vainshtein'" References: , <14C7F4F06DB5814AB0DE29716C4F6D6701296244C3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>, , <1B88357C808B432E871CA9D678305B7C@v2comsam> <6F9ADEDA06A04AB98C247D303AFE93BE@v2comsam> Subject: RE: The status of the approaches to the E-Tree solution? Date: Sun, 22 Apr 2012 22:22:26 +0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01CD20D6.69320B70" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AQHNHxPnvCW4Idac1kehO7tUxP5nzJaj1eOAgACwqQCAALY7AIAAC0AAgAFzRgCAACHU8IAACSVg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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: Sun, 22 Apr 2012 14:22:33 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0021_01CD20D6.69320B70 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Sasha, =20 I agree with your comments. But maybe I don=A1=AFt make myself = understood. I make it clear. =20 If one chip can not support control word, then one switch which uses = this chip can not work as Root-Leaf-Mixed PE since we can not extend it. Is = this correct? Is this reasonable? =20 Anyway, chip limit is big problem for CW approach. =20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 _____ =20 From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Sunday, April 22, 2012 9:56 PM To: Sam Cao Cc: l2vpn@ietf.org; 'Raymond Key' Subject: RE: The status of the approaches to the E-Tree solution? =20 Sam, You=A1=AFve asked: If it only supports VPLS, ok, it can work as Root-only, but why it = cannot work as Root-Leaf-Mixed or Leaf-only if it cannot support CW? IMHO and FWIW there is not too much you can expect from a true legacy PE = (i. e. a PE that did not change its forwarding behavior): 1. It can obviously support Root-only functionality 2. It can support Leaf-only functionality if there are no Mixed by preventing setup PW (by not setting up PWs to other Leaf-only PEs). Anything beyond that would be very much implementation-specific. E.g., I = am aware of legacy implementations that could support functionality of a = Mixed PE provided that it would be the only Mixed PE in the VPLS instance, and other legacy implementations that are, as legacy, fully interoperable = with these ones but could not support such functionality. =20 My 2c, Sasha =20 From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Sam Cao Sent: Sunday, April 22, 2012 4:41 PM To: 'Raymond Key' Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? =20 Raymond, =20 Network efficiency: [Sam] Leaf/Root configuration is local configuration, and PE can not = know remote AC type configuration. This is CW Fundamentals. So even if CW approach defines optional enhancement for Leaf-Only PE, but can not = signal it between Leaf-Only PEs, so there is no good way to support this. The possible solution is, manually configure hub-spoke topology, but if we = do like this, current solutions have support most E-Tree cases with = Hub-Spoke configuration. Lizhong mentioned this in one mail. =20 Backwards compatibility: [Sam] Yes, new draft considers backward compatibility, but it makes precondition: The PE which can not support Control word only works as Root-only PE. This does not make sense for me. If it only supports VPLS, = ok, it can work as Root-only, but why it can not work as Root-Leaf-Mixed or Leaf-only if it can not support CW? =20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 _____ =20 From: raymond.key@hotmail.com [mailto:raymond.key@hotmail.com] On Behalf = Of Raymond Key Sent: Saturday, April 21, 2012 11:32 PM To: yuqun.cao@gmail.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? =20 Some clarifications [RK] inserted below Thanks Raymond Key _____ =20 From: yuqun.cao@gmail.com To: lizho.jin@gmail.com; wim.henderickx@alcatel-lucent.com Subject: RE: The status of the approaches to the E-Tree solution? Date: Sat, 21 Apr 2012 22:51:28 +0800 CC: l2vpn@ietf.org Hi all, =20 We reach an impasse:-). BTW, Meeting minutes is ready now. We can get E-tree summary from IETF site. =20 Today I collected all items we discussed before. They are, =20 1) Silicon issue or chip limit; 2) Network efficiency; 3) Encapsulation mode, tag or raw; 4) H-VPLS; 5) Backwards compatibility, especially legacy PE or Non-supporting = PE with IEEE E-tree support joins E-Tree domain; 6) Configuration change in operation, for example, Leaf-only -> Root-Leaf-Mixed; 7) S-VLAN preservation support; 8) Multi-segment PW; 9) VLAN ID allocation (Only for Dual-VLAN); 10) Multi-AS deployment; 11) ECMP; 12) P2MP-PW; 13) Ethernet OAM; =20 If we review the mail-list, CW approach has the following limits: 1) Chip limit. Please read reply from Giles and Wim; 2) Network efficiency: There are garbage fames which will be = dropped on egress PE since only egress PE can decide forward or drop frames = while it receives frames. Ingress PE can not decide forward or not. Yes, current solution can support Hub-Spoke configuration, but as we know, the configuration is not easy if the network is big. Dual-VLAN or Multi-PW approach can break communication between Leaf-Only PEs via signaling. [RK] It seems to me this is not the case. Section 6 of the draft has = some discussions on this. http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-6 6. Optional Enhancements for Leaf-only PE 6.1. No PW between Leaf-only PEs 6.2. Not Forward Frame from Leaf AC to Leaf-only PE =20 3) Backwards compatibility: Not all PEs supports control word. If = one can not support control word, it will not join E-Tree domain; =20 [RK] It seems to me this is not the case. Section 5 of the draft has = some discussions on this. http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-5 5. Backward Compatibility 5.1. AC Type 5.2. Control Word 5.3. Additional Action in Data Forwarding 5.3.1. Ingress PE Supporting the Extension but Egress PE Not 5.3.2. Egress PE Supporting the Extension but Ingress PE Not =20 Dual VLAN has following limits: 1) Chip limit: As we know, we need to push one VLAN into frames = before MPLS encapsulation on ingress PE and stripe it out on egress PE. This is non-standard operation. Wait for confirmation from chip vendor; 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, but can NOT configure it at all in Spoke PW case; 3) Multi-PW: Rafi figures this out, but we don=A1=AFt think this = over at that time. I think that it also has same problem as H-VPLS has. 4) Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will stripe = S-VLAN ID; 5) Backward Compatibility: Just as Daniel mentioned, there is compatibility issue if legacy PE joins E-Tree domain. For me, I = don=A1=AFt get clear response from co-authors of Dual-VLAN. =20 For all approaches, we don=A1=AFt cover ECMP / Ethernet OAM till now.=20 =20 Is there anything missed?=20 =20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 _____ =20 From: Lizhong Jin [mailto:lizho.jin@gmail.com]=20 Sent: Saturday, April 21, 2012 11:59 AM To: Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; = yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? =20 Hi Win, Thank you for the answers. In that case, PE-rs should configure the root/leaf properties of VPWS, not on the remote PE of VPWS. And usually = on PE-rs, you could not figure out the accessing spoke PW is from PE-r of = VPWS or MTU-s. Unless having some additional indication in NMS, you even = don't know which spoke PW needs to do VLAN manipulation. I am not sure such = R/L configuration could be accepted from operational view. Hope to see more comments. Regards Lizhong =D4=DA 2012=C4=EA4=D4=C221=C8=D5=D0=C7=C6=DA=C1=F9=A3=ACHenderickx, Wim = (Wim) =D0=B4=B5=C0=A3=BA > The VPWS which terminates at the H-VPLS node is indicated to be root = or leaf and the procedures associated will do the VLAN manipulation > > =20 > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Lizhong Jin > Sent: vrijdag 20 april 2012 18:38 > To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com > Cc: yuqun.cao@gmail.com > Subject: RE: The status of the approaches to the E-Tree solution? > > =20 > > Hi, all, > The difference between 2-VLAN and CW approach is who will provide the = R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW = will carry R/L information for CW approach. > I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used = to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information? > > Thanks > Lizhong > >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 Apr 2012 04:38:36 +0000 >> From: Alexander Vainshtein >> To: "Rogers, Josh" , Lucy yong >> , Daniel Cohn , Sam = Cao >> >> Cc: "l2vpn@ietf.org" >> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID: >> = >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi all, >> I fully understand that that what I am going to say is not very = popular, but: >> >> IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, = and, in a more generic way, localization of effects of changes in the PE configuration. >> >> In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect only = the PE where this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a = more >> complex model. Wether outside s-tag is used to differentiate, or >> dedicated pw's are used for the same purpose, it seems both become = more >> complex. >> >> Gile's comparison slide still concisely captures the differences = between >> these methods, in my opinion. I haven't seen any new ideas or = thoughts >> brought to the group in the past week or two on the subject. I would hate >> for both proposed methods to die on the vine because we couldn't = decide >> between two methods that have nothing inherently wrong with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" wrote: >> >>>Send this again. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree = uses >>>P2P PW fo=20 This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies thereof.=20 ------=_NextPart_000_0021_01CD20D6.69320B70 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Sasha,<= /span>

 <= /span>

I agree with your = comments. But maybe I don=A1=AFt make myself understood. I make it = clear.

 <= /span>

If one chip can = not support control word, then one switch which uses this chip can not work = as Root-Leaf-Mixed PE since we can not extend it. Is this correct? Is this reasonable?

 <= /span>

Anyway, chip = limit is big problem for CW approach.

 <= /span>

Regards,

 

=

Yuqun (Sam) Cao

E-mail: Yuqun.cao@gmail.com

 

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Sunday, April 22, = 2012 9:56 PM
To: Sam Cao
Cc: l2vpn@ietf.org; = 'Raymond Key'
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Sam,

You=A1=AFve = asked:

If it only supports VPLS, ok, it can = work as Root-only, but why it cannot work as Root-Leaf-Mixed or Leaf-only if it = cannot support CW?

IMHO and = FWIW there is not too much you can expect from a true legacy PE (i.e. a PE that did = not change its forwarding behavior):

1.       It can obviously support Root-only = functionality

2.       It can support Leaf-only functionality if there are no = Mixed by preventing setup PW (by not setting up PWs to other Leaf-only = PEs).

Anything = beyond that would be very much implementation-specific. E.g., I am aware of legacy implementations that could support functionality of a Mixed PE provided = that it would be the only Mixed PE in the VPLS instance, and other = legacy implementations that are, as legacy, fully interoperable with these ones = but could not support such functionality.

 <= /o:p>

My = 2c,

  =    Sasha

 <= /o:p>

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Sam Cao
Sent: Sunday, April 22, = 2012 4:41 PM
To: 'Raymond Key'
Cc: l2vpn@ietf.org
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Raymond,

 <= /span>

Network = efficiency:

[Sam] Leaf/Root configuration is local configuration, and PE can not know remote AC type configuration. This is CW Fundamentals. So even if CW approach defines = optional enhancement for Leaf-Only PE, but can not signal it between Leaf-Only = PEs, so there is no good way to support this. The possible solution is, manually configure hub-spoke topology, but if we do like this, current solutions = have support most E-Tree cases with Hub-Spoke configuration. Lizhong = mentioned this in one mail.

 <= /span>

Backwards = compatibility:

[Sam] Yes, new = draft considers backward compatibility, but it makes precondition: The PE = which can not support Control word only works as Root-only PE. This does not make = sense for me. If it only supports VPLS, ok, it can work as Root-only, but why = it can not work as Root-Leaf-Mixed or Leaf-only if it can not support = CW?

 <= /span>

Regards,

 

=

Yuqun (Sam) Cao

E-mail: Yuqun.cao@gmail.com

 

From: raymond.key@hotmail.com [mailto:raymond.key@hotmail.com] On Behalf Of Raymond Key
Sent: Saturday, April 21, = 2012 11:32 PM
To: = yuqun.cao@gmail.com
Cc: l2vpn@ietf.org
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Some clarifications [RK] inserted = below

Thanks

Raymond Key

From: yuqun.cao@gmail.com
To: lizho.jin@gmail.com; wim.henderickx@alcatel-lucent.com
Subject: RE: The status of the approaches to the E-Tree solution?
Date: Sat, 21 Apr 2012 22:51:28 +0800
CC: l2vpn@ietf.org

Hi all,

 

We reach an = impasseJ.  BTW, Meeting minutes is ready now. We can get E-tree summary from = IETF site.

 

Today I collected all items = we discussed before. They are,

 

1)       = Silicon issue or chip limit;

2)       = Network efficiency;

3)       = Encapsulation mode, tag or raw;

4)       = H-VPLS;

5)       = Backwards compatibility, especially legacy PE or Non-supporting PE with IEEE = E-tree support joins E-Tree domain;

6)       = Configuration change in operation, for example, Leaf-only -> = Root-Leaf-Mixed;

7)       = S-VLAN preservation support;

8)       = Multi-segment PW;

9)       = VLAN ID allocation (Only for Dual-VLAN);

10)   Multi-AS deployment;

11)   ECMP;

12)   P2MP-PW;

13)   Ethernet OAM;

 

If we review the mail-list, CW approach has the following limits:

1)       = Chip limit. Please read reply from Giles = and Wim;

2)       = Network efficiency: There are garbage = fames which will be dropped on egress PE since only egress PE can decide forward or = drop frames while it receives frames. Ingress PE can not decide = forward or not. Yes, current solution can support Hub-Spoke configuration, but as we = know, the configuration is not easy if the network is big. Dual-VLAN or Multi-PW = approach can break communication between Leaf-Only PEs via = signaling.

[RK] It seems to me this is not the case. = Section 6 of the draft has some discussions on this.
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-6=
6. Optional Enhancements for Leaf-only PE
6.1. No PW between Leaf-only PEs
6.2. Not Forward Frame from Leaf AC to Leaf-only PE

 

3)       = Backwards compatibility: Not all PEs = supports control word. If one can not support control word, it will not join = E-Tree domain;

 

[RK] It seems to = me this is not the case. Section 5 of the draft has some discussions on = this.
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-5=
5. Backward Compatibility
5.1. AC Type
5.2. Control Word
5.3. Additional Action in Data Forwarding
5.3.1. Ingress PE Supporting the Extension but Egress PE Not
5.3.2. Egress PE Supporting the Extension but Ingress PE Not

 

Dual VLAN has = following limits:

1)       = Chip limit: As we know, we need to push = one VLAN into frames before MPLS encapsulation on ingress PE and stripe it out on = egress PE. This is non-standard operation. Wait for confirmation from chip = vendor;

2)       = HVPLS: If we follow Fig 3 or Fig = 4 in RFC 4762 to deploy = HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, = but can NOT configure it at all in Spoke PW case;

3)       = Multi-PW: Rafi figures this out, but we = don=A1=AFt think this over at that time. I think that it also has same problem as = H-VPLS has.

4)       = Encapsulation mode: If deploy GVPLS with = Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE = will stripe S-VLAN ID;

5)       = Backward Compatibility: Just as Daniel = mentioned, there is compatibility issue if legacy PE joins E-Tree domain. For me, I = don=A1=AFt get clear response from co-authors of Dual-VLAN.

 

For all = approaches, we don=A1=AFt cover ECMP / Ethernet OAM till now.

 

Is there anything = missed?

 

Regards,

 

Yuqun = (Sam) Cao

E-mail: = Yuqun.cao@gmail.com =

 

From: Lizhong Jin [mailto:lizho.jin@gmail.com]
Sent: Saturday, April 21, = 2012 11:59 AM
To: Henderickx, Wim = (Wim)
Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; yuqun.cao@gmail.com
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Hi Win,
Thank you for the answers. In that case, PE-rs should configure the = root/leaf properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, = you could not figure out the accessing spoke PW is from PE-r of VPWS or = MTU-s. Unless having some additional indication in NMS, you even don't know = which spoke PW needs to do VLAN manipulation. I am not sure such R/L = configuration could be accepted from operational view. Hope to see more comments.

Regards
Lizhong


=D4=DA 2012=C4=EA4=D4=C221=C8=D5=D0=C7=C6=DA=C1=F9=A3=ACHenderickx, Wim (Wim) <wim.henderickx@alcatel-= lucent.com> =D0=B4=B5=C0=A3=BA
> The VPWS which terminates at the H-VPLS node is indicated to be = root or leaf and the procedures associated will do the VLAN manipulation
>
>  
>
> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin
> Sent: vrijdag 20 april 2012 18:38
> To: l2vpn@ietf.org; Alexander.Vainshtein@eci= tele.com
> Cc: yuqun.cao@gmail.com
> Subject: RE: The status of the approaches to the E-Tree = solution?
>
>  
>
> Hi, all,
> The difference between 2-VLAN and CW approach is who will provide = the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW = will carry R/L information for CW approach.
> I have a question with the 2-VLAN approach in H-VPLS where H-VPLS = is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds = VLAN to indicate R/L information?
>
> Thanks
> Lizhong
>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 19 Apr 2012 04:38:36 +0000
>> From: Alexander Vainshtein <Alexander.Vainshtein@eci= tele.com>
>> To: "Rogers, Josh" <josh.rogers@twcable.com>, = Lucy yong
>>        <lucy.yong@huawei.com>, Daniel Cohn <DanielC@orckit.com>, Sam Cao
>>        <yuqun.cao@gmail.com>
>> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
>> Subject: RE: The status of the approaches to the E-Tree = solution?
>> Message-ID:
>>        <F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>
>> Content-Type: text/plain; charset=3D"us-ascii"
>>
>> Hi all,
>> I fully understand that that what I am going to say is not very popular, but:
>>
>> IMO one of the advantages of the CW-based solution is that it = is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic.
>>
>> Another advantage is preservation of full mesh of P2P PWs in a = VPLS, and, in a more generic way, localization of effects of changes in the PE configuration.
>>
>> In particular, adding a Leaf AC to a PE that previously has = been only supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect only the = PE where this operation happens and not the rest of the PEs.
>>
>> As for the need for HW changes that have been mentioned as a = main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution.
>>
>> My 2c,
>>     Sasha
>>
>>
>>
>> ________________________________________
>> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] = on behalf of Rogers, Josh [josh.rogers@twcable.com]
>> Sent: Wednesday, April 18, 2012 9:57 PM
>> To: Lucy yong; Daniel Cohn; Sam Cao
>> Cc: l2vpn@ietf.org
>> Subject: Re: The status of the approaches to the E-Tree = solution?
>>
>> Again, the P2MP situation throws me.  Is this something = that is used
>> commonly?
>>
>> I'm under the impression that adding P2MP to any model results = in a more
>> complex model.  Wether outside s-tag is used to = differentiate, or
>> dedicated pw's are used for the same purpose, it seems both = become more
>> complex.
>>
>> Gile's comparison slide still concisely captures the = differences between
>> these methods, in my opinion.  I haven't seen any new = ideas or thoughts
>> brought to the group in the past week or two on the subject. =  I would hate
>> for both proposed methods to die on the vine because we = couldn't decide
>> between two methods that have nothing inherently wrong with = either.
>>
>> -Josh
>>
>>
>> On 4/18/12 1:53 PM, "Lucy yong" <lucy.yong@huawei.com> = wrote:
>>
>>>Send this again.
>>>
>>>Two PW approach can be complex too if the VPLS instance for = E-Tree uses
>>>P2P PW fo

This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, phone = or fax, and then delete the original and all copies thereof. =

------=_NextPart_000_0021_01CD20D6.69320B70-- From Alexander.Vainshtein@ecitele.com Sun Apr 22 07:56:51 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D414821F85CC for ; Sun, 22 Apr 2012 07:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.191 X-Spam-Level: X-Spam-Status: No, score=-4.191 tagged_above=-999 required=5 tests=[AWL=1.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, 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 8+eWChiAw9e5 for ; Sun, 22 Apr 2012 07:56:49 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 7F18C21F85A8 for ; Sun, 22 Apr 2012 07:56:48 -0700 (PDT) Received: from [85.158.139.83:51248] by server-1.bemta-5.messagelabs.com id 53/F0-28458-E2C149F4; Sun, 22 Apr 2012 14:56:46 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1335106605!20997506!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.7; banners=-,-,- Received: (qmail 16911 invoked from network); 22 Apr 2012 14:56:46 -0000 Received: from unknown (HELO fridlppsb001.ecitele.com) (168.87.1.157) by server-7.tower-182.messagelabs.com with SMTP; 22 Apr 2012 14:56:46 -0000 X-AuditID: a8571401-b7f186d000005261-c8-4f941c7fba91 Received: from FRIDWPPCH001.ecitele.com (fridwppch001.ecitele.com [10.1.16.52]) by fridlppsb001.ecitele.com (Symantec Messaging Gateway) with SMTP id B4.59.21089.F7C149F4; Sun, 22 Apr 2012 16:58:07 +0200 (CEST) Received: from FRIDWPPMB002.ecitele.com ([169.254.4.167]) by FRIDWPPCH001.ecitele.com ([10.1.16.52]) with mapi id 14.01.0339.001; Sun, 22 Apr 2012 16:56:43 +0200 From: Alexander Vainshtein To: Sam Cao Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNHxPnvCW4Idac1kehO7tUxP5nzJaj1eOAgACwqQCAALY7AIAAC0AAgAFzRgCAACHU8IAACSVggAAKQVA= Date: Sun, 22 Apr 2012 14:56:42 +0000 Message-ID: References: , <14C7F4F06DB5814AB0DE29716C4F6D6701296244C3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>, , <1B88357C808B432E871CA9D678305B7C@v2comsam> <6F9ADEDA06A04AB98C247D303AFE93BE@v2comsam> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA02034DB3FRIDWPPMB002ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTW0gUURjuzIy7ozkxrqt73KSmKV8Mt11U2qIVDQIrYqWkIoOc3T3uTu3O bDubaERtFkFGYRZRC6bhJS/phg9eogfzxTSkCKES3AfdIhW6WUlElxnHTIjm6Tv/953v/845 /5C47orWSPJCEAUEzstqEogEsMKYdSb9ut1c25thnfo6qLVe+dpJWOvOjWry8cL+8IS28HXN I6ywqekbVoQfCoFtnCCIQS6IGBeSnDa2KMCXc85KluFdNtbCMn4v50Q+JARtLOf3I8HF5iUw /3zbZBkvMEhwii5ecNvYnfvsWVZr7pYsC5tX7OElBmX5ON7L+JAkcW7EyBUlt+Aq7cI9P1vO a/2RYbyir3EUC4HJa3g1IElI58D++5ZqEC/DVPgsGtFUgwRSR48B2FEfWlw0A9j+Yx5XVBra Brs7JjQK1tPrYHQ4qlUwTu+Goc6uBU0yXQAvv60GqmY7nB5vxFXsgDdCYUzBBJ0Bb96PASUE Re+Bb2IZSllHv8Nh72ezguNpK7zx4fZCKyCHmx+5h6mtDHA8Vo+poWnY9PApruIUOD31M07F a2BV29hiNBF2XHi8oKHoJDh8K0aomjT4qPUlUQNSw8tsw8u2hJdtUeub4MOrI4t4I2y5M4ur 2ASjfT/iltcbgLYdGMoCvMvvlxxms8WEnHwQeZHJKfq6gTxIrQf0oA9MXjYNApoEbCKVv/ma XRfHlUuVvkGQRmJsCmU3XrfrVjlEV6WHkzxHAie8SBoEkMRZPTWnl+WUi6s8iQLiH2qHfLVX ceNKp6g8ffBIttn8/wVroCJ78+w62i0P5zGE/CjwxyedJFlI7Vott08KIDeqKOO9wb80RsYr MRLlGHZFQ0l+zifxbpUfARnkr57hMaAjBFFARgO1VRHRishzQljymQEG+eDJlE9hE+VhXXKY kc0x2bz0cK1iLv88S5QxBE7zt3Q9muJ0j6NYv+Ho2aF9zWtMD2ZnGpPuMk86c98f79WfSiZe VVHFO3ZlfiEiBXWt9XvrGvpG58pqTeJUfvTY+L3E3BLse9qliwPNOesrgiiizV7bVtLdWvpt qLZ/vuZjna3r+UxTy4tPtHF/fazg4Ioh61rfpfInVQ2OgZw3LCF5OEsmHpC435twBlkhBAAA Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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: Sun, 22 Apr 2012 14:56:51 -0000 --_000_F9336571731ADE42A5397FC831CEAA02034DB3FRIDWPPMB002ecite_ Content-Type: text/plain; charset="iso-2022-jp" content-transfer-encoding: quoted-printable Sam, I will try to explain myself. I have misspoken before, and I owe you an apology. A true legacy PE cannot operate as a Mixed PE for E-tree since this operatio= n requires some changes in the forwarding behavior. This is IMHO correct reg= ardless of the specific E-tree solution that is implemented by the rest of t= he PEs (CW-based, dual PW-based or VLAN-based). I.e. without some additional= implementation-specific tricks it can be either a Root-only PE or a Leaf-on= ly PE in the VPLS that does not contain Mixed PEs. Regards, Sasha From: Sam Cao [mailto:yuqun.cao@gmail.com] Sent: Sunday, April 22, 2012 5:22 PM To: Alexander Vainshtein Cc: l2vpn@ietf.org; 'Raymond Key' Subject: RE: The status of the approaches to the E-Tree solution? Sasha, I agree with your comments. But maybe I don=1B$B!G=1B(Bt make myself underst= ood. I make it clear. If one chip can not support control word, then one switch which uses this ch= ip can not work as Root-Leaf-Mixed PE since we can not extend it. Is this co= rrect? Is this reasonable? Anyway, chip limit is big problem for CW approach. Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Sunday, April 22, 2012 9:56 PM To: Sam Cao Cc: l2vpn@ietf.org; 'Raymond Key' Subject: RE: The status of the approaches to the E-Tree solution? Sam, You=1B$B!G=1B(Bve asked: If it only supports VPLS, ok, it can work as Root-only, but why it cannot wo= rk as Root-Leaf-Mixed or Leaf-only if it cannot support CW? IMHO and FWIW there is not too much you can expect from a true legacy PE (i.= e. a PE that did not change its forwarding behavior): 1. It can obviously support Root-only functionality 2. It can support Leaf-only functionality if there are no Mixed by pre= venting setup PW (by not setting up PWs to other Leaf-only PEs). Anything beyond that would be very much implementation-specific. E.g., I am= aware of legacy implementations that could support functionality of a Mixed= PE provided that it would be the only Mixed PE in the VPLS instance, and ot= her legacy implementations that are, as legacy, fully interoperable with the= se ones but could not support such functionality. My 2c, Sasha From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Sa= m Cao Sent: Sunday, April 22, 2012 4:41 PM To: 'Raymond Key' Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Raymond, Network efficiency: [Sam] Leaf/Root configuration is local configuration, and PE can not know re= mote AC type configuration. This is CW Fundamentals. So even if CW approach= defines optional enhancement for Leaf-Only PE, but can not signal it betwee= n Leaf-Only PEs, so there is no good way to support this. The possible solut= ion is, manually configure hub-spoke topology, but if we do like this, curre= nt solutions have support most E-Tree cases with Hub-Spoke configuration. Li= zhong mentioned this in one mail. Backwards compatibility: [Sam] Yes, new draft considers backward compatibility, but it makes precondi= tion: The PE which can not support Control word only works as Root-only PE.= This does not make sense for me. If it only supports VPLS, ok, it can work= as Root-only, but why it can not work as Root-Leaf-Mixed or Leaf-only if it= can not support CW? Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com ________________________________ From: raymond.key@hotmail.com [mailto:raymond.key@hotmail.com] On Behalf Of= Raymond Key Sent: Saturday, April 21, 2012 11:32 PM To: yuqun.cao@gmail.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Some clarifications [RK] inserted below Thanks Raymond Key ________________________________ From: yuqun.cao@gmail.com To: lizho.jin@gmail.com; wim.henderickx@alcatel-lucent.com Subject: RE: The status of the approaches to the E-Tree solution? Date: Sat, 21 Apr 2012 22:51:28 +0800 CC: l2vpn@ietf.org Hi all, We reach an impasse:). BTW, Meeting minutes is ready now. We can get E-tree= summary from IETF site. Today I collected all items we discussed before. They are, 1) Silicon issue or chip limit; 2) Network efficiency; 3) Encapsulation mode, tag or raw; 4) H-VPLS; 5) Backwards compatibility, especially legacy PE or Non-supporting PE= with IEEE E-tree support joins E-Tree domain; 6) Configuration change in operation, for example, Leaf-only -> Root-L= eaf-Mixed; 7) S-VLAN preservation support; 8) Multi-segment PW; 9) VLAN ID allocation (Only for Dual-VLAN); 10) Multi-AS deployment; 11) ECMP; 12) P2MP-PW; 13) Ethernet OAM; If we review the mail-list, CW approach has the following limits: 1) Chip limit. Please read reply from Giles and Wim; 2) Network efficiency: There are garbage fames which will be dropped o= n egress PE since only egress PE can decide forward or drop frames while it= receives frames. Ingress PE can not decide forward or not. Yes, current sol= ution can support Hub-Spoke configuration, but as we know, the configuration= is not easy if the network is big. Dual-VLAN or Multi-PW approach can break= communication between Leaf-Only PEs via signaling. [RK] It seems to me this is not the case. Section 6 of the draft has some di= scussions on this. http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-6 6. Optional Enhancements for Leaf-only PE 6.1. No PW between Leaf-only PEs 6.2. Not Forward Frame from Leaf AC to Leaf-only PE 3) Backwards compatibility: Not all PEs supports control word. If one= can not support control word, it will not join E-Tree domain; [RK] It seems to me this is not the case. Section 5 of the draft has some di= scussions on this. http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-5 5. Backward Compatibility 5.1. AC Type 5.2. Control Word 5.3. Additional Action in Data Forwarding 5.3.1. Ingress PE Supporting the Extension but Egress PE Not 5.3.2. Egress PE Supporting the Extension but Ingress PE Not Dual VLAN has following limits: 1) Chip limit: As we know, we need to push one VLAN into frames before= MPLS encapsulation on ingress PE and stripe it out on egress PE. This is no= n-standard operation. Wait for confirmation from chip vendor; 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-= rs works in different manner, PE-rs should figure out AC type in VPWS case,= but can NOT configure it at all in Spoke PW case; 3) Multi-PW: Rafi figures this out, but we don=1B$B!G=1B(Bt think this= over at that time. I think that it also has same problem as H-VPLS has. 4) Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs shoul= d work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN ID; 5) Backward Compatibility: Just as Daniel mentioned, there is compatib= ility issue if legacy PE joins E-Tree domain. For me, I don=1B$B!G=1B(Bt get= clear response from co-authors of Dual-VLAN. For all approaches, we don=1B$B!G=1B(Bt cover ECMP / Ethernet OAM till now. Is there anything missed? Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com ________________________________ From: Lizhong Jin [mailto:lizho.jin@gmail.com] Sent: Saturday, April 21, 2012 11:59 AM To: Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi Win, Thank you for the answers. In that case, PE-rs should configure the root/lea= f properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, yo= u could not figure out the accessing spoke PW is from PE-r of VPWS or MTU-s.= Unless having some additional indication in NMS, you even don't know which= spoke PW needs to do VLAN manipulation. I am not sure such R/L configuratio= n could be accepted from operational view. Hope to see more comments. Regards Lizhong =1B$B:_=1B(B 2012=1B$BG/=1B(B4=1B$B7n=1B(B21=1B$BF|@14|O;!$=1B(BHenderickx,= Wim (Wim) > =1B$B The VPWS which terminates at the H-VPLS node is indicated to be root or le= af and the procedures associated will do the VLAN manipulation > > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-= bounces@ietf.org] On Behalf Of Lizhong Jin > Sent: vrijdag 20 april 2012 18:38 > To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.co= m > Cc: yuqun.cao@gmail.com > Subject: RE: The status of the approaches to the E-Tree solution? > > > > Hi, all, > The difference between 2-VLAN and CW approach is who will provide the R/L= information, customer payload or PW? The customer payload will be always mo= dified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach. > I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is acces= sed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informatio= n? > > Thanks > Lizhong > >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 Apr 2012 04:38:36 +0000 >> From: Alexander Vainshtein > >> To: "Rogers, Josh" >, Lucy yong >> >, Daniel Cohn <= DanielC@orckit.com>, Sam Cao >> > >> Cc: "l2vpn@ietf.org" > >> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID: >> > >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi all, >> I fully understand that that what I am going to say is not very popular,= but: >> >> IMO one of the advantages of the CW-based solution is that it is orthogon= al to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic= . >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, and,= in a more generic way, localization of effects of changes in the PE configu= ration. >> >> In particular, adding a Leaf AC to a PE that previously has been only sup= porting Root ACs (or vice versa), removal of the last Leaf or last Root AC f= rom a PE that previously has been supporting a mix etc. affect only the PE w= here this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main disadva= ntage of the CW-based approach - I believe it strongly depends on specific i= mplementations. And some changes in the forwarding process are required in a= ny solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounce= s@ietf.org] on behalf of Rogers, Josh [josh.r= ogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a more >> complex model. Wether outside s-tag is used to differentiate, or >> dedicated pw's are used for the same purpose, it seems both become more >> complex. >> >> Gile's comparison slide still concisely captures the differences between >> these methods, in my opinion. I haven't seen any new ideas or thoughts >> brought to the group in the past week or two on the subject. I would hat= e >> for both proposed methods to die on the vine because we couldn't decide >> between two methods that have nothing inherently wrong with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" > wrote: >> >>>Send this again. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>P2P PW fo This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA02034DB3FRIDWPPMB002ecite_ Content-Type: text/html; charset="iso-2022-jp" content-transfer-encoding: quoted-printable

Sam,

I will try to explain mysel= f.

 

I have misspoken before, an= d I owe you an apology.

 

A true legacy PE cannot ope= rate as a Mixed PE for E-tree since this operation requires some changes in= the forwarding behavior. This is IMHO correct regardless of the specific E-tree solution that is implemented by the res= t of the PEs (CW-based, dual PW-based or VLAN-based). I.e. without some= additional implementation-specific tricks it can be either a Root-only PE o= r a Leaf-only PE in the VPLS that does not contain Mixed PEs.

 

= Regards,

=      Sasha

 

From: Sam Cao [ma= ilto:yuqun.cao@gmail.com]
Sent: Sunday, April 22, 2012 5:22 PM
To: Alexander Vainshtein
Cc: l2vpn@ietf.org; 'Raymond Key'
Subject: RE: The status of the approaches to the E-Tree solution?

 

Sasha,

 

I agree with your comments. But m= aybe I don=1B$B!G=1B(Bt make myself understood. I make it clear.<= /span>

 

If one chip can not support contr= ol word, then one switch which uses this chip can not work as Root-Leaf-Mixe= d PE since we can not extend it. Is this correct? Is this reasonable?

 

Anyway, chip limit is big problem= for CW approach.

 

Regards,<= /span>

 

Yuqun (Sa= m) Cao

E-mail: <= a href=3D"mailto:Yuqun.cao@gmail.com"> Yuqun.cao@gmail.com =

 

From: Alexander V= ainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Sunday, April 22, 2012 9:56 PM
To: Sam Cao
Cc: l2vpn@ietf.org; 'Raymond Key'
Subject: RE: The status of the approaches to the E-Tree solution?

 

Sam,

You=1B$B!G=1B(Bve asked:

If it only supports VPLS, ok, it can work as Root-only, but why it cann= ot work as Root-Leaf-Mixed or Leaf-only if it cannot support CW?

IMHO and FWIW there is not= too much you can expect from a true legacy PE (i.e. a PE that did not chang= e its forwarding behavior):

1. &n= bsp;     It can obviously support Root-only functionality

2. &n= bsp;     It can support Leaf-only functionality if there are no Mixed by preven= ting setup PW (by not setting up PWs to other Leaf-only PEs).

Anything beyond that would= be very much implementation-specific. E.g., I am aware of legacy implementa= tions that could support functionality of a Mixed PE provided that it would be the only Mixed PE in the VPLS instance, and other legacy i= mplementations that are, as legacy, fully interoperable with these ones but= could not support such functionality.

 

My 2c,

     Sa= sha

 

From: l2vpn-bounc= es@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Sam Cao
Sent: Sunday, April 22, 2012 4:41 PM
To: 'Raymond Key'
Cc: l2vpn@ietf.org
Subject: RE: The status of the approaches to the E-Tree solution?

 

Raymond,

 

Network efficiency:

[Sam] Leaf/Root configuration is= local configuration, and PE can not know remote AC type configuration. This= is CW Fundamentals. So even if CW approach defines optional enhancement for Leaf-Only PE, but can not signal it between Leaf-Only PEs,= so there is no good way to support this. The possible solution is, manually= configure hub-spoke topology, but if we do like this, current solutions hav= e support most E-Tree cases with Hub-Spoke configuration. Lizhong mentioned this in one mail.

 

Backwards compatibility:

[Sam] Yes, new draft considers ba= ckward compatibility, but it makes precondition: The PE which can not suppor= t Control word only works as Root-only PE. This does not make sense for me. If it only supports VPLS, ok, it can work as Root-on= ly, but why it can not work as Root-Leaf-Mixed or Leaf-only if it can not su= pport CW?

 

Regards,<= /span>

 

Yuqun (Sa= m) Cao

E-mail: <= a href=3D"mailto:Yuqun.cao@gmail.com"> Yuqun.cao@gmail.com =

 

From: raymond.key= @hotmail.com [mailto:raymond.key@hotmail.com] On Behalf Of Raymond Key
Sent: Saturday, April 21, 2012 11:32 PM
To: yuqun.cao@gmail.com
Cc: l2vpn@ietf.org
Subject: RE: The status of the approaches to the E-Tree solution?

 

Some clarifications [RK] inserted below

Thanks

Raymond Key

From: yuqun.cao@gmail.= com
To: lizho.jin@gmail.com; wim.henderickx@alcatel-lucent.com
Subject: RE: The status of the approaches to the E-Tree solution?
Date: Sat, 21 Apr 2012 22:51:28 +0800
CC: l2vpn@ietf.org

Hi all,

 

We reach an impasseJ.  BTW, Meeting= minutes is ready now. We can get E-tree summary from IETF site.

 

Today I collected all items we discussed= before. They are,

 

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">1)       Silicon issue or chip limit;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">2)       Network efficiency;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">3)       Encapsulation mode, tag or raw;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">4)       H-VPLS;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">5)       Backwards compatibility, especially legacy PE or Non-support= ing PE with IEEE E-tree support joins E-Tree domain;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">6)       Configuration change in operation, for example, Leaf-only -&= gt; Root-Leaf-Mixed;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">7)       S-VLAN preservation support;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">8)       Multi-segment PW;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">9)       VLAN ID allocation (Only for Dual-VLAN);

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">10)   Multi-AS deployment;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">11)   ECMP;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">12)   P2MP-PW;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= "">13)   Ethernet OAM;

 

If we review the mail-list, CW= approach has the following limits:

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= ";color:navy">1)    = ;   Chip limit. Please read reply from Giles and Wim;=

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= ";color:navy">2)    = ;   Network efficiency: There are garbage fames which= will be dropped on egress PE since only egress PE can decide forward or dro= p frames while it receives frames. Ingress PE can not decide forward or not. Yes, current solution can support Hub-Spoke configur= ation, but as we know, the configuration is not easy if the network is big.= Dual-VLAN or Multi-PW approach can break communication between Leaf-Only PE= s via signaling.

<= span style=3D"font-family:"Arial","sans-serif";color:nav= y">[RK] It seems to me this is not the case. Section 6 of the draft has some= discussions on this.
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-6 6. Optional Enhancements for Leaf-only PE
6.1. No PW between Leaf-only PEs
6.2. Not Forward Frame from Leaf AC to Leaf-only PE

&= nbsp;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= ";color:navy">3)    = ;   Backwards compatibility: Not all PEs supports con= trol word. If one can not support control word, it will not join E-Tree doma= in;

 

[RK] It seems to me this is not the case. Sect= ion 5 of the draft has some discussions on this.
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-5 5. Backward Compatibility
5.1. AC Type
5.2. Control Word
5.3. Additional Action in Data Forwarding
5.3.1. Ingress PE Supporting the Extension but Egress PE Not
5.3.2. Egress PE Supporting the Extension but Ingress PE Not

 

Dual VLAN has following limits= :

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= ";color:navy">1)    = ;   Chip limit: As we know, we need to push one VLAN= into frames before MPLS encapsulation on ingress PE and stripe it out on eg= ress PE. This is non-standard operation. Wait for confirmation from chip vendor;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= ";color:navy">2)    = ;   HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to= deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC t= ype in VPWS case, but can NOT configure it at all in Spoke PW case;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= ";color:navy">3)    = ;   Multi-PW: Rafi figures this out, but we don=1B$B!= G=1B(Bt think this over at that time. I think that it also has same problem= as H-VPLS has.

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= ";color:navy">4)    = ;   Encapsulation mode: If deploy GVPLS with Spoke PW= mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will s= tripe S-VLAN ID;

<= span style=3D"font-size:9.0pt;font-family:"Arial","sans-serif= ";color:navy">5)    = ;   Backward Compatibility: Just as Daniel mentioned,= there is compatibility issue if legacy PE joins E-Tree domain. For me, I do= n=1B$B!G=1B(Bt get clear response from co-authors of Dual-VLAN.<= /o:p>

 

For all approaches, we don=1B$= B!G=1B(Bt cover ECMP / Ethernet OAM till now.

 

Is there anything missed?

 

Regards,

&nbs= p;

Yuqun (Sam) Cao

E-mail: Yuqun.cao@gmail.com <= /o:p>

&nbs= p;

From: Lizhong= Jin [mailto:lizho.jin@gmail.com]
Sent: Saturday, April 21, 2012 11:59 AM
To: Henderickx, Wim (Wim)
Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; yuqun.cao@gmail= .com
Subject: RE: The status of the approaches to the E-Tree solution?

 

Hi Win,
Thank you for the answers. In that case, PE-rs should configure the root/lea= f properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, yo= u could not figure out the accessing spoke PW is from PE-r of VPWS or MTU-s.= Unless having some additional indication in NMS, you even don't know which spoke PW needs to do VLAN mani= pulation. I am not sure such R/L configuration could be accepted from operat= ional view. Hope to see more comments.

Regards
Lizhong


=1B$B:_=1B(B 2012=1B$BG/=1B(B<= /span>4=1B$B7n=1B(B21=1B$BF|@14|O;!$=1B(BHenderickx, Wim (Wim) <wim.hend= erickx@alcatel-lucent.com> =1B$B
> The VPWS which terminates at the H-VPLS node is indicated to be root or= leaf and the procedures associated will do the VLAN manipulation
>
>  
>
> From: l2vpn-bounces@ietf.org<= /a> [mailto:l2vpn-bounces@ietf.org= ] On Behalf Of Lizhong Jin
> Sent: vrijdag 20 april 2012 18:38
> To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com
> Cc: yuqun.cao@gmail.com
> Subject: RE: The status of the approaches to the E-Tree solution?
>
>  
>
> Hi, all,
> The difference between 2-VLAN and CW approach is who will provide the R= /L information, customer payload or PW? The customer payload will be always= modified to carry R/L information in 2-VLAN approach, while PW with CW will= carry R/L information for CW approach.
> I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is ac= cessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to ac= cess H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informa= tion?
>
> Thanks
> Lizhong
>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 19 Apr 2012 04:38:36 +0000
>> From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
>> To: "Rogers, Josh" <josh.rogers@twcable.com>, Lucy yong
>>        <lucy.yong@huawei.com>, Daniel Cohn <DanielC@orckit.com>, Sam Cao
>>        <yuqun.cao@gmail.com>
>> Cc: "l2vpn@ietf.org"= ; <l2vpn@ietf.org>
>> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID:
>>        <F9336571731ADE42A5397FC831CEA= A02034192@FRIDWPPMB002.ecitele.com>
>> Content-Type: text/plain; charset=3D"us-ascii"
>>
>> Hi all,
>> I fully understand that that what I am going to say is not very pop= ular, but:
>>
>> IMO one of the advantages of the CW-based solution is that it is or= thogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN t= raffic.
>>
>> Another advantage is preservation of full mesh of P2P PWs in a VPLS= , and, in a more generic way, localization of effects of changes in the PE c= onfiguration.
>>
>> In particular, adding a Leaf AC to a PE that previously has been on= ly supporting Root ACs (or vice versa), removal of the last Leaf or last Roo= t AC from a PE that previously has been supporting a mix etc. affect only th= e PE where this operation happens and not the rest of the PEs.
>>
>> As for the need for HW changes that have been mentioned as a main d= isadvantage of the CW-based approach - I believe it strongly depends on spec= ific implementations. And some changes in the forwarding process are require= d in any solution.
>>
>> My 2c,
>>     Sasha
>>
>>
>>
>> ________________________________________
>> From: l2vpn-bounces@ietf.= org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [jos= h.rogers@twcable.com]
>> Sent: Wednesday, April 18, 2012 9:57 PM
>> To: Lucy yong; Daniel Cohn; Sam Cao
>> Cc: l2vpn@ietf.org
>> Subject: Re: The status of the approaches to the E-Tree solution? >>
>> Again, the P2MP situation throws me.  Is this something that i= s used
>> commonly?
>>
>> I'm under the impression that adding P2MP to any model results in a= more
>> complex model.  Wether outside s-tag is used to differentiate,= or
>> dedicated pw's are used for the same purpose, it seems both become= more
>> complex.
>>
>> Gile's comparison slide still concisely captures the differences be= tween
>> these methods, in my opinion.  I haven't seen any new ideas or= thoughts
>> brought to the group in the past week or two on the subject.  = I would hate
>> for both proposed methods to die on the vine because we couldn't de= cide
>> between two methods that have nothing inherently wrong with either.=
>>
>> -Josh
>>
>>
>> On 4/18/12 1:53 PM, "Lucy yong" <lucy.yong@huawei.com> wrote:
>>
>>>Send this again.
>>>
>>>Two PW approach can be complex too if the VPLS instance for E-Tr= ee uses
>>>P2P PW fo

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA02034DB3FRIDWPPMB002ecite_-- From ju1738@att.com Sun Apr 22 16:27:51 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD24421F85DF for ; Sun, 22 Apr 2012 16:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4, 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 aCr5yBMRVCaz for ; Sun, 22 Apr 2012 16:27:44 -0700 (PDT) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id 035D421F8570 for ; Sun, 22 Apr 2012 16:27:43 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo03.seg.att.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-8) with ESMTP id 0f3949f4.2aaaf1047940.112958.00-591.300751.nbfkord-smmo03.seg.att.com (envelope-from ); Sun, 22 Apr 2012 23:27:44 +0000 (UTC) X-MXL-Hash: 4f9493f06daf2688-fab9f15603b83ce43e9c51cd7d23c9bd9fdaf2ec Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 4e3949f4.0.112928.00-415.300681.nbfkord-smmo03.seg.att.com (envelope-from ); Sun, 22 Apr 2012 23:27:34 +0000 (UTC) X-MXL-Hash: 4f9493e6339f12b6-a77bd2e4f26119a5f3a5f90eaf92d37f0ba184f6 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3MNRW9h022038; Sun, 22 Apr 2012 19:27:32 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3MNRS7u022033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Apr 2012 19:27:28 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by sflint01.pst.cso.att.com (RSA Interceptor); Sun, 22 Apr 2012 19:27:06 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.36]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.01.0355.002; Sun, 22 Apr 2012 19:27:06 -0400 From: "UTTARO, JAMES" To: "'Alexander Vainshtein'" , Sam Cao Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNHxPnxbisvEh3kk6CwsWQjlzY35akOniAgACwqQCAALY7AIAAC0AAgAFzRgCAAARQAIAAB2IAgAAJkwCAAEmWAA== Date: Sun, 22 Apr 2012 23:27:05 +0000 Message-ID: References: , <14C7F4F06DB5814AB0DE29716C4F6D6701296244C3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>, , <1B88357C808B432E871CA9D678305B7C@v2comsam> <6F9ADEDA06A04AB98C247D303AFE93BE@v2comsam> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.206.246] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FACAD1DMISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=GTUsfharYz0A:10 a=lhC5ufdvBjcA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=IRDgFnn-AAAA:8 a=69EAbJreA] X-AnalysisOut: [AAA:8 a=gxZvrgisAAAA:8 a=ahv8dbORAAAA:8 a=i0EeH86SAAAA:8 a] X-AnalysisOut: [=2obxBgYoAAAA:8 a=pJzfd4Svofi9VKbzJycA:9 a=jRmrXOKR8htHUWK] X-AnalysisOut: [fLdMA:7 a=UAVRJdkkkM0A:10 a=esyrR_pz34kA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=MSl-tDqOz04A:10 a=1QW4SJF8ptEA:10 a=EfJqPEOeqlMA:10 ] X-AnalysisOut: [a=3FZX-ydVlcEA:10 a=UD3V0yxRLtG19vPf:21 a=s0T8ZcmWHvhMpaEN] X-AnalysisOut: [:21 a=SSmOFEACAAAA:8 a=Y2VNeNrzAAAA:8 a=yMhMjlubAAAA:8 a=T] X-AnalysisOut: [W66zc2HAAAA:8 a=HQ31llbKAAAA:8 a=XNVLwOEZD5gBhkUssKkA:9 a=] X-AnalysisOut: [Sl25G67MRp9y4DFLWGcA:7 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10] X-AnalysisOut: [ a=hTZeC7Yk6K0A:10 a=1DrbwGU4homqh8n-:21 a=USt0z4So5V96kuk] X-AnalysisOut: [5:21] Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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: Sun, 22 Apr 2012 23:27:51 -0000 --_000_B17A6910EEDD1F45980687268941550FACAD1DMISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable For a given PE, If you use BGP and define separate VRFs one for the leafs a= nd one for roots than the semantic provided by the RT assignment should be = translated correctly in to the forwarding programmed.. This means that intr= a-PE between the leaf and root VRF should be treated as a Labeled PW. If tr= eated as a regular ethernet interface than a leaf on VRF S1 can forward tra= ffic on VRF H1 and then onto a different PEs leaf VRF=1B$B!D=1B(B I believe= we had a very similar conversation over a year ago about E-Tree=1B$B!D=1B(= B So, here are the reqs I shared * E-Tree/Partial mesh topologies need to be realized in the contro= l plane by constructing PWs. The data plane should not infer a topology. In= other words data should not have to be inspected to determine if the packe= t is sourced from a leaf or a root * The same PE must be able to host Root and Leaf sites. * Disallowing of Leaf to Leaf traffic on the same PE must be done = using PW semantics. * When Root and Leaf sites are deployed on the same PE the packets= between them should obey the same semantics as if they had traversed a PW = i.e ( Split Horizon, No Label Re-Imposition etc=1B$B!D=1B(B ) * If PE has a root and leaf site and sends traffic to PE1. PE1 sho= uld be able to decide if the traffic was sourced from the root or leaf site= . If from PE:Leaf then the traffic should not be resolved in PE1:Leaf. Jim Uttaro From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of A= lexander Vainshtein Sent: Sunday, April 22, 2012 10:57 AM To: Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Sam, I will try to explain myself. I have misspoken before, and I owe you an apology. A true legacy PE cannot operate as a Mixed PE for E-tree since this operati= on requires some changes in the forwarding behavior. This is IMHO correct r= egardless of the specific E-tree solution that is implemented by the rest o= f the PEs (CW-based, dual PW-based or VLAN-based). I.e. without some additi= onal implementation-specific tricks it can be either a Root-only PE or a Le= af-only PE in the VPLS that does not contain Mixed PEs. Regards, Sasha From: Sam Cao [mailto:yuqun.cao@gmail.com] Sent: Sunday, April 22, 2012 5:22 PM To: Alexander Vainshtein Cc: l2vpn@ietf.org; 'Raymond Key' Subject: RE: The status of the approaches to the E-Tree solution? Sasha, I agree with your comments. But maybe I don=1B$B!G=1B(Bt make myself unders= tood. I make it clear. If one chip can not support control word, then one switch which uses this c= hip can not work as Root-Leaf-Mixed PE since we can not extend it. Is this = correct? Is this reasonable? Anyway, chip limit is big problem for CW approach. Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Sunday, April 22, 2012 9:56 PM To: Sam Cao Cc: l2vpn@ietf.org; 'Raymond Key' Subject: RE: The status of the approaches to the E-Tree solution? Sam, You=1B$B!G=1B(Bve asked: If it only supports VPLS, ok, it can work as Root-only, but why it cannot w= ork as Root-Leaf-Mixed or Leaf-only if it cannot support CW? IMHO and FWIW there is not too much you can expect from a true legacy PE (i= .e. a PE that did not change its forwarding behavior): 1. It can obviously support Root-only functionality 2. It can support Leaf-only functionality if there are no Mixed by pr= eventing setup PW (by not setting up PWs to other Leaf-only PEs). Anything beyond that would be very much implementation-specific. E.g., I am= aware of legacy implementations that could support functionality of a Mixe= d PE provided that it would be the only Mixed PE in the VPLS instance, and = other legacy implementations that are, as legacy, fully interoperable with = these ones but could not support such functionality. My 2c, Sasha From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of S= am Cao Sent: Sunday, April 22, 2012 4:41 PM To: 'Raymond Key' Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Raymond, Network efficiency: [Sam] Leaf/Root configuration is local configuration, and PE can not know r= emote AC type configuration. This is CW Fundamentals. So even if CW approac= h defines optional enhancement for Leaf-Only PE, but can not signal it betw= een Leaf-Only PEs, so there is no good way to support this. The possible so= lution is, manually configure hub-spoke topology, but if we do like this, c= urrent solutions have support most E-Tree cases with Hub-Spoke configuratio= n. Lizhong mentioned this in one mail. Backwards compatibility: [Sam] Yes, new draft considers backward compatibility, but it makes precond= ition: The PE which can not support Control word only works as Root-only PE= . This does not make sense for me. If it only supports VPLS, ok, it can wor= k as Root-only, but why it can not work as Root-Leaf-Mixed or Leaf-only if = it can not support CW? Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com ________________________________ From: raymond.key@hotmail.com [mailto:raymond.key@hotmail.com] On Behalf Of= Raymond Key Sent: Saturday, April 21, 2012 11:32 PM To: yuqun.cao@gmail.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Some clarifications [RK] inserted below Thanks Raymond Key ________________________________ From: yuqun.cao@gmail.com To: lizho.jin@gmail.com; wim.henderickx@alcatel-lucent.com Subject: RE: The status of the approaches to the E-Tree solution? Date: Sat, 21 Apr 2012 22:51:28 +0800 CC: l2vpn@ietf.org Hi all, We reach an impasse:). BTW, Meeting minutes is ready now. We can get E-tre= e summary from IETF site. Today I collected all items we discussed before. They are, 1) Silicon issue or chip limit; 2) Network efficiency; 3) Encapsulation mode, tag or raw; 4) H-VPLS; 5) Backwards compatibility, especially legacy PE or Non-supporting PE= with IEEE E-tree support joins E-Tree domain; 6) Configuration change in operation, for example, Leaf-only -> Root-= Leaf-Mixed; 7) S-VLAN preservation support; 8) Multi-segment PW; 9) VLAN ID allocation (Only for Dual-VLAN); 10) Multi-AS deployment; 11) ECMP; 12) P2MP-PW; 13) Ethernet OAM; If we review the mail-list, CW approach has the following limits: 1) Chip limit. Please read reply from Giles and Wim; 2) Network efficiency: There are garbage fames which will be dropped = on egress PE since only egress PE can decide forward or drop frames while i= t receives frames. Ingress PE can not decide forward or not. Yes, current s= olution can support Hub-Spoke configuration, but as we know, the configurat= ion is not easy if the network is big. Dual-VLAN or Multi-PW approach can b= reak communication between Leaf-Only PEs via signaling. [RK] It seems to me this is not the case. Section 6 of the draft has some d= iscussions on this. http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-6 6. Optional Enhancements for Leaf-only PE 6.1. No PW between Leaf-only PEs 6.2. Not Forward Frame from Leaf AC to Leaf-only PE 3) Backwards compatibility: Not all PEs supports control word. If one= can not support control word, it will not join E-Tree domain; [RK] It seems to me this is not the case. Section 5 of the draft has some d= iscussions on this. http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-5 5. Backward Compatibility 5.1. AC Type 5.2. Control Word 5.3. Additional Action in Data Forwarding 5.3.1. Ingress PE Supporting the Extension but Egress PE Not 5.3.2. Egress PE Supporting the Extension but Ingress PE Not Dual VLAN has following limits: 1) Chip limit: As we know, we need to push one VLAN into frames befor= e MPLS encapsulation on ingress PE and stripe it out on egress PE. This is = non-standard operation. Wait for confirmation from chip vendor; 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE= -rs works in different manner, PE-rs should figure out AC type in VPWS case= , but can NOT configure it at all in Spoke PW case; 3) Multi-PW: Rafi figures this out, but we don=1B$B!G=1B(Bt think thi= s over at that time. I think that it also has same problem as H-VPLS has. 4) Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs shou= ld work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN ID; 5) Backward Compatibility: Just as Daniel mentioned, there is compati= bility issue if legacy PE joins E-Tree domain. For me, I don=1B$B!G=1B(Bt g= et clear response from co-authors of Dual-VLAN. For all approaches, we don=1B$B!G=1B(Bt cover ECMP / Ethernet OAM till now. Is there anything missed? Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com ________________________________ From: Lizhong Jin [mailto:lizho.jin@gmail.com] Sent: Saturday, April 21, 2012 11:59 AM To: Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi Win, Thank you for the answers. In that case, PE-rs should configure the root/le= af properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, = you could not figure out the accessing spoke PW is from PE-r of VPWS or MTU= -s. Unless having some additional indication in NMS, you even don't know wh= ich spoke PW needs to do VLAN manipulation. I am not sure such R/L configur= ation could be accepted from operational view. Hope to see more comments. Regards Lizhong =1B$B:_=1B(B 2012=1B$BG/=1B(B4=1B$B7n=1B(B21=1B$BF|@14|O;!$=1B(BHenderickx,= Wim (Wim) > =1B$B The VPWS which terminates at the H-VPLS node is indicated to be root or l= eaf and the procedures associated will do the VLAN manipulation > > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn= -bounces@ietf.org] On Behalf Of Lizhong Jin > Sent: vrijdag 20 april 2012 18:38 > To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.c= om > Cc: yuqun.cao@gmail.com > Subject: RE: The status of the approaches to the E-Tree solution? > > > > Hi, all, > The difference between 2-VLAN and CW approach is who will provide the R/L= information, customer payload or PW? The customer payload will be always m= odified to carry R/L information in 2-VLAN approach, while PW with CW will = carry R/L information for CW approach. > I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is acce= ssed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acc= ess H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informa= tion? > > Thanks > Lizhong > >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 Apr 2012 04:38:36 +0000 >> From: Alexander Vainshtein > >> To: "Rogers, Josh" >, Lucy yong >> >, Daniel Cohn = >, Sam Cao >> > >> Cc: "l2vpn@ietf.org" > >> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID: >> > >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi all, >> I fully understand that that what I am going to say is not very popular,= but: >> >> IMO one of the advantages of the CW-based solution is that it is orthogo= nal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traff= ic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, and= , in a more generic way, localization of effects of changes in the PE confi= guration. >> >> In particular, adding a Leaf AC to a PE that previously has been only su= pporting Root ACs (or vice versa), removal of the last Leaf or last Root AC= from a PE that previously has been supporting a mix etc. affect only the P= E where this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main disadv= antage of the CW-based approach - I believe it strongly depends on specific= implementations. And some changes in the forwarding process are required i= n any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounc= es@ietf.org] on behalf of Rogers, Josh [josh= .rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a more >> complex model. Wether outside s-tag is used to differentiate, or >> dedicated pw's are used for the same purpose, it seems both become more >> complex. >> >> Gile's comparison slide still concisely captures the differences between >> these methods, in my opinion. I haven't seen any new ideas or thoughts >> brought to the group in the past week or two on the subject. I would ha= te >> for both proposed methods to die on the vine because we couldn't decide >> between two methods that have nothing inherently wrong with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" > wrote: >> >>>Send this again. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>P2P PW fo This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_B17A6910EEDD1F45980687268941550FACAD1DMISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

For a given PE, If you use BGP and define separate VRFs one = for the leafs and one for roots than the semantic provided by the RT assign= ment should be translated correctly in to the forwarding programmed.. This means that intra-PE betwe= en the leaf and root VRF should be treated as a Labeled PW. If treated as a= regular ethernet interface than a leaf on VRF S1 can forward traffic on VR= F H1 and then onto a different PEs leaf VRF=1B$B!D=1B(B I believe we had a very similar conversation over a y= ear ago about E-Tree=1B$B!D=1B(B

 

So, here are the reqs I shared

 

• = ;         E-Tree/Partial me= sh topologies need to be realized in the control plane by constructing PWs.= The data plane should not infer a topology. In other words data should not have to be inspected to determine if the packet is s= ourced from a leaf or a root

• = ;         The same PE must = be able to host Root and Leaf sites.

• = ;         Disallowing of Le= af to Leaf traffic on the same PE must be done using PW semantics. • = ;         When Root and Lea= f sites are deployed on the same PE the packets between them should obey th= e same semantics as if they had traversed a PW i.e ( Split Horizon, No Label Re-Imposition etc=1B$B!D=1B(B )

• = ;         If PE has a root = and leaf site and sends traffic to PE1. PE1 should be able to decide if the= traffic was sourced from the root or leaf site. If from PE:Leaf then the traffic should not be resolved in PE1:Leaf.

 

 

Jim Uttaro

From: l2vpn-bo= unces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Sunday, April 22, 2012 10:57 AM
To: Sam Cao
Cc: l2vpn@ietf.org
Subject: RE: The status of the approaches to the E-Tree solution?

 

Sam,

I will try to explain myself.

 

I have misspoken before, and I owe you an apology.

 

A true legacy PE cannot operate as a Mixed PE for E-tree sin= ce this operation requires some changes in the forwarding behavior. This is= IMHO correct regardless of the specific E-tree solution that is implemented by the re= st of the PEs (CW-based, dual PW-based or VLAN-based). I.e. without som= e additional implementation-specific tricks it can be either a Root-only PE= or a Leaf-only PE in the VPLS that does not contain Mixed PEs.

 

Regards,

     Sasha

 

From: Sam Cao = [mailto:yuqun.cao@gmail.com]
Sent: Sunday, April 22, 2012 5:22 PM
To: Alexander Vainshtein
Cc: l2vpn@ietf.org; 'Raymond Key'
Subject: RE: The status of the approaches to the E-Tree solution?

 

Sasha,

 

I agree with your comments. But maybe I don=1B$B!G=1B(Bt make m= yself understood. I make it clear.

 

If one chip can not support control word, then one switch which= uses this chip can not work as Root-Leaf-Mixed PE since we can not extend = it. Is this correct? Is this reasonable?

 

Anyway, chip limit is big problem for CW approach.

 

Regards,=

 

Yuqun (S= am) Cao

E-mail: = Yuqun.cao@gmail.com

 

From: Alexande= r Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Sunday, April 22, 2012 9:56 PM
To: Sam Cao
Cc: l2vpn@ietf.org; 'Raymond Key'
Subject: RE: The status of the approaches to the E-Tree solution?

 

Sam,

You=1B$B!G=1B(Bve asked:

If it= only supports VPLS, ok, it can work as Root-only, but why it cannot work a= s Root-Leaf-Mixed or Leaf-only if it cannot support CW?

IMHO and FWIW there is not too much you can expect from a tr= ue legacy PE (i.e. a PE that did not change its forwarding behavior):<= /o:p>

      = ; It can obviously support Root-only functionality<= /span>

      = ; It can support Leaf-only functionality if there are no Mixed= by preventing setup PW (by not setting up PWs to other Leaf-only PEs).

Anything beyond that would be very much implementation-speci= fic. E.g., I am aware of legacy implementations that could support function= ality of a Mixed PE provided that it would be the only Mixed PE in the VPLS instance, and othe= r legacy implementations that are, as legacy, fully interoperable with thes= e ones but could not support such functionality.

 

My 2c,

     Sasha

 

From: l2vpn-bo= unces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Sam Cao
Sent: Sunday, April 22, 2012 4:41 PM
To: 'Raymond Key'
Cc: l2vpn@ietf.org
Subject: RE: The status of the approaches to the E-Tree solution?

 

Raymond,

 

Network efficiency:

[Sam] Leaf/Root configuration is local configuration, and PE ca= n not know remote AC type configuration. This is CW Fundamentals. So even i= f CW approach defines optional enhancement for Leaf-Only PE, but can not signal it between Leaf-= Only PEs, so there is no good way to support this. The possible solution is= , manually configure hub-spoke topology, but if we do like this, current so= lutions have support most E-Tree cases with Hub-Spoke configuration. Lizhong mentioned this in one mail.

 

Backwards compatibility:

[Sam] Yes, new draft considers backward compatibility, but it m= akes precondition: The PE which can not support Control word only works as = Root-only PE. This does not make sense for me. If it only supports VPLS, ok, it can work as Root-o= nly, but why it can not work as Root-Leaf-Mixed or Leaf-only if it can not = support CW?

 

Regards,=

 

Yuqun (S= am) Cao

E-mail: = Yuqun.cao@gmail.com

 

From: raymond.= key@hotmail.com [mailto:raymond.key@hotmail.com] On Behalf Of Raymond Key
Sent: Saturday, April 21, 2012 11:32 PM
To: yuqun.cao@gmail.com
Cc: l2vpn@ietf.org
Subject: RE: The status of the approaches to the E-Tree solution?

 

Some clarifications [RK] inserted below

Thanks

Raymond Key

From: yuqun.cao@gmail= .com
To: lizho.jin@gmail.com; wim.henderickx@alcatel-lucent.com
Subject: RE: The status of the approaches to the E-Tree solution?
Date: Sat, 21 Apr 2012 22:51:28 +0800
CC: l2vpn@ietf.org

Hi all,

 

We reach an impasseJ.  BTW, M= eeting minutes is ready now. We can get E-tree summary from IETF site.<= /p>

 

Today I collected all items we discusse= d before. They are,

 

1)       Silicon issue or chip limit;

2)       Network efficiency;

3)       Encapsulation mode, tag or raw;

4)       H-VPLS;

5)       Backwards compatibility, especially legacy PE or Non-suppo= rting PE with IEEE E-tree support joins E-Tree domain;

6)       Configuration change in operation, for example, Leaf-only = -> Root-Leaf-Mixed;

7)       S-VLAN preservation support;

8)       Multi-segment PW;

9)       VLAN ID allocation (Only for Dual-VLAN);=

10)   Multi-AS deployment;

11)   ECMP;

12)   P2MP-PW;

13)   Ethernet OAM;

 

If we review the mail-list, CW approach has the following limit= s:

1)   &nb= sp;   Chip limit. Please read reply from Giles and Wim;

2)   &nb= sp;   Network efficiency: There are garbage fames which will be dropp= ed on egress PE since only egress PE can decide forward or drop frames whil= e it receives frames. Ingress PE can not decide forward or not. Yes, current solution can support Hub-Spoke con= figuration, but as we know, the configuration is not easy if the network is= big. Dual-VLAN or Multi-PW approach can break communication between Leaf-O= nly PEs via signaling.

[RK] It seems to me this is not the case. Section 6 of the draft has som= e discussions on this.
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-6<= br> 6. Optional Enhancements for Leaf-only PE
6.1. No PW between Leaf-only PEs
6.2. Not Forward Frame from Leaf AC to Leaf-only PE

&nb= sp;

3)   &nb= sp;   Backwards compatibility: Not all PEs supports control word. If = one can not support control word, it will not join E-Tree domain;

 

[RK] It seems to me this is not the case. Se= ction 5 of the draft has some discussions on this.
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-5<= br> 5. Backward Compatibility
5.1. AC Type
5.2. Control Word
5.3. Additional Action in Data Forwarding
5.3.1. Ingress PE Supporting the Extension but Egress PE Not
5.3.2. Egress PE Supporting the Extension but Ingress PE Not

 

Dual VLAN has following limits:

1)   &nb= sp;   Chip limit: As we know, we need to push one VLAN into frames be= fore MPLS encapsulation on ingress PE and stripe it out on egress PE. This = is non-standard operation. Wait for confirmation from chip vendor;

2)   &nb= sp;   HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS,= PE-rs works in different manner, PE-rs should figure out AC type in VPWS c= ase, but can NOT configure it at all in Spoke PW case;

3)   &nb= sp;   Multi-PW: Rafi figures this out, but we don=1B$B!G=1B(Bt think = this over at that time. I think that it also has same problem as H-VPLS has= .

4)   &nb= sp;   Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs s= hould work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN = ID;

5)   &nb= sp;   Backward Compatibility: Just as Daniel mentioned, there is comp= atibility issue if legacy PE joins E-Tree domain. For me, I don=1B$B!G=1B(B= t get clear response from co-authors of Dual-VLAN.

 

For all approaches, we don=1B$B!G=1B(Bt cover ECMP / Ethernet O= AM till now.

 

Is there anything missed?

 

Regards,

 

Yuqun (Sam) Cao

E-mail: Yuqun.cao@gmail.com =

 

From: Lizho= ng Jin [mailto:lizho.jin@gmail.com]
Sent: Saturday, April 21, 2012 11:59 AM
To: Henderickx, Wim (Wim)
Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; yuqun.cao@gmai= l.com
Subject: RE: The status of the approaches to the E-Tree solution?

 

Hi Win,
Thank you for the answers. In that case, PE-rs should configure the root/le= af properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, = you could not figure out the accessing spoke PW is from PE-r of VPWS or MTU= -s. Unless having some additional indication in NMS, you even don't know which spoke PW needs to do VLAN man= ipulation. I am not sure such R/L configuration could be accepted from oper= ational view. Hope to see more comments.

Regards
Lizhong


=1B$B:_=1B(B 2012=1B$BG/=1B(B4=1B$B7n=1B(B21=1B$BF|@14|O;!$=1B(BHenderick= x, Wim (Wim) <wim.hen= derickx@alcatel-lucent.com> =1B$B
> The VPWS which terminates at the H-VPLS node is indicated to be root o= r leaf and the procedures associated will do the VLAN manipulation
>
>  
>
> From: l2vpn-bounces@ietf.org= [mailto:l2vpn-bounces@ietf.o= rg] On Behalf Of Lizhong Jin
> Sent: vrijdag 20 april 2012 18:38
> To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com
> Cc: yuqun.cao@gmail.com
> Subject: RE: The status of the approaches to the E-Tree solution?
>
>  
>
> Hi, all,
> The difference between 2-VLAN and CW approach is who will provide the = R/L information, customer payload or PW? The customer payload will be alway= s modified to carry R/L information in 2-VLAN approach, while PW with CW wi= ll carry R/L information for CW approach.
> I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is a= ccessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to = access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L info= rmation?
>
> Thanks
> Lizhong
>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 19 Apr 2012 04:38:36 +0000
>> From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
>> To: "Rogers, Josh" <josh.rogers@twcable.com>, Lucy yong
>>        <lucy.yong@huawei.com>, Daniel Cohn <DanielC@orcki= t.com>, Sam Cao
>>        <yuqun.cao@gmail.com= >
>> Cc: "l2vpn@ietf.org&quo= t; <l2vpn@ietf.org>
>> Subject: RE: The status of the approaches to the E-Tree solution?<= br> >> Message-ID:
>>        <F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ec= itele.com>
>> Content-Type: text/plain; charset=3D"us-ascii"
>>
>> Hi all,
>> I fully understand that that what I am going to say is not very po= pular, but:
>>
>> IMO one of the advantages of the CW-based solution is that it is o= rthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN= traffic.
>>
>> Another advantage is preservation of full mesh of P2P PWs in a VPL= S, and, in a more generic way, localization of effects of changes in the PE= configuration.
>>
>> In particular, adding a Leaf AC to a PE that previously has been o= nly supporting Root ACs (or vice versa), removal of the last Leaf or last R= oot AC from a PE that previously has been supporting a mix etc. affect only= the PE where this operation happens and not the rest of the PEs.
>>
>> As for the need for HW changes that have been mentioned as a main = disadvantage of the CW-based approach - I believe it strongly depends on sp= ecific implementations. And some changes in the forwarding process are requ= ired in any solution.
>>
>> My 2c,
>>     Sasha
>>
>>
>>
>> ________________________________________
>> From: l2vpn-bounces@ietf= .org [l2vpn-bounces@ietf.org<= /a>] on behalf of Rogers, Josh [= josh.rogers@twcable.com]
>> Sent: Wednesday, April 18, 2012 9:57 PM
>> To: Lucy yong; Daniel Cohn; Sam Cao
>> Cc: l2vpn@ietf.org
>> Subject: Re: The status of the approaches to the E-Tree solution?<= br> >>
>> Again, the P2MP situation throws me.  Is this something that is= used
>> commonly?
>>
>> I'm under the impression that adding P2MP to any model results in = a more
>> complex model.  Wether outside s-tag is used to differenti= ate, or
>> dedicated pw's are used for the same purpose, it seems both become= more
>> complex.
>>
>> Gile's comparison slide still concisely captures the differences b= etween
>> these methods, in my opinion.  I haven't seen any new idea= s or thoughts
>> brought to the group in the past week or two on the subject.  I would hate
>> for both proposed methods to die on the vine because we couldn't d= ecide
>> between two methods that have nothing inherently wrong with either= .
>>
>> -Josh
>>
>>
>> On 4/18/12 1:53 PM, "Lucy yong" <lucy.yong@huawei.com> wrote:
>>
>>>Send this again.
>>>
>>>Two PW approach can be complex too if the VPLS instance for E-T= ree uses
>>>P2P PW fo

This e-mail message is intended for the recipient only and contains info= rmation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. = If you have received this transmission in error, please inform us by e-mail= , phone or fax, and then delete the original and all copies thereof.

This e-mail message is intended for the recipient only and contains info= rmation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. = If you have received this transmission in error, please inform us by e-mail= , phone or fax, and then delete the original and all copies thereof.

--_000_B17A6910EEDD1F45980687268941550FACAD1DMISOUT7MSGUSR9IIT_-- From josh.rogers@twcable.com Sun Apr 22 17:54:50 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE4921F84B6 for ; Sun, 22 Apr 2012 17:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.18 X-Spam-Level: X-Spam-Status: No, score=0.18 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_31=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 HgtbtaJA8j3w for ; Sun, 22 Apr 2012 17:54:49 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB1521F84B2 for ; Sun, 22 Apr 2012 17:54:48 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,463,1330923600"; d="scan'208";a="354546604" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 22 Apr 2012 20:53:31 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Sun, 22 Apr 2012 20:54:48 -0400 From: "Rogers, Josh" To: Jiangyuanlong Date: Sun, 22 Apr 2012 20:54:45 -0400 Subject: Re: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0g664PX16smsEaRMutiI4lX7Ba9Q== Message-ID: In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E7ED@SZXEML508-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.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 23 Apr 2012 00:54:50 -0000 Hello Yuanlong, If the UNI is service multiplexed (multiple services), then the customer must tag all traffic destined for this ETREE instance (as well as expect it tagged with the same ID). So, imagine the customer transmit frame with VLAN-ID '3' into the service from a root site. Frame traverses the AC, and enters the AC port on the first PE. Service Provider is using VLAN-ID 4001 for traffic sourced from 'root' AC's, and 4002 for traffic sourced from 'leaf' AC's. Since this frame came in from a root site, we prepend the frame with VLAN-ID 4001 (now 4001:3), it traverses the PW(s) that the CAM designates on first PE. On egress PE, vlan 4001 is popped off and the frame is returned with VLAN ID 3 back to customer. In my example below, 4001 would be the R/L S-Tag, and 3 would be the 'AC S-Tag' (I think someone mentioned that this is not technically an S-Tag because it is coordinated with the customer), and the 'C-Tag' below may be an additional tag if the customer were double tagging. My point was that the SP is dealing with double tagged frames for the ETREE service. In the example above, the SP still has to deal with 4001:3, the 3 designates which service the frame belongs to, and 4001 designates the frame came from a root site. From the customer's perspective, the three approaches change nothing, none require anything different from the customer. The 2VLAN method, however, does require a little more understanding with VLAN mapping from the service provider's perspective, since they are dealing with a double tag. I suppose this depends a bit on the hardware vendor's implementation of the method, however. It could be possible to automate and/or hide the outer ETREE tag. For example, if the implementation standardizes on 4001 for root sourced, and 4002 for leaf sourced, then w/in the VPLS instance, if a) the service is defined as ETREE, and b) each AC is defined as 'root' or 'leaf', then the R/L vlan tagging could be automated and not really noticed or cared much about by the operator, which would hide this complexity. I do think it is worth noting that the double tagging introduces complexity, however. Thank you, -Josh On 4/22/12 4:50 AM, "Jiangyuanlong" wrote: >Hi Josh, > >Wish the last email on "SVLAN in the 2VLAN E-Tree solution" covered this >issue. >BTW, a 2VLAN encapsulated frame is not in the format as described. A >single S-tag is usually enough. > >Thanks >Yuanlong > >---------------------------------------------------------------------- > >Message: 1 >Date: Sat, 21 Apr 2012 11:02:51 -0400 >From: "Rogers, Josh" >To: Sam Cao , 'Lizhong Jin' > , "'Henderickx, Wim (Wim)'" > >Cc: "l2vpn@ietf.org" >Subject: Re: The status of the approaches to the E-Tree solution? >Message-ID: >Content-Type: text/plain; charset=3D"utf-8" > >Sam? Where is the list for multi-PW method? > >One item I don't think is covered in your 2VLAN list, is where service >multiplexed UNI's are involved, or any time there is a layer 2 CPE >between PE and CE, these devices usually expect a single, bidirectional >s-tag, and according to your explanation this morning, coordinating the >S-Tags used for ETREE with the customer SHOULD NOT to be done, therefor >there must be an 'inner S-Tag' on the AC, and an 'outer S-Tag' in the PW. > >While inside the PW, a 2VLAN method frame would look like: > >+-----------+-----------+----------+-------+-----------------+ >|MPLS Label | R/L S-Tag | AC S-Tag | C-tag | Layer 2 Payload | >+-----------+-----------+----------+-------+-----------------+ > >Correct? > >Would you consider this an 'issue' or just a 'complication' ? > >A lot of the 'pro 2VLAN' argument has been centered around existing IEEE >standard, and at first it sounded like this was better/proposed for the >ability to extend the R/L S-tag beyond the PW, but it sounds like that >isn't really an option, so I'm not sure that is a valid benefit/driver. > >Thanks much, >Josh > >From: Sam Cao > >To: 'Lizhong Jin' >, >"'Henderickx, Wim (Wim)'" >m>> >Cc: "l2vpn@ietf.org" >> >Subject: RE: The status of the approaches to the E-Tree solution? > >Hi all, > >We reach an impasse?. BTW, Meeting minutes is ready now. We can get >E-tree summary from IETF site. > >Today I collected all items we discussed before. They are, > >1) Silicon issue or chip limit; >2) Network efficiency; >3) Encapsulation mode, tag or raw; >4) H-VPLS; >5) Backwards compatibility, especially legacy PE or Non-supporting >PE with IEEE E-tree support joins E-Tree domain; >6) Configuration change in operation, for example, Leaf-only -> >Root-Leaf-Mixed; >7) S-VLAN preservation support; >8) Multi-segment PW; >9) VLAN ID allocation (Only for Dual-VLAN); >10) Multi-AS deployment; >11) ECMP; >12) P2MP-PW; >13) Ethernet OAM; > >If we review the mail-list, CW approach has the following limits: >1) Chip limit. Please read reply from Giles and Wim; >2) Network efficiency: There are garbage fames which will be >dropped on egress PE since only egress PE can decide forward or drop >frames while it receives frames. Ingress PE can not decide forward or >not. Yes, current solution can support Hub-Spoke configuration, but as we >know, the configuration is not easy if the network is big. Dual-VLAN or >Multi-PW approach can break communication between Leaf-Only PEs via >signaling. >3) Backwards compatibility: Not all PEs supports control word. If >one can not support control word, it will not join E-Tree domain; > >Dual VLAN has following limits: >1) Chip limit: As we know, we need to push one VLAN into frames >before MPLS encapsulation on ingress PE and stripe it out on egress PE. >This is non-standard operation. Wait for confirmation from chip vendor; >2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, >PE-rs works in different manner, PE-rs should figure out AC type in VPWS >case, but can NOT configure it at all in Spoke PW case; >3) Multi-PW: Rafi figures this out, but we don?t think this over at >that time. I think that it also has same problem as H-VPLS has. >4) Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs >should work in tagged mode, otherwise PE-rs or egress PE will stripe >S-VLAN ID; >5) Backward Compatibility: Just as Daniel mentioned, there is >compatibility issue if legacy PE joins E-Tree domain. For me, I don?t get >clear response from co-authors of Dual-VLAN. > >For all approaches, we don?t cover ECMP / Ethernet OAM till now. > >Is there anything missed? > >Regards, > >Yuqun (Sam) Cao >E-mail: Yuqun.cao@gmail.com > >________________________________ >From: Lizhong Jin [mailto:lizho.jin@gmail.com] >Sent: Saturday, April 21, 2012 11:59 AM >To: Henderickx, Wim (Wim) >Cc: l2vpn@ietf.org; >Alexander.Vainshtein@ecitele.com; > yuqun.cao@gmail.com >Subject: RE: The status of the approaches to the E-Tree solution? > >Hi Win, >Thank you for the answers. In that case, PE-rs should configure the >root/leaf properties of VPWS, not on the remote PE of VPWS. And usually >on PE-rs, you could not figure out the accessing spoke PW is from PE-r of >VPWS or MTU-s. Unless having some additional indication in NMS, you even >don't know which spoke PW needs to do VLAN manipulation. I am not sure >such R/L configuration could be accepted from operational view. Hope to >see more comments. > >Regards >Lizhong > > >? 2012?4?21?????Henderickx, Wim (Wim) >m>> ??? >> The VPWS which terminates at the H-VPLS node is indicated to be root or >>leaf and the procedures associated will do the VLAN manipulation >> >> >> >> From: l2vpn-bounces@ietf.org >>[mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Lizhong Jin >> Sent: vrijdag 20 april 2012 18:38 >> To: l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >> Cc: yuqun.cao@gmail.com >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> >> >> Hi, all, >> The difference between 2-VLAN and CW approach is who will provide the >>R/L information, customer payload or PW? The customer payload will be >>always modified to carry R/L information in 2-VLAN approach, while PW >>with CW will carry R/L information for CW approach. >> I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is >>accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used >>to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate >>R/L information? >> >> Thanks >> Lizhong >> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Thu, 19 Apr 2012 04:38:36 +0000 >>> From: Alexander Vainshtein >>>>>m>> >>> To: "Rogers, Josh" >>>>, Lucy yong >>> >, Daniel >>>Cohn >, Sam Cao >>> > >>> Cc: "l2vpn@ietf.org" >>>> >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> Message-ID: >>> >>>>>F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> >>> Content-Type: text/plain; charset=3D"us-ascii" >>> >>> Hi all, >>> I fully understand that that what I am going to say is not very >>>popular, but: >>> >>> IMO one of the advantages of the CW-based solution is that it is >>>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery >>>of BUN traffic. >>> >>> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>>and, in a more generic way, localization of effects of changes in the >>>PE configuration. >>> >>> In particular, adding a Leaf AC to a PE that previously has been only >>>supporting Root ACs (or vice versa), removal of the last Leaf or last >>>Root AC from a PE that previously has been supporting a mix etc. affect >>>only the PE where this operation happens and not the rest of the PEs. >>> >>> As for the need for HW changes that have been mentioned as a main >>>disadvantage of the CW-based approach - I believe it strongly depends >>>on specific implementations. And some changes in the forwarding process >>>are required in any solution. >>> >>> My 2c, >>> Sasha >>> >>> >>> >>> ________________________________________ >>> From: l2vpn-bounces@ietf.org >>>[l2vpn-bounces@ietf.org] on behalf of >>>Rogers, Josh [josh.rogers@twcable.com] >>> Sent: Wednesday, April 18, 2012 9:57 PM >>> To: Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: Re: The status of the approaches to the E-Tree solution? >>> >>> Again, the P2MP situation throws me. Is this something that is used >>> commonly? >>> >>> I'm under the impression that adding P2MP to any model results in a >>>more >>> complex model. Wether outside s-tag is used to differentiate, or >>> dedicated pw's are used for the same purpose, it seems both become more >>> complex. >>> >>> Gile's comparison slide still concisely captures the differences >>>between >>> these methods, in my opinion. I haven't seen any new ideas or thoughts >>> brought to the group in the past week or two on the subject. I would >>>hate >>> for both proposed methods to die on the vine because we couldn't decide >>> between two methods that have nothing inherently wrong with either. >>> >>> -Josh >>> >>> >>> On 4/18/12 1:53 PM, "Lucy yong" >>>> wrote: >>> >>>>Send this again. >>>> >>>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>>P2P PW fo > >________________________________ >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: >attachment.htm> > >------------------------------ > >_______________________________________________ >L2vpn mailing list >L2vpn@ietf.org >https://www.ietf.org/mailman/listinfo/l2vpn > > >End of L2vpn Digest, Vol 95, Issue 49 >************************************* This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From yuqun.cao@gmail.com Sun Apr 22 18:24:52 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D53821F8559 for ; Sun, 22 Apr 2012 18:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.590, BAYES_00=-2.599, J_CHICKENPOX_31=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 1gS+sF0g4Nhe for ; Sun, 22 Apr 2012 18:24:51 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1D11C21F8475 for ; Sun, 22 Apr 2012 18:24:51 -0700 (PDT) Received: by dady13 with SMTP id y13so20579167dad.27 for ; Sun, 22 Apr 2012 18:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :in-reply-to:x-mimeole; bh=nrWPHuVGCQF5mOGeTo4knq3PZwa/pZi9UDXY9HUknmQ=; b=y/9xrrPWPCiCt02g9iejACp/tFQb63j2AO/B1cjBuAydZV7mwnDUrkoKlOEvTqHXww 9IOqdAwZUlW+cSlCnXwOz9T3cZMF5EPX7+u59O7U6vPJHf84GvlxNpgSid0xyxAXzm6W JLBpmcN0dbcRRnAX1HaO7voKSH99tFgU+J5UHc7SkKscmUvK4Ts/pAfvYDKhcYj2v0ZZ RJSwbjcEDkoCdL4tBijA8edsQJ+MrgKYdseN3VWO+7ImKQTedZDB9jla5JnEhpQNZNY/ JlQB0WziZ0nIEnACKgiSHv0McQeMIvJtavrO4HY4FPR9G359WXeY4mb1GrOrAo7YWXy1 0coA== Received: by 10.68.196.167 with SMTP id in7mr9340474pbc.130.1335144290816; Sun, 22 Apr 2012 18:24:50 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id ge1sm12874264pbc.0.2012.04.22.18.24.45 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Apr 2012 18:24:49 -0700 (PDT) From: "Sam Cao" To: "'Jiangyuanlong'" References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E7DD@SZXEML508-MBS.china.huawei.com> Subject: RE: The status of the approaches to the E-Tree solution? Date: Mon, 23 Apr 2012 09:24:42 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AQHNIGxIkTBdljOSQkeqvNTqsF/qWZanmv2w In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E7DD@SZXEML508-MBS.china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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, 23 Apr 2012 01:24:52 -0000 Hi Yuanlong, Yesterday evening I think HVPLS again, and again I think that it is problem if I don't misunderstand Dual-VLAN draft. First, this is VPWS access; secondly, if it is VPWS access, all active drafts does not extend anything for VPWS. I agree with your answer to Josh's question (Original is Multi-AS, but it is really HVPLS). Would you please read that mail again? Thanks. Please get more comments below. [JY] The same as above, only T-PE will deal with VLAN, S-PE only switches PW label, so I can't see what is the problem. [Sam] This came up in the first round (By Rafi). You explained that switching PE does NOT aware VLAN mapping. At first glance it seems reasonable. But this depends on your VLAN allocation. Would you please update your draft? Then I can give more comments. [JY] Could you elaborate a little more what is the compatibility issue? // 2012-3-29 from Daniel But how would the non-legacy PE know which VLANs are available at the legacy PE? The legacy PE cannot advertise it if it doesn't support extensions! BTW, I just collect the items we have discussed, and list what we can not make agreement before :). Thanks, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Sunday, April 22, 2012 5:43 PM To: Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Sam, Please see my comments in line with [JY]. Regards, Yuanlong ---------------------------------------------------------------------- Message: 1 Date: Sat, 21 Apr 2012 22:51:28 +0800 From: "Sam Cao" To: "'Lizhong Jin'" , "'Henderickx, Wim \(Wim\)'" Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <1B88357C808B432E871CA9D678305B7C@v2comsam> Content-Type: text/plain; charset="gb2312" Hi all, We reach an impasse:-). BTW, Meeting minutes is ready now. We can get E-tree summary from IETF site. Today I collected all items we discussed before. They are, 1) Silicon issue or chip limit; 2) Network efficiency; 3) Encapsulation mode, tag or raw; 4) H-VPLS; 5) Backwards compatibility, especially legacy PE or Non-supporting PE with IEEE E-tree support joins E-Tree domain; 6) Configuration change in operation, for example, Leaf-only -> Root-Leaf-Mixed; 7) S-VLAN preservation support; 8) Multi-segment PW; 9) VLAN ID allocation (Only for Dual-VLAN); 10) Multi-AS deployment; 11) ECMP; 12) P2MP-PW; 13) Ethernet OAM; If we review the mail-list, CW approach has the following limits: 1) Chip limit. Please read reply from Giles and Wim; 2) Network efficiency: There are garbage fames which will be dropped on egress PE since only egress PE can decide forward or drop frames while it receives frames. Ingress PE can not decide forward or not. Yes, current solution can support Hub-Spoke configuration, but as we know, the configuration is not easy if the network is big. Dual-VLAN or Multi-PW approach can break communication between Leaf-Only PEs via signaling. 3) Backwards compatibility: Not all PEs supports control word. If one can not support control word, it will not join E-Tree domain; Dual VLAN has following limits: 1) Chip limit: As we know, we need to push one VLAN into frames before MPLS encapsulation on ingress PE and stripe it out on egress PE. This is non-standard operation. Wait for confirmation from chip vendor; [JY] Do you really consider tagged PW as non-standard? 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, but can NOT configure it at all in Spoke PW case; [JY] In the first place, why PE-rs need to figure out the AC type for a spoke? The VLAN should be processed in the MTU, not in the PE-rs. 3) Multi-PW: Rafi figures this out, but we don?t think this over at that time. I think that it also has same problem as H-VPLS has. [JY] The same as above, only T-PE will deal with VLAN, S-PE only switches PW label, so I can't see what is the problem. 4) Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN ID; [JY] Is anything not working with tagged PW mode? 5) Backward Compatibility: Just as Daniel mentioned, there is compatibility issue if legacy PE joins E-Tree domain. For me, I don?t get clear response from co-authors of Dual-VLAN. [JY] Could you elaborate a little more what is the compatibility issue? For all approaches, we don?t cover ECMP / Ethernet OAM till now. Is there anything missed? Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com _____ From: Lizhong Jin [mailto:lizho.jin@gmail.com] Sent: Saturday, April 21, 2012 11:59 AM To: Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi Win, Thank you for the answers. In that case, PE-rs should configure the root/leaf properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, you could not figure out the accessing spoke PW is from PE-r of VPWS or MTU-s. Unless having some additional indication in NMS, you even don't know which spoke PW needs to do VLAN manipulation. I am not sure such R/L configuration could be accepted from operational view. Hope to see more comments. Regards Lizhong ? 2012?4?21?????Henderickx, Wim (Wim) ??? > The VPWS which terminates at the H-VPLS node is indicated to be root or leaf and the procedures associated will do the VLAN manipulation > > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin > Sent: vrijdag 20 april 2012 18:38 > To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com > Cc: yuqun.cao@gmail.com > Subject: RE: The status of the approaches to the E-Tree solution? > > > > Hi, all, > The difference between 2-VLAN and CW approach is who will provide the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW will carry R/L information for CW approach. > I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information? > > Thanks > Lizhong > >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 Apr 2012 04:38:36 +0000 >> From: Alexander Vainshtein >> To: "Rogers, Josh" , Lucy yong >> , Daniel Cohn , Sam Cao >> >> Cc: "l2vpn@ietf.org" >> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID: >> >> Content-Type: text/plain; charset="us-ascii" >> >> Hi all, >> I fully understand that that what I am going to say is not very popular, but: >> >> IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes in the PE configuration. >> >> In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root AC from a PE that previously has been supporting a mix etc. affect only the PE where this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a more >> complex model. Wether outside s-tag is used to differentiate, or >> dedicated pw's are used for the same purpose, it seems both become more >> complex. >> >> Gile's comparison slide still concisely captures the differences between >> these methods, in my opinion. I haven't seen any new ideas or thoughts >> brought to the group in the past week or two on the subject. I would hate >> for both proposed methods to die on the vine because we couldn't decide >> between two methods that have nothing inherently wrong with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" wrote: >> >>>Send this again. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>P2P PW fo -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 48 ************************************* From yuqun.cao@gmail.com Sun Apr 22 18:27:37 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E7E21F8575 for ; Sun, 22 Apr 2012 18:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.856 X-Spam-Level: X-Spam-Status: No, score=-2.856 tagged_above=-999 required=5 tests=[AWL=0.742, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YB1lamd14TkE for ; Sun, 22 Apr 2012 18:27:36 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3953921F8570 for ; Sun, 22 Apr 2012 18:27:36 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so3242273pbb.31 for ; Sun, 22 Apr 2012 18:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :in-reply-to:x-mimeole; bh=nso6FR7hRpSDPT2TDkRKKYF93/4JrMHLTuLEhzEJXKI=; b=ZaXbm61dHfyPs24mC22MSCUDKq+8e1o9d8hL1G4A+tPo1jVf1QkgKZhcbAaMHqHzJU laz3LM7MtVAfBRGQDDBZOOjDsRWh9Q+H1A6a5+9sNfZ+THYevnPBO7fzx0Wgr8lOqS76 8QrnZvtPT9nBcEZuyqeOZkUlcX4ribt08f2yjODsqWYpbkcz0ZFEFolRtM4KjK2iXnsh 5RS9OwFWVMDVJkWb+zjJCqlS5cQisKWdp8fNlY6TOn3AAQyMH3ISCgGg3xhqYbUFx5lP I5B4LvSFfOVpmPw2400SEkyud9wVQc5W6yXq1SuYfStftzI5fgQKLC0g/lmpeV4Mfbt+ 9Rdg== Received: by 10.68.233.99 with SMTP id tv3mr1655157pbc.11.1335144455794; Sun, 22 Apr 2012 18:27:35 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id na8sm11447100pbc.7.2012.04.22.18.27.30 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Apr 2012 18:27:34 -0700 (PDT) From: "Sam Cao" To: "'Alexander Vainshtein'" References: <2691CE0099834E4A9C5044EEC662BB9D3264A725@dfweml505-mbx>, , <14C7F4F06DB5814AB0DE29716C4F6D670129623CA8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Subject: RE: The status of the approaches to the E-Tree solution? Date: Mon, 23 Apr 2012 09:27:26 +0800 Message-ID: <245DBC48776345279E9EA6326623AAD6@R01842> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac0YdJZFvCW4Idac1kehO7tUxP5nzAABa612AFMldrAAg7gO1wACovJQAA1D5U0AAHKKMAAYYOlgAAZIvIAAOS0wEAAQaI4AAA5sZxAAF6R+jP/+ZruAgAAR2oCAALDcdv//8c1AgAAdiov//4SRIP//A88g//iBteA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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, 23 Apr 2012 01:27:37 -0000 Sasha, Can we close this now? Daniel and I explained it, but is it acceptable for you? Sam -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Thursday, April 19, 2012 9:19 PM To: Sam Cao Cc: l2vpn@ietf.org; 'Daniel Cohn'; 'Henderickx, Wim (Wim)'; 'Rogers, Josh'; 'Lucy yong' Subject: RE: The status of the approaches to the E-Tree solution? Sam (hope this is the appropriate form of address and my apologies if not), I am actually trying to build a list of operational (not implementation-driven) issues that must be addressed by a reasonable E-tree solution. Then we could compare multiple approaches. As for setting up/tearing PWs with multiple peers just because your local configuration has changed, I am not sure this is reasonable from the operational point of view. E.g., consider the case of a Leaf-only PE migrating to a Mixed PE. To the best of my understanding, PWs between Leaf-only PWs are not ever set, so our original Leaf PE could be unaware about existence of other Leaf-only PEs (or, even worse, its list of Leaf-only peers could be not matching the current situation) - and this would not affect traffic in any way. Once it suddenly becomes a Mix PE, it must set up PWs with all the Leaf-only PEs have been ignored before, and they must agree to this... IMHO and FWIW, unless you use a very elaborate auto-discovery mechanism, this process has all the potential to become an operational nightmare. My 2c, Sasha > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Thursday, April 19, 2012 3:50 PM > To: Alexander Vainshtein; 'Henderickx, Wim (Wim)'; 'Rogers, Josh'; 'Lucy > yong'; 'Daniel Cohn' > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Sasha, > > We have discussed this case before. While configuration is changed in fly, > it is reasonable to establish or teardown PW. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Thursday, April 19, 2012 1:31 PM > To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Wim, > Lots of thanks for a prompt response. > > I think that operational aspects of the VLAN approach (e.g., how is the > Global VID selected and distributed) should be examined in more detail. > > At the same time it seems that the double PW approach carries with it too > many operational problems. > E.g., no PWs are set up between Leaf-only PEs, but once one of these > becomes > a Mix PE, all the Leaf-only PEs must now recognize it as a valid peer. And > if a Mix PE reverts to a Leaf only one, all its Leaf-only peers must drop it > and shut down the relevant PWs... > > My 2c, > Sasha > > ________________________________________ > From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] > Sent: Thursday, April 19, 2012 7:21 AM > To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Sasha, the VLAN approach allows for a similar operation as the CW does. It > is orthogonal to the underlying PW deployment of VPLS. > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of > Alexander Vainshtein > Sent: donderdag 19 april 2012 6:39 > To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > > Hi all, > I fully understand that that what I am going to say is not very popular, > but: > > IMO one of the advantages of the CW-based solution is that it is orthogonal > to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in > a more generic way, localization of effects of changes in the PE > configuration. > > In particular, adding a Leaf AC to a PE that previously has been only > supporting Root ACs (or vice versa), removal of the last Leaf or last Root > AC from a PE that previously has been supporting a mix etc. affect only the > PE where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main > disadvantage of the CW-based approach - I believe it strongly depends on > specific implementations. And some changes in the forwarding process are > required in any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of > Rogers, > Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a more > complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become more > complex. > > Gile's comparison slide still concisely captures the differences between > these methods, in my opinion. I haven't seen any new ideas or thoughts > brought to the group in the past week or two on the subject. I would hate > for both proposed methods to die on the vine because we couldn't decide > between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" wrote: > > >Send this again. > > > >Two PW approach can be complex too if the VPLS instance for E-Tree uses > >P2P PW for unicast traffic and P2MP PW for broadcast and unknown > >unicast traffic, and some P2MP PWs for multicast traffic. It may double > >all of them. > > > >Lucy > > > >-----Original Message----- > >From: Daniel Cohn [mailto:DanielC@orckit.com] > >Sent: Wednesday, April 18, 2012 1:42 PM > >To: Lucy yong; Rogers, Josh; Sam Cao > >Cc: l2vpn@ietf.org > >Subject: RE: The status of the approaches to the E-Tree solution? > > > >I think the first option its the natural way to go. How is the processing > >in this case more complex? > > > >Thumb typed - please be tolerant > > > >Lucy yong wrote: > > > > > > > >Snipped.. > > > >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW > >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for > >traffic coming from a root AC) > >[[LY]] Not that simple. You construct either two P2MP PWs to all other > >PEs and let egress PE performing filtering, or construct one P2MP PW to > >leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE > >perform forwarding and filtering. Both make node process complex. > > > >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for > >delivering the frames to remote PEs. We should utilize them with the > >minimized changes. Dual VLAN solution is simpler than Dual PW. > > > >Regards, > >Lucy > > > > > >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I > >haven't had any first hand experience with P2MP PW's, however, so don't > >feel terribly strong about this objection. Is this a real problem for > >others (now or in the future), or is this objection in the weeds? > > > >I'm not sure the 'additional complexity' is notable, or even relevant. I > >encourage others to speak up if they disagree, as P2MP PW is only > >conceptual to me, and I am unfamiliar with real-life use cases for it. > > > >Thanks, > >Josh > > > > > > > >On 4/18/12 10:30 AM, "Lucy yong" wrote: > > > >>Please see inline. > >> > >>-----Original Message----- > >>From: Sam Cao [mailto:yuqun.cao@gmail.com] > >>Sent: Tuesday, April 17, 2012 7:14 AM > >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; > >>giles.heron@gmail.com; simon.delord@gmail.com; > >>Alexander.Vainshtein@ecitele.com > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > >>Subject: RE: The status of the approaches to the E-Tree solution? > >> > >>Yes, 2 pws are only needed between pes with both root and leaf acs after > >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup > 2 > >>P2MP > >>PWs if need. There is no difference between P2MP or normal PW setup. > But, > >>can Leaf-ACs be bound to Root PE of P2MP PW? > >> > >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both > >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have > >>both root and leaf AC and some only have leaf ACs)? > >>Regards, > >>Lucy > >> > >>Regards, > >> > >>Yuqun (Sam) Cao > >>E-mail: Yuqun.cao@gmail.com > >> > >> > >>-----Original Message----- > >>From: Daniel Cohn [mailto:DanielC@orckit.com] > >>Sent: Tuesday, April 17, 2012 4:56 PM > >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); > >>giles.heron@gmail.com; > >>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > >>Subject: RE: The status of the approaches to the E-Tree solution? > >> > >>Adding Sam (as l2vpn@ is holding messages) > >> > >>DC > >> > >>-----Original Message----- > >>From: Lucy yong [mailto:lucy.yong@huawei.com] > >>Sent: Tuesday, April 17, 2012 12:39 AM > >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); > >>giles.heron@gmail.com; simon.delord@gmail.com; > >>Alexander.Vainshtein@ecitele.com > >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; > >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; > >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com > >>Subject: RE: The status of the approaches to the E-Tree solution? > >> > >> > >>Snipped, > >> > >>As we discussed extensively in the list, and as reflected in giles > >>slide, 2 pws are only needed between pes with both root and leaf acs, > >>which will typically be a small minority. > >>[[LY]] Don't know if the assumption is true. Even it is the case, both > >>approaches can benefit from it. I was off for a while and captures some > >>discussions now. > >> > >>Also as per giles slide, dual vlan can have scalability issues due to > >>additional lookup and double use of vlans in internal emulated lan > >>interface. Also there are potential backward compatibility issues with > >>silicon that doesn't support vlan mapping. > >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am > >>not clear on all the issues. Could you be more specific? As I mentioned > >>in below, two PW approach makes VPLS transport construction and packet > >>forwarding more complex, I can see potential backward compatibility > >>issues with 2 PW solution. > >> > >>Regards, > >>Lucy > >> > >>Regards, > >> > >>Daniel > >> > >>Thumb typed - please be tolerant > >> > >>Lucy yong wrote: > >> > >>In my mind, the VLAN approach means dual vlan method. > >> > >>The main concern for CW approach is hardware support. > >> > >>Two PW approach can be complex too if the VPLS instance for E-Tree uses > >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown > unicast > >>traffic, and some P2MP PWs for multicast traffic. It may double all of > >>them. > >> > >>E-tree is an Ethernet service and there is already VLAN based solution > >>in IEEE, can we just utilize it without complicating VPLS transport > >>construction? This also makes interworking with Eth only network easier. > >> > >>Cheers, > >>Lucy > >> > >>-----Original Message----- > >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] > >>Sent: Monday, April 16, 2012 8:35 AM > >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; > >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' > >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; > >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; > >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' > >>Subject: RE: The status of the approaches to the E-Tree solution? > >> > >>I believe the initial question was in regard to the CW method. Are you > >>saying that you no longer are interested in that method in preference of > >>the dual vlan method? > >> > >> > >> > >>Lucy yong wrote: > >> > >> > >>Agree with Wim. VLAN approach is the best solution for E-Tree. > >> > >>Lucy > >> > >>-----Original Message----- > >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > >>Of Henderickx, Wim (Wim) > >>Sent: Thursday, April 12, 2012 2:03 AM > >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; > >>'Alexander.Vainshtein@ecitele.com' > >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; > >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; > >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' > >>Subject: Re: The status of the approaches to the E-Tree solution? > >> > >>The vlan approach is superior as it also works for eth only networks, > >>etc. On top some vendors indicate hw issues with the cw approach. As > >>such we have dropped more or less the cw approach. > >> > >>Cheers, > >>Wim > >>_________________ > >>sent from blackberry > >> > >>----- Original Message ----- > >>From: Giles Heron [mailto:giles.heron@gmail.com] > >>Sent: Thursday, April 12, 2012 08:22 AM > >>To: Simon Delord ; Alexander Vainshtein > >> > >>Cc: l2vpn@ietf.org ; Vladimir Kleiner > >>; Andrew Sergeev > >>; Idan Kaspit ; > >>Mishael Wexler ; Rotem Cohen > >> > >>Subject: Re: The status of the approaches to the E-Tree solution? > >> > >>Sorry - the "anonymous presentation" was mine. I should possibly have > >>put in a third column on the CW approach. And hopefully the minutes > >>will be posted soon. > >> > >>We had various discussions, as Simon stated, and consensus seemed to > be > >>forming around the two alternatives of two PWEs or two VLANs. I believe > >>three of the authors of the CW approach are also authors of the two VLAN > >>approach and one is also an author of the two PWE approach. So perhaps > >>it's best to let those four individuals say which approach they prefer > >>and why? > >> > >>Giles > >> > >>On 10/04/2012 00:45, "Simon Delord" wrote: > >> > >>> Hi Alexander, > >>> > >>> You are right, no discussion on the WG mailing list recently, but > >>> there have been substantial discussions among the authors of various > >>> solution drafts off the mailing list. As far as I know, no consensus > >>> yet before ietf83, not sure the progress in the Paris WG meeting. I > >>> think the CW approach has not been rejected by the WG yet, or the WG > >>> has not yet decided on which one to adopt. > >>> > >>> Simon > >>> > >>> 2012/4/8 Alexander Vainshtein > >>> > >>>> Hi all, > >>>> > >>>> Unfortunately I have not been able to attend the Paris IETF. > >>>> > >>>> However, looking up the L2VPN proceedings, I've found a short > >>>> anonymous presentation called "E-Tree Update" ( > >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). > >>>> This presentation discusses the differences of the E-Tree approaches > >>>> based on dedicated VLANs (as in > >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t > >>>> ext=1) and multiple PWs between the PEs (as in > >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple- > pw/?in > >>>> clude_te > >>>> xt=1) > >>>> and completely ignores the solution based on usage of the CW in the > >>>> PWs connecting the PEs (as in > >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t > >>>> ext=1 > >>>> ). > >>>> > >>>> > >>>> > >>>> The Minutes of the Paris L2VPN session are not yet available, but I > >>>> wonder whether the WG has taken a decision to reject the approach > >>>> based on the CW usage? I do not remember any recent discussion of > >>>> this topic on the WG mailing list. > >>>> > >>>> > >>>> > >>>> Regards, and lots of thanks in advance, > >>>> > >>>> Sasha > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> This e-mail message is intended for the recipient only and contains > >>>> information which is CONFIDENTIAL and which may be proprietary to > ECI > >> > >>>> Telecom. If you have received this transmission in error, please > >>>> inform us by e-mail, phone or fax, and then delete the original and > >>>> all copies thereof. > >>>> > >> > >> > >> > >> > >> > >>This E-mail and any of its attachments may contain Time Warner Cable > >>proprietary information, which is privileged, confidential, or subject > >>to copyright belonging to Time Warner Cable. This E-mail is intended > >>solely for the use of the individual or entity to which it is addressed. > >>If you are not the intended recipient of this E-mail, you are hereby > >>notified that any dissemination, distribution, copying, or action taken > >>in relation to the contents of and attachments to this E-mail is > >>strictly prohibited and may be unlawful. If you have received this > >>E-mail in error, please notify the sender immediately and permanently > >>delete the original and any copy of this E-mail and any printout. > >> > > > > > >This E-mail and any of its attachments may contain Time Warner Cable > >proprietary information, which is privileged, confidential, or subject to > >copyright belonging to Time Warner Cable. This E-mail is intended solely > >for the use of the individual or entity to which it is addressed. If you > >are not the intended recipient of this E-mail, you are hereby notified > >that any dissemination, distribution, copying, or action taken in > >relation to the contents of and attachments to this E-mail is strictly > >prohibited and may be unlawful. If you have received this E-mail in > >error, please notify the sender immediately and permanently delete the > >original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely for > the use of the individual or entity to which it is addressed. If you are not > the intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify the > sender immediately and permanently delete the original and any copy of > this > E-mail and any printout. > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us > by e-mail, phone or fax, and then delete the original and all copies > thereof. > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us > by e-mail, phone or fax, and then delete the original and all copies > thereof. > This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. From yuqun.cao@gmail.com Sun Apr 22 18:30:47 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC64E21F853F for ; Sun, 22 Apr 2012 18:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=-0.407, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, J_BACKHAIR_34=1, J_BACKHAIR_43=1, 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 B3CHM-l3VEUZ for ; Sun, 22 Apr 2012 18:30:46 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id DE17421F853E for ; Sun, 22 Apr 2012 18:30:45 -0700 (PDT) Received: by dady13 with SMTP id y13so20585533dad.27 for ; Sun, 22 Apr 2012 18:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :in-reply-to:x-mimeole; bh=Ba706w03otp5/fJmdRMPUGqALpm95aXNNNKWVZB4q4M=; b=K8ZhPVjYXgAb2f3eDfQMBIyaDRsUmFURH8i0zpEBm4pbsBIeFUQWFS/uBw8oJX7V7g brWVFV9I53OyCpLGWLaWCaVKhj5sKGG+5VP2FlxKtjPaRUhFVv4EX2XYGDsm+rPHXZWl INoR600v2hyWr+y1Sd5dlzliUMqtsnw7q9yPpGJlR3x/PYnTil5nez21pSSlEJNEmoF/ KiOT3tRXM+8txrq51yQIyF1zwOEoM0Zq6D3JGs/eP5uFQeJiUbvXSWTKCCawzh46u0sE Woox5We5CBsX1zlMVOBpuCbgGaVYxZKRlY+B4QiBWRHToIU4S9aEIZ7jt0b45oXBzxya BzwQ== Received: by 10.68.220.2 with SMTP id ps2mr32526864pbc.109.1335144645710; Sun, 22 Apr 2012 18:30:45 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id 2sm12866532pbw.57.2012.04.22.18.30.39 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Apr 2012 18:30:44 -0700 (PDT) From: "Sam Cao" To: "'Rogers, Josh'" , "'Alexander Vainshtein'" , "'DelRegno, Christopher N \(Nick\)'" References: Subject: RE: The status of the approaches to the E-Tree solution? Date: Mon, 23 Apr 2012 09:30:37 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac0eWtsfXTL4ZTonTma1jYCQD0aZowClZv3w In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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, 23 Apr 2012 01:30:47 -0000 I agree with Josh's idea. But Multi-PW approach also covers the case Sasha mentioned. Operator can configure E-Tree manually without BGP AD. Sam -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Friday, April 20, 2012 2:33 AM To: Alexander Vainshtein; DelRegno, Christopher N (Nick) Cc: l2vpn@ietf.org; Daniel Cohn; Henderickx, Wim (Wim); Lucy yong; Sam Cao Subject: Re: The status of the approaches to the E-Tree solution? It is a good question, and frankly, I wouldn't want to manage a network with this solution w/out BGP-AD. (personally, I don't want to manage ANY VPLS w/out BGP-AD though. ;) ) On 4/19/12 2:30 PM, "Alexander Vainshtein" wrote: >Josh, >Lots of thanks for a prompt response. > >Yes, of course I consider BGP-AD and fully agree that with BGP-AD >(extended to distribute PE state - AFAIK, it is not part of the regular >VPLS-related NRLI) the situation becomes manageable. > >The question is, can the dual-PW solution manageable without BGP-AD? > >Regards, > Sasha > >________________________________________ >From: Rogers, Josh [josh.rogers@twcable.com] >Sent: Thursday, April 19, 2012 8:18 PM >To: Alexander Vainshtein; DelRegno, Christopher N (Nick) >Cc: l2vpn@ietf.org; Daniel Cohn; Henderickx, Wim (Wim); Lucy yong; Sam Cao >Subject: Re: The status of the approaches to the E-Tree solution? > >Sasha, > >are you considering a vantage of using BGP-AD, or no? BGP-AD isn't what >I'd call 'an elaborate' auto discovery. If BGP signaling is enlisted, >then all PE's are aware of the existence of all other PE's (regardless of >type), even if they don't setup PW to them. > >So, for your example, current Leaf PE moves to mixed PE. As soon as it >does, it updates signaling (presumably via a defined route-target), all >other PE's now know this is a Mixed PE, and set up PW's to it, just the >same as they would if a new PE was added to the instance. > >If no signaling is involved, these sorts of changes could be laborious, >but no more than any PE add/remove from an instance. > >Thanks, >-Josh > > > >On 4/19/12 12:46 PM, "Alexander Vainshtein" > wrote: > >>Nick, >>I am probably repeating myself, but please consider the case when a >>Leaf-only PE migrates to a Mix one. >> >>Prior to migration all the other Leaf PEs in this VPN did not need any >>PWs to the migrating one so there is a good chance they did not even know >>of its existence. After migration you need PWs between the migrated PE >>and all these Leaf PEs. This means that the configuration action is not >>local to a migrating PE. (PW teardown is easier, since it is enough for >>one side to initiate it, but with setup you need two to tango:-). >> >>My 2c, >> Sasha >> >> >>> -----Original Message----- >>> From: DelRegno, Christopher N (Nick) [mailto:nick.delregno@verizon.com] >>> Sent: Thursday, April 19, 2012 7:38 PM >>> To: Daniel Cohn; Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, >>> Josh; Lucy yong; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> No, I don't see a problem with setting up/tearing down a PW when there >>>is >>> a move of the root to leaf nodes or vice versa, assuming the move is >>>based >>> on a provisioning action (e.g. an customer order), not some dynamic >>> bouncing between switches. >>> >>> Nick >>> >>> -----Original Message----- >>> From: Daniel Cohn [mailto:DanielC@orckit.com] >>> Sent: Thursday, April 19, 2012 7:53 AM >>> To: DelRegno, Christopher N (Nick); Henderickx, Wim (Wim); Alexander >>> Vainshtein; Rogers, Josh; Lucy yong; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> Nick, >>> >>> Thanks for the feedback. Now, do you see a problem setting up/tearing >>> down a PW when this happens? >>> >>> Daniel >>> >>> -----Original Message----- >>> From: DelRegno, Christopher N (Nick) [mailto:nick.delregno@verizon.com] >>> Sent: Thursday, April 19, 2012 3:40 PM >>> To: Daniel Cohn; Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, >>> Josh; Lucy yong; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> Dan: >>> >>> As the transformation of a PE from Root<-->Mix and Mix<-->Leaf will be >>> driven by our customers, we can't say how often this will or won't >>>occur. It >>> must be accommodated regardless of perceived rarity. >>> >>> If I use one of our current extremely popular L2VPN services as an >>>example, >>> our customers tend to move their ENNI (e.g. Root) locations constantly, >>> quite frequently to switches which heretofore only contained UNIs (e.g. >>> leaves). >>> >>> Nick >>> >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>> Of Daniel Cohn >>> Sent: Thursday, April 19, 2012 4:49 AM >>> To: Henderickx, Wim (Wim); Alexander Vainshtein; Rogers, Josh; Lucy >>>yong; >>> Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> Hi Wim, >>> >>> That seems to me a non-negligible change to bridge forwarding logic, I >>>think >>> setting up/tearing down the PE is cleaner. I don't expect that >>>leaf-only to >>> root/leaf PE transformations will happen all that often. >>> But I think it's important to clarify that the issue is common to both >>>drafts. >>> >>> DC >>> >>> -----Original Message----- >>> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- >>> lucent.com] >>> Sent: Thursday, April 19, 2012 9:34 AM >>> To: Daniel Cohn; Alexander Vainshtein; Rogers, Josh; Lucy yong; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> Daniel, we should discuss this as this is not absolutely required to >>>tear down >>> PW. You can also have an indication in the E-TREE fwd to indicate that >>>the >>> endpoint has no leaf and as such avoid sending traffic down but allow >>>the >>> PW to be setup. As such we have some flexibility such that operators >>>can >>> select the proper approach they would like to have/implement. >>> >>> -----Original Message----- >>> From: Daniel Cohn [mailto:DanielC@orckit.com] >>> Sent: donderdag 19 april 2012 8:16 >>> To: Alexander Vainshtein; Henderickx, Wim (Wim); Rogers, Josh; Lucy >>>yong; >>> Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> Hi Sasha and all, >>> >>> You have exactly the same "problem" in the 2-VLAN approach - quoting >>> from the draft: >>> >>> 6. LDP Extensions for E-Tree Support >>> >>> P is a Leaf-only bit, it is set to 1 to indicate that the PE is >>>attached with only >>> leaves, and set to 0 otherwise. >>> >>> If the P bit is set, then: >>> >>> { >>> >>> If the PE is a leaf-only node itself, then a label release >>> message with the error code "Leaf to Leaf PW error" is sent to >>>the >>> peer PE and exit the process; >>> >>> >>> So all that you wrote about a leaf-only PE becoming mixed and viceversa >>> applies to both solutions. >>> >>> Regards, >>> >>> Daniel >>> >>> -----Original Message----- >>> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] >>> Sent: Thursday, April 19, 2012 8:31 AM >>> To: Henderickx, Wim (Wim); Rogers, Josh; Lucy yong; Daniel Cohn; Sam >>>Cao >>> Cc: l2vpn@ietf.org >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> Wim, >>> Lots of thanks for a prompt response. >>> >>> I think that operational aspects of the VLAN approach (e.g., how is the >>> Global VID selected and distributed) should be examined in more detail. >>> >>> At the same time it seems that the double PW approach carries with it >>>too >>> many operational problems. >>> E.g., no PWs are set up between Leaf-only PEs, but once one of these >>> becomes a Mix PE, all the Leaf-only PEs must now recognize it as a >>>valid >>> peer. And if a Mix PE reverts to a Leaf only one, all its Leaf-only >>>peers must >>> drop it and shut down the relevant PWs... >>> >>> My 2c, >>> Sasha >>> >>> ________________________________________ >>> From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] >>> Sent: Thursday, April 19, 2012 7:21 AM >>> To: Alexander Vainshtein; Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> Sasha, the VLAN approach allows for a similar operation as the CW does. >>> It is orthogonal to the underlying PW deployment of VPLS. >>> >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>> Of Alexander Vainshtein >>> Sent: donderdag 19 april 2012 6:39 >>> To: Rogers, Josh; Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> Hi all, >>> I fully understand that that what I am going to say is not very >>>popular, >>> but: >>> >>> IMO one of the advantages of the CW-based solution is that it is >>>orthogonal >>> to usage (or non-usage) of P2MP PWs for effective delivery of BUN >>>traffic. >>> >>> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>>and, in >>> a more generic way, localization of effects of changes in the PE >>> configuration. >>> >>> In particular, adding a Leaf AC to a PE that previously has been only >>> supporting Root ACs (or vice versa), removal of the last Leaf or last >>>Root AC >>> from a PE that previously has been supporting a mix etc. affect only >>>the PE >>> where this operation happens and not the rest of the PEs. >>> >>> As for the need for HW changes that have been mentioned as a main >>> disadvantage of the CW-based approach - I believe it strongly depends >>>on >>> specific implementations. And some changes in the forwarding process >>>are >>> required in any solution. >>> >>> My 2c, >>> Sasha >>> >>> >>> >>> ________________________________________ >>> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of >>> Rogers, Josh [josh.rogers@twcable.com] >>> Sent: Wednesday, April 18, 2012 9:57 PM >>> To: Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: Re: The status of the approaches to the E-Tree solution? >>> >>> Again, the P2MP situation throws me. Is this something that is used >>> commonly? >>> >>> I'm under the impression that adding P2MP to any model results in a >>>more >>> complex model. Wether outside s-tag is used to differentiate, or >>>dedicated >>> pw's are used for the same purpose, it seems both become more complex. >>> >>> Gile's comparison slide still concisely captures the differences >>>between >>> these methods, in my opinion. I haven't seen any new ideas or thoughts >>> brought to the group in the past week or two on the subject. I would >>>hate >>> for both proposed methods to die on the vine because we couldn't decide >>> between two methods that have nothing inherently wrong with either. >>> >>> -Josh >>> >>> >>> On 4/18/12 1:53 PM, "Lucy yong" wrote: >>> >>> >Send this again. >>> > >>> >Two PW approach can be complex too if the VPLS instance for E-Tree >>>uses >>> >P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>> >unicast traffic, and some P2MP PWs for multicast traffic. It may >>>double >>> >all of them. >>> > >>> >Lucy >>> > >>> >-----Original Message----- >>> >From: Daniel Cohn [mailto:DanielC@orckit.com] >>> >Sent: Wednesday, April 18, 2012 1:42 PM >>> >To: Lucy yong; Rogers, Josh; Sam Cao >>> >Cc: l2vpn@ietf.org >>> >Subject: RE: The status of the approaches to the E-Tree solution? >>> > >>> >I think the first option its the natural way to go. How is the >>> processing >>> >in this case more complex? >>> > >>> >Thumb typed - please be tolerant >>> > >>> >Lucy yong wrote: >>> > >>> > >>> > >>> >Snipped.. >>> > >>> >Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >>> PW >>> >(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >>> >traffic coming from a root AC) [[LY]] Not that simple. You construct >>> >either two P2MP PWs to all other PEs and let egress PE performing >>> >filtering, or construct one P2MP PW to leaf-only PEs and two P2MP PWs >>> >to root and leaf PEs and let ingress PE perform forwarding and >>> >filtering. Both make node process complex. >>> > >>> >[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>> >delivering the frames to remote PEs. We should utilize them with the >>> >minimized changes. Dual VLAN solution is simpler than Dual PW. >>> > >>> >Regards, >>> >Lucy >>> > >>> > >>> >I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>> >haven't had any first hand experience with P2MP PW's, however, so >>>don't >>> >feel terribly strong about this objection. Is this a real problem for >>> >others (now or in the future), or is this objection in the weeds? >>> > >>> >I'm not sure the 'additional complexity' is notable, or even relevant. >>> I >>> >encourage others to speak up if they disagree, as P2MP PW is only >>> >conceptual to me, and I am unfamiliar with real-life use cases for it. >>> > >>> >Thanks, >>> >Josh >>> > >>> > >>> > >>> >On 4/18/12 10:30 AM, "Lucy yong" wrote: >>> > >>> >>Please see inline. >>> >> >>> >>-----Original Message----- >>> >>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>> >>Sent: Tuesday, April 17, 2012 7:14 AM >>> >>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>(Wim)'; >>> >>giles.heron@gmail.com; simon.delord@gmail.com; >>> >>Alexander.Vainshtein@ecitele.com >>> >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>> >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>> >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >>> >> >>> >>Yes, 2 pws are only needed between pes with both root and leaf acs >>> after >>> >>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup >>> 2 >>> >>P2MP PWs if need. There is no difference between P2MP or normal PW >>> >>setup. >>> But, >>> >>can Leaf-ACs be bound to Root PE of P2MP PW? >>> >> >>> >>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>> both >>> >>root and leaf ACs set up two or one P2MP PW to other PEs (some PE >>>have >>> >>both root and leaf AC and some only have leaf ACs)? >>> >>Regards, >>> >>Lucy >>> >> >>> >>Regards, >>> >> >>> >>Yuqun (Sam) Cao >>> >>E-mail: Yuqun.cao@gmail.com >>> >> >>> >> >>> >>-----Original Message----- >>> >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>> >>Sent: Tuesday, April 17, 2012 4:56 PM >>> >>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>> >>giles.heron@gmail.com; simon.delord@gmail.com; >>> >>Alexander.Vainshtein@ecitele.com; Sam Cao >>> >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>> >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>> >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >>> >> >>> >>Adding Sam (as l2vpn@ is holding messages) >>> >> >>> >>DC >>> >> >>> >>-----Original Message----- >>> >>From: Lucy yong [mailto:lucy.yong@huawei.com] >>> >>Sent: Tuesday, April 17, 2012 12:39 AM >>> >>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>> >>giles.heron@gmail.com; simon.delord@gmail.com; >>> >>Alexander.Vainshtein@ecitele.com >>> >>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>> >>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>> >>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >>> >> >>> >> >>> >>Snipped, >>> >> >>> >>As we discussed extensively in the list, and as reflected in giles >>> >>slide, 2 pws are only needed between pes with both root and leaf acs, >>> >>which will typically be a small minority. >>> >>[[LY]] Don't know if the assumption is true. Even it is the case, >>>both >>> >>approaches can benefit from it. I was off for a while and captures >>> some >>> >>discussions now. >>> >> >>> >>Also as per giles slide, dual vlan can have scalability issues due to >>> >>additional lookup and double use of vlans in internal emulated lan >>> >>interface. Also there are potential backward compatibility issues >>>with >>> >>silicon that doesn't support vlan mapping. >>> >>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >>> am >>> >>not clear on all the issues. Could you be more specific? As I >>> mentioned >>> >>in below, two PW approach makes VPLS transport construction and >>>packet >>> >>forwarding more complex, I can see potential backward compatibility >>> >>issues with 2 PW solution. >>> >> >>> >>Regards, >>> >>Lucy >>> >> >>> >>Regards, >>> >> >>> >>Daniel >>> >> >>> >>Thumb typed - please be tolerant >>> >> >>> >>Lucy yong wrote: >>> >> >>> >>In my mind, the VLAN approach means dual vlan method. >>> >> >>> >>The main concern for CW approach is hardware support. >>> >> >>> >>Two PW approach can be complex too if the VPLS instance for E-Tree >>> uses >>> >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>> unicast >>> >>traffic, and some P2MP PWs for multicast traffic. It may double all >>>of >>> >>them. >>> >> >>> >>E-tree is an Ethernet service and there is already VLAN based >>>solution >>> >>in IEEE, can we just utilize it without complicating VPLS transport >>> >>construction? This also makes interworking with Eth only network >>> easier. >>> >> >>> >>Cheers, >>> >>Lucy >>> >> >>> >>-----Original Message----- >>> >>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>> >>Sent: Monday, April 16, 2012 8:35 AM >>> >>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>> >>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>> >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>> >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>> >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >>> >> >>> >>I believe the initial question was in regard to the CW method. Are >>> you >>> >>saying that you no longer are interested in that method in preference >>> of >>> >>the dual vlan method? >>> >> >>> >> >>> >> >>> >>Lucy yong wrote: >>> >> >>> >> >>> >>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >> >>> >>Lucy >>> >> >>> >>-----Original Message----- >>> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>> Behalf >>> >>Of Henderickx, Wim (Wim) >>> >>Sent: Thursday, April 12, 2012 2:03 AM >>> >>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>> >>'Alexander.Vainshtein@ecitele.com' >>> >>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>> >>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>> >>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>> >>Subject: Re: The status of the approaches to the E-Tree solution? >>> >> >>> >>The vlan approach is superior as it also works for eth only networks, >>> >>etc. On top some vendors indicate hw issues with the cw approach. As >>> >>such we have dropped more or less the cw approach. >>> >> >>> >>Cheers, >>> >>Wim >>> >>_________________ >>> >>sent from blackberry >>> >> >>> >>----- Original Message ----- >>> >>From: Giles Heron [mailto:giles.heron@gmail.com] >>> >>Sent: Thursday, April 12, 2012 08:22 AM >>> >>To: Simon Delord ; Alexander Vainshtein >>> >> >>> >>Cc: l2vpn@ietf.org ; Vladimir Kleiner >>> >>; Andrew Sergeev >>> >>; Idan Kaspit ; >>> >>Mishael Wexler ; Rotem Cohen >>> >> >>> >>Subject: Re: The status of the approaches to the E-Tree solution? >>> >> >>> >>Sorry - the "anonymous presentation" was mine. I should possibly >>>have >>> >>put in a third column on the CW approach. And hopefully the minutes >>> >>will be posted soon. >>> >> >>> >>We had various discussions, as Simon stated, and consensus seemed to >>> be >>> >>forming around the two alternatives of two PWEs or two VLANs. I >>> believe >>> >>three of the authors of the CW approach are also authors of the two >>> VLAN >>> >>approach and one is also an author of the two PWE approach. So >>>perhaps >>> >>it's best to let those four individuals say which approach they >>>prefer >>> >>and why? >>> >> >>> >>Giles >>> >> >>> >>On 10/04/2012 00:45, "Simon Delord" wrote: >>> >> >>> >>> Hi Alexander, >>> >>> >>> >>> You are right, no discussion on the WG mailing list recently, but >>> >>> there have been substantial discussions among the authors of >>>various >>> >>> solution drafts off the mailing list. As far as I know, no >>>consensus >>> >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>> >>> think the CW approach has not been rejected by the WG yet, or the >>>WG >>> >>> has not yet decided on which one to adopt. >>> >>> >>> >>> Simon >>> >>> >>> >>> 2012/4/8 Alexander Vainshtein >>> >>> >>> >>>> Hi all, >>> >>>> >>> >>>> Unfortunately I have not been able to attend the Paris IETF. >>> >>>> >>> >>>> However, looking up the L2VPN proceedings, I've found a short >>> >>>> anonymous presentation called "E-Tree Update" ( >>> >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>> >>>> This presentation discusses the differences of the E-Tree >>> approaches >>> >>>> based on dedicated VLANs (as in >>> >>>> >>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>> >>>> ext=1) and multiple PWs between the PEs (as in >>> >>>> >>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>> >>>> clude_te >>> >>>> xt=1) >>> >>>> and completely ignores the solution based on usage of the CW in >>>the >>> >>>> PWs connecting the PEs (as in >>> >>>> >>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>> >>>> ext=1 >>> >>>> ). >>> >>>> >>> >>>> >>> >>>> >>> >>>> The Minutes of the Paris L2VPN session are not yet available, but >>>I >>> >>>> wonder whether the WG has taken a decision to reject the approach >>> >>>> based on the CW usage? I do not remember any recent discussion of >>> >>>> this topic on the WG mailing list. >>> >>>> >>> >>>> >>> >>>> >>> >>>> Regards, and lots of thanks in advance, >>> >>>> >>> >>>> Sasha >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> This e-mail message is intended for the recipient only and >>>contains >>> >>>> information which is CONFIDENTIAL and which may be proprietary to >>> ECI >>> >> >>> >>>> Telecom. If you have received this transmission in error, please >>> >>>> inform us by e-mail, phone or fax, and then delete the original >>>and >>> >>>> all copies thereof. >>> >>>> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >>This E-mail and any of its attachments may contain Time Warner Cable >>> >>proprietary information, which is privileged, confidential, or >>>subject >>> >>to copyright belonging to Time Warner Cable. This E-mail is intended >>> >>solely for the use of the individual or entity to which it is >>> addressed. >>> >>If you are not the intended recipient of this E-mail, you are hereby >>> >>notified that any dissemination, distribution, copying, or action >>> taken >>> >>in relation to the contents of and attachments to this E-mail is >>> >>strictly prohibited and may be unlawful. If you have received this >>> >>E-mail in error, please notify the sender immediately and permanently >>> >>delete the original and any copy of this E-mail and any printout. >>> >> >>> > >>> > >>> >This E-mail and any of its attachments may contain Time Warner Cable >>> >proprietary information, which is privileged, confidential, or subject >>> to >>> >copyright belonging to Time Warner Cable. This E-mail is intended >>> solely >>> >for the use of the individual or entity to which it is addressed. If >>> you >>> >are not the intended recipient of this E-mail, you are hereby notified >>> >that any dissemination, distribution, copying, or action taken in >>> >relation to the contents of and attachments to this E-mail is strictly >>> >prohibited and may be unlawful. If you have received this E-mail in >>> >error, please notify the sender immediately and permanently delete the >>> >original and any copy of this E-mail and any printout. >>> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>> proprietary information, which is privileged, confidential, or subject >>>to >>> copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for >>> the use of the individual or entity to which it is addressed. >>> If you are not the intended recipient of this E-mail, you are hereby >>>notified >>> that any dissemination, distribution, copying, or action taken in >>>relation to >>> the contents of and attachments to this E-mail is strictly prohibited >>>and may >>> be unlawful. If you have received this E-mail in error, please notify >>>the >>> sender immediately and permanently delete the original and any copy of >>> this E-mail and any printout. >>> This e-mail message is intended for the recipient only and contains >>> information which is CONFIDENTIAL and which may be proprietary to ECI >>> Telecom. If you have received this transmission in error, please inform >>>us by >>> e-mail, phone or fax, and then delete the original and all copies >>>thereof. >>> This e-mail message is intended for the recipient only and contains >>> information which is CONFIDENTIAL and which may be proprietary to ECI >>> Telecom. If you have received this transmission in error, please inform >>>us by >>> e-mail, phone or fax, and then delete the original and all copies >>>thereof. >> >> >>This e-mail message is intended for the recipient only and contains >>information which is CONFIDENTIAL and which may be proprietary to ECI >>Telecom. If you have received this transmission in error, please inform >>us by e-mail, phone or fax, and then delete the original and all copies >>thereof. >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. >This e-mail message is intended for the recipient only and contains >information which is CONFIDENTIAL and which may be proprietary to ECI >Telecom. If you have received this transmission in error, please inform >us by e-mail, phone or fax, and then delete the original and all copies >thereof. > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From yuqun.cao@gmail.com Sun Apr 22 18:58:10 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E3E21F8587 for ; Sun, 22 Apr 2012 18:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.27 X-Spam-Level: X-Spam-Status: No, score=-1.27 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 VPpwib+Z9pzM for ; Sun, 22 Apr 2012 18:58:07 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id BD70221F8581 for ; Sun, 22 Apr 2012 18:58:07 -0700 (PDT) Received: by dady13 with SMTP id y13so20614518dad.27 for ; Sun, 22 Apr 2012 18:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:in-reply-to:x-mimeole; bh=2Bih6CMpYNjXBCI41JtbG+LfSAIFTvpAaMcXwudD55s=; b=pIcSi4zl5k/QH2nrDou0n02jBxHXefKcLa6iHH7mFwqN5wEwEc36ERnLit7CFko+cp vbYTapw5cH6nqhe7heb7E7yBA0KwHqUzStXbGwFjOcVrnNJ15QbHkmKdfog8MUWBWUoN zoZB+sTkZM0sqX3IAeMDoZfVL7LzDol5tm82xzcs0RBXJ+h+OD2TZXJoMFO2DCJRfti8 RRHMsGnPxyfBxVWD2ab6XRiJuo8GUghMuEwGyav8/wX/ICTaKITO8iTDku/m6UkLHiVO xzgf6kcLiCL/2Cjf2PuV0qi5OWAsG1DfMlouP7xkCG5vbC4cGC8RCN0EtSuZ5HOWoAiN fyow== Received: by 10.68.232.101 with SMTP id tn5mr7443553pbc.97.1335146287279; Sun, 22 Apr 2012 18:58:07 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id ph10sm12944650pbb.2.2012.04.22.18.57.49 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Apr 2012 18:58:05 -0700 (PDT) From: "Sam Cao" To: "'Alexander Vainshtein'" References: , <14C7F4F06DB5814AB0DE29716C4F6D6701296244C3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>, , <1B88357C808B432E871CA9D678305B7C@v2comsam> <6F9ADEDA06A04AB98C247D303AFE93BE@v2comsam> Subject: RE: The status of the approaches to the E-Tree solution? Date: Mon, 23 Apr 2012 09:57:40 +0800 Message-ID: <27D84E1D94844A3B8ABDB500370CDE70@R01842> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01CD2137.90090300" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AQHNHxPnvCW4Idac1kehO7tUxP5nzJaj1eOAgACwqQCAALY7AIAAC0AAgAFzRgCAACHU8IAACSVggAAKQVCAALMosA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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, 23 Apr 2012 01:58:10 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0013_01CD2137.90090300 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Sasha, =20 Yes, I agree. =20 =20 But IMHO Legacy PE can be Root-only PE, not be Leaf-Only PE, since there = is no communication limit between PEs in VPLS domain. Generally VPLS is deployed in Full-Mesh, although we can deploy it in Hub-Spoke. Hub-Spoke = is NOT typical deployment. With Hub-Spoke, we can specify one PE as = Leaf-only PE manually (Use RT with BGP-AD, or manually configure PW wi/out = BGP-AD), but the configuration seems too complex. That is why I prefer to = Multi-PW or Dual-VLAN approach, not CW approach.=20 =20 For CW, no control-word, no E-tree, but CW is just optional. =20 Thanks, =20 Sam =20 _____ =20 From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Sunday, April 22, 2012 10:57 PM To: Sam Cao Cc: l2vpn@ietf.org; 'Raymond Key' Subject: RE: The status of the approaches to the E-Tree solution? =20 Sam, I will try to explain myself. =20 I have misspoken before, and I owe you an apology. =20 A true legacy PE cannot operate as a Mixed PE for E-tree since this operation requires some changes in the forwarding behavior. This is IMHO correct regardless of the specific E-tree solution that is implemented = by the rest of the PEs (CW-based, dual PW-based or VLAN-based). I.e. = without some additional implementation-specific tricks it can be either a = Root-only PE or a Leaf-only PE in the VPLS that does not contain Mixed PEs. =20 Regards, Sasha =20 From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Sunday, April 22, 2012 5:22 PM To: Alexander Vainshtein Cc: l2vpn@ietf.org; 'Raymond Key' Subject: RE: The status of the approaches to the E-Tree solution? =20 Sasha, =20 I agree with your comments. But maybe I don=A1=AFt make myself = understood. I make it clear. =20 If one chip can not support control word, then one switch which uses = this chip can not work as Root-Leaf-Mixed PE since we can not extend it. Is = this correct? Is this reasonable? =20 Anyway, chip limit is big problem for CW approach. =20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 _____ =20 From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Sunday, April 22, 2012 9:56 PM To: Sam Cao Cc: l2vpn@ietf.org; 'Raymond Key' Subject: RE: The status of the approaches to the E-Tree solution? =20 Sam, You=A1=AFve asked: If it only supports VPLS, ok, it can work as Root-only, but why it = cannot work as Root-Leaf-Mixed or Leaf-only if it cannot support CW? IMHO and FWIW there is not too much you can expect from a true legacy PE = (i. e. a PE that did not change its forwarding behavior): 1. It can obviously support Root-only functionality 2. It can support Leaf-only functionality if there are no Mixed by preventing setup PW (by not setting up PWs to other Leaf-only PEs). Anything beyond that would be very much implementation-specific. E.g., I = am aware of legacy implementations that could support functionality of a = Mixed PE provided that it would be the only Mixed PE in the VPLS instance, and other legacy implementations that are, as legacy, fully interoperable = with these ones but could not support such functionality. =20 My 2c, Sasha =20 From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Sam Cao Sent: Sunday, April 22, 2012 4:41 PM To: 'Raymond Key' Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? =20 Raymond, =20 Network efficiency: [Sam] Leaf/Root configuration is local configuration, and PE can not = know remote AC type configuration. This is CW Fundamentals. So even if CW approach defines optional enhancement for Leaf-Only PE, but can not = signal it between Leaf-Only PEs, so there is no good way to support this. The possible solution is, manually configure hub-spoke topology, but if we = do like this, current solutions have support most E-Tree cases with = Hub-Spoke configuration. Lizhong mentioned this in one mail. =20 Backwards compatibility: [Sam] Yes, new draft considers backward compatibility, but it makes precondition: The PE which can not support Control word only works as Root-only PE. This does not make sense for me. If it only supports VPLS, = ok, it can work as Root-only, but why it can not work as Root-Leaf-Mixed or Leaf-only if it can not support CW? =20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 _____ =20 From: raymond.key@hotmail.com [mailto:raymond.key@hotmail.com] On Behalf = Of Raymond Key Sent: Saturday, April 21, 2012 11:32 PM To: yuqun.cao@gmail.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? =20 Some clarifications [RK] inserted below Thanks Raymond Key _____ =20 From: yuqun.cao@gmail.com To: lizho.jin@gmail.com; wim.henderickx@alcatel-lucent.com Subject: RE: The status of the approaches to the E-Tree solution? Date: Sat, 21 Apr 2012 22:51:28 +0800 CC: l2vpn@ietf.org Hi all, =20 We reach an impasse:-). BTW, Meeting minutes is ready now. We can get E-tree summary from IETF site. =20 Today I collected all items we discussed before. They are, =20 1) Silicon issue or chip limit; 2) Network efficiency; 3) Encapsulation mode, tag or raw; 4) H-VPLS; 5) Backwards compatibility, especially legacy PE or Non-supporting = PE with IEEE E-tree support joins E-Tree domain; 6) Configuration change in operation, for example, Leaf-only -> Root-Leaf-Mixed; 7) S-VLAN preservation support; 8) Multi-segment PW; 9) VLAN ID allocation (Only for Dual-VLAN); 10) Multi-AS deployment; 11) ECMP; 12) P2MP-PW; 13) Ethernet OAM; =20 If we review the mail-list, CW approach has the following limits: 1) Chip limit. Please read reply from Giles and Wim; 2) Network efficiency: There are garbage fames which will be = dropped on egress PE since only egress PE can decide forward or drop frames = while it receives frames. Ingress PE can not decide forward or not. Yes, current solution can support Hub-Spoke configuration, but as we know, the configuration is not easy if the network is big. Dual-VLAN or Multi-PW approach can break communication between Leaf-Only PEs via signaling. [RK] It seems to me this is not the case. Section 6 of the draft has = some discussions on this. http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-6 6. Optional Enhancements for Leaf-only PE 6.1. No PW between Leaf-only PEs 6.2. Not Forward Frame from Leaf AC to Leaf-only PE =20 3) Backwards compatibility: Not all PEs supports control word. If = one can not support control word, it will not join E-Tree domain; =20 [RK] It seems to me this is not the case. Section 5 of the draft has = some discussions on this. http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-5 5. Backward Compatibility 5.1. AC Type 5.2. Control Word 5.3. Additional Action in Data Forwarding 5.3.1. Ingress PE Supporting the Extension but Egress PE Not 5.3.2. Egress PE Supporting the Extension but Ingress PE Not =20 Dual VLAN has following limits: 1) Chip limit: As we know, we need to push one VLAN into frames = before MPLS encapsulation on ingress PE and stripe it out on egress PE. This is non-standard operation. Wait for confirmation from chip vendor; 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, but can NOT configure it at all in Spoke PW case; 3) Multi-PW: Rafi figures this out, but we don=A1=AFt think this = over at that time. I think that it also has same problem as H-VPLS has. 4) Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will stripe = S-VLAN ID; 5) Backward Compatibility: Just as Daniel mentioned, there is compatibility issue if legacy PE joins E-Tree domain. For me, I = don=A1=AFt get clear response from co-authors of Dual-VLAN. =20 For all approaches, we don=A1=AFt cover ECMP / Ethernet OAM till now.=20 =20 Is there anything missed?=20 =20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 _____ =20 From: Lizhong Jin [mailto:lizho.jin@gmail.com]=20 Sent: Saturday, April 21, 2012 11:59 AM To: Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; = yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? =20 Hi Win, Thank you for the answers. In that case, PE-rs should configure the root/leaf properties of VPWS, not on the remote PE of VPWS. And usually = on PE-rs, you could not figure out the accessing spoke PW is from PE-r of = VPWS or MTU-s. Unless having some additional indication in NMS, you even = don't know which spoke PW needs to do VLAN manipulation. I am not sure such = R/L configuration could be accepted from operational view. Hope to see more comments. Regards Lizhong =D4=DA 2012=C4=EA4=D4=C221=C8=D5=D0=C7=C6=DA=C1=F9=A3=ACHenderickx, Wim = (Wim) =D0=B4=B5=C0=A3=BA > The VPWS which terminates at the H-VPLS node is indicated to be root = or leaf and the procedures associated will do the VLAN manipulation > > =20 > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Lizhong Jin > Sent: vrijdag 20 april 2012 18:38 > To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com > Cc: yuqun.cao@gmail.com > Subject: RE: The status of the approaches to the E-Tree solution? > > =20 > > Hi, all, > The difference between 2-VLAN and CW approach is who will provide the = R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW = will carry R/L information for CW approach. > I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used = to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information? > > Thanks > Lizhong > >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 Apr 2012 04:38:36 +0000 >> From: Alexander Vainshtein >> To: "Rogers, Josh" , Lucy yong >> , Daniel Cohn , Sam = Cao >> >> Cc: "l2vpn@ietf.org" >> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID: >> = >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi all, >> I fully understand that that what I am going to say is not very = popular, but: >> >> IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, = and, in a more generic way, localization of effects of changes in the PE configuration. >> >> In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect only = the PE where this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a = more >> complex model. Wether outside s-tag is used to differentiate, or >> dedicated pw's are used for the same purpose, it seems both become = more >> complex. >> >> Gile's comparison slide still concisely captures the differences = between >> these methods, in my opinion. I haven't seen any new ideas or = thoughts >> brought to the group in the past week or two on the subject. I would hate >> for both proposed methods to die on the vine because we couldn't = decide >> between two methods that have nothing inherently wrong with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" wrote: >> >>>Send this again. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree = uses >>>P2P PW fo=20 This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies thereof.=20 This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies thereof.=20 ------=_NextPart_000_0013_01CD2137.90090300 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Sasha,<= /span>

 <= /span>

Yes, I agree. =  

 <= /span>

But IMHO Legacy = PE can be Root-only PE, not be Leaf-Only PE, since there is no communication limit between PEs in VPLS domain. Generally VPLS is deployed in Full-Mesh, = although we can deploy it in Hub-Spoke. Hub-Spoke is NOT typical deployment. With Hub-Spoke, we can specify one PE as Leaf-only PE manually (Use RT with = BGP-AD, or manually configure PW wi/out BGP-AD), but the configuration seems too = complex. That is why I prefer to Multi-PW or Dual-VLAN approach, not CW approach. =

 <= /span>

For CW, no = control-word, no E-tree, but CW is just optional.

 <= /span>

Thanks,=

 <= /span>

Sam

 <= /span>

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Sunday, April 22, = 2012 10:57 PM
To: Sam Cao
Cc: l2vpn@ietf.org; = 'Raymond Key'
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Sam,

I will try = to explain myself.

 <= /o:p>

I have = misspoken before, and I owe you an apology.

 <= /o:p>

A true = legacy PE cannot operate as a Mixed PE for E-tree since this operation requires = some changes in the forwarding behavior. This is IMHO correct regardless of the specific E-tree solution = that is implemented by the rest of the PEs (CW-based, dual PW-based = or VLAN-based). I.e. without some additional implementation-specific tricks = it can be either a Root-only PE or a Leaf-only PE in the VPLS that does not = contain Mixed PEs.

 <= /o:p>

Regards,

  =    Sasha

 <= /o:p>

From: Sam Cao [mailto:yuqun.cao@gmail.com]
Sent: Sunday, April 22, = 2012 5:22 PM
To: Alexander = Vainshtein
Cc: l2vpn@ietf.org; = 'Raymond Key'
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Sasha,<= /span>

 <= /span>

I agree with your comments. But maybe I don=A1=AFt make myself understood. I make it = clear.

 <= /span>

If one chip can = not support control word, then one switch which uses this chip can not work = as Root-Leaf-Mixed PE since we can not extend it. Is this correct? Is this reasonable?

 <= /span>

Anyway, chip = limit is big problem for CW approach.

 <= /span>

Regards,

 

=

Yuqun (Sam) Cao

E-mail: Yuqun.cao@gmail.com

 

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Sunday, April 22, = 2012 9:56 PM
To: Sam Cao
Cc: l2vpn@ietf.org; = 'Raymond Key'
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Sam,

You=A1=AFve = asked:

If it only supports VPLS, ok, it can = work as Root-only, but why it cannot work as Root-Leaf-Mixed or Leaf-only if it = cannot support CW?

IMHO and = FWIW there is not too much you can expect from a true legacy PE (i.e. a PE that did = not change its forwarding behavior):

1.       It can obviously support Root-only = functionality

2.       It can support Leaf-only functionality if there are no = Mixed by preventing setup PW (by not setting up PWs to other Leaf-only = PEs).

Anything = beyond that would be very much implementation-specific. E.g., I am aware of legacy implementations that could support functionality of a Mixed PE provided = that it would be the only Mixed PE in the VPLS instance, and other = legacy implementations that are, as legacy, fully interoperable with these ones = but could not support such functionality.

 <= /o:p>

My = 2c,

  =    Sasha

 <= /o:p>

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Sam Cao
Sent: Sunday, April 22, = 2012 4:41 PM
To: 'Raymond Key'
Cc: l2vpn@ietf.org
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Raymond,

 <= /span>

Network = efficiency:

[Sam] Leaf/Root configuration is local configuration, and PE can not know remote AC type configuration. This is CW Fundamentals. So even if CW approach defines = optional enhancement for Leaf-Only PE, but can not signal it between Leaf-Only = PEs, so there is no good way to support this. The possible solution is, manually configure hub-spoke topology, but if we do like this, current solutions = have support most E-Tree cases with Hub-Spoke configuration. Lizhong = mentioned this in one mail.

 <= /span>

Backwards = compatibility:

[Sam] Yes, new = draft considers backward compatibility, but it makes precondition: The PE = which can not support Control word only works as Root-only PE. This does not make = sense for me. If it only supports VPLS, ok, it can work as Root-only, but why = it can not work as Root-Leaf-Mixed or Leaf-only if it can not support = CW?

 <= /span>

Regards,

 

=

Yuqun (Sam) Cao

E-mail: Yuqun.cao@gmail.com

 

From: raymond.key@hotmail.com [mailto:raymond.key@hotmail.com] On Behalf Of Raymond Key
Sent: Saturday, April 21, = 2012 11:32 PM
To: = yuqun.cao@gmail.com
Cc: l2vpn@ietf.org
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Some clarifications [RK] inserted = below

Thanks

Raymond Key

From: yuqun.cao@gmail.com
To: lizho.jin@gmail.com; wim.henderickx@alcatel-lucent.com
Subject: RE: The status of the approaches to the E-Tree solution?
Date: Sat, 21 Apr 2012 22:51:28 +0800
CC: l2vpn@ietf.org

Hi all,

 

We reach an = impasseJ.  BTW, Meeting minutes is ready now. We can get E-tree summary from = IETF site.

 

Today I collected all items = we discussed before. They are,

 

1)       = Silicon issue or chip limit;

2)       = Network efficiency;

3)       = Encapsulation mode, tag or raw;

4)       = H-VPLS;

5)       = Backwards compatibility, especially legacy PE or Non-supporting PE with IEEE = E-tree support joins E-Tree domain;

6)       = Configuration change in operation, for example, Leaf-only -> = Root-Leaf-Mixed;

7)       = S-VLAN preservation support;

8)       = Multi-segment PW;

9)       = VLAN ID allocation (Only for Dual-VLAN);

10)   Multi-AS deployment;

11)   ECMP;

12)   P2MP-PW;

13)   Ethernet OAM;

 

If we review the mail-list, CW approach has the following limits:

1)       = Chip limit. Please read reply from Giles = and Wim;

2)       = Network efficiency: There are garbage = fames which will be dropped on egress PE since only egress PE can decide forward or = drop frames while it receives frames. Ingress PE can not decide = forward or not. Yes, current solution can support Hub-Spoke configuration, but as we = know, the configuration is not easy if the network is big. Dual-VLAN or Multi-PW = approach can break communication between Leaf-Only PEs via = signaling.

[RK] It seems to me this is not the case. = Section 6 of the draft has some discussions on this.
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-6=
6. Optional Enhancements for Leaf-only PE
6.1. No PW between Leaf-only PEs
6.2. Not Forward Frame from Leaf AC to Leaf-only PE

 

3)       = Backwards compatibility: Not all PEs = supports control word. If one can not support control word, it will not join = E-Tree domain;

 

[RK] It seems to = me this is not the case. Section 5 of the draft has some discussions on = this.
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-5=
5. Backward Compatibility
5.1. AC Type
5.2. Control Word
5.3. Additional Action in Data Forwarding
5.3.1. Ingress PE Supporting the Extension but Egress PE Not
5.3.2. Egress PE Supporting the Extension but Ingress PE Not

 

Dual VLAN has = following limits:

1)       = Chip limit: As we know, we need to push = one VLAN into frames before MPLS encapsulation on ingress PE and stripe it out on = egress PE. This is non-standard operation. Wait for confirmation from chip = vendor;

2)       = HVPLS: If we follow Fig 3 or Fig = 4 in RFC 4762 to deploy = HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, = but can NOT configure it at all in Spoke PW case;

3)       = Multi-PW: Rafi figures this out, but we = don=A1=AFt think this over at that time. I think that it also has same problem as = H-VPLS has.

4)       = Encapsulation mode: If deploy GVPLS with = Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE = will stripe S-VLAN ID;

5)       = Backward Compatibility: Just as Daniel = mentioned, there is compatibility issue if legacy PE joins E-Tree domain. For me, I = don=A1=AFt get clear response from co-authors of Dual-VLAN.

 

For all = approaches, we don=A1=AFt cover ECMP / Ethernet OAM till now.

 

Is there anything = missed?

 

Regards,

 

Yuqun = (Sam) Cao

E-mail: = Yuqun.cao@gmail.com =

 

From: Lizhong Jin [mailto:lizho.jin@gmail.com]
Sent: Saturday, April 21, = 2012 11:59 AM
To: Henderickx, Wim = (Wim)
Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; yuqun.cao@gmail.com
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Hi Win,
Thank you for the answers. In that case, PE-rs should configure the = root/leaf properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, = you could not figure out the accessing spoke PW is from PE-r of VPWS or = MTU-s. Unless having some additional indication in NMS, you even don't know = which spoke PW needs to do VLAN manipulation. I am not sure such R/L = configuration could be accepted from operational view. Hope to see more comments.

Regards
Lizhong


=D4=DA 2012=C4=EA4=D4=C221=C8=D5=D0=C7=C6=DA=C1=F9=A3=ACHenderickx, Wim (Wim) <wim.henderickx@alcatel-= lucent.com> =D0=B4=B5=C0=A3=BA
> The VPWS which terminates at the H-VPLS node is indicated to be = root or leaf and the procedures associated will do the VLAN manipulation
>
>  
>
> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin
> Sent: vrijdag 20 april 2012 18:38
> To: l2vpn@ietf.org; Alexander.Vainshtein@eci= tele.com
> Cc: yuqun.cao@gmail.com
> Subject: RE: The status of the approaches to the E-Tree = solution?
>
>  
>
> Hi, all,
> The difference between 2-VLAN and CW approach is who will provide = the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW = will carry R/L information for CW approach.
> I have a question with the 2-VLAN approach in H-VPLS where H-VPLS = is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds = VLAN to indicate R/L information?
>
> Thanks
> Lizhong
>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 19 Apr 2012 04:38:36 +0000
>> From: Alexander Vainshtein <Alexander.Vainshtein@eci= tele.com>
>> To: "Rogers, Josh" <josh.rogers@twcable.com>, = Lucy yong
>>        <lucy.yong@huawei.com>, Daniel Cohn <DanielC@orckit.com>, Sam Cao
>>        <yuqun.cao@gmail.com>
>> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
>> Subject: RE: The status of the approaches to the E-Tree = solution?
>> Message-ID:
>>        <F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>
>> Content-Type: text/plain; charset=3D"us-ascii"
>>
>> Hi all,
>> I fully understand that that what I am going to say is not very popular, but:
>>
>> IMO one of the advantages of the CW-based solution is that it = is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic.
>>
>> Another advantage is preservation of full mesh of P2P PWs in a = VPLS, and, in a more generic way, localization of effects of changes in the PE configuration.
>>
>> In particular, adding a Leaf AC to a PE that previously has = been only supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect only the = PE where this operation happens and not the rest of the PEs.
>>
>> As for the need for HW changes that have been mentioned as a = main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution.
>>
>> My 2c,
>>     Sasha
>>
>>
>>
>> ________________________________________
>> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] = on behalf of Rogers, Josh [josh.rogers@twcable.com]
>> Sent: Wednesday, April 18, 2012 9:57 PM
>> To: Lucy yong; Daniel Cohn; Sam Cao
>> Cc: l2vpn@ietf.org
>> Subject: Re: The status of the approaches to the E-Tree = solution?
>>
>> Again, the P2MP situation throws me.  Is this something = that is used
>> commonly?
>>
>> I'm under the impression that adding P2MP to any model results = in a more
>> complex model.  Wether outside s-tag is used to = differentiate, or
>> dedicated pw's are used for the same purpose, it seems both = become more
>> complex.
>>
>> Gile's comparison slide still concisely captures the = differences between
>> these methods, in my opinion.  I haven't seen any new = ideas or thoughts
>> brought to the group in the past week or two on the subject. =  I would hate
>> for both proposed methods to die on the vine because we = couldn't decide
>> between two methods that have nothing inherently wrong with = either.
>>
>> -Josh
>>
>>
>> On 4/18/12 1:53 PM, "Lucy yong" <lucy.yong@huawei.com> = wrote:
>>
>>>Send this again.
>>>
>>>Two PW approach can be complex too if the VPLS instance for = E-Tree uses
>>>P2P PW fo

This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, phone = or fax, and then delete the original and all copies thereof. =

This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, phone = or fax, and then delete the original and all copies thereof. =

------=_NextPart_000_0013_01CD2137.90090300-- From jiangyuanlong@huawei.com Sun Apr 22 19:01:22 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF38321F857D for ; Sun, 22 Apr 2012 19:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, J_CHICKENPOX_31=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 Ocn+L5UHvwiq for ; Sun, 22 Apr 2012 19:01:22 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D5D9D21F8577 for ; Sun, 22 Apr 2012 19:01:21 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFL12233; Sun, 22 Apr 2012 22:01:21 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 22 Apr 2012 18:59:08 -0700 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 22 Apr 2012 18:59:07 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.137]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 23 Apr 2012 09:59:02 +0800 From: Jiangyuanlong To: Sam Cao Subject: RE: L2vpn Digest, Vol 95, Issue 58 Thread-Topic: L2vpn Digest, Vol 95, Issue 58 Thread-Index: AQHNIJEYLAvX+w2mCESAuzptp0LkpZanpEzA Date: Mon, 23 Apr 2012 01:59:02 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E891@SZXEML508-MBS.china.huawei.com> References: 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.70.40.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 23 Apr 2012 02:01:22 -0000 Hi Sam, If E-Tree service is provided in a scenario as Fig. 3 and Fig 4 in RFC 4762= , then a CE (leaf or root) is connected to the MTU-s or PE-r, thus the AC s= hould be terminated and the E-Tree service should be encapsulated by the MT= U-s or PE-r. I don't quite understand why you need to "take VPWS PW as one = AC", but even in that case, the attribute of the AC may be configured at th= e PE-rs. So what is the problem for H-VPLS? Thanks Yuanlong Date: Sun, 22 Apr 2012 22:03:52 +0800 From: "Sam Cao" To: "'Jiangyuanlong'" Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <962A848896EF4678B17D76C826A7EAEF@v2comsam> Content-Type: text/plain; charset=3D"us-ascii" Yuanlong, I just collect all issues we discussed before, and we still can not make agreement. I gave my comments on 2 items below. I will think other items over and give my comments tomorrow. 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, but can NOT configure it at all in Spoke PW case;=20 [JY] In the first place, why PE-rs need to figure out the AC type for a spoke? The VLAN should be processed in the MTU, not in the PE-rs. [Sam] Yuanlong, I understand your idea. It does NOT make sense for me. First, Fig. 3 and Fig 4 in RFC 4762 are different cases. For VPWS (Fig. 3), we can take VPWS PW as one AC. You know, PE-rs is termination of VPWS, so i= t will add VLAN-ID to identify Root/Leaf. BTW, you will map several VLAN IDs into one Root-VLAN ID or Leaf-VLAN ID on PE-rs, so we need to configure Root/Leaf on PE-rs (Refer to your reply to Josh's comments). 4) Encapsulation mode: If deploy HVPLS with Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN ID; [JY] Is anything not working with tagged PW mode? [Sam] Tagged mode works.=20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Sunday, April 22, 2012 5:43 PM To: Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Sam, Please see my comments in line with [JY]. Regards, Yuanlong ---------------------------------------------------------------------- Message: 1 Date: Sat, 21 Apr 2012 22:51:28 +0800 From: "Sam Cao" To: "'Lizhong Jin'" , "'Henderickx, Wim \(Wim\)'" Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <1B88357C808B432E871CA9D678305B7C@v2comsam> Content-Type: text/plain; charset=3D"gb2312" Hi all, =20 We reach an impasse:-). BTW, Meeting minutes is ready now. We can get E-tree summary from IETF site. =20 Today I collected all items we discussed before. They are, =20 1) Silicon issue or chip limit; 2) Network efficiency; 3) Encapsulation mode, tag or raw; 4) H-VPLS; 5) Backwards compatibility, especially legacy PE or Non-supporting PE with IEEE E-tree support joins E-Tree domain; 6) Configuration change in operation, for example, Leaf-only -> Root-Leaf-Mixed; 7) S-VLAN preservation support; 8) Multi-segment PW; 9) VLAN ID allocation (Only for Dual-VLAN); 10) Multi-AS deployment; 11) ECMP; 12) P2MP-PW; 13) Ethernet OAM; =20 If we review the mail-list, CW approach has the following limits: 1) Chip limit. Please read reply from Giles and Wim; 2) Network efficiency: There are garbage fames which will be dropped on egress PE since only egress PE can decide forward or drop frames while i= t receives frames. Ingress PE can not decide forward or not. Yes, current solution can support Hub-Spoke configuration, but as we know, the configuration is not easy if the network is big. Dual-VLAN or Multi-PW approach can break communication between Leaf-Only PEs via signaling. 3) Backwards compatibility: Not all PEs supports control word. If one can not support control word, it will not join E-Tree domain; =20 Dual VLAN has following limits: 1) Chip limit: As we know, we need to push one VLAN into frames befor= e MPLS encapsulation on ingress PE and stripe it out on egress PE. This is non-standard operation. Wait for confirmation from chip vendor; [JY] Do you really consider tagged PW as non-standard? 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, but can NOT configure it at all in Spoke PW case; [JY] In the first place, why PE-rs need to figure out the AC type for a spoke? The VLAN should be processed in the MTU, not in the PE-rs. 3) Multi-PW: Rafi figures this out, but we don?t think this over at that time. I think that it also has same problem as H-VPLS has. [JY] The same as above, only T-PE will deal with VLAN, S-PE only switches P= W label, so I can't see what is the problem.=20 4) Encapsulation mode: If deploy HVPLS with Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN ID; [JY] Is anything not working with tagged PW mode? 5) Backward Compatibility: Just as Daniel mentioned, there is compatibility issue if legacy PE joins E-Tree domain. For me, I don?t get clear response from co-authors of Dual-VLAN. [JY] Could you elaborate a little more what is the compatibility issue?=20 =20 For all approaches, we don?t cover ECMP / Ethernet OAM till now.=20 =20 Is there anything missed?=20 =20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 From jiangyuanlong@huawei.com Sun Apr 22 19:46:27 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7713521F8464 for ; Sun, 22 Apr 2012 19:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, J_CHICKENPOX_31=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 YmD3ydQb9Epf for ; Sun, 22 Apr 2012 19:46:26 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9605B21F842E for ; Sun, 22 Apr 2012 19:46:26 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFD11346; Sun, 22 Apr 2012 22:46:26 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 22 Apr 2012 19:43:38 -0700 Received: from SZXEML428-HUB.china.huawei.com (10.72.61.36) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 22 Apr 2012 19:43:39 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.137]) by szxeml428-hub.china.huawei.com ([10.72.61.36]) with mapi id 14.01.0323.003; Mon, 23 Apr 2012 10:43:35 +0800 From: Jiangyuanlong To: "Rogers, Josh" Subject: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNIPrg6EtByQ/40kOxR9XHP0QViA== Date: Mon, 23 Apr 2012 02:43:34 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E8AE@SZXEML508-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AFe5 Ahlh BB3T C8VP GoiI G20U HXun I4j9 LNYK LxHF Mj8+ Nwr+ PNJ9 S72L S/RA Tr6I; 2; agBvAHMAaAAuAHIAbwBnAGUAcgBzAEAAdAB3AGMAYQBiAGwAZQAuAGMAbwBtADsAbAAyAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {7E0104E7-AA66-4723-B63A-E7D51B9B6D1C}; agBpAGEAbgBnAHkAdQBhAG4AbABvAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Mon, 23 Apr 2012 02:43:31 GMT; VABoAGUAIABzAHQAYQB0AHUAcwAgAG8AZgAgAHQAaABlACAAYQBwAHAAcgBvAGEAYwBoAGUAcwAgAHQAbwAgAHQAaABlACAARQAtAFQAcgBlAGUAIABzAG8AbAB1AHQAaQBvAG4APwA= x-cr-puzzleid: {7E0104E7-AA66-4723-B63A-E7D51B9B6D1C} x-originating-ip: [10.70.40.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 23 Apr 2012 02:46:27 -0000 Hi Josh, E-Tree UNI with double tagging is something new, could the WG include it in= the E-Tree requirement draft? But maybe it is better to be kicked off in the MEF first since it is the SD= O that is defining the Carrier Ethernet services. The 2VLAN I-D (draft-jiang-l2vpn-vpls-pe-etree) did provide two options: 1) S-VLAN translation; 2) using B-VLAN. Since the draft on PBB VPLS is already mature in this WG. Thanks Yuanlong ---------------------------------------------------------------------- Date: Sun, 22 Apr 2012 20:54:45 -0400 From: To: Jiangyuanlong Cc: "l2vpn@ietf.org" Subject: Re: The status of the approaches to the E-Tree solution? Message-ID: Content-Type: text/plain; charset=3D"us-ascii" Hello Yuanlong, If the UNI is service multiplexed (multiple services), then the customer must tag all traffic destined for this ETREE instance (as well as expect it tagged with the same ID). So, imagine the customer transmit frame with VLAN-ID '3' into the service from a root site. Frame traverses the AC, and enters the AC port on the first PE. Service Provider is using VLAN-ID 4001 for traffic sourced from 'root' AC's, and 4002 for traffic sourced from 'leaf' AC's. Since this frame came in from a root site, we prepend the frame with VLAN-ID 4001 (now 4001:3), it traverses the PW(s) that the CAM designates on first PE. On egress PE, vlan 4001 is popped off and the frame is returned with VLAN ID 3 back to customer. In my example below, 4001 would be the R/L S-Tag, and 3 would be the 'AC S-Tag' (I think someone mentioned that this is not technically an S-Tag because it is coordinated with the customer), and the 'C-Tag' below may be an additional tag if the customer were double tagging. My point was that the SP is dealing with double tagged frames for the ETREE service. In the example above, the SP still has to deal with 4001:3, the 3 designates which service the frame belongs to, and 4001 designates the frame came from a root site. From the customer's perspective, the three approaches change nothing, none require anything different from the customer. The 2VLAN method, however, does require a little more understanding with VLAN mapping from the service provider's perspective, since they are dealing with a double tag. I suppose this depends a bit on the hardware vendor's implementation of the method, however. It could be possible to automate and/or hide the outer ETREE tag. For example, if the implementation standardizes on 4001 for root sourced, and 4002 for leaf sourced, then w/in the VPLS instance, if a) the service is defined as ETREE, and b) each AC is defined as 'root' or 'leaf', then the R/L vlan tagging could be automated and not really noticed or cared much about by the operator, which would hide this complexity. I do think it is worth noting that the double tagging introduces complexity, however. Thank you, -Josh On 4/22/12 4:50 AM, "Jiangyuanlong" wrote: >Hi Josh, > >Wish the last email on "SVLAN in the 2VLAN E-Tree solution" covered this >issue. >BTW, a 2VLAN encapsulated frame is not in the format as described. A >single S-tag is usually enough. > >Thanks >Yuanlong > >---------------------------------------------------------------------- > >Message: 1 >Date: Sat, 21 Apr 2012 11:02:51 -0400 >From: "Rogers, Josh" >To: Sam Cao , 'Lizhong Jin' > , "'Henderickx, Wim (Wim)'" > >Cc: "l2vpn@ietf.org" >Subject: Re: The status of the approaches to the E-Tree solution? >Message-ID: >Content-Type: text/plain; charset=3D"utf-8" > >Sam? Where is the list for multi-PW method? > >One item I don't think is covered in your 2VLAN list, is where service >multiplexed UNI's are involved, or any time there is a layer 2 CPE >between PE and CE, these devices usually expect a single, bidirectional >s-tag, and according to your explanation this morning, coordinating the >S-Tags used for ETREE with the customer SHOULD NOT to be done, therefor >there must be an 'inner S-Tag' on the AC, and an 'outer S-Tag' in the PW. > >While inside the PW, a 2VLAN method frame would look like: > >+-----------+-----------+----------+-------+-----------------+ >|MPLS Label | R/L S-Tag | AC S-Tag | C-tag | Layer 2 Payload | >+-----------+-----------+----------+-------+-----------------+ > >Correct? > >Would you consider this an 'issue' or just a 'complication' ? > >A lot of the 'pro 2VLAN' argument has been centered around existing IEEE >standard, and at first it sounded like this was better/proposed for the >ability to extend the R/L S-tag beyond the PW, but it sounds like that >isn't really an option, so I'm not sure that is a valid benefit/driver. > >Thanks much, >Josh > >From: Sam Cao > >To: 'Lizhong Jin' >, >"'Henderickx, Wim (Wim)'" >m>> >Cc: "l2vpn@ietf.org" >> >Subject: RE: The status of the approaches to the E-Tree solution? > >Hi all, > >We reach an impasse?. BTW, Meeting minutes is ready now. We can get >E-tree summary from IETF site. > >Today I collected all items we discussed before. They are, > >1) Silicon issue or chip limit; >2) Network efficiency; >3) Encapsulation mode, tag or raw; >4) H-VPLS; >5) Backwards compatibility, especially legacy PE or Non-supporting >PE with IEEE E-tree support joins E-Tree domain; >6) Configuration change in operation, for example, Leaf-only -> >Root-Leaf-Mixed; >7) S-VLAN preservation support; >8) Multi-segment PW; >9) VLAN ID allocation (Only for Dual-VLAN); >10) Multi-AS deployment; >11) ECMP; >12) P2MP-PW; >13) Ethernet OAM; > >If we review the mail-list, CW approach has the following limits: >1) Chip limit. Please read reply from Giles and Wim; >2) Network efficiency: There are garbage fames which will be >dropped on egress PE since only egress PE can decide forward or drop >frames while it receives frames. Ingress PE can not decide forward or >not. Yes, current solution can support Hub-Spoke configuration, but as we >know, the configuration is not easy if the network is big. Dual-VLAN or >Multi-PW approach can break communication between Leaf-Only PEs via >signaling. >3) Backwards compatibility: Not all PEs supports control word. If >one can not support control word, it will not join E-Tree domain; > >Dual VLAN has following limits: >1) Chip limit: As we know, we need to push one VLAN into frames >before MPLS encapsulation on ingress PE and stripe it out on egress PE. >This is non-standard operation. Wait for confirmation from chip vendor; >2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, >PE-rs works in different manner, PE-rs should figure out AC type in VPWS >case, but can NOT configure it at all in Spoke PW case; >3) Multi-PW: Rafi figures this out, but we don?t think this over at >that time. I think that it also has same problem as H-VPLS has. >4) Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs >should work in tagged mode, otherwise PE-rs or egress PE will stripe >S-VLAN ID; >5) Backward Compatibility: Just as Daniel mentioned, there is >compatibility issue if legacy PE joins E-Tree domain. For me, I don?t get >clear response from co-authors of Dual-VLAN. > >For all approaches, we don?t cover ECMP / Ethernet OAM till now. > >Is there anything missed? > >Regards, > >Yuqun (Sam) Cao >E-mail: Yuqun.cao@gmail.com > From yuqun.cao@gmail.com Sun Apr 22 20:28:04 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC4E11E8072 for ; Sun, 22 Apr 2012 20:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599, J_CHICKENPOX_31=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 4cs-xsEmWJoT for ; Sun, 22 Apr 2012 20:28:03 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id AFEEB21F8526 for ; Sun, 22 Apr 2012 20:28:03 -0700 (PDT) Received: by dady13 with SMTP id y13so20711420dad.27 for ; Sun, 22 Apr 2012 20:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :in-reply-to:x-mimeole; bh=bOqiaaS0XmMKDPfLPk5fbnRtixQIGOzfG9lqbhENuEI=; b=muzDy2SDJuMu6xwt0Q9t0Cf9lcDOsNlpLcLBGpiQNsOZCHS9jjNx0dij+k5H9KrSHG 8fzrnKsMArWissyIcOVdGNMU3nXjbQkVhujVS9CQ/qRK5nTeOAyr/lMlDaFFVV9Z1hTN NQ9AmASLq3wf/+4GZC8vW1hIlESy2Z6yaIG5zw3NF1+obsrBCIXCfdMUD2rq/KMfMmvW o518y4/ywgD0jM18OGH0lD8RGhlAUVtwmLp82RCg1V8OQ4/AbTQWcSQbsOnJw1z5yopc NuLCcGJn1bSA5xxSpUaa8uG2pkptIgo+q60amKJu3lkn2BVuI+ppLssrtgx2M1+nuMVW ajXQ== Received: by 10.68.221.98 with SMTP id qd2mr32952673pbc.3.1335151683522; Sun, 22 Apr 2012 20:28:03 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id pt8sm13104227pbc.64.2012.04.22.20.27.59 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Apr 2012 20:28:02 -0700 (PDT) From: "Sam Cao" To: "'Jiangyuanlong'" References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E891@SZXEML508-MBS.china.huawei.com> Subject: RE: L2vpn Digest, Vol 95, Issue 58 Date: Mon, 23 Apr 2012 11:27:53 +0800 Message-ID: <5C3578E316494634B1DCAC06C15E2C21@R01842> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AQHNIJEYLAvX+w2mCESAuzptp0LkpZanpEzAgAASyWA= In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E891@SZXEML508-MBS.china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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, 23 Apr 2012 03:28:04 -0000 Yuanlong, I do apologize for my unclear description. I try to make it clear. VPWS or Spoke PW, PE-rs will take the PW as Spoke PW. Or say, PE-rs really does NOT care remote access is VPWS access (point-to-point, Fig. 3) or VPLS spoke access (Fig. 4). PE-rs just know it is spoke PW and it is ENOUGH, and does NOT care customer payload. is this correct? At least it is correct in RFC 4762. But, if remote is VPWS access (Fig. 3), PE-rs SHOULD configure AC-type for remote VPWS access although it is still spoke PW in E-Tree. Please refer to your answer to Josh's question. It seems reasonable. Ok, we think another case in Fig. 4. In Fig. 4, PE-rs CAN NOT configure AC-type at all in this case. In fact, on MTU-s it is VPLS and we should configure AC type on MTU-s. Ok, problem came up for me. For spoke PW on PE-rs, in one case it should configure AC type and work as agent; in another case, it can NOT configure AC type and can not work as agent. In fact, PE-rs knows it is spoke PW, it is enough; why spoke-PW has different configuration in same VPLS instance on same PE? I am confused although I know why we should configure in that way. I prefer not to configure AC type on PE-rs since we can take it as "Switching PE" (NOT pefact here and it is not real "Switching Point") which does NOT aware customer payload. Extension to VPWS? Seems not reasonable. Thanks, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Monday, April 23, 2012 9:59 AM To: Sam Cao Cc: l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 95, Issue 58 Hi Sam, If E-Tree service is provided in a scenario as Fig. 3 and Fig 4 in RFC 4762, then a CE (leaf or root) is connected to the MTU-s or PE-r, thus the AC should be terminated and the E-Tree service should be encapsulated by the MTU-s or PE-r. I don't quite understand why you need to "take VPWS PW as one AC", but even in that case, the attribute of the AC may be configured at the PE-rs. So what is the problem for H-VPLS? Thanks Yuanlong Date: Sun, 22 Apr 2012 22:03:52 +0800 From: "Sam Cao" To: "'Jiangyuanlong'" Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <962A848896EF4678B17D76C826A7EAEF@v2comsam> Content-Type: text/plain; charset="us-ascii" Yuanlong, I just collect all issues we discussed before, and we still can not make agreement. I gave my comments on 2 items below. I will think other items over and give my comments tomorrow. 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, but can NOT configure it at all in Spoke PW case; [JY] In the first place, why PE-rs need to figure out the AC type for a spoke? The VLAN should be processed in the MTU, not in the PE-rs. [Sam] Yuanlong, I understand your idea. It does NOT make sense for me. First, Fig. 3 and Fig 4 in RFC 4762 are different cases. For VPWS (Fig. 3), we can take VPWS PW as one AC. You know, PE-rs is termination of VPWS, so it will add VLAN-ID to identify Root/Leaf. BTW, you will map several VLAN IDs into one Root-VLAN ID or Leaf-VLAN ID on PE-rs, so we need to configure Root/Leaf on PE-rs (Refer to your reply to Josh's comments). 4) Encapsulation mode: If deploy HVPLS with Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN ID; [JY] Is anything not working with tagged PW mode? [Sam] Tagged mode works. Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Sunday, April 22, 2012 5:43 PM To: Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Sam, Please see my comments in line with [JY]. Regards, Yuanlong ---------------------------------------------------------------------- Message: 1 Date: Sat, 21 Apr 2012 22:51:28 +0800 From: "Sam Cao" To: "'Lizhong Jin'" , "'Henderickx, Wim \(Wim\)'" Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <1B88357C808B432E871CA9D678305B7C@v2comsam> Content-Type: text/plain; charset="gb2312" Hi all, We reach an impasse:-). BTW, Meeting minutes is ready now. We can get E-tree summary from IETF site. Today I collected all items we discussed before. They are, 1) Silicon issue or chip limit; 2) Network efficiency; 3) Encapsulation mode, tag or raw; 4) H-VPLS; 5) Backwards compatibility, especially legacy PE or Non-supporting PE with IEEE E-tree support joins E-Tree domain; 6) Configuration change in operation, for example, Leaf-only -> Root-Leaf-Mixed; 7) S-VLAN preservation support; 8) Multi-segment PW; 9) VLAN ID allocation (Only for Dual-VLAN); 10) Multi-AS deployment; 11) ECMP; 12) P2MP-PW; 13) Ethernet OAM; If we review the mail-list, CW approach has the following limits: 1) Chip limit. Please read reply from Giles and Wim; 2) Network efficiency: There are garbage fames which will be dropped on egress PE since only egress PE can decide forward or drop frames while it receives frames. Ingress PE can not decide forward or not. Yes, current solution can support Hub-Spoke configuration, but as we know, the configuration is not easy if the network is big. Dual-VLAN or Multi-PW approach can break communication between Leaf-Only PEs via signaling. 3) Backwards compatibility: Not all PEs supports control word. If one can not support control word, it will not join E-Tree domain; Dual VLAN has following limits: 1) Chip limit: As we know, we need to push one VLAN into frames before MPLS encapsulation on ingress PE and stripe it out on egress PE. This is non-standard operation. Wait for confirmation from chip vendor; [JY] Do you really consider tagged PW as non-standard? 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, but can NOT configure it at all in Spoke PW case; [JY] In the first place, why PE-rs need to figure out the AC type for a spoke? The VLAN should be processed in the MTU, not in the PE-rs. 3) Multi-PW: Rafi figures this out, but we don?t think this over at that time. I think that it also has same problem as H-VPLS has. [JY] The same as above, only T-PE will deal with VLAN, S-PE only switches PW label, so I can't see what is the problem. 4) Encapsulation mode: If deploy HVPLS with Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN ID; [JY] Is anything not working with tagged PW mode? 5) Backward Compatibility: Just as Daniel mentioned, there is compatibility issue if legacy PE joins E-Tree domain. For me, I don?t get clear response from co-authors of Dual-VLAN. [JY] Could you elaborate a little more what is the compatibility issue? For all approaches, we don?t cover ECMP / Ethernet OAM till now. Is there anything missed? Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com From jiangyuanlong@huawei.com Sun Apr 22 20:51:46 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A7F21F8526 for ; Sun, 22 Apr 2012 20:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, J_CHICKENPOX_31=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 4d7AEh63X1xr for ; Sun, 22 Apr 2012 20:51:45 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4325121F844B for ; Sun, 22 Apr 2012 20:51:45 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFL18134; Sun, 22 Apr 2012 23:51:45 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 22 Apr 2012 20:48:53 -0700 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 22 Apr 2012 20:48:52 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.137]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Mon, 23 Apr 2012 11:48:45 +0800 From: Jiangyuanlong To: Sam Cao Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNIGxIkTBdljOSQkeqvNTqsF/qWZanmv2wgAAoxVA= Date: Mon, 23 Apr 2012 03:48:44 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E96D@SZXEML508-MBS.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E7DD@SZXEML508-MBS.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.70.40.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 23 Apr 2012 03:51:46 -0000 Hi Sam, Please see my comments in line. Regards, Yuanlong -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Monday, April 23, 2012 9:25 AM To: Jiangyuanlong Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Yuanlong, Yesterday evening I think HVPLS again, and again I think that it is problem if I don't misunderstand Dual-VLAN draft. First, this is VPWS access; secondly, if it is VPWS access, all active drafts does not extend anything for VPWS. I agree with your answer to Josh's question (Original is Multi-AS= , but it is really HVPLS). Would you please read that mail again? Thanks. Please get more comments below. [JY] The same as above, only T-PE will deal with VLAN, S-PE only switches P= W label, so I can't see what is the problem. [Sam] This came up in the first round (By Rafi). You explained that switching PE does NOT aware VLAN mapping. At first glance it seems reasonable. But this depends on your VLAN allocation. Would you please update your draft? Then I can give more comments. [JY] Could you detail your concerns so that I can understand it? [JY] Could you elaborate a little more what is the compatibility issue? // 2012-3-29 from Daniel But how would the non-legacy PE know which VLANs are available at the legac= y PE? The legacy PE cannot advertise it if it doesn't support extensions! [JY] Thanks, I got your point. So the question is the control plane interwo= rking with the legacy PE, it seems the same VPLS processing as traditional = can well deal with this scenario. That is, in Compatible mode, the PE with = new E-Tree extension can establish raw PW with the legacy PE, and the VLAN = can be removed on the PW. However, if the VLANs are configured, the VLAN ca= n also be available. BTW, I just collect the items we have discussed, and list what we can not make agreement before :). Thanks, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Sunday, April 22, 2012 5:43 PM To: Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Sam, Please see my comments in line with [JY]. Regards, Yuanlong ---------------------------------------------------------------------- Message: 1 Date: Sat, 21 Apr 2012 22:51:28 +0800 From: "Sam Cao" To: "'Lizhong Jin'" , "'Henderickx, Wim \(Wim\)'" Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <1B88357C808B432E871CA9D678305B7C@v2comsam> Content-Type: text/plain; charset=3D"gb2312" Hi all, =20 We reach an impasse:-). BTW, Meeting minutes is ready now. We can get E-tree summary from IETF site. =20 Today I collected all items we discussed before. They are, =20 1) Silicon issue or chip limit; 2) Network efficiency; 3) Encapsulation mode, tag or raw; 4) H-VPLS; 5) Backwards compatibility, especially legacy PE or Non-supporting PE with IEEE E-tree support joins E-Tree domain; 6) Configuration change in operation, for example, Leaf-only -> Root-Leaf-Mixed; 7) S-VLAN preservation support; 8) Multi-segment PW; 9) VLAN ID allocation (Only for Dual-VLAN); 10) Multi-AS deployment; 11) ECMP; 12) P2MP-PW; 13) Ethernet OAM; =20 If we review the mail-list, CW approach has the following limits: 1) Chip limit. Please read reply from Giles and Wim; 2) Network efficiency: There are garbage fames which will be dropped on egress PE since only egress PE can decide forward or drop frames while i= t receives frames. Ingress PE can not decide forward or not. Yes, current solution can support Hub-Spoke configuration, but as we know, the configuration is not easy if the network is big. Dual-VLAN or Multi-PW approach can break communication between Leaf-Only PEs via signaling. 3) Backwards compatibility: Not all PEs supports control word. If one can not support control word, it will not join E-Tree domain; =20 Dual VLAN has following limits: 1) Chip limit: As we know, we need to push one VLAN into frames befor= e MPLS encapsulation on ingress PE and stripe it out on egress PE. This is non-standard operation. Wait for confirmation from chip vendor; [JY] Do you really consider tagged PW as non-standard? 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, but can NOT configure it at all in Spoke PW case; [JY] In the first place, why PE-rs need to figure out the AC type for a spoke? The VLAN should be processed in the MTU, not in the PE-rs. 3) Multi-PW: Rafi figures this out, but we don?t think this over at that time. I think that it also has same problem as H-VPLS has. [JY] The same as above, only T-PE will deal with VLAN, S-PE only switches P= W label, so I can't see what is the problem.=20 4) Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN ID; [JY] Is anything not working with tagged PW mode? 5) Backward Compatibility: Just as Daniel mentioned, there is compatibility issue if legacy PE joins E-Tree domain. For me, I don?t get clear response from co-authors of Dual-VLAN. [JY] Could you elaborate a little more what is the compatibility issue?=20 =20 For all approaches, we don?t cover ECMP / Ethernet OAM till now.=20 =20 Is there anything missed?=20 =20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 _____ =20 From: Lizhong Jin [mailto:lizho.jin@gmail.com]=20 Sent: Saturday, April 21, 2012 11:59 AM To: Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? =20 Hi Win, Thank you for the answers. In that case, PE-rs should configure the root/leaf properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, you could not figure out the accessing spoke PW is from PE-r of VPWS or MTU-s. Unless having some additional indication in NMS, you even don't know which spoke PW needs to do VLAN manipulation. I am not sure such R/L configuration could be accepted from operational view. Hope to see more comments. Regards Lizhong ? 2012?4?21?????Henderickx, Wim (Wim) ??? > The VPWS which terminates at the H-VPLS node is indicated to be root or leaf and the procedures associated will do the VLAN manipulation > > =20 > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin > Sent: vrijdag 20 april 2012 18:38 > To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com > Cc: yuqun.cao@gmail.com > Subject: RE: The status of the approaches to the E-Tree solution? > > =20 > > Hi, all, > The difference between 2-VLAN and CW approach is who will provide the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW will carry R/L information for CW approach. > I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information? > > Thanks > Lizhong > >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 Apr 2012 04:38:36 +0000 >> From: Alexander Vainshtein >> To: "Rogers, Josh" , Lucy yong >> , Daniel Cohn , Sam Cao >> >> Cc: "l2vpn@ietf.org" >> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID: >> >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi all, >> I fully understand that that what I am going to say is not very popular, but: >> >> IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BU= N traffic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, and= , in a more generic way, localization of effects of changes in the PE configuration. >> >> In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root AC from a PE that previously has been supporting a mix etc. affect only the PE where this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a more >> complex model. Wether outside s-tag is used to differentiate, or >> dedicated pw's are used for the same purpose, it seems both become more >> complex. >> >> Gile's comparison slide still concisely captures the differences between >> these methods, in my opinion. I haven't seen any new ideas or thoughts >> brought to the group in the past week or two on the subject. I would hate >> for both proposed methods to die on the vine because we couldn't decide >> between two methods that have nothing inherently wrong with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" wrote: >> >>>Send this again. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>P2P PW fo=20 -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 48 ************************************* From yuqun.cao@gmail.com Sun Apr 22 21:06:08 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5763621F84C2 for ; Sun, 22 Apr 2012 21:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, MIME_CHARSET_FARAWAY=2.45, 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 k3G86gZf2IhY for ; Sun, 22 Apr 2012 21:05:59 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id E69C821F84BF for ; Sun, 22 Apr 2012 21:05:58 -0700 (PDT) Received: by dady13 with SMTP id y13so20752069dad.27 for ; Sun, 22 Apr 2012 21:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:in-reply-to:x-mimeole; bh=P/UOqgPCDgksG0jFEffEXHLZbPAKRiKV0rTyit/BiXE=; b=iL9DmOWvtipdWcj0wVPvsmsgTQdf1vNHABCf/3q/QYoAVzSHQnJJTQ0uq/u1Hw7Zu2 +liDngnspmLYxwfg+/89jQBZMoVbwGIG1tCIVELqqN45quMd46V227Is8i0dnOnBngV4 e6SMtEB5R69+Fx5pSJWr062W2NuCtLReWDeDHQP1DUWqDJGqNLFv2BG8Tl/UuVoZYjYl VFbI3K9mldf0Sr1GLuz0p85WggFp6yQJXOD98IOHmtaS5FZq4McldVv0Ht5F2hyON/+C u9CWdUxG2Ywi9CvPSya3XrrBeH/VopxOt7H8cC0HcqCtdxdS3DgDcUtBrzghLQ14UbNm jCJQ== Received: by 10.68.135.99 with SMTP id pr3mr21525502pbb.95.1335153958397; Sun, 22 Apr 2012 21:05:58 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id ox2sm13202562pbc.55.2012.04.22.21.05.46 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Apr 2012 21:05:56 -0700 (PDT) From: "Sam Cao" To: "'UTTARO, JAMES'" , "'Alexander Vainshtein'" References: , <14C7F4F06DB5814AB0DE29716C4F6D6701296244C3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>, , <1B88357C808B432E871CA9D678305B7C@v2comsam><6F9ADEDA06A04AB98C247D303AFE93BE@v2comsam> Subject: RE: The status of the approaches to the E-Tree solution? Date: Mon, 23 Apr 2012 12:05:44 +0800 Message-ID: <13822856E9C84A49BBF95D1867C5FF11@R01842> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01CD2149.6CEC3100" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AQHNHxPnxbisvEh3kk6CwsWQjlzY35akOniAgACwqQCAALY7AIAAC0AAgAFzRgCAAARQAIAAB2IAgAAJkwCAAEmWAIAARubA In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Mailman-Approved-At: Mon, 23 Apr 2012 01:32:51 -0700 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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, 23 Apr 2012 04:06:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0036_01CD2149.6CEC3100 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Jim, =20 Thank you very much for your comments. But what we did is a little = different from yours. =20 Multi-PW carries AC type in =A1=B0Layer2 Info Extended Community=A1=B1, = NOT different RT, and control plane will translate it, but we don=A1=AFt = separate it into 2 VRFs (VSI in the draft). They belong to one VSI.=20 =20 I guess your E-Tree deployment via BGP-AD is, assign one Root-RT (same = in all VPLA-PE in VPLS domain), and assign different Leaf RT for each = Leaf-only PE, then we will not setup PW between Leaf-only PEs, then we can break = the communication between Leaf-Only PEs. Is my understanding correct or not? This is Hub-Spoke deployment, and current solution can support this. But = it can not cover all cases.=20 =20 I agree with some requirements on E-Tree in your mail. =20 - Partial mesh topologies.=20 [Sam] Agree. Now CW, Dual-VLAN or Dual-PW consider this in draft, but = for me, CW or Dual-VLAN will deploy partial mesh in your way or configure it manually; Dual-PW can support this via signaling.=20 - Same PE mush be able to host Root and Leaf Sites.=20 [Sam] Agree. This is Root-Leaf-Mixed case in all E-tree draft; All = drafts should support this. - Disallowing of Leaf to Leaf traffic on the same PE must be = done using PW semantics.=20 [Sam] Jim, can not fully understand this case. If on same PE, this is = local behavior, is it correct? Do you mean we need to setup one dummy PW on = any PE if it hosts Root and Leaf sites? Shall we describe in draft? - When Root and Leaf sites are deployed on the same PE the = packets between them should obey the same semantics as if they had traversed a = PW i. e ( Split Horizon, No Label Re-Imposition etc=A1=AD ).=20 [Sam] Same question as above. Anyway, =A1=B0Split Horizon=A1=B1 is basic = rule for all drafts. - If PE has a root and leaf site and sends traffic to PE1. PE1 should be able to decide if the traffic was sourced from the root or = leaf site. If from PE:Leaf then the traffic should not be resolved in = PE1:Leaf.=20 [Sam] Yes, what we are doing is to solve this. =20 Thanks, =20 Sam _____ =20 From: UTTARO, JAMES [mailto:ju1738@att.com]=20 Sent: Monday, April 23, 2012 7:27 AM To: 'Alexander Vainshtein'; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? =20 For a given PE, If you use BGP and define separate VRFs one for the = leafs and one for roots than the semantic provided by the RT assignment should = be translated correctly in to the forwarding programmed.. This means that intra-PE between the leaf and root VRF should be treated as a Labeled = PW. If treated as a regular ethernet interface than a leaf on VRF S1 can = forward traffic on VRF H1 and then onto a different PEs leaf VRF=A1=AD I believe = we had a very similar conversation over a year ago about E-Tree=A1=AD=20 =20 So, here are the reqs I shared=20 =20 * E-Tree/Partial mesh topologies need to be realized in the = control plane by constructing PWs. The data plane should not infer a topology. = In other words data should not have to be inspected to determine if the = packet is sourced from a leaf or a root * The same PE must be able to host Root and Leaf sites.=20 * Disallowing of Leaf to Leaf traffic on the same PE must be = done using PW semantics. * When Root and Leaf sites are deployed on the same PE the = packets between them should obey the same semantics as if they had traversed a = PW i. e ( Split Horizon, No Label Re-Imposition etc=A1=AD ) * If PE has a root and leaf site and sends traffic to PE1. PE1 should be able to decide if the traffic was sourced from the root or = leaf site. If from PE:Leaf then the traffic should not be resolved in = PE1:Leaf. =20 =20 Jim Uttaro From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Alexander Vainshtein Sent: Sunday, April 22, 2012 10:57 AM To: Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? =20 Sam, I will try to explain myself. =20 I have misspoken before, and I owe you an apology. =20 A true legacy PE cannot operate as a Mixed PE for E-tree since this operation requires some changes in the forwarding behavior. This is IMHO correct regardless of the specific E-tree solution that is implemented = by the rest of the PEs (CW-based, dual PW-based or VLAN-based). I.e. = without some additional implementation-specific tricks it can be either a = Root-only PE or a Leaf-only PE in the VPLS that does not contain Mixed PEs. =20 Regards, Sasha =20 From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Sunday, April 22, 2012 5:22 PM To: Alexander Vainshtein Cc: l2vpn@ietf.org; 'Raymond Key' Subject: RE: The status of the approaches to the E-Tree solution? =20 Sasha, =20 I agree with your comments. But maybe I don=A1=AFt make myself = understood. I make it clear. =20 If one chip can not support control word, then one switch which uses = this chip can not work as Root-Leaf-Mixed PE since we can not extend it. Is = this correct? Is this reasonable? =20 Anyway, chip limit is big problem for CW approach. =20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 _____ =20 From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Sunday, April 22, 2012 9:56 PM To: Sam Cao Cc: l2vpn@ietf.org; 'Raymond Key' Subject: RE: The status of the approaches to the E-Tree solution? =20 Sam, You=A1=AFve asked: If it only supports VPLS, ok, it can work as Root-only, but why it = cannot work as Root-Leaf-Mixed or Leaf-only if it cannot support CW? IMHO and FWIW there is not too much you can expect from a true legacy PE = (i. e. a PE that did not change its forwarding behavior): 1. It can obviously support Root-only functionality 2. It can support Leaf-only functionality if there are no Mixed by preventing setup PW (by not setting up PWs to other Leaf-only PEs). Anything beyond that would be very much implementation-specific. E.g., I = am aware of legacy implementations that could support functionality of a = Mixed PE provided that it would be the only Mixed PE in the VPLS instance, and other legacy implementations that are, as legacy, fully interoperable = with these ones but could not support such functionality. =20 My 2c, Sasha =20 From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Sam Cao Sent: Sunday, April 22, 2012 4:41 PM To: 'Raymond Key' Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? =20 Raymond, =20 Network efficiency: [Sam] Leaf/Root configuration is local configuration, and PE can not = know remote AC type configuration. This is CW Fundamentals. So even if CW approach defines optional enhancement for Leaf-Only PE, but can not = signal it between Leaf-Only PEs, so there is no good way to support this. The possible solution is, manually configure hub-spoke topology, but if we = do like this, current solutions have support most E-Tree cases with = Hub-Spoke configuration. Lizhong mentioned this in one mail. =20 Backwards compatibility: [Sam] Yes, new draft considers backward compatibility, but it makes precondition: The PE which can not support Control word only works as Root-only PE. This does not make sense for me. If it only supports VPLS, = ok, it can work as Root-only, but why it can not work as Root-Leaf-Mixed or Leaf-only if it can not support CW? =20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 _____ =20 From: raymond.key@hotmail.com [mailto:raymond.key@hotmail.com] On Behalf = Of Raymond Key Sent: Saturday, April 21, 2012 11:32 PM To: yuqun.cao@gmail.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? =20 Some clarifications [RK] inserted below Thanks Raymond Key _____ =20 From: yuqun.cao@gmail.com To: lizho.jin@gmail.com; wim.henderickx@alcatel-lucent.com Subject: RE: The status of the approaches to the E-Tree solution? Date: Sat, 21 Apr 2012 22:51:28 +0800 CC: l2vpn@ietf.org Hi all, =20 We reach an impasse:-). BTW, Meeting minutes is ready now. We can get E-tree summary from IETF site. =20 Today I collected all items we discussed before. They are, =20 1) Silicon issue or chip limit; 2) Network efficiency; 3) Encapsulation mode, tag or raw; 4) H-VPLS; 5) Backwards compatibility, especially legacy PE or Non-supporting = PE with IEEE E-tree support joins E-Tree domain; 6) Configuration change in operation, for example, Leaf-only -> Root-Leaf-Mixed; 7) S-VLAN preservation support; 8) Multi-segment PW; 9) VLAN ID allocation (Only for Dual-VLAN); 10) Multi-AS deployment; 11) ECMP; 12) P2MP-PW; 13) Ethernet OAM; =20 If we review the mail-list, CW approach has the following limits: 1) Chip limit. Please read reply from Giles and Wim; 2) Network efficiency: There are garbage fames which will be = dropped on egress PE since only egress PE can decide forward or drop frames = while it receives frames. Ingress PE can not decide forward or not. Yes, current solution can support Hub-Spoke configuration, but as we know, the configuration is not easy if the network is big. Dual-VLAN or Multi-PW approach can break communication between Leaf-Only PEs via signaling. [RK] It seems to me this is not the case. Section 6 of the draft has = some discussions on this. http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-6 6. Optional Enhancements for Leaf-only PE 6.1. No PW between Leaf-only PEs 6.2. Not Forward Frame from Leaf AC to Leaf-only PE =20 3) Backwards compatibility: Not all PEs supports control word. If = one can not support control word, it will not join E-Tree domain; =20 [RK] It seems to me this is not the case. Section 5 of the draft has = some discussions on this. http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-5 5. Backward Compatibility 5.1. AC Type 5.2. Control Word 5.3. Additional Action in Data Forwarding 5.3.1. Ingress PE Supporting the Extension but Egress PE Not 5.3.2. Egress PE Supporting the Extension but Ingress PE Not =20 Dual VLAN has following limits: 1) Chip limit: As we know, we need to push one VLAN into frames = before MPLS encapsulation on ingress PE and stripe it out on egress PE. This is non-standard operation. Wait for confirmation from chip vendor; 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, but can NOT configure it at all in Spoke PW case; 3) Multi-PW: Rafi figures this out, but we don=A1=AFt think this = over at that time. I think that it also has same problem as H-VPLS has. 4) Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will stripe = S-VLAN ID; 5) Backward Compatibility: Just as Daniel mentioned, there is compatibility issue if legacy PE joins E-Tree domain. For me, I = don=A1=AFt get clear response from co-authors of Dual-VLAN. =20 For all approaches, we don=A1=AFt cover ECMP / Ethernet OAM till now.=20 =20 Is there anything missed?=20 =20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 _____ =20 From: Lizhong Jin [mailto:lizho.jin@gmail.com]=20 Sent: Saturday, April 21, 2012 11:59 AM To: Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; = yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? =20 Hi Win, Thank you for the answers. In that case, PE-rs should configure the root/leaf properties of VPWS, not on the remote PE of VPWS. And usually = on PE-rs, you could not figure out the accessing spoke PW is from PE-r of = VPWS or MTU-s. Unless having some additional indication in NMS, you even = don't know which spoke PW needs to do VLAN manipulation. I am not sure such = R/L configuration could be accepted from operational view. Hope to see more comments. Regards Lizhong =D4=DA 2012=C4=EA4=D4=C221=C8=D5=D0=C7=C6=DA=C1=F9=A3=ACHenderickx, Wim = (Wim) =D0=B4=B5=C0=A3=BA > The VPWS which terminates at the H-VPLS node is indicated to be root = or leaf and the procedures associated will do the VLAN manipulation > > =20 > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Lizhong Jin > Sent: vrijdag 20 april 2012 18:38 > To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com > Cc: yuqun.cao@gmail.com > Subject: RE: The status of the approaches to the E-Tree solution? > > =20 > > Hi, all, > The difference between 2-VLAN and CW approach is who will provide the = R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW = will carry R/L information for CW approach. > I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used = to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information? > > Thanks > Lizhong > >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 Apr 2012 04:38:36 +0000 >> From: Alexander Vainshtein >> To: "Rogers, Josh" , Lucy yong >> , Daniel Cohn , Sam = Cao >> >> Cc: "l2vpn@ietf.org" >> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID: >> = >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi all, >> I fully understand that that what I am going to say is not very = popular, but: >> >> IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, = and, in a more generic way, localization of effects of changes in the PE configuration. >> >> In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect only = the PE where this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a = more >> complex model. Wether outside s-tag is used to differentiate, or >> dedicated pw's are used for the same purpose, it seems both become = more >> complex. >> >> Gile's comparison slide still concisely captures the differences = between >> these methods, in my opinion. I haven't seen any new ideas or = thoughts >> brought to the group in the past week or two on the subject. I would hate >> for both proposed methods to die on the vine because we couldn't = decide >> between two methods that have nothing inherently wrong with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" wrote: >> >>>Send this again. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree = uses >>>P2P PW fo=20 This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies thereof.=20 This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies thereof.=20 ------=_NextPart_000_0036_01CD2149.6CEC3100 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi = Jim,

 <= /span>

Thank you very = much for your comments. But what we did is a little different from = yours.

 <= /span>

Multi-PW carries = AC type in =A1=B0Layer2 Info Extended Community=A1=B1, NOT different RT, and = control plane will translate it, but we don=A1=AFt separate it into 2 VRFs (VSI in the = draft). They belong to one VSI.

 <= /span>

I guess your = E-Tree deployment via BGP-AD is, assign one Root-RT (same in all VPLA-PE in VPLS domain), = and assign different Leaf RT for each Leaf-only PE, then we will not setup = PW between Leaf-only PEs, then we can break the communication between = Leaf-Only PEs. Is my understanding correct or not? This is Hub-Spoke deployment, = and current solution can support this. But it can not cover all cases. =

 <= /span>

I agree with some = requirements on E-Tree in your mail.

 <= /span>

-          Partial mesh topologies.

[Sam] Agree. Now CW, Dual-VLAN or Dual-PW consider this in = draft, but for me, CW or Dual-VLAN will deploy partial mesh in your way or = configure it manually; Dual-PW can support this via signaling. =

-          Same PE mush be able to host Root and Leaf Sites. =

[Sam] Agree. This is Root-Leaf-Mixed case in all E-tree = draft; All drafts should support this.

-          Disallowing of Leaf to Leaf traffic on the same PE must be = done using PW semantics.

[Sam] Jim, can not fully understand this case. If on same = PE, this is local behavior, is it correct? Do you mean we need to setup one dummy = PW on any PE if it hosts Root and Leaf sites? Shall we describe in = draft?

-          When Root and Leaf sites are deployed on the same PE the = packets between them should obey the same semantics as if they had traversed a = PW i.e ( Split Horizon, No Label Re-Imposition etc=A1=AD ). =

[Sam] Same question as above. Anyway, =A1=B0Split = Horizon=A1=B1 is basic rule for all drafts.

-          If PE has a root and leaf site and sends traffic to PE1. PE1 = should be able to decide if the traffic was sourced from the root or leaf site. = If from PE:Leaf then the traffic should not be resolved in PE1:Leaf. =

[Sam] Yes, what we are doing is to solve = this.

 <= /span>

Thanks,=

 <= /span>

Sam

From: UTTARO, JAMES [mailto:ju1738@att.com]
Sent: Monday, April 23, = 2012 7:27 AM
To: 'Alexander = Vainshtein'; Sam Cao
Cc: l2vpn@ietf.org
Subject: RE: The status = of the approaches to the E-Tree solution?

 

For a given = PE, If you use BGP and define separate VRFs one for the leafs and one for roots = than the semantic provided by the RT assignment should be translated = correctly in to the forwarding programmed.. This means that intra-PE between the leaf = and root VRF should be treated as a Labeled PW. If treated as a regular ethernet interface than a leaf on VRF S1 can forward traffic on VRF H1 and then = onto a different PEs leaf VRF=A1=AD I believe we had a very similar = conversation over a year ago about E-Tree=A1=AD

 <= /o:p>

So, here = are the reqs I shared

 <= /o:p>

•          E-Tree/Partial mesh topologies need to = be realized in the control plane by constructing PWs. The data plane should = not infer a topology. In other words data should not have to be inspected to determine if the packet is sourced from a leaf or a = root

•          The same PE must be able to host Root = and Leaf sites. <= /span>

•          Disallowing of Leaf to Leaf traffic on = the same PE must be done using PW semantics.

•          When Root and Leaf sites are deployed on = the same PE the packets between them should obey the same semantics as if = they had traversed a PW i.e ( Split Horizon, No Label Re-Imposition etc=A1=AD )

•          If PE has a root and leaf site and sends traffic to PE1. PE1 should be able to decide if the traffic was sourced = from the root or leaf site. If from PE:Leaf then the traffic should not be = resolved in PE1:Leaf.<= /span>

 <= /o:p>

 <= /o:p>

Jim = Uttaro

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander = Vainshtein
Sent: Sunday, April 22, = 2012 10:57 AM
To: Sam Cao
Cc: l2vpn@ietf.org
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Sam,

I will try = to explain myself.

 <= /o:p>

I have = misspoken before, and I owe you an apology.

 <= /o:p>

A true = legacy PE cannot operate as a Mixed PE for E-tree since this operation requires = some changes in the forwarding behavior. This is IMHO correct regardless of the specific E-tree solution = that is implemented by the rest of the PEs (CW-based, dual PW-based = or VLAN-based). I.e. without some additional implementation-specific tricks = it can be either a Root-only PE or a Leaf-only PE in the VPLS that does not = contain Mixed PEs.

 <= /o:p>

Regards,

  =    Sasha

 <= /o:p>

From: Sam Cao [mailto:yuqun.cao@gmail.com]
Sent: Sunday, April 22, = 2012 5:22 PM
To: Alexander = Vainshtein
Cc: l2vpn@ietf.org; = 'Raymond Key'
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Sasha,<= /span>

 <= /span>

I agree with your comments. But maybe I don=A1=AFt make myself understood. I make it = clear.

 <= /span>

If one chip can = not support control word, then one switch which uses this chip can not work = as Root-Leaf-Mixed PE since we can not extend it. Is this correct? Is this reasonable?

 <= /span>

Anyway, chip = limit is big problem for CW approach.

 <= /span>

Regards,

 

Yuqun (Sam) Cao

E-mail: Yuqun.cao@gmail.com

 

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Sunday, April 22, = 2012 9:56 PM
To: Sam Cao
Cc: l2vpn@ietf.org; = 'Raymond Key'
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Sam,

You=A1=AFve = asked:

If it only supports VPLS, ok, it can = work as Root-only, but why it cannot work as Root-Leaf-Mixed or Leaf-only if it = cannot support CW?

IMHO and = FWIW there is not too much you can expect from a true legacy PE (i.e. a PE that did = not change its forwarding behavior):

1.       = It can obviously support Root-only functionality

2.       = It can support Leaf-only = functionality if there are no Mixed by preventing setup PW (by not setting up PWs to = other Leaf-only PEs).

Anything = beyond that would be very much implementation-specific. E.g., I am aware of legacy implementations that could support functionality of a Mixed PE provided = that it would be the only Mixed PE in the VPLS instance, and other = legacy implementations that are, as legacy, fully interoperable with these ones = but could not support such functionality.

 <= /o:p>

My = 2c,

  =    Sasha

 <= /o:p>

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Sam Cao
Sent: Sunday, April 22, = 2012 4:41 PM
To: 'Raymond Key'
Cc: l2vpn@ietf.org
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Raymond,

 <= /span>

Network = efficiency:

[Sam] Leaf/Root configuration is local configuration, and PE can not know remote AC type configuration. This is CW Fundamentals. So even if CW approach defines = optional enhancement for Leaf-Only PE, but can not signal it between Leaf-Only = PEs, so there is no good way to support this. The possible solution is, manually configure hub-spoke topology, but if we do like this, current solutions = have support most E-Tree cases with Hub-Spoke configuration. Lizhong = mentioned this in one mail.

 <= /span>

Backwards = compatibility:

[Sam] Yes, new = draft considers backward compatibility, but it makes precondition: The PE = which can not support Control word only works as Root-only PE. This does not make = sense for me. If it only supports VPLS, ok, it can work as Root-only, but why = it can not work as Root-Leaf-Mixed or Leaf-only if it can not support = CW?

 <= /span>

Regards,

 

Yuqun (Sam) Cao

E-mail: Yuqun.cao@gmail.com

 

From: raymond.key@hotmail.com [mailto:raymond.key@hotmail.com] On Behalf Of Raymond Key
Sent: Saturday, April 21, = 2012 11:32 PM
To: = yuqun.cao@gmail.com
Cc: l2vpn@ietf.org
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Some clarifications [RK] inserted below

Thanks

Raymond Key

From: yuqun.cao@gmail.com
To: lizho.jin@gmail.com; wim.henderickx@alcatel-lucent.com
Subject: RE: The status of the approaches to the E-Tree solution?
Date: Sat, 21 Apr 2012 22:51:28 +0800
CC: l2vpn@ietf.org

Hi all,

 

We reach an = impasseJ.  BTW, Meeting minutes is ready now. We can get E-tree summary from = IETF site.

 

Today I collected all items = we discussed before. They are,

 

1)       = Silicon issue or chip limit;

2)       = Network efficiency;

3)       = Encapsulation mode, tag or raw;

4)       = H-VPLS;

5)       = Backwards compatibility, especially legacy PE or Non-supporting PE with IEEE = E-tree support joins E-Tree domain;

6)       = Configuration change in operation, for example, Leaf-only -> = Root-Leaf-Mixed;

7)       = S-VLAN preservation support;

8)       = Multi-segment PW;

9)       = VLAN ID allocation (Only for Dual-VLAN);

10)   Multi-AS deployment;

11)   ECMP;

12)   P2MP-PW;

13)   Ethernet OAM;

 

If we review the mail-list, CW approach has the following limits:

1)       = Chip limit. Please read reply from Giles = and Wim;

2)       = Network efficiency: There are garbage = fames which will be dropped on egress PE since only egress PE can decide forward or = drop frames while it receives frames. Ingress PE can not decide = forward or not. Yes, current solution can support Hub-Spoke configuration, but as we = know, the configuration is not easy if the network is big. Dual-VLAN or Multi-PW = approach can break communication between Leaf-Only PEs via = signaling.

[RK] It seems to me this is not the case. = Section 6 of the draft has some discussions on this.
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-6=
6. Optional Enhancements for Leaf-only PE
6.1. No PW between Leaf-only PEs
6.2. Not Forward Frame from Leaf AC to Leaf-only PE

 

3)       = Backwards compatibility: Not all PEs = supports control word. If one can not support control word, it will not join = E-Tree domain;

 

[RK] It seems to = me this is not the case. Section 5 of the draft has some discussions on = this.
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-5=
5. Backward Compatibility
5.1. AC Type
5.2. Control Word
5.3. Additional Action in Data Forwarding
5.3.1. Ingress PE Supporting the Extension but Egress PE Not
5.3.2. Egress PE Supporting the Extension but Ingress PE Not

 

Dual VLAN has = following limits:

1)       = Chip limit: As we know, we need to push = one VLAN into frames before MPLS encapsulation on ingress PE and stripe it out on = egress PE. This is non-standard operation. Wait for confirmation from chip = vendor;

2)       = HVPLS: If we follow Fig 3 or Fig = 4 in RFC 4762 to deploy = HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, = but can NOT configure it at all in Spoke PW case;

3)       = Multi-PW: Rafi figures this out, but we = don=A1=AFt think this over at that time. I think that it also has same problem as = H-VPLS has.

4)       = Encapsulation mode: If deploy GVPLS with = Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE = will stripe S-VLAN ID;

5)       = Backward Compatibility: Just as Daniel = mentioned, there is compatibility issue if legacy PE joins E-Tree domain. For me, I = don=A1=AFt get clear response from co-authors of Dual-VLAN.

 

For all = approaches, we don=A1=AFt cover ECMP / Ethernet OAM till now.

 

Is there anything = missed?

 

Regards,

 

Yuqun = (Sam) Cao

E-mail: = Yuqun.cao@gmail.com =

 

From: Lizhong Jin [mailto:lizho.jin@gmail.com]
Sent: Saturday, April 21, = 2012 11:59 AM
To: Henderickx, Wim = (Wim)
Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; yuqun.cao@gmail.com
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Hi Win,
Thank you for the answers. In that case, PE-rs should configure the = root/leaf properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, = you could not figure out the accessing spoke PW is from PE-r of VPWS or = MTU-s. Unless having some additional indication in NMS, you even don't know = which spoke PW needs to do VLAN manipulation. I am not sure such R/L = configuration could be accepted from operational view. Hope to see more comments.

Regards
Lizhong


=D4=DA 2012=C4=EA4=D4=C221=C8=D5=D0=C7=C6=DA=C1=F9=A3=ACHenderickx, Wim (Wim) <wim.henderickx@alcatel-= lucent.com> =D0=B4=B5=C0=A3=BA
> The VPWS which terminates at the H-VPLS node is indicated to be = root or leaf and the procedures associated will do the VLAN manipulation
>
>  
>
> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin
> Sent: vrijdag 20 april 2012 18:38
> To: l2vpn@ietf.org; Alexander.Vainshtein@eci= tele.com
> Cc: yuqun.cao@gmail.com
> Subject: RE: The status of the approaches to the E-Tree = solution?
>
>  
>
> Hi, all,
> The difference between 2-VLAN and CW approach is who will provide = the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW = will carry R/L information for CW approach.
> I have a question with the 2-VLAN approach in H-VPLS where H-VPLS = is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds = VLAN to indicate R/L information?
>
> Thanks
> Lizhong
>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 19 Apr 2012 04:38:36 +0000
>> From: Alexander Vainshtein <Alexander.Vainshtein@eci= tele.com>
>> To: "Rogers, Josh" <josh.rogers@twcable.com>, = Lucy yong
>>        <lucy.yong@huawei.com>, = Daniel Cohn <DanielC@orckit.com>, = Sam Cao
>>        <yuqun.cao@gmail.com>
>> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
>> Subject: RE: The status of the approaches to the E-Tree = solution?
>> Message-ID:
>>        <F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>
>> Content-Type: text/plain; charset=3D"us-ascii"
>>
>> Hi all,
>> I fully understand that that what I am going to say is not very popular, but:
>>
>> IMO one of the advantages of the CW-based solution is that it = is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic.
>>
>> Another advantage is preservation of full mesh of P2P PWs in a = VPLS, and, in a more generic way, localization of effects of changes in the PE = configuration.
>>
>> In particular, adding a Leaf AC to a PE that previously has = been only supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect only the = PE where this operation happens and not the rest of the PEs.
>>
>> As for the need for HW changes that have been mentioned as a = main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution.
>>
>> My 2c,
>>     Sasha
>>
>>
>>
>> ________________________________________
>> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] = on behalf of Rogers, Josh [josh.rogers@twcable.com]
>> Sent: Wednesday, April 18, 2012 9:57 PM
>> To: Lucy yong; Daniel Cohn; Sam Cao
>> Cc: l2vpn@ietf.org
>> Subject: Re: The status of the approaches to the E-Tree = solution?
>>
>> Again, the P2MP situation throws me.  Is this something that is used
>> commonly?
>>
>> I'm under the impression that adding P2MP to any model results = in a more
>> complex model.  Wether outside s-tag is used to differentiate, or
>> dedicated pw's are used for the same purpose, it seems both = become more
>> complex.
>>
>> Gile's comparison slide still concisely captures the = differences between
>> these methods, in my opinion.  I haven't seen any new ideas or thoughts
>> brought to the group in the past week or two on the subject. =  I would hate
>> for both proposed methods to die on the vine because we = couldn't decide
>> between two methods that have nothing inherently wrong with = either.
>>
>> -Josh
>>
>>
>> On 4/18/12 1:53 PM, "Lucy yong" <lucy.yong@huawei.com> = wrote:
>>
>>>Send this again.
>>>
>>>Two PW approach can be complex too if the VPLS instance for = E-Tree uses
>>>P2P PW fo

This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, phone = or fax, and then delete the original and all copies thereof. =

This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, phone = or fax, and then delete the original and all copies thereof. =

------=_NextPart_000_0036_01CD2149.6CEC3100-- From jiangyuanlong@huawei.com Mon Apr 23 01:36:54 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F5D21F863F; Mon, 23 Apr 2012 01:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599] 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 tErSbihPz2U2; Mon, 23 Apr 2012 01:36:52 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 98C2B21F863C; Mon, 23 Apr 2012 01:36:52 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFD32109; Mon, 23 Apr 2012 04:36:52 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Apr 2012 01:34:14 -0700 Received: from SZXEML429-HUB.china.huawei.com (10.72.61.37) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Apr 2012 01:34:15 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.137]) by SZXEML429-HUB.china.huawei.com ([10.72.61.37]) with mapi id 14.01.0323.003; Mon, 23 Apr 2012 16:34:09 +0800 From: Jiangyuanlong To: Stewart Bryant Subject: Re: Fwd: IPR Statements concerning etree Thread-Topic: Fwd: IPR Statements concerning etree Thread-Index: AQHNISvaxOG9O90SYkm8bQARl+8XDA== Date: Mon, 23 Apr 2012 08:34:08 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EA4B@SZXEML508-MBS.china.huawei.com> References: 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.70.40.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , "l2vpn-chairs@tools.ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" X-BeenThere: l2vpn@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, 23 Apr 2012 08:36:54 -0000 As far as I know, tagging E-Tree traffic with different VLANs had already b= een published in 2005 (it is called asymmetric VLANs in IEEE 802.1Q-2005), = well ahead of it. ------------------------------ Date: Fri, 20 Apr 2012 15:37:23 +0100 From: Stewart Bryant To: "l2vpn@ietf.org" , "l2vpn-chairs@tools.ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Fwd: IPR Statements concerning etree Message-ID: <4F9174A3.6000102@cisco.com> Content-Type: text/plain; charset=3D"iso-8859-1"; Format=3D"flowed" WGs, You may wish to look at the following IPR statements that were received yesterday. They all relate to etree. The stated terms appear to require payment of a royalty. Stewart -------- Original Message -------- Subject: IPR Statements Date: Thu, 19 Apr 2012 13:04:27 -0400 From: Russ Housley To: Stewart Bryant Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:14:30 PM EDT > To: simon.delord@gmail.com, raymond.key@ieee.org, wim.henderickx@alcatel= -lucent.com, lucy.yong@huawei.com, lizhong.jin@zte.com.cn, frederic.jounay@= orange.ch > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR rela= ted to draft-delord-pwe3-cw-bit-etree-07 > > > Dear Simon DeLord, Raymond Key, Wim Henderickx, Lucy Yong, Lizhong Jin, = Frederic JOUNAY: > > An IPR disclosure that pertains to your Internet-Draft entitled "Control= Word > Reserved bit for use in E-Tree" (draft-delord-pwe3-cw-bit-etree) was sub= mitted > to the IETF Secretariat on 2012-04-19 and has been posted on the "IETF P= age of > Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/= ipr/1760/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Stat= ement about IPR related to draft-delord-pwe3-cw-bit-etree-07.""); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:15:08 PM EDT > To: yuqun.cao@gmail.com > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR rela= ted to draft-cao-l2vpn-vpls-etree-02 > > > Dear Yuqun Cao: > > An IPR disclosure that pertains to your Internet-Draft entitled "Extensi= on to > VPLS for E-Tree" (draft-cao-l2vpn-vpls-etree) was submitted to the IETF > Secretariat on 2012-04-19 and has been posted on the "IETF Page of Intel= lectual > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1759/). T= he title > of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR rel= ated to > draft-cao-l2vpn-vpls-etree-02."); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:15:34 PM EDT > To: chen.ran@zte.com.cn > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR rela= ted to draft-chen-l2vpn-vpls-etree-vlan-01 > > > Dear Ran Chen: > > An IPR disclosure that pertains to your Internet-Draft entitled "Automat= ic VLAN > allocation in E-tree" (draft-chen-l2vpn-vpls-etree-vlan) was submitted t= o the > IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of > Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/= ipr/1758/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Stat= ement about IPR related to draft-chen-l2vpn-vpls-etree-vlan-01."); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:16:29 PM EDT > To: jiangyuanlong@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.d= e, frederic.jounay@orange.ch, florin.balus@alcatel-lucent.com, wim.henderic= kx@alcatel-lucent.com, sajassi@cisco.com > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR rela= ted to draft-jiang-l2vpn-etree-bgp-00 > > > Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Bal= us, Wim Henderickx, Ali Sajassi: > > An IPR disclosure that pertains to your Internet-Draft entitled "E-Tree = Support > in VPLS with BGP Signaling" (draft-jiang-l2vpn-etree-bgp) was submitted = to the > IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of > Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/= ipr/1757/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Stat= ement about IPR related to draft-jiang-l2vpn-etree-bgp-00."); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:17:02 PM EDT > To: yljiang@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.de, fre= deric.jounay@orange-ftgroup.com, florin.balus@alcatel-lucent.com, wim.hende= rickx@alcatel-lucent.com > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR rela= ted to draft-jiang-l2vpn-vpls-pe-etree-05 > > > Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Bal= us, Wim Henderickx: > > An IPR disclosure that pertains to your Internet-Draft entitled "VPLS PE= Model > for E-Tree Support" (draft-jiang-l2vpn-vpls-pe-etree) was submitted to t= he IETF > Secretariat on 2012-04-19 and has been posted on the "IETF Page of Intel= lectual > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1756/). T= he title > of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR rel= ated to > draft-jiang-l2vpn-vpls-pe-etree-05.""); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:17:48 PM EDT > To: danielc@orckit.com, rafir@orckit.com, pagarwal@broadcom.com, raymond= .key@team.telstra.com > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR rela= ted to draft-ram-l2vpn-ldp-vpls-etree-2pw-02 > > > Dear Daniel Cohn, Rafi Ram, Puneet Agarwal, Raymond Key: > > An IPR disclosure that pertains to your Internet-Draft entitled "Extensi= on to > LDP-VPLS for E-Tree Using Two PW" (draft-ram-l2vpn-ldp-vpls-etree-2pw) w= as > submitted to the IETF Secretariat on 2012-04-19 and has been posted on t= he "IETF Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1755/). The title of the IPR disclosur= e is > "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-l= dp-vpls- > etree-2pw-02.""); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:18:32 PM EDT > To: rafir@orckit.com, danielc@orckit.com, raymond.key@ieee.org, pagarwal= @broadcom.com, josh.rogers@twcable.com > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR rela= ted to draft-ram-l2vpn-etree-multiple-pw-01 > > > Dear Rafi Ram, Daniel Cohn, Raymond Key, Puneet Agarwal, Joshua Rogers: > > An IPR disclosure that pertains to your Internet-Draft entitled "Extensi= on to > VPLS for E-Tree Using Multiple PWs" (draft-ram-l2vpn-etree-multiple-pw) = was > submitted to the IETF Secretariat on 2012-04-19 and has been posted on t= he "IETF > Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1754/). The title of the IPR disclosur= e is > "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-e= tree- > multiple-pw-01.""); > > The IETF Secretariat > From jiangyuanlong@huawei.com Mon Apr 23 04:26:03 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9AC21F8693 for ; Mon, 23 Apr 2012 04:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599] 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 d4bZ-YrtURgg for ; Mon, 23 Apr 2012 04:26:02 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9F82021F8659 for ; Mon, 23 Apr 2012 04:26:02 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFD42105; Mon, 23 Apr 2012 07:26:02 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Apr 2012 04:23:22 -0700 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Apr 2012 04:23:21 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.137]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 23 Apr 2012 19:23:16 +0800 From: Jiangyuanlong To: Sam Cao Subject: Discussion on E-Tree and H-VPLS Thread-Topic: Discussion on E-Tree and H-VPLS Thread-Index: AQHNIUN67h0xDILTIEWgVSrvExKN6w== Date: Mon, 23 Apr 2012 11:23:15 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EAE6@SZXEML508-MBS.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E891@SZXEML508-MBS.china.huawei.com> <5C3578E316494634B1DCAC06C15E2C21@R01842> In-Reply-To: <5C3578E316494634B1DCAC06C15E2C21@R01842> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AIQC AjPi BVT5 Bf3Y CJqY Cc7Y Dhhq Fz/T H9wS IuMr JCYJ Ln+j P/Fy Q4W7 RADf UHD0; 2; bAAyAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAeQB1AHEAdQBuAC4AYwBhAG8AQABnAG0AYQBpAGwALgBjAG8AbQA=; Sosha1_v1; 7; {79D0BCC2-BF53-44D4-831D-10457A0DCA90}; agBpAGEAbgBnAHkAdQBhAG4AbABvAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Mon, 23 Apr 2012 11:23:12 GMT; RABpAHMAYwB1AHMAcwBpAG8AbgAgAG8AbgAgAEUALQBUAHIAZQBlACAAYQBuAGQAIABIAC0AVgBQAEwAUwA= x-cr-puzzleid: {79D0BCC2-BF53-44D4-831D-10457A0DCA90} x-originating-ip: [10.70.40.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 23 Apr 2012 11:26:03 -0000 Sam, Please see my comments in line. I also change the title to reflect the topi= c. Regards Yuanlong -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Monday, April 23, 2012 11:28 AM To: Jiangyuanlong Cc: l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 95, Issue 58 Yuanlong, I do apologize for my unclear description. I try to make it clear. VPWS or Spoke PW, PE-rs will take the PW as Spoke PW. Or say, PE-rs really does NOT care remote access is VPWS access (point-to-point, Fig. 3) or VPLS spoke access (Fig. 4). PE-rs just know it is spoke PW and it is ENOUGH, and does NOT care customer payload. is this correct? At least it is correct in RFC 4762.=20 [JY] why divide the remote access to VPWS access and VPLS access? But, if remote is VPWS access (Fig. 3), PE-rs SHOULD configure AC-type for remote VPWS access although it is still spoke PW in E-Tree. Please refer to your answer to Josh's question. It seems reasonable. Ok, we think another case in Fig. 4. In Fig. 4, PE-rs CAN NOT configure AC-type at all in this case. In fact, on MTU-s it is VPLS and we should configure AC type on MTU-s= . [JY] Quite opposite, in case of Fig.4, IMHO, it is better to configure the = E-Tree attribute on the PE-rs since the PE-r does not support any bridging = functions. I think this case is provided in RFC4762 just to be compatible w= ith some legacy routers. Ok, problem came up for me. For spoke PW on PE-rs, in one case it should configure AC type and work as agent; in another case, it can NOT configure AC type and can not work as agent. In fact, PE-rs knows it is spoke PW, it is enough; why spoke-PW has different configuration in same VPLS instance o= n same PE? I am confused although I know why we should configure in that way. I prefer not to configure AC type on PE-rs since we can take it as "Switching PE" (NOT pefact here and it is not real "Switching Point") which does NOT aware customer payload. Extension to VPWS? Seems not reasonable. [JY] Not sure I got your points. PE-rs will terminate the PW and switch the= Ethernet frames. IMO, whether configuring the E-Tree service on a PE-rs or= a MTU-s is dependent on the topology of the service and how they are attac= hed. H-VPLS can be seen as a transparent transport network, or as a service= itself. Thanks, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Monday, April 23, 2012 9:59 AM To: Sam Cao Cc: l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 95, Issue 58 Hi Sam, If E-Tree service is provided in a scenario as Fig. 3 and Fig 4 in RFC 4762= , then a CE (leaf or root) is connected to the MTU-s or PE-r, thus the AC should be terminated and the E-Tree service should be encapsulated by the MTU-s or PE-r. I don't quite understand why you need to "take VPWS PW as on= e AC", but even in that case, the attribute of the AC may be configured at th= e PE-rs. So what is the problem for H-VPLS? Thanks Yuanlong Date: Sun, 22 Apr 2012 22:03:52 +0800 From: "Sam Cao" To: "'Jiangyuanlong'" Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <962A848896EF4678B17D76C826A7EAEF@v2comsam> Content-Type: text/plain; charset=3D"us-ascii" Yuanlong, I just collect all issues we discussed before, and we still can not make agreement. I gave my comments on 2 items below. I will think other items over and give my comments tomorrow. 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, but can NOT configure it at all in Spoke PW case;=20 [JY] In the first place, why PE-rs need to figure out the AC type for a spoke? The VLAN should be processed in the MTU, not in the PE-rs. [Sam] Yuanlong, I understand your idea. It does NOT make sense for me. First, Fig. 3 and Fig 4 in RFC 4762 are different cases. For VPWS (Fig. 3), we can take VPWS PW as one AC. You know, PE-rs is termination of VPWS, so i= t will add VLAN-ID to identify Root/Leaf. BTW, you will map several VLAN IDs into one Root-VLAN ID or Leaf-VLAN ID on PE-rs, so we need to configure Root/Leaf on PE-rs (Refer to your reply to Josh's comments). 4) Encapsulation mode: If deploy HVPLS with Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN ID; [JY] Is anything not working with tagged PW mode? [Sam] Tagged mode works.=20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 From Alexander.Vainshtein@ecitele.com Mon Apr 23 04:33:31 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F3921F8697 for ; Mon, 23 Apr 2012 04:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.318 X-Spam-Level: X-Spam-Status: No, score=-4.318 tagged_above=-999 required=5 tests=[AWL=0.884, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, 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 MWgUJULEvxOg for ; Mon, 23 Apr 2012 04:33:31 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5C79921F868A for ; Mon, 23 Apr 2012 04:33:30 -0700 (PDT) Received: from [85.158.138.51:15455] by server-9.bemta-3.messagelabs.com id BF/EF-26691-90E359F4; Mon, 23 Apr 2012 11:33:29 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1335180808!23320302!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.7; banners=-,-,- Received: (qmail 23669 invoked from network); 23 Apr 2012 11:33:28 -0000 Received: from unknown (HELO fridlpvsb005.ecitele.com) (168.87.1.157) by server-11.tower-174.messagelabs.com with SMTP; 23 Apr 2012 11:33:28 -0000 X-AuditID: a8571406-b7fe86d0000037a2-40-4f953e03c8a6 Received: from FRGRWPVCH001.ecitele.com (frgrwpvch001.ecitele.com [10.1.18.35]) by fridlpvsb005.ecitele.com (Symantec Messaging Gateway) with SMTP id 27.0A.14242.30E359F4; Mon, 23 Apr 2012 13:33:23 +0200 (CEST) Received: from FRIDWPPMB002.ecitele.com ([169.254.4.167]) by FRGRWPVCH001.ecitele.com ([10.1.18.35]) with mapi id 14.01.0339.001; Mon, 23 Apr 2012 13:33:28 +0200 From: Alexander Vainshtein To: Jiangyuanlong , Sam Cao Subject: RE: Discussion on E-Tree and H-VPLS Thread-Topic: Discussion on E-Tree and H-VPLS Thread-Index: AQHNIUPk8Ypm+Dwl9keYw7edV1ij15aoRiAQ Date: Mon, 23 Apr 2012 11:33:27 +0000 Message-ID: References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E891@SZXEML508-MBS.china.huawei.com> <5C3578E316494634B1DCAC06C15E2C21@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EAE6@SZXEML508-MBS.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EAE6@SZXEML508-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTfUgTYRzu3d3O03ZxzdVeh8W4kKLa2Pqghc6iiMyKRUWFGHVtb9vVdht3 S7Qgh0kfimGhSOtjllr2YYYhlX1QMwqL6MvKij5dkEZlBX6B0Z1XZnR/Pe/7PL/n+b3v+zsS 03YQBpLjg0jgWS9DJOAJYITBhKWXOyzRimTbk65dhK29OxpnO7zjHjEXy7gUfhWXUXjzszqj urpPtQzLCoE0luf9QTaIjC4kOu3MMoHLYZ15jJFz2RkrYwx4WSfyIT5oZ9hAAPEuJj3B+N+X Jsk43oh4p9/F8W47s2iFw2SzzZxtsjLpKz2caEQmH8t5jT4kiqwbGaUduW/etf4s5mnrbcQC FVNzm5uvq0LgKVMESBLSM2DfYWcRiJfgWPjgdT1RBBJILd0KYF3hI6AsagC8da6bkFUEbYcN p18NYh29GDZ9LFDJGKNTYGHDNSDjRNoEzzdEcEVjhp0fmjA5TEdPg0cq9fI2Lslj16vVMqbo pfD980pcyRoAsL+7BJOJeHoVrHp3b9AHSN313DnzO0sPX8QiKqVrGlZfuY8peAzsaP+pVvB4 WHCyNU7RT4WVl78TCp4Cjx/9hCnBo2HLgRiu6JPgjdo2vBTow8MiwsPKw8PKw8PKKwF+CsCN AufyBnLEDRbLTDNyckHkRWan39cApIGpXa0jLoJQqTkKaBIwGqqXL3No1WyOmOeLgiRSxYyh rtjKHdpRG/yuPA8retYJW7xIjAJIYoyOqkuVOMrF5m1Fgv8PZZNucR9mGOn0y08cXDfdYvln weip+uXpDi3tluZuM0IBJPwpTSZJBlJz7JLraAG5Ue5Gzhv8S6vIeDlZIyW/SZOTxQDrEzm3 wt8BKWTfg5ZWoMV5P48MeipbNqJlkWcLP+TTCfTSWRMpVmY10hwOOXRK5irJfH32ftlc+i+G KEMIlFydZYqc1K/4at3+PartEdSxZPeM/gGNam9b7oX2N7NfPt6TNff0pi+PfnR9aTw2sbh2 YY29aimWaI0vpZfkH7mQ0ZVlrUmKG6d51miYH/EczCze3fFQVzbKljpvbWb4bv6kb7sG1iwo nPDi7rbeebF6YO+aUPO2fWBn3YnQIe1tcyuDix7WOhkTRPYXnHmFUPwDAAA= Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 23 Apr 2012 11:33:31 -0000 Sam, Yuanlong and all, >From my point of view the CW-based solution is by far the simplest way to de= al with H-VPLS: all that is required is preservation of the CW (or, in the u= nlikely case PW sequencing is used, of its flags) when a packet is forwarded= from the "core" PW to a "spoke" one (or vice versa). With Dual PWE the situation becomes more complicated IMO. Not sure about dua= l VLAN - but may be also tricky. Regards, Sasha > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Jiangyuanlong > Sent: Monday, April 23, 2012 2:23 PM > To: Sam Cao > Cc: l2vpn@ietf.org > Subject: Discussion on E-Tree and H-VPLS > > Sam, > > Please see my comments in line. I also change the title to reflect the top= ic. > > Regards > Yuanlong > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Monday, April 23, 2012 11:28 AM > To: Jiangyuanlong > Cc: l2vpn@ietf.org > Subject: RE: L2vpn Digest, Vol 95, Issue 58 > > Yuanlong, > > I do apologize for my unclear description. I try to make it clear. > > VPWS or Spoke PW, PE-rs will take the PW as Spoke PW. Or say, PE-rs really > does NOT care remote access is VPWS access (point-to-point, Fig. 3) or VPL= S > spoke access (Fig. 4). PE-rs just know it is spoke PW and it is ENOUGH, an= d > does NOT care customer payload. is this correct? At least it is correct i= n > RFC 4762. > [JY] why divide the remote access to VPWS access and VPLS access? > > But, if remote is VPWS access (Fig. 3), PE-rs SHOULD configure AC-type for > remote VPWS access although it is still spoke PW in E-Tree. Please refer t= o > your answer to Josh's question. It seems reasonable. Ok, we think another > case in Fig. 4. In Fig. 4, PE-rs CAN NOT configure AC-type at all in this > case. In fact, on MTU-s it is VPLS and we should configure AC type on MTU-= s. > [JY] Quite opposite, in case of Fig.4, IMHO, it is better to configure the= E- > Tree attribute on the PE-rs since the PE-r does not support any bridging > functions. I think this case is provided in RFC4762 just to be compatible= with > some legacy routers. > > > Ok, problem came up for me. For spoke PW on PE-rs, in one case it should > configure AC type and work as agent; in another case, it can NOT configure > AC type and can not work as agent. In fact, PE-rs knows it is spoke PW, it > is enough; why spoke-PW has different configuration in same VPLS instance > on > same PE? I am confused although I know why we should configure in that > way. > > I prefer not to configure AC type on PE-rs since we can take it as > "Switching PE" (NOT pefact here and it is not real "Switching Point") whic= h > does NOT aware customer payload. Extension to VPWS? Seems not > reasonable. > [JY] Not sure I got your points. PE-rs will terminate the PW and switch th= e > Ethernet frames. IMO, whether configuring the E-Tree service on a PE-rs or= a > MTU-s is dependent on the topology of the service and how they are > attached. H-VPLS can be seen as a transparent transport network, or as a > service itself. > > Thanks, > > Sam > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, April 23, 2012 9:59 AM > To: Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: L2vpn Digest, Vol 95, Issue 58 > > Hi Sam, > > If E-Tree service is provided in a scenario as Fig. 3 and Fig 4 in RFC 476= 2, > then a CE (leaf or root) is connected to the MTU-s or PE-r, thus the AC > should be terminated and the E-Tree service should be encapsulated by the > MTU-s or PE-r. I don't quite understand why you need to "take VPWS PW as > one > AC", but even in that case, the attribute of the AC may be configured at t= he > PE-rs. So what is the problem for H-VPLS? > > Thanks > Yuanlong > > Date: Sun, 22 Apr 2012 22:03:52 +0800 > From: "Sam Cao" > To: "'Jiangyuanlong'" > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: <962A848896EF4678B17D76C826A7EAEF@v2comsam> > Content-Type: text/plain; charset=3D"us-ascii" > > Yuanlong, > > I just collect all issues we discussed before, and we still can not make > agreement. I gave my comments on 2 items below. I will think other items > over and give my comments tomorrow. > > 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, > PE-rs works in different manner, PE-rs should figure out AC type in VPWS > case, but can NOT configure it at all in Spoke PW case; > [JY] In the first place, why PE-rs need to figure out the AC type for a > spoke? The VLAN should be processed in the MTU, not in the PE-rs. > [Sam] Yuanlong, I understand your idea. It does NOT make sense for me. > First, Fig. 3 and Fig 4 in RFC 4762 are different cases. For VPWS (Fig. 3)= , > we can take VPWS PW as one AC. You know, PE-rs is termination of VPWS, > so it > will add VLAN-ID to identify Root/Leaf. BTW, you will map several VLAN IDs > into one Root-VLAN ID or Leaf-VLAN ID on PE-rs, so we need to configure > Root/Leaf on PE-rs (Refer to your reply to Josh's comments). > > 4) Encapsulation mode: If deploy HVPLS with Spoke PW mode, PE-rs > should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLA= N > ID; > [JY] Is anything not working with tagged PW mode? > [Sam] Tagged mode works. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From jiangyuanlong@huawei.com Mon Apr 23 04:52:46 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C4621F86D1 for ; Mon, 23 Apr 2012 04:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599] 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 T1oGQNlLa021 for ; Mon, 23 Apr 2012 04:52:45 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A031521F86CF for ; Mon, 23 Apr 2012 04:52:45 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFL46312; Mon, 23 Apr 2012 07:52:45 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Apr 2012 04:49:50 -0700 Received: from SZXEML435-HUB.china.huawei.com (10.72.61.63) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Apr 2012 04:49:49 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.137]) by szxeml435-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 23 Apr 2012 19:49:46 +0800 From: Jiangyuanlong To: Alexander Vainshtein , Sam Cao Subject: RE: Discussion on E-Tree and H-VPLS Thread-Topic: Discussion on E-Tree and H-VPLS Thread-Index: AQHNIUN67h0xDILTIEWgVSrvExKN65anwSmAgACGqvA= Date: Mon, 23 Apr 2012 11:49:45 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EB16@SZXEML508-MBS.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E891@SZXEML508-MBS.china.huawei.com> <5C3578E316494634B1DCAC06C15E2C21@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EAE6@SZXEML508-MBS.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-cr-hashedpuzzle: H41Y Kg58 LIHP MbnC OLUd Og0t OyeO RHuc RmAz VHkn WQQO cWwr cYIp c8fv doKQ eGpo; 3; YQBsAGUAeABhAG4AZABlAHIALgB2AGEAaQBuAHMAaAB0AGUAaQBuAEAAZQBjAGkAdABlAGwAZQAuAGMAbwBtADsAbAAyAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAeQB1AHEAdQBuAC4AYwBhAG8AQABnAG0AYQBpAGwALgBjAG8AbQA=; Sosha1_v1; 7; {2980D340-2D88-45B6-8EB2-027F2965F3EC}; agBpAGEAbgBnAHkAdQBhAG4AbABvAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Mon, 23 Apr 2012 11:49:41 GMT; UgBFADoAIABEAGkAcwBjAHUAcwBzAGkAbwBuACAAbwBuACAARQAtAFQAcgBlAGUAIABhAG4AZAAgAEgALQBWAFAATABTAA== x-cr-puzzleid: {2980D340-2D88-45B6-8EB2-027F2965F3EC} x-originating-ip: [10.70.40.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 23 Apr 2012 11:52:46 -0000 Hi Sash, What Sam discussed is the use case where some legacy devices play the role = of PE-r or MTU-s, these devices may not support CW either (some spoke are Q= inQ actually). If all devices support the E-Tree extension, dual VLAN seems quite simple t= oo - the PE-rs just needs to preserve the VLAN tagged by the MTU-s. Section= A.2 of our I-D already discusses this H-VPLS scenario, could you have a re= view of it? Regards and thanks, Yuanlong -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Monday, April 23, 2012 7:33 PM To: Jiangyuanlong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS=20 Sam, Yuanlong and all, >From my point of view the CW-based solution is by far the simplest way to d= eal with H-VPLS: all that is required is preservation of the CW (or, in the= unlikely case PW sequencing is used, of its flags) when a packet is forwar= ded from the "core" PW to a "spoke" one (or vice versa). With Dual PWE the situation becomes more complicated IMO. Not sure about du= al VLAN - but may be also tricky. Regards, Sasha > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Jiangyuanlong > Sent: Monday, April 23, 2012 2:23 PM > To: Sam Cao > Cc: l2vpn@ietf.org > Subject: Discussion on E-Tree and H-VPLS >=20 > Sam, >=20 > Please see my comments in line. I also change the title to reflect the to= pic. >=20 > Regards > Yuanlong >=20 > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Monday, April 23, 2012 11:28 AM > To: Jiangyuanlong > Cc: l2vpn@ietf.org > Subject: RE: L2vpn Digest, Vol 95, Issue 58 >=20 > Yuanlong, >=20 > I do apologize for my unclear description. I try to make it clear. >=20 > VPWS or Spoke PW, PE-rs will take the PW as Spoke PW. Or say, PE-rs reall= y > does NOT care remote access is VPWS access (point-to-point, Fig. 3) or VP= LS > spoke access (Fig. 4). PE-rs just know it is spoke PW and it is ENOUGH, a= nd > does NOT care customer payload. is this correct? At least it is correct = in > RFC 4762. > [JY] why divide the remote access to VPWS access and VPLS access? >=20 > But, if remote is VPWS access (Fig. 3), PE-rs SHOULD configure AC-type fo= r > remote VPWS access although it is still spoke PW in E-Tree. Please refer = to > your answer to Josh's question. It seems reasonable. Ok, we think another > case in Fig. 4. In Fig. 4, PE-rs CAN NOT configure AC-type at all in this > case. In fact, on MTU-s it is VPLS and we should configure AC type on MTU= -s. > [JY] Quite opposite, in case of Fig.4, IMHO, it is better to configure th= e E- > Tree attribute on the PE-rs since the PE-r does not support any bridging > functions. I think this case is provided in RFC4762 just to be compatible= with > some legacy routers. >=20 >=20 > Ok, problem came up for me. For spoke PW on PE-rs, in one case it should > configure AC type and work as agent; in another case, it can NOT configur= e > AC type and can not work as agent. In fact, PE-rs knows it is spoke PW, i= t > is enough; why spoke-PW has different configuration in same VPLS instance > on > same PE? I am confused although I know why we should configure in that > way. >=20 > I prefer not to configure AC type on PE-rs since we can take it as > "Switching PE" (NOT pefact here and it is not real "Switching Point") whi= ch > does NOT aware customer payload. Extension to VPWS? Seems not > reasonable. > [JY] Not sure I got your points. PE-rs will terminate the PW and switch t= he > Ethernet frames. IMO, whether configuring the E-Tree service on a PE-rs o= r a > MTU-s is dependent on the topology of the service and how they are > attached. H-VPLS can be seen as a transparent transport network, or as a > service itself. >=20 > Thanks, >=20 > Sam >=20 > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, April 23, 2012 9:59 AM > To: Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: L2vpn Digest, Vol 95, Issue 58 >=20 > Hi Sam, >=20 > If E-Tree service is provided in a scenario as Fig. 3 and Fig 4 in RFC 47= 62, > then a CE (leaf or root) is connected to the MTU-s or PE-r, thus the AC > should be terminated and the E-Tree service should be encapsulated by the > MTU-s or PE-r. I don't quite understand why you need to "take VPWS PW as > one > AC", but even in that case, the attribute of the AC may be configured at = the > PE-rs. So what is the problem for H-VPLS? >=20 > Thanks > Yuanlong >=20 > Date: Sun, 22 Apr 2012 22:03:52 +0800 > From: "Sam Cao" > To: "'Jiangyuanlong'" > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: <962A848896EF4678B17D76C826A7EAEF@v2comsam> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Yuanlong, >=20 > I just collect all issues we discussed before, and we still can not make > agreement. I gave my comments on 2 items below. I will think other items > over and give my comments tomorrow. >=20 > 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, > PE-rs works in different manner, PE-rs should figure out AC type in VPWS > case, but can NOT configure it at all in Spoke PW case; > [JY] In the first place, why PE-rs need to figure out the AC type for a > spoke? The VLAN should be processed in the MTU, not in the PE-rs. > [Sam] Yuanlong, I understand your idea. It does NOT make sense for me. > First, Fig. 3 and Fig 4 in RFC 4762 are different cases. For VPWS (Fig. 3= ), > we can take VPWS PW as one AC. You know, PE-rs is termination of VPWS, > so it > will add VLAN-ID to identify Root/Leaf. BTW, you will map several VLAN ID= s > into one Root-VLAN ID or Leaf-VLAN ID on PE-rs, so we need to configure > Root/Leaf on PE-rs (Refer to your reply to Josh's comments). >=20 > 4) Encapsulation mode: If deploy HVPLS with Spoke PW mode, PE-rs > should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VL= AN > ID; > [JY] Is anything not working with tagged PW mode? > [Sam] Tagged mode works. >=20 > Regards, >=20 > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com >=20 This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. From giles.heron@gmail.com Mon Apr 23 05:18:54 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BF221F84DA; Mon, 23 Apr 2012 05:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDHd8UQfyv1A; Mon, 23 Apr 2012 05:18:52 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4943621F84C4; Mon, 23 Apr 2012 05:18:52 -0700 (PDT) Received: by werb10 with SMTP id b10so9130422wer.31 for ; Mon, 23 Apr 2012 05:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=C/mDP8O3C/Jny0uYBPeuqLYdhHe2aXZEOoKXotl6ffs=; b=Eigxla3Br0eZpNnAP+a7bv5AHWP1WjpsEvfHjnhz4AEVJcofi4UyWMFUF8P1WhpII5 xvoFsIGgEcXFmqePJ7xV/AHnyIu/l3L18nJJWyQtOTFpqEqBXYJF+upR39e5RrUuOmfK eHKwRIcCijTHSsTAumbgqR+kaoJalAPmCXCXyifXVv4etlpRHqDg6EZZ7r20atP/gh2L HLKTfBwOGBIoMteTcp/pjvjHgGiL+Y44H/Vjg03sPuZXIkrNQxsaDVLtgaJGG1Ij74Fv 6jjVILntEqYxNxsThyx46Ywy74ifixysmCo8pKF2btjdj17LWcyLDwKZa+7mdrnizKJE QCGQ== Received: by 10.216.205.35 with SMTP id i35mr1092063weo.17.1335183531138; Mon, 23 Apr 2012 05:18:51 -0700 (PDT) Received: from [10.147.56.203] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ff9sm22316938wib.2.2012.04.23.05.18.49 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 05:18:50 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 23 Apr 2012 13:19:02 +0100 Subject: Re: IPR Statements concerning etree From: Giles Heron To: , "l2vpn@ietf.org" , "l2vpn-chairs@tools.ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Message-ID: Thread-Topic: IPR Statements concerning etree Thread-Index: Ac0hS0SNJywDFTgpykaGT5z1KiKZOA== In-Reply-To: <4F9174A3.6000102@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-BeenThere: l2vpn@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, 23 Apr 2012 12:18:54 -0000 Since we're having this discussion now, please could anyone with any other IPR related to E-Tree notify the IETF Secretariat, so that we can have this discussion once and once only? Giles On 20/04/2012 15:37, "Stewart Bryant" wrote: > > WGs, > > You may wish to look at the following IPR statements that were > received yesterday. > > They all relate to etree. > > The stated terms appear to require payment of a royalty. > > Stewart > > > -------- Original Message -------- > Subject: IPR Statements > Date: Thu, 19 Apr 2012 13:04:27 -0400 > From: Russ Housley > To: Stewart Bryant > > > > Begin forwarded message: > >> From: IETF Secretariat >> Date: April 19, 2012 12:14:30 PM EDT >> To: simon.delord@gmail.com, raymond.key@ieee.org, >> wim.henderickx@alcatel-lucent.com, lucy.yong@huawei.com, >> lizhong.jin@zte.com.cn, frederic.jounay@orange.ch >> Cc: housley@vigilsec.com, ipr-announce@ietf.org >> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related >> to draft-delord-pwe3-cw-bit-etree-07 >> >> >> Dear Simon DeLord, Raymond Key, Wim Henderickx, Lucy Yong, Lizhong Jin, >> Frederic JOUNAY: >> >> An IPR disclosure that pertains to your Internet-Draft entitled "Control >> Word >> Reserved bit for use in E-Tree" (draft-delord-pwe3-cw-bit-etree) was >> submitted >> to the IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page >> of >> Intellectual Property Rights Disclosures" >> (https://datatracker.ietf.org/ipr/1760/). The title of the IPR disclosure is >> "Orckit-Corrigent Ltd's Statement about IPR related to >> draft-delord-pwe3-cw-bit-etree-07.""); >> >> The IETF Secretariat >> > Begin forwarded message: > >> From: IETF Secretariat >> Date: April 19, 2012 12:15:08 PM EDT >> To: yuqun.cao@gmail.com >> Cc: housley@vigilsec.com, ipr-announce@ietf.org >> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related >> to draft-cao-l2vpn-vpls-etree-02 >> >> >> Dear Yuqun Cao: >> >> An IPR disclosure that pertains to your Internet-Draft entitled "Extension >> to >> VPLS for E-Tree" (draft-cao-l2vpn-vpls-etree) was submitted to the IETF >> Secretariat on 2012-04-19 and has been posted on the "IETF Page of >> Intellectual >> Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1759/). The >> title >> of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related >> to >> draft-cao-l2vpn-vpls-etree-02."); >> >> The IETF Secretariat >> > Begin forwarded message: > >> From: IETF Secretariat >> Date: April 19, 2012 12:15:34 PM EDT >> To: chen.ran@zte.com.cn >> Cc: housley@vigilsec.com, ipr-announce@ietf.org >> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related >> to draft-chen-l2vpn-vpls-etree-vlan-01 >> >> >> Dear Ran Chen: >> >> An IPR disclosure that pertains to your Internet-Draft entitled "Automatic >> VLAN >> allocation in E-tree" (draft-chen-l2vpn-vpls-etree-vlan) was submitted to >> the >> IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of >> Intellectual Property Rights Disclosures" >> (https://datatracker.ietf.org/ipr/1758/). The title of the IPR disclosure is >> "Orckit-Corrigent Ltd's Statement about IPR related to >> draft-chen-l2vpn-vpls-etree-vlan-01."); >> >> The IETF Secretariat >> > Begin forwarded message: > >> From: IETF Secretariat >> Date: April 19, 2012 12:16:29 PM EDT >> To: jiangyuanlong@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.de, >> frederic.jounay@orange.ch, florin.balus@alcatel-lucent.com, >> wim.henderickx@alcatel-lucent.com, sajassi@cisco.com >> Cc: housley@vigilsec.com, ipr-announce@ietf.org >> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related >> to draft-jiang-l2vpn-etree-bgp-00 >> >> >> Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Balus, >> Wim Henderickx, Ali Sajassi: >> >> An IPR disclosure that pertains to your Internet-Draft entitled "E-Tree >> Support >> in VPLS with BGP Signaling" (draft-jiang-l2vpn-etree-bgp) was submitted to >> the >> IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of >> Intellectual Property Rights Disclosures" >> (https://datatracker.ietf.org/ipr/1757/). The title of the IPR disclosure is >> "Orckit-Corrigent Ltd's Statement about IPR related to >> draft-jiang-l2vpn-etree-bgp-00."); >> >> The IETF Secretariat >> > Begin forwarded message: > >> From: IETF Secretariat >> Date: April 19, 2012 12:17:02 PM EDT >> To: yljiang@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.de, >> frederic.jounay@orange-ftgroup.com, florin.balus@alcatel-lucent.com, >> wim.henderickx@alcatel-lucent.com >> Cc: housley@vigilsec.com, ipr-announce@ietf.org >> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related >> to draft-jiang-l2vpn-vpls-pe-etree-05 >> >> >> Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Balus, >> Wim Henderickx: >> >> An IPR disclosure that pertains to your Internet-Draft entitled "VPLS PE >> Model >> for E-Tree Support" (draft-jiang-l2vpn-vpls-pe-etree) was submitted to the >> IETF >> Secretariat on 2012-04-19 and has been posted on the "IETF Page of >> Intellectual >> Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1756/). The >> title >> of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related >> to >> draft-jiang-l2vpn-vpls-pe-etree-05.""); >> >> The IETF Secretariat >> > Begin forwarded message: > >> From: IETF Secretariat >> Date: April 19, 2012 12:17:48 PM EDT >> To: danielc@orckit.com, rafir@orckit.com, pagarwal@broadcom.com, >> raymond.key@team.telstra.com >> Cc: housley@vigilsec.com, ipr-announce@ietf.org >> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related >> to draft-ram-l2vpn-ldp-vpls-etree-2pw-02 >> >> >> Dear Daniel Cohn, Rafi Ram, Puneet Agarwal, Raymond Key: >> >> An IPR disclosure that pertains to your Internet-Draft entitled "Extension >> to >> LDP-VPLS for E-Tree Using Two PW" (draft-ram-l2vpn-ldp-vpls-etree-2pw) was >> submitted to the IETF Secretariat on 2012-04-19 and has been posted on the >> "IETF Page of Intellectual Property Rights Disclosures" >> (https://datatracker.ietf.org/ipr/1755/). The title of the IPR disclosure is >> "Orckit-Corrigent Ltd's Statement about IPR related to >> draft-ram-l2vpn-ldp-vpls- >> etree-2pw-02.""); >> >> The IETF Secretariat >> > Begin forwarded message: > >> From: IETF Secretariat >> Date: April 19, 2012 12:18:32 PM EDT >> To: rafir@orckit.com, danielc@orckit.com, raymond.key@ieee.org, >> pagarwal@broadcom.com, josh.rogers@twcable.com >> Cc: housley@vigilsec.com, ipr-announce@ietf.org >> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related >> to draft-ram-l2vpn-etree-multiple-pw-01 >> >> >> Dear Rafi Ram, Daniel Cohn, Raymond Key, Puneet Agarwal, Joshua Rogers: >> >> An IPR disclosure that pertains to your Internet-Draft entitled "Extension >> to >> VPLS for E-Tree Using Multiple PWs" (draft-ram-l2vpn-etree-multiple-pw) was >> submitted to the IETF Secretariat on 2012-04-19 and has been posted on the >> "IETF >> Page of Intellectual Property Rights Disclosures" >> (https://datatracker.ietf.org/ipr/1754/). The title of the IPR disclosure is >> "Orckit-Corrigent Ltd's Statement about IPR related to >> draft-ram-l2vpn-etree- >> multiple-pw-01.""); >> >> The IETF Secretariat >> > > > From jiangyuanlong@huawei.com Mon Apr 23 05:25:43 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB71821F85B6 for ; Mon, 23 Apr 2012 05:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599] 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 8CsfcRjoQu56 for ; Mon, 23 Apr 2012 05:25:43 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id CC2E521F8597 for ; Mon, 23 Apr 2012 05:25:42 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFD45330; Mon, 23 Apr 2012 08:25:42 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Apr 2012 05:23:45 -0700 Received: from SZXEML438-HUB.china.huawei.com (10.72.61.73) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Apr 2012 05:23:44 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.137]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Mon, 23 Apr 2012 20:23:28 +0800 From: Jiangyuanlong To: Alexander Vainshtein , Sam Cao Subject: RE: Discussion on E-Tree and H-VPLS Thread-Topic: Discussion on E-Tree and H-VPLS Thread-Index: AQHNIUN67h0xDILTIEWgVSrvExKN65anwSmAgACGqvCAAAqFkA== Date: Mon, 23 Apr 2012 12:23:38 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EB46@SZXEML508-MBS.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E891@SZXEML508-MBS.china.huawei.com> <5C3578E316494634B1DCAC06C15E2C21@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EAE6@SZXEML508-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AagI HKk1 Hu/Q KUKN MRQU M7Mb OCZN OaTL RKMR UExs V1h3 XXVL Ztqm adKJ bbmF bpsu; 3; YQBsAGUAeABhAG4AZABlAHIALgB2AGEAaQBuAHMAaAB0AGUAaQBuAEAAZQBjAGkAdABlAGwAZQAuAGMAbwBtADsAbAAyAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAeQB1AHEAdQBuAC4AYwBhAG8AQABnAG0AYQBpAGwALgBjAG8AbQA=; Sosha1_v1; 7; {ED95DBE0-E48C-46A7-86DA-CD442D5E6C14}; agBpAGEAbgBnAHkAdQBhAG4AbABvAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Mon, 23 Apr 2012 12:23:34 GMT; UgBFADoAIABEAGkAcwBjAHUAcwBzAGkAbwBuACAAbwBuACAARQAtAFQAcgBlAGUAIABhAG4AZAAgAEgALQBWAFAATABTAA== x-cr-puzzleid: {ED95DBE0-E48C-46A7-86DA-CD442D5E6C14} x-originating-ip: [10.70.40.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 23 Apr 2012 12:25:43 -0000 Sasha, Sorry, but I don't think the CW-based solution can preserve the CW in such = a way. In PE-rs, the PW should be terminated and the Ethernet frame needs t= o be forwarded with dst MAC lookup. Therefore, we need some tricky bits in = the switch fabric in order to carry the CW information intact across the Et= hernet forwarding plane.=20 Thanks Yuanlong -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Monday, April 23, 2012 7:33 PM To: Jiangyuanlong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS=20 Sam, Yuanlong and all, >From my point of view the CW-based solution is by far the simplest way to d= eal with H-VPLS: all that is required is preservation of the CW (or, in the= unlikely case PW sequencing is used, of its flags) when a packet is forwar= ded from the "core" PW to a "spoke" one (or vice versa). With Dual PWE the situation becomes more complicated IMO. Not sure about du= al VLAN - but may be also tricky. Regards, Sasha > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Jiangyuanlong > Sent: Monday, April 23, 2012 2:23 PM > To: Sam Cao > Cc: l2vpn@ietf.org > Subject: Discussion on E-Tree and H-VPLS >=20 > Sam, >=20 > Please see my comments in line. I also change the title to reflect the to= pic. >=20 > Regards > Yuanlong >=20 > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Monday, April 23, 2012 11:28 AM > To: Jiangyuanlong > Cc: l2vpn@ietf.org > Subject: RE: L2vpn Digest, Vol 95, Issue 58 >=20 > Yuanlong, >=20 > I do apologize for my unclear description. I try to make it clear. >=20 > VPWS or Spoke PW, PE-rs will take the PW as Spoke PW. Or say, PE-rs reall= y > does NOT care remote access is VPWS access (point-to-point, Fig. 3) or VP= LS > spoke access (Fig. 4). PE-rs just know it is spoke PW and it is ENOUGH, a= nd > does NOT care customer payload. is this correct? At least it is correct = in > RFC 4762. > [JY] why divide the remote access to VPWS access and VPLS access? >=20 > But, if remote is VPWS access (Fig. 3), PE-rs SHOULD configure AC-type fo= r > remote VPWS access although it is still spoke PW in E-Tree. Please refer = to > your answer to Josh's question. It seems reasonable. Ok, we think another > case in Fig. 4. In Fig. 4, PE-rs CAN NOT configure AC-type at all in this > case. In fact, on MTU-s it is VPLS and we should configure AC type on MTU= -s. > [JY] Quite opposite, in case of Fig.4, IMHO, it is better to configure th= e E- > Tree attribute on the PE-rs since the PE-r does not support any bridging > functions. I think this case is provided in RFC4762 just to be compatible= with > some legacy routers. >=20 >=20 > Ok, problem came up for me. For spoke PW on PE-rs, in one case it should > configure AC type and work as agent; in another case, it can NOT configur= e > AC type and can not work as agent. In fact, PE-rs knows it is spoke PW, i= t > is enough; why spoke-PW has different configuration in same VPLS instance > on > same PE? I am confused although I know why we should configure in that > way. >=20 > I prefer not to configure AC type on PE-rs since we can take it as > "Switching PE" (NOT pefact here and it is not real "Switching Point") whi= ch > does NOT aware customer payload. Extension to VPWS? Seems not > reasonable. > [JY] Not sure I got your points. PE-rs will terminate the PW and switch t= he > Ethernet frames. IMO, whether configuring the E-Tree service on a PE-rs o= r a > MTU-s is dependent on the topology of the service and how they are > attached. H-VPLS can be seen as a transparent transport network, or as a > service itself. >=20 > Thanks, >=20 > Sam >=20 > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, April 23, 2012 9:59 AM > To: Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: L2vpn Digest, Vol 95, Issue 58 >=20 > Hi Sam, >=20 > If E-Tree service is provided in a scenario as Fig. 3 and Fig 4 in RFC 47= 62, > then a CE (leaf or root) is connected to the MTU-s or PE-r, thus the AC > should be terminated and the E-Tree service should be encapsulated by the > MTU-s or PE-r. I don't quite understand why you need to "take VPWS PW as > one > AC", but even in that case, the attribute of the AC may be configured at = the > PE-rs. So what is the problem for H-VPLS? >=20 > Thanks > Yuanlong >=20 > Date: Sun, 22 Apr 2012 22:03:52 +0800 > From: "Sam Cao" > To: "'Jiangyuanlong'" > Cc: l2vpn@ietf.org > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: <962A848896EF4678B17D76C826A7EAEF@v2comsam> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Yuanlong, >=20 > I just collect all issues we discussed before, and we still can not make > agreement. I gave my comments on 2 items below. I will think other items > over and give my comments tomorrow. >=20 > 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, > PE-rs works in different manner, PE-rs should figure out AC type in VPWS > case, but can NOT configure it at all in Spoke PW case; > [JY] In the first place, why PE-rs need to figure out the AC type for a > spoke? The VLAN should be processed in the MTU, not in the PE-rs. > [Sam] Yuanlong, I understand your idea. It does NOT make sense for me. > First, Fig. 3 and Fig 4 in RFC 4762 are different cases. For VPWS (Fig. 3= ), > we can take VPWS PW as one AC. You know, PE-rs is termination of VPWS, > so it > will add VLAN-ID to identify Root/Leaf. BTW, you will map several VLAN ID= s > into one Root-VLAN ID or Leaf-VLAN ID on PE-rs, so we need to configure > Root/Leaf on PE-rs (Refer to your reply to Josh's comments). >=20 > 4) Encapsulation mode: If deploy HVPLS with Spoke PW mode, PE-rs > should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VL= AN > ID; > [JY] Is anything not working with tagged PW mode? > [Sam] Tagged mode works. >=20 > Regards, >=20 > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com >=20 This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. From Alexander.Vainshtein@ecitele.com Mon Apr 23 06:44:37 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56BF21F864B for ; Mon, 23 Apr 2012 06:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, 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 xRMxzmHcDbK4 for ; Mon, 23 Apr 2012 06:44:37 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.98]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD9E21F8636 for ; Mon, 23 Apr 2012 06:44:36 -0700 (PDT) Received: from [193.109.254.147:21968] by server-12.bemta-14.messagelabs.com id D5/0E-05898-3CC559F4; Mon, 23 Apr 2012 13:44:35 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1335188673!3425191!2 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.7; banners=-,-,- Received: (qmail 15714 invoked from network); 23 Apr 2012 13:44:35 -0000 Received: from unknown (HELO fridlppsb001.ecitele.com) (168.87.1.157) by server-7.tower-27.messagelabs.com with SMTP; 23 Apr 2012 13:44:35 -0000 X-AuditID: a8571401-b7f186d000005261-23-4f955d17b9f6 Received: from FRGRWPVCH001.ecitele.com (frgrwpvch001.ecitele.com [10.1.18.35]) by fridlppsb001.ecitele.com (Symantec Messaging Gateway) with SMTP id 54.C9.21089.71D559F4; Mon, 23 Apr 2012 15:46:00 +0200 (CEST) Received: from FRIDWPPMB002.ecitele.com ([169.254.4.167]) by FRGRWPVCH001.ecitele.com ([10.1.18.35]) with mapi id 14.01.0339.001; Mon, 23 Apr 2012 15:44:34 +0200 From: Alexander Vainshtein To: Jiangyuanlong , Sam Cao Subject: RE: Discussion on E-Tree and H-VPLS Thread-Topic: Discussion on E-Tree and H-VPLS Thread-Index: AQHNIU369Lbm7egqqU6Fib9ksarNBJaoaRcw Date: Mon, 23 Apr 2012 13:44:33 +0000 Message-ID: References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E891@SZXEML508-MBS.china.huawei.com> <5C3578E316494634B1DCAC06C15E2C21@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EAE6@SZXEML508-MBS.china.huawei.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EB46@SZXEML508-MBS.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EB46@SZXEML508-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTfWwLYRz29q636+zkVqOvDrkc84fp1vmsWBeCmIjUVxAfsVv77nq016Z3 PkbEbIuxkCCb0BkjJdvMxpIJsy3ZEFTEWCUiIWEIFiwEmT/w3m5m4v64PO/veZ7f87u739GE +RNlpSVZRSFZ8PFUPBkPhlltcGO5y151kHQ87i2hHN3fOuIclUX3qblE9rXws7js4psfjNmR SJ9hGbGuAGQKshxQBRVxHqS4nfyykLRNcOfznORx8hk8F/QJbuRHsurkhWAQyR4+K57778rE MknmkOwOeCRZdPKLV7psDseM2bYMPmuVV1I4ZPMLko/zI0URRMThija37MmpJ7w3WsqIYNS5 40j3QaoAxNJLgYmG7HT4pu2AQcejYefzBqoUxNNmNgZgz/H2gcM5AE/WtxOaimKdsPHCM0rD SewS2Py2sN9NsCmwuLENaHgkOwUWtT4y6BobjFVfwnUa46nwRdlarUxi+ame7/0tGXYprK76 ZdSzDhHw49vLpEaY2NWw62RNvwjg6b5H6wayLPDpq9MDU7Mw0vKA0PEo+K77p1HH42FhTSxO 10+BVdc/UzpOhefP9AwEJ8K7J16Run4MbK9+Qh4GlvCQiPAQe3iIPTzEXgXIWmDJC0meYFDJ tdsz0pBbUpEPpbkD/kaAF6Z6TRK4Cl4eSusALA34BKZPLnOZjcI2Jd/fAcbQBn4U41xf7jKP yA148r2C4t0U2upDSgeANMEnMRfnYI7xCPk7USjwh3Lgl3iEsA53B7RPrG6aZrf/c+AtTMOK LJeZFfHebUEoiEJ/rGNpmodMm5aYGEIi2pEn+dS/tIE2ackJOHmCpmGUoOBXJFHnoyCV/nXl bgzQfZ34biblgIysOEyTsprUu1Ue7PYeWPATj2QuamwC3sbBPu9xhAFH5Gw4qkXgv2OQshaA mc1l6YTqv7cofc/waMl2S5pMRCuzP45QRUOgt6lV3tfQax03b2HupJ7X4r2mOq58QWdX/d7E 04m3d+a8/tK6e+2PR3feHSvaPHFW3ripL5vntFwmXdcsyWLF7HCXqaSCs6TU9vlc3i9nTZv3 R6LLS43crs+nxEnJD29FrPMrG77ypOIVMiYTIUX4DQehepICBAAA Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 23 Apr 2012 13:44:38 -0000 Yuanlong, Lots of thanks for a prompt response. I think that actual complexity of preserving the flags in the CW when forwar= ding from a core PW to a spoke one (or vice versa) strongly depends on your= implementation. E.g., in Chassis-based PEs it is quite customary for the in= gress blade to prepend some internal header to the packet(s) it sends across= the Fabric to the egress blade. In this case you need at most to find one u= nused bit in this header (usually not a big deal), and you can also possibly= do without. Of course this implementing this behavior in some tailored HW could be highl= y problematic - but IMHO so would be any approach that has not been taken in= to account by the vendor of the specific chip. Regards, Sasha > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, April 23, 2012 3:24 PM > To: Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Sasha, > > Sorry, but I don't think the CW-based solution can preserve the CW in such= a > way. In PE-rs, the PW should be terminated and the Ethernet frame needs > to be forwarded with dst MAC lookup. Therefore, we need some tricky bits > in the switch fabric in order to carry the CW information intact across th= e > Ethernet forwarding plane. > > Thanks > Yuanlong > > > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Monday, April 23, 2012 7:33 PM > To: Jiangyuanlong; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, Yuanlong and all, > From my point of view the CW-based solution is by far the simplest way to > deal with H-VPLS: all that is required is preservation of the CW (or, in t= he > unlikely case PW sequencing is used, of its flags) when a packet is > forwarded from the "core" PW to a "spoke" one (or vice versa). > > With Dual PWE the situation becomes more complicated IMO. Not sure > about dual VLAN - but may be also tricky. > > Regards, > Sasha > > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > > Of Jiangyuanlong > > Sent: Monday, April 23, 2012 2:23 PM > > To: Sam Cao > > Cc: l2vpn@ietf.org > > Subject: Discussion on E-Tree and H-VPLS > > > > Sam, > > > > Please see my comments in line. I also change the title to reflect the t= opic. > > > > Regards > > Yuanlong > > > > -----Original Message----- > > From: Sam Cao [mailto:yuqun.cao@gmail.com] > > Sent: Monday, April 23, 2012 11:28 AM > > To: Jiangyuanlong > > Cc: l2vpn@ietf.org > > Subject: RE: L2vpn Digest, Vol 95, Issue 58 > > > > Yuanlong, > > > > I do apologize for my unclear description. I try to make it clear. > > > > VPWS or Spoke PW, PE-rs will take the PW as Spoke PW. Or say, PE-rs > really > > does NOT care remote access is VPWS access (point-to-point, Fig. 3) or > VPLS > > spoke access (Fig. 4). PE-rs just know it is spoke PW and it is ENOUGH,= and > > does NOT care customer payload. is this correct? At least it is correct= in > > RFC 4762. > > [JY] why divide the remote access to VPWS access and VPLS access? > > > > But, if remote is VPWS access (Fig. 3), PE-rs SHOULD configure AC-type f= or > > remote VPWS access although it is still spoke PW in E-Tree. Please refer= to > > your answer to Josh's question. It seems reasonable. Ok, we think anothe= r > > case in Fig. 4. In Fig. 4, PE-rs CAN NOT configure AC-type at all in thi= s > > case. In fact, on MTU-s it is VPLS and we should configure AC type on MT= U- > s. > > [JY] Quite opposite, in case of Fig.4, IMHO, it is better to configure t= he E- > > Tree attribute on the PE-rs since the PE-r does not support any bridging > > functions. I think this case is provided in RFC4762 just to be compatibl= e > with > > some legacy routers. > > > > > > Ok, problem came up for me. For spoke PW on PE-rs, in one case it should > > configure AC type and work as agent; in another case, it can NOT configu= re > > AC type and can not work as agent. In fact, PE-rs knows it is spoke PW,= it > > is enough; why spoke-PW has different configuration in same VPLS > instance > > on > > same PE? I am confused although I know why we should configure in that > > way. > > > > I prefer not to configure AC type on PE-rs since we can take it as > > "Switching PE" (NOT pefact here and it is not real "Switching Point") wh= ich > > does NOT aware customer payload. Extension to VPWS? Seems not > > reasonable. > > [JY] Not sure I got your points. PE-rs will terminate the PW and switch= the > > Ethernet frames. IMO, whether configuring the E-Tree service on a PE-rs= or > a > > MTU-s is dependent on the topology of the service and how they are > > attached. H-VPLS can be seen as a transparent transport network, or as a > > service itself. > > > > Thanks, > > > > Sam > > > > -----Original Message----- > > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > > Sent: Monday, April 23, 2012 9:59 AM > > To: Sam Cao > > Cc: l2vpn@ietf.org > > Subject: RE: L2vpn Digest, Vol 95, Issue 58 > > > > Hi Sam, > > > > If E-Tree service is provided in a scenario as Fig. 3 and Fig 4 in RFC 4= 762, > > then a CE (leaf or root) is connected to the MTU-s or PE-r, thus the AC > > should be terminated and the E-Tree service should be encapsulated by > the > > MTU-s or PE-r. I don't quite understand why you need to "take VPWS PW > as > > one > > AC", but even in that case, the attribute of the AC may be configured at > the > > PE-rs. So what is the problem for H-VPLS? > > > > Thanks > > Yuanlong > > > > Date: Sun, 22 Apr 2012 22:03:52 +0800 > > From: "Sam Cao" > > To: "'Jiangyuanlong'" > > Cc: l2vpn@ietf.org > > Subject: RE: The status of the approaches to the E-Tree solution? > > Message-ID: <962A848896EF4678B17D76C826A7EAEF@v2comsam> > > Content-Type: text/plain; charset=3D"us-ascii" > > > > Yuanlong, > > > > I just collect all issues we discussed before, and we still can not make > > agreement. I gave my comments on 2 items below. I will think other items > > over and give my comments tomorrow. > > > > 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, > > PE-rs works in different manner, PE-rs should figure out AC type in VPWS > > case, but can NOT configure it at all in Spoke PW case; > > [JY] In the first place, why PE-rs need to figure out the AC type for a > > spoke? The VLAN should be processed in the MTU, not in the PE-rs. > > [Sam] Yuanlong, I understand your idea. It does NOT make sense for me. > > First, Fig. 3 and Fig 4 in RFC 4762 are different cases. For VPWS (Fig.= 3), > > we can take VPWS PW as one AC. You know, PE-rs is termination of VPWS, > > so it > > will add VLAN-ID to identify Root/Leaf. BTW, you will map several VLAN > IDs > > into one Root-VLAN ID or Leaf-VLAN ID on PE-rs, so we need to configure > > Root/Leaf on PE-rs (Refer to your reply to Josh's comments). > > > > 4) Encapsulation mode: If deploy HVPLS with Spoke PW mode, PE-rs > > should work in tagged mode, otherwise PE-rs or egress PE will stripe S- > VLAN > > ID; > > [JY] Is anything not working with tagged PW mode? > > [Sam] Tagged mode works. > > > > Regards, > > > > Yuqun (Sam) Cao > > E-mail: Yuqun.cao@gmail.com > > > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us= by > e-mail, phone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From ju1738@att.com Mon Apr 23 06:56:31 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9333621F85E1 for ; Mon, 23 Apr 2012 06:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.148 X-Spam-Level: X-Spam-Status: No, score=-106.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4, 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 mHHRZMCFP50Y for ; Mon, 23 Apr 2012 06:56:28 -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 1BB5B21F85D9 for ; Mon, 23 Apr 2012 06:56:28 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-8) with ESMTP id c8f559f4.2aaaf7451940.252659.00-573.678326.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 23 Apr 2012 13:56:28 +0000 (UTC) X-MXL-Hash: 4f955f8c46c40948-db35ce287dbc20e8760f25f25aec8382ffb38606 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 08f559f4.0.252568.00-425.678060.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 23 Apr 2012 13:56:18 +0000 (UTC) X-MXL-Hash: 4f955f820ca2d163-979ae6e2c00da5db3aad1f767817dc359dfe4aef Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3NDuGEi019640; Mon, 23 Apr 2012 09:56:16 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3NDu841019470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2012 09:56:10 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by sflint01.pst.cso.att.com (RSA Interceptor); Mon, 23 Apr 2012 09:55:52 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.36]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.01.0355.002; Mon, 23 Apr 2012 09:55:52 -0400 From: "UTTARO, JAMES" To: "'Sam Cao'" , "'Alexander Vainshtein'" Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNHxPnxbisvEh3kk6CwsWQjlzY35akOniAgACwqQCAALY7AIAAC0AAgAFzRgCAAARQAIAAB2IAgAAJkwCAAEmWAIAARubAgACsKxA= Date: Mon, 23 Apr 2012 13:55:51 +0000 Message-ID: References: , <14C7F4F06DB5814AB0DE29716C4F6D6701296244C3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>, , <1B88357C808B432E871CA9D678305B7C@v2comsam><6F9ADEDA06A04AB98C247D303AFE93BE@v2comsam> <13822856E9C84A49BBF95D1867C5FF11@R01842> In-Reply-To: <13822856E9C84A49BBF95D1867C5FF11@R01842> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.92.45] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FACAFF4MISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=30wz3fGWir8A:10 a=lhC5ufdvBjcA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=pG] X-AnalysisOut: [LkceISAAAA:8 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=IRDgFnn-A] X-AnalysisOut: [AAA:8 a=69EAbJreAAAA:8 a=gxZvrgisAAAA:8 a=ahv8dbORAAAA:8 a] X-AnalysisOut: [=i0EeH86SAAAA:8 a=2obxBgYoAAAA:8 a=xHM_HSuLhglFTCIvnBIA:9 ] X-AnalysisOut: [a=40VIVs59CwLtwL-pF68A:7 a=QEXdDO2ut3YA:10 a=esyrR_pz34kA:] X-AnalysisOut: [10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10 a] X-AnalysisOut: [=1QW4SJF8ptEA:10 a=EfJqPEOeqlMA:10 a=3FZX-ydVlcEA:10 a=wvc] X-AnalysisOut: [rEAeYV2wN9GaT:21 a=xNjrTgm1juMKOWCj:21 a=SSmOFEACAAAA:8 a=] X-AnalysisOut: [Y2VNeNrzAAAA:8 a=yMhMjlubAAAA:8 a=TW66zc2HAAAA:8 a=HQ31llb] X-AnalysisOut: [KAAAA:8 a=1xRhqUzEFq7U7yVm0dUA:9 a=zoW_sKwmw7RAKCxFgJIA:7 ] X-AnalysisOut: [a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=fb] X-AnalysisOut: [PoKYFiiF8ivSR5:21 a=PoVGDt1k7y4pCBB4:21] X-Mailman-Approved-At: Mon, 23 Apr 2012 06:59:49 -0700 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 23 Apr 2012 13:56:31 -0000 --_000_B17A6910EEDD1F45980687268941550FACAFF4MISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2FtLA0KDQogICAgICAgICAgICAgICAgQ29tbWVudHMgSW4tTGluZS4uDQoNClRoYW5rcywNCiAg ICAgICAgICAgICAgICBKaW0gVXR0YXJvDQoNCkZyb206IFNhbSBDYW8gW21haWx0bzp5dXF1bi5j YW9AZ21haWwuY29tXQ0KU2VudDogTW9uZGF5LCBBcHJpbCAyMywgMjAxMiAxMjowNiBBTQ0KVG86 IFVUVEFSTywgSkFNRVM7ICdBbGV4YW5kZXIgVmFpbnNodGVpbicNCkNjOiBsMnZwbkBpZXRmLm9y Zw0KU3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJl ZSBzb2x1dGlvbj8NCg0KSGkgSmltLA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIGNv bW1lbnRzLiBCdXQgd2hhdCB3ZSBkaWQgaXMgYSBsaXR0bGUgZGlmZmVyZW50IGZyb20geW91cnMu DQoNCk11bHRpLVBXIGNhcnJpZXMgQUMgdHlwZSBpbiDigJxMYXllcjIgSW5mbyBFeHRlbmRlZCBD b21tdW5pdHnigJ0sIE5PVCBkaWZmZXJlbnQgUlQsIGFuZCBjb250cm9sIHBsYW5lIHdpbGwgdHJh bnNsYXRlIGl0LCBidXQgd2UgZG9u4oCZdCBzZXBhcmF0ZSBpdCBpbnRvIDIgVlJGcyAoVlNJIGlu IHRoZSBkcmFmdCkuIFRoZXkgYmVsb25nIHRvIG9uZSBWU0kuDQoNCkkgZ3Vlc3MgeW91ciBFLVRy ZWUgZGVwbG95bWVudCB2aWEgQkdQLUFEIGlzLCBhc3NpZ24gb25lIFJvb3QtUlQgKHNhbWUgaW4g YWxsIFZQTEEtUEUgaW4gVlBMUyBkb21haW4pLCBhbmQgYXNzaWduIGRpZmZlcmVudCBMZWFmIFJU IGZvciBlYWNoIExlYWYtb25seSBQRSwgdGhlbiB3ZSB3aWxsIG5vdCBzZXR1cCBQVyBiZXR3ZWVu IExlYWYtb25seSBQRXMsIHRoZW4gd2UgY2FuIGJyZWFrIHRoZSBjb21tdW5pY2F0aW9uIGJldHdl ZW4gTGVhZi1Pbmx5IFBFcy4gSXMgbXkgdW5kZXJzdGFuZGluZyBjb3JyZWN0IG9yIG5vdD8gVGhp cyBpcyBIdWItU3Bva2UgZGVwbG95bWVudCwgYW5kIGN1cnJlbnQgc29sdXRpb24gY2FuIHN1cHBv cnQgdGhpcy4gQnV0IGl0IGNhbiBub3QgY292ZXIgYWxsIGNhc2VzLiBbSmltIFU+XSBUaGF0IGlz IHRoZSBhcHByb2FjaCBidXQgYXMgeW91IG5vdGUgaXQgZG9lcyBub3QgY292ZXIgYWxsIGNhc2Vz Li4NCg0KSSBhZ3JlZSB3aXRoIHNvbWUgcmVxdWlyZW1lbnRzIG9uIEUtVHJlZSBpbiB5b3VyIG1h aWwuDQoNCi0gICAgICAgUGFydGlhbCBtZXNoIHRvcG9sb2dpZXMuDQpbU2FtXSBBZ3JlZS4gTm93 IENXLCBEdWFsLVZMQU4gb3IgRHVhbC1QVyBjb25zaWRlciB0aGlzIGluIGRyYWZ0LCBidXQgZm9y IG1lLCBDVyBvciBEdWFsLVZMQU4gd2lsbCBkZXBsb3kgcGFydGlhbCBtZXNoIGluIHlvdXIgd2F5 IG9yIGNvbmZpZ3VyZSBpdCBtYW51YWxseTsgRHVhbC1QVyBjYW4gc3VwcG9ydCB0aGlzIHZpYSBz aWduYWxpbmcuDQotICAgICAgIFNhbWUgUEUgbXVzaCBiZSBhYmxlIHRvIGhvc3QgUm9vdCBhbmQg TGVhZiBTaXRlcy4NCltTYW1dIEFncmVlLiBUaGlzIGlzIFJvb3QtTGVhZi1NaXhlZCBjYXNlIGlu IGFsbCBFLXRyZWUgZHJhZnQ7IEFsbCBkcmFmdHMgc2hvdWxkIHN1cHBvcnQgdGhpcy4NCi0gICAg ICAgRGlzYWxsb3dpbmcgb2YgTGVhZiB0byBMZWFmIHRyYWZmaWMgb24gdGhlIHNhbWUgUEUgbXVz dCBiZSBkb25lIHVzaW5nIFBXIHNlbWFudGljcy4NCltTYW1dIEppbSwgY2FuIG5vdCBmdWxseSB1 bmRlcnN0YW5kIHRoaXMgY2FzZS4gSWYgb24gc2FtZSBQRSwgdGhpcyBpcyBsb2NhbCBiZWhhdmlv ciwgaXMgaXQgY29ycmVjdD8gRG8geW91IG1lYW4gd2UgbmVlZCB0byBzZXR1cCBvbmUgZHVtbXkg UFcgb24gYW55IFBFIGlmIGl0IGhvc3RzIFJvb3QgYW5kIExlYWYgc2l0ZXM/IFNoYWxsIHdlIGRl c2NyaWJlIGluIGRyYWZ0Pw0KW0ppbSBVPl0gSWYgdHdvIFZSRnMgb25lIExlYWYgYW5kIG9uZSBS b290IG9uIGEgY29tbW9uIFBFIHRyYWZmaWMgd2hlbiBzZW50IGZyb20gdGhlIExlYWYgdG8gdGhl IFJvb3QgY29udGV4dCBtdXN0IG5vdCBiZSB0cmVhdGVkIGFzIG5hdGl2ZSBldGhlcm5ldCB0cmFm ZmljIGFzIGl0IHdvdWxkIHRoZW4g4oCcYXBwZWFy4oCdIHRoZSBzYW1lIGFzIHRyYWZmaWMgYXJy aXZpbmcgZnJvbSBleHRlcm5hbCBldGhlcm5ldCBpbnRlcmZhY2VzLi4gSW4gdGhpcyByZWdhcmQg eW91IGxvc2UgdGhlIG5vdGlvbiB0aGF0IGEgbGVhZiBzZW1hbnRpYyBpcyBhc3NvY2lhdGVkIHdp dGggdGhhdCB0cmFmZmljLi4NCi0gICAgICAgV2hlbiBSb290IGFuZCBMZWFmIHNpdGVzIGFyZSBk ZXBsb3llZCBvbiB0aGUgc2FtZSBQRSB0aGUgcGFja2V0cyBiZXR3ZWVuIHRoZW0gc2hvdWxkIG9i ZXkgdGhlIHNhbWUgc2VtYW50aWNzIGFzIGlmIHRoZXkgaGFkIHRyYXZlcnNlZCBhIFBXIGkuZSAo IFNwbGl0IEhvcml6b24sIE5vIExhYmVsIFJlLUltcG9zaXRpb24gZXRj4oCmICkuDQpbU2FtXSBT YW1lIHF1ZXN0aW9uIGFzIGFib3ZlLiBBbnl3YXksIOKAnFNwbGl0IEhvcml6b27igJ0gaXMgYmFz aWMgcnVsZSBmb3IgYWxsIGRyYWZ0cy4NCltKaW0gVT5dIFNlZSBhYm92ZS4uIFNvcnQgb2YgdGhl IHNhbWUgcmVxdWlyZW1lbnQgYXMgc3RhdGVkIGFib3ZlLi4gSSBiZWxpZXZlIHRoYXQgdGhlIGxv Y2FsIGJlaGF2aW9yIGludHJhLVBFIGJldHdlZW4gYSBMZWFmIGFuZCBhIFJvb3Qgc2hvdWxkIG1p bWljIHRoZSBiZWhhdmlvciBhcyBpZiB0aGUgdHJhZmZpYyBhcnJpdmVkIGZyb20gYSBkaWZmZXJl bnQgUEU+Li4NCi0gICAgICAgSWYgUEUgaGFzIGEgcm9vdCBhbmQgbGVhZiBzaXRlIGFuZCBzZW5k cyB0cmFmZmljIHRvIFBFMS4gUEUxIHNob3VsZCBiZSBhYmxlIHRvIGRlY2lkZSBpZiB0aGUgdHJh ZmZpYyB3YXMgc291cmNlZCBmcm9tIHRoZSByb290IG9yIGxlYWYgc2l0ZS4gSWYgZnJvbSBQRTpM ZWFmIHRoZW4gdGhlIHRyYWZmaWMgc2hvdWxkIG5vdCBiZSByZXNvbHZlZCBpbiBQRTE6TGVhZi4N CltTYW1dIFllcywgd2hhdCB3ZSBhcmUgZG9pbmcgaXMgdG8gc29sdmUgdGhpcy4NCltKaW0gVT5d IEkgaGF2ZSBub3QgYmVlbiBmb2xsb3dpbmcgRS1UcmVlIHRvbyBjbG9zZWx5IGlzIHRoaXMgd2hl cmUgdGhlIHNvbHV0aW9uIHNwYWNlIGlzIG11bHRpcGxlIFBXcyBvciBpbmZlcnJpbmcgY29udGV4 dCBmcm9tIGRhdGEgdHJhZmZpYz8NCg0KVGhhbmtzLA0KDQpTYW0NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpGcm9tOiBVVFRBUk8sIEpBTUVTIFttYWlsdG86anUxNzM4QGF0dC5j b21dDQpTZW50OiBNb25kYXksIEFwcmlsIDIzLCAyMDEyIDc6MjcgQU0NClRvOiAnQWxleGFuZGVy IFZhaW5zaHRlaW4nOyBTYW0gQ2FvDQpDYzogbDJ2cG5AaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBU aGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQoNCkZv ciBhIGdpdmVuIFBFLCBJZiB5b3UgdXNlIEJHUCBhbmQgZGVmaW5lIHNlcGFyYXRlIFZSRnMgb25l IGZvciB0aGUgbGVhZnMgYW5kIG9uZSBmb3Igcm9vdHMgdGhhbiB0aGUgc2VtYW50aWMgcHJvdmlk ZWQgYnkgdGhlIFJUIGFzc2lnbm1lbnQgc2hvdWxkIGJlIHRyYW5zbGF0ZWQgY29ycmVjdGx5IGlu IHRvIHRoZSBmb3J3YXJkaW5nIHByb2dyYW1tZWQuLiBUaGlzIG1lYW5zIHRoYXQgaW50cmEtUEUg YmV0d2VlbiB0aGUgbGVhZiBhbmQgcm9vdCBWUkYgc2hvdWxkIGJlIHRyZWF0ZWQgYXMgYSBMYWJl bGVkIFBXLiBJZiB0cmVhdGVkIGFzIGEgcmVndWxhciBldGhlcm5ldCBpbnRlcmZhY2UgdGhhbiBh IGxlYWYgb24gVlJGIFMxIGNhbiBmb3J3YXJkIHRyYWZmaWMgb24gVlJGIEgxIGFuZCB0aGVuIG9u dG8gYSBkaWZmZXJlbnQgUEVzIGxlYWYgVlJG4oCmIEkgYmVsaWV2ZSB3ZSBoYWQgYSB2ZXJ5IHNp bWlsYXIgY29udmVyc2F0aW9uIG92ZXIgYSB5ZWFyIGFnbyBhYm91dCBFLVRyZWXigKYNCg0KU28s IGhlcmUgYXJlIHRoZSByZXFzIEkgc2hhcmVkDQoNCuKAoiAgICAgICAgICBFLVRyZWUvUGFydGlh bCBtZXNoIHRvcG9sb2dpZXMgbmVlZCB0byBiZSByZWFsaXplZCBpbiB0aGUgY29udHJvbCBwbGFu ZSBieSBjb25zdHJ1Y3RpbmcgUFdzLiBUaGUgZGF0YSBwbGFuZSBzaG91bGQgbm90IGluZmVyIGEg dG9wb2xvZ3kuIEluIG90aGVyIHdvcmRzIGRhdGEgc2hvdWxkIG5vdCBoYXZlIHRvIGJlIGluc3Bl Y3RlZCB0byBkZXRlcm1pbmUgaWYgdGhlIHBhY2tldCBpcyBzb3VyY2VkIGZyb20gYSBsZWFmIG9y IGEgcm9vdA0K4oCiICAgICAgICAgIFRoZSBzYW1lIFBFIG11c3QgYmUgYWJsZSB0byBob3N0IFJv b3QgYW5kIExlYWYgc2l0ZXMuDQrigKIgICAgICAgICAgRGlzYWxsb3dpbmcgb2YgTGVhZiB0byBM ZWFmIHRyYWZmaWMgb24gdGhlIHNhbWUgUEUgbXVzdCBiZSBkb25lIHVzaW5nIFBXIHNlbWFudGlj cy4NCuKAoiAgICAgICAgICBXaGVuIFJvb3QgYW5kIExlYWYgc2l0ZXMgYXJlIGRlcGxveWVkIG9u IHRoZSBzYW1lIFBFIHRoZSBwYWNrZXRzIGJldHdlZW4gdGhlbSBzaG91bGQgb2JleSB0aGUgc2Ft ZSBzZW1hbnRpY3MgYXMgaWYgdGhleSBoYWQgdHJhdmVyc2VkIGEgUFcgaS5lICggU3BsaXQgSG9y aXpvbiwgTm8gTGFiZWwgUmUtSW1wb3NpdGlvbiBldGPigKYgKQ0K4oCiICAgICAgICAgIElmIFBF IGhhcyBhIHJvb3QgYW5kIGxlYWYgc2l0ZSBhbmQgc2VuZHMgdHJhZmZpYyB0byBQRTEuIFBFMSBz aG91bGQgYmUgYWJsZSB0byBkZWNpZGUgaWYgdGhlIHRyYWZmaWMgd2FzIHNvdXJjZWQgZnJvbSB0 aGUgcm9vdCBvciBsZWFmIHNpdGUuIElmIGZyb20gUEU6TGVhZiB0aGVuIHRoZSB0cmFmZmljIHNo b3VsZCBub3QgYmUgcmVzb2x2ZWQgaW4gUEUxOkxlYWYuDQoNCg0KSmltIFV0dGFybw0KRnJvbTog bDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBBbGV4YW5kZXIgVmFpbnNodGVpbg0KU2VudDogU3VuZGF5LCBBcHJpbCAyMiwg MjAxMiAxMDo1NyBBTQ0KVG86IFNhbSBDYW8NCkNjOiBsMnZwbkBpZXRmLm9yZw0KU3ViamVjdDog UkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8N Cg0KU2FtLA0KSSB3aWxsIHRyeSB0byBleHBsYWluIG15c2VsZi4NCg0KSSBoYXZlIG1pc3Nwb2tl biBiZWZvcmUsIGFuZCBJIG93ZSB5b3UgYW4gYXBvbG9neS4NCg0KQSB0cnVlIGxlZ2FjeSBQRSBj YW5ub3Qgb3BlcmF0ZSBhcyBhIE1peGVkIFBFIGZvciBFLXRyZWUgc2luY2UgdGhpcyBvcGVyYXRp b24gcmVxdWlyZXMgc29tZSBjaGFuZ2VzIGluIHRoZSBmb3J3YXJkaW5nIGJlaGF2aW9yLiBUaGlz IGlzIElNSE8gY29ycmVjdCByZWdhcmRsZXNzIG9mIHRoZSBzcGVjaWZpYyBFLXRyZWUgc29sdXRp b24gdGhhdCBpcyBpbXBsZW1lbnRlZCBieSB0aGUgcmVzdCBvZiB0aGUgUEVzIChDVy1iYXNlZCwg ZHVhbCBQVy1iYXNlZCBvciBWTEFOLWJhc2VkKS4gSS5lLiB3aXRob3V0IHNvbWUgYWRkaXRpb25h bCBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYyB0cmlja3MgaXQgY2FuIGJlIGVpdGhlciBhIFJvb3Qt b25seSBQRSBvciBhIExlYWYtb25seSBQRSBpbiB0aGUgVlBMUyB0aGF0IGRvZXMgbm90IGNvbnRh aW4gTWl4ZWQgUEVzLg0KDQpSZWdhcmRzLA0KICAgICBTYXNoYQ0KDQpGcm9tOiBTYW0gQ2FvIFtt YWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbV0NClNlbnQ6IFN1bmRheSwgQXByaWwgMjIsIDIwMTIg NToyMiBQTQ0KVG86IEFsZXhhbmRlciBWYWluc2h0ZWluDQpDYzogbDJ2cG5AaWV0Zi5vcmc7ICdS YXltb25kIEtleScNClN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRv IHRoZSBFLVRyZWUgc29sdXRpb24/DQoNClNhc2hhLA0KDQpJIGFncmVlIHdpdGggeW91ciBjb21t ZW50cy4gQnV0IG1heWJlIEkgZG9u4oCZdCBtYWtlIG15c2VsZiB1bmRlcnN0b29kLiBJIG1ha2Ug aXQgY2xlYXIuDQoNCklmIG9uZSBjaGlwIGNhbiBub3Qgc3VwcG9ydCBjb250cm9sIHdvcmQsIHRo ZW4gb25lIHN3aXRjaCB3aGljaCB1c2VzIHRoaXMgY2hpcCBjYW4gbm90IHdvcmsgYXMgUm9vdC1M ZWFmLU1peGVkIFBFIHNpbmNlIHdlIGNhbiBub3QgZXh0ZW5kIGl0LiBJcyB0aGlzIGNvcnJlY3Q/ IElzIHRoaXMgcmVhc29uYWJsZT8NCg0KQW55d2F5LCBjaGlwIGxpbWl0IGlzIGJpZyBwcm9ibGVt IGZvciBDVyBhcHByb2FjaC4NCg0KUmVnYXJkcywNCg0KWXVxdW4gKFNhbSkgQ2FvDQpFLW1haWw6 IFl1cXVuLmNhb0BnbWFpbC5jb208bWFpbHRvOll1cXVuLmNhb0BnbWFpbC5jb20+DQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBBbGV4YW5kZXIgVmFpbnNodGVpbiBb bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXQ0KU2VudDogU3VuZGF5LCBB cHJpbCAyMiwgMjAxMiA5OjU2IFBNDQpUbzogU2FtIENhbw0KQ2M6IGwydnBuQGlldGYub3JnOyAn UmF5bW9uZCBLZXknDQpTdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0 byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KDQpTYW0sDQpZb3XigJl2ZSBhc2tlZDoNCklmIGl0IG9u bHkgc3VwcG9ydHMgVlBMUywgb2ssIGl0IGNhbiB3b3JrIGFzIFJvb3Qtb25seSwgYnV0IHdoeSBp dCBjYW5ub3Qgd29yayBhcyBSb290LUxlYWYtTWl4ZWQgb3IgTGVhZi1vbmx5IGlmIGl0IGNhbm5v dCBzdXBwb3J0IENXPw0KSU1ITyBhbmQgRldJVyB0aGVyZSBpcyBub3QgdG9vIG11Y2ggeW91IGNh biBleHBlY3QgZnJvbSBhIHRydWUgbGVnYWN5IFBFIChpLmUuIGEgUEUgdGhhdCBkaWQgbm90IGNo YW5nZSBpdHMgZm9yd2FyZGluZyBiZWhhdmlvcik6DQoNCjEuICAgICAgIEl0IGNhbiBvYnZpb3Vz bHkgc3VwcG9ydCBSb290LW9ubHkgZnVuY3Rpb25hbGl0eQ0KDQoyLiAgICAgICBJdCBjYW4gc3Vw cG9ydCBMZWFmLW9ubHkgZnVuY3Rpb25hbGl0eSBpZiB0aGVyZSBhcmUgbm8gTWl4ZWQgYnkgcHJl dmVudGluZyBzZXR1cCBQVyAoYnkgbm90IHNldHRpbmcgdXAgUFdzIHRvIG90aGVyIExlYWYtb25s eSBQRXMpLg0KQW55dGhpbmcgYmV5b25kIHRoYXQgd291bGQgYmUgdmVyeSBtdWNoIGltcGxlbWVu dGF0aW9uLXNwZWNpZmljLiBFLmcuLCBJIGFtIGF3YXJlIG9mIGxlZ2FjeSBpbXBsZW1lbnRhdGlv bnMgdGhhdCBjb3VsZCBzdXBwb3J0IGZ1bmN0aW9uYWxpdHkgb2YgYSBNaXhlZCBQRSBwcm92aWRl ZCB0aGF0IGl0IHdvdWxkIGJlIHRoZSBvbmx5IE1peGVkIFBFIGluIHRoZSBWUExTIGluc3RhbmNl LCBhbmQgb3RoZXIgbGVnYWN5IGltcGxlbWVudGF0aW9ucyB0aGF0IGFyZSwgYXMgbGVnYWN5LCBm dWxseSBpbnRlcm9wZXJhYmxlIHdpdGggdGhlc2Ugb25lcyBidXQgY291bGQgbm90IHN1cHBvcnQg c3VjaCBmdW5jdGlvbmFsaXR5Lg0KDQpNeSAyYywNCiAgICAgU2FzaGENCg0KRnJvbTogbDJ2cG4t Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBTYW0gQ2FvDQpTZW50OiBTdW5kYXksIEFwcmlsIDIyLCAyMDEyIDQ6NDEgUE0NClRvOiAn UmF5bW9uZCBLZXknDQpDYzogbDJ2cG5AaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBUaGUgc3RhdHVz IG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQoNClJheW1vbmQsDQoN Ck5ldHdvcmsgZWZmaWNpZW5jeToNCltTYW1dIExlYWYvUm9vdCBjb25maWd1cmF0aW9uIGlzIGxv Y2FsIGNvbmZpZ3VyYXRpb24sIGFuZCBQRSBjYW4gbm90IGtub3cgcmVtb3RlIEFDIHR5cGUgY29u ZmlndXJhdGlvbi4gVGhpcyBpcyBDVyBGdW5kYW1lbnRhbHMuIFNvIGV2ZW4gaWYgQ1cgYXBwcm9h Y2ggZGVmaW5lcyBvcHRpb25hbCBlbmhhbmNlbWVudCBmb3IgTGVhZi1Pbmx5IFBFLCBidXQgY2Fu IG5vdCBzaWduYWwgaXQgYmV0d2VlbiBMZWFmLU9ubHkgUEVzLCBzbyB0aGVyZSBpcyBubyBnb29k IHdheSB0byBzdXBwb3J0IHRoaXMuIFRoZSBwb3NzaWJsZSBzb2x1dGlvbiBpcywgbWFudWFsbHkg Y29uZmlndXJlIGh1Yi1zcG9rZSB0b3BvbG9neSwgYnV0IGlmIHdlIGRvIGxpa2UgdGhpcywgY3Vy cmVudCBzb2x1dGlvbnMgaGF2ZSBzdXBwb3J0IG1vc3QgRS1UcmVlIGNhc2VzIHdpdGggSHViLVNw b2tlIGNvbmZpZ3VyYXRpb24uIExpemhvbmcgbWVudGlvbmVkIHRoaXMgaW4gb25lIG1haWwuDQoN CkJhY2t3YXJkcyBjb21wYXRpYmlsaXR5Og0KW1NhbV0gWWVzLCBuZXcgZHJhZnQgY29uc2lkZXJz IGJhY2t3YXJkIGNvbXBhdGliaWxpdHksIGJ1dCBpdCBtYWtlcyBwcmVjb25kaXRpb246IFRoZSBQ RSB3aGljaCBjYW4gbm90IHN1cHBvcnQgQ29udHJvbCB3b3JkIG9ubHkgd29ya3MgYXMgUm9vdC1v bmx5IFBFLiBUaGlzIGRvZXMgbm90IG1ha2Ugc2Vuc2UgZm9yIG1lLiBJZiBpdCBvbmx5IHN1cHBv cnRzIFZQTFMsIG9rLCBpdCBjYW4gd29yayBhcyBSb290LW9ubHksIGJ1dCB3aHkgaXQgY2FuIG5v dCB3b3JrIGFzIFJvb3QtTGVhZi1NaXhlZCBvciBMZWFmLW9ubHkgaWYgaXQgY2FuIG5vdCBzdXBw b3J0IENXPw0KDQpSZWdhcmRzLA0KDQpZdXF1biAoU2FtKSBDYW8NCkUtbWFpbDogWXVxdW4uY2Fv QGdtYWlsLmNvbTxtYWlsdG86WXVxdW4uY2FvQGdtYWlsLmNvbT4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkZyb206IHJheW1vbmQua2V5QGhvdG1haWwuY29tIFttYWlsdG86 cmF5bW9uZC5rZXlAaG90bWFpbC5jb21dIE9uIEJlaGFsZiBPZiBSYXltb25kIEtleQ0KU2VudDog U2F0dXJkYXksIEFwcmlsIDIxLCAyMDEyIDExOjMyIFBNDQpUbzogeXVxdW4uY2FvQGdtYWlsLmNv bQ0KQ2M6IGwydnBuQGlldGYub3JnDQpTdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBw cm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KDQpTb21lIGNsYXJpZmljYXRpb25zIFtS S10gaW5zZXJ0ZWQgYmVsb3cNClRoYW5rcw0KUmF5bW9uZCBLZXkNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpGcm9tOiB5dXF1bi5jYW9AZ21haWwuY29tDQpUbzogbGl6aG8uamlu QGdtYWlsLmNvbTsgd2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29tDQpTdWJqZWN0OiBS RTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0K RGF0ZTogU2F0LCAyMSBBcHIgMjAxMiAyMjo1MToyOCArMDgwMA0KQ0M6IGwydnBuQGlldGYub3Jn DQoNCkhpIGFsbCwNCg0KDQoNCldlIHJlYWNoIGFuIGltcGFzc2XimLouICBCVFcsIE1lZXRpbmcg bWludXRlcyBpcyByZWFkeSBub3cuIFdlIGNhbiBnZXQgRS10cmVlIHN1bW1hcnkgZnJvbSBJRVRG IHNpdGUuDQoNCg0KDQpUb2RheSBJIGNvbGxlY3RlZCBhbGwgaXRlbXMgd2UgZGlzY3Vzc2VkIGJl Zm9yZS4gVGhleSBhcmUsDQoNCg0KDQoxKSAgICAgICBTaWxpY29uIGlzc3VlIG9yIGNoaXAgbGlt aXQ7DQoNCjIpICAgICAgIE5ldHdvcmsgZWZmaWNpZW5jeTsNCg0KMykgICAgICAgRW5jYXBzdWxh dGlvbiBtb2RlLCB0YWcgb3IgcmF3Ow0KDQo0KSAgICAgICBILVZQTFM7DQoNCjUpICAgICAgIEJh Y2t3YXJkcyBjb21wYXRpYmlsaXR5LCBlc3BlY2lhbGx5IGxlZ2FjeSBQRSBvciBOb24tc3VwcG9y dGluZyBQRSB3aXRoIElFRUUgRS10cmVlIHN1cHBvcnQgam9pbnMgRS1UcmVlIGRvbWFpbjsNCg0K NikgICAgICAgQ29uZmlndXJhdGlvbiBjaGFuZ2UgaW4gb3BlcmF0aW9uLCBmb3IgZXhhbXBsZSwg TGVhZi1vbmx5IC0+IFJvb3QtTGVhZi1NaXhlZDsNCg0KNykgICAgICAgUy1WTEFOIHByZXNlcnZh dGlvbiBzdXBwb3J0Ow0KDQo4KSAgICAgICBNdWx0aS1zZWdtZW50IFBXOw0KDQo5KSAgICAgICBW TEFOIElEIGFsbG9jYXRpb24gKE9ubHkgZm9yIER1YWwtVkxBTik7DQoNCjEwKSAgIE11bHRpLUFT IGRlcGxveW1lbnQ7DQoNCjExKSAgIEVDTVA7DQoNCjEyKSAgIFAyTVAtUFc7DQoNCjEzKSAgIEV0 aGVybmV0IE9BTTsNCg0KDQoNCklmIHdlIHJldmlldyB0aGUgbWFpbC1saXN0LCBDVyBhcHByb2Fj aCBoYXMgdGhlIGZvbGxvd2luZyBsaW1pdHM6DQoNCjEpICAgICAgIENoaXAgbGltaXQuIFBsZWFz ZSByZWFkIHJlcGx5IGZyb20gR2lsZXMgYW5kIFdpbTsNCg0KMikgICAgICAgTmV0d29yayBlZmZp Y2llbmN5OiBUaGVyZSBhcmUgZ2FyYmFnZSBmYW1lcyB3aGljaCB3aWxsIGJlIGRyb3BwZWQgb24g ZWdyZXNzIFBFIHNpbmNlIG9ubHkgZWdyZXNzIFBFIGNhbiBkZWNpZGUgZm9yd2FyZCBvciBkcm9w IGZyYW1lcyB3aGlsZSBpdCByZWNlaXZlcyBmcmFtZXMuIEluZ3Jlc3MgUEUgY2FuIG5vdCBkZWNp ZGUgZm9yd2FyZCBvciBub3QuIFllcywgY3VycmVudCBzb2x1dGlvbiBjYW4gc3VwcG9ydCBIdWIt U3Bva2UgY29uZmlndXJhdGlvbiwgYnV0IGFzIHdlIGtub3csIHRoZSBjb25maWd1cmF0aW9uIGlz IG5vdCBlYXN5IGlmIHRoZSBuZXR3b3JrIGlzIGJpZy4gRHVhbC1WTEFOIG9yIE11bHRpLVBXIGFw cHJvYWNoIGNhbiBicmVhayBjb21tdW5pY2F0aW9uIGJldHdlZW4gTGVhZi1Pbmx5IFBFcyB2aWEg c2lnbmFsaW5nLg0KDQpbUktdIEl0IHNlZW1zIHRvIG1lIHRoaXMgaXMgbm90IHRoZSBjYXNlLiBT ZWN0aW9uIDYgb2YgdGhlIGRyYWZ0IGhhcyBzb21lIGRpc2N1c3Npb25zIG9uIHRoaXMuDQpodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rZXktbDJ2cG4tdnBscy1ldHJlZS0wNyNzZWN0 aW9uLTYNCjYuIE9wdGlvbmFsIEVuaGFuY2VtZW50cyBmb3IgTGVhZi1vbmx5IFBFDQo2LjEuIE5v IFBXIGJldHdlZW4gTGVhZi1vbmx5IFBFcw0KNi4yLiBOb3QgRm9yd2FyZCBGcmFtZSBmcm9tIExl YWYgQUMgdG8gTGVhZi1vbmx5IFBFDQoNCg0KDQozKSAgICAgICBCYWNrd2FyZHMgY29tcGF0aWJp bGl0eTogTm90IGFsbCBQRXMgc3VwcG9ydHMgY29udHJvbCB3b3JkLiBJZiBvbmUgY2FuIG5vdCBz dXBwb3J0IGNvbnRyb2wgd29yZCwgaXQgd2lsbCBub3Qgam9pbiBFLVRyZWUgZG9tYWluOw0KDQoN Cg0KW1JLXSBJdCBzZWVtcyB0byBtZSB0aGlzIGlzIG5vdCB0aGUgY2FzZS4gU2VjdGlvbiA1IG9m IHRoZSBkcmFmdCBoYXMgc29tZSBkaXNjdXNzaW9ucyBvbiB0aGlzLg0KaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQta2V5LWwydnBuLXZwbHMtZXRyZWUtMDcjc2VjdGlvbi01DQo1LiBC YWNrd2FyZCBDb21wYXRpYmlsaXR5DQo1LjEuIEFDIFR5cGUNCjUuMi4gQ29udHJvbCBXb3JkDQo1 LjMuIEFkZGl0aW9uYWwgQWN0aW9uIGluIERhdGEgRm9yd2FyZGluZw0KNS4zLjEuIEluZ3Jlc3Mg UEUgU3VwcG9ydGluZyB0aGUgRXh0ZW5zaW9uIGJ1dCBFZ3Jlc3MgUEUgTm90DQo1LjMuMi4gRWdy ZXNzIFBFIFN1cHBvcnRpbmcgdGhlIEV4dGVuc2lvbiBidXQgSW5ncmVzcyBQRSBOb3QNCg0KDQoN CkR1YWwgVkxBTiBoYXMgZm9sbG93aW5nIGxpbWl0czoNCg0KMSkgICAgICAgQ2hpcCBsaW1pdDog QXMgd2Uga25vdywgd2UgbmVlZCB0byBwdXNoIG9uZSBWTEFOIGludG8gZnJhbWVzIGJlZm9yZSBN UExTIGVuY2Fwc3VsYXRpb24gb24gaW5ncmVzcyBQRSBhbmQgc3RyaXBlIGl0IG91dCBvbiBlZ3Jl c3MgUEUuIFRoaXMgaXMgbm9uLXN0YW5kYXJkIG9wZXJhdGlvbi4gV2FpdCBmb3IgY29uZmlybWF0 aW9uIGZyb20gY2hpcCB2ZW5kb3I7DQoNCjIpICAgICAgIEhWUExTOiBJZiB3ZSBmb2xsb3cgRmln IDMgb3IgRmlnIDQgaW4gUkZDIDQ3NjIgdG8gZGVwbG95IEhWUExTLCBQRS1ycyB3b3JrcyBpbiBk aWZmZXJlbnQgbWFubmVyLCBQRS1ycyBzaG91bGQgZmlndXJlIG91dCBBQyB0eXBlIGluIFZQV1Mg Y2FzZSwgYnV0IGNhbiBOT1QgY29uZmlndXJlIGl0IGF0IGFsbCBpbiBTcG9rZSBQVyBjYXNlOw0K DQozKSAgICAgICBNdWx0aS1QVzogUmFmaSBmaWd1cmVzIHRoaXMgb3V0LCBidXQgd2UgZG9u4oCZ dCB0aGluayB0aGlzIG92ZXIgYXQgdGhhdCB0aW1lLiBJIHRoaW5rIHRoYXQgaXQgYWxzbyBoYXMg c2FtZSBwcm9ibGVtIGFzIEgtVlBMUyBoYXMuDQoNCjQpICAgICAgIEVuY2Fwc3VsYXRpb24gbW9k ZTogSWYgZGVwbG95IEdWUExTIHdpdGggU3Bva2UgUFcgbW9kZSwgUEUtcnMgc2hvdWxkIHdvcmsg aW4gdGFnZ2VkIG1vZGUsIG90aGVyd2lzZSBQRS1ycyBvciBlZ3Jlc3MgUEUgd2lsbCBzdHJpcGUg Uy1WTEFOIElEOw0KDQo1KSAgICAgICBCYWNrd2FyZCBDb21wYXRpYmlsaXR5OiBKdXN0IGFzIERh bmllbCBtZW50aW9uZWQsIHRoZXJlIGlzIGNvbXBhdGliaWxpdHkgaXNzdWUgaWYgbGVnYWN5IFBF IGpvaW5zIEUtVHJlZSBkb21haW4uIEZvciBtZSwgSSBkb27igJl0IGdldCBjbGVhciByZXNwb25z ZSBmcm9tIGNvLWF1dGhvcnMgb2YgRHVhbC1WTEFOLg0KDQoNCg0KRm9yIGFsbCBhcHByb2FjaGVz LCB3ZSBkb27igJl0IGNvdmVyIEVDTVAgLyBFdGhlcm5ldCBPQU0gdGlsbCBub3cuDQoNCg0KDQpJ cyB0aGVyZSBhbnl0aGluZyBtaXNzZWQ/DQoNCg0KDQpSZWdhcmRzLA0KDQoNCg0KWXVxdW4gKFNh bSkgQ2FvDQoNCkUtbWFpbDogWXVxdW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86WXVxdW4uY2FvQGdt YWlsLmNvbT4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkZyb206 IExpemhvbmcgSmluIFttYWlsdG86bGl6aG8uamluQGdtYWlsLmNvbV0NClNlbnQ6IFNhdHVyZGF5 LCBBcHJpbCAyMSwgMjAxMiAxMTo1OSBBTQ0KVG86IEhlbmRlcmlja3gsIFdpbSAoV2ltKQ0KQ2M6 IGwydnBuQGlldGYub3JnOyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgeXVxdW4u Y2FvQGdtYWlsLmNvbQ0KU3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMg dG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCg0KDQoNCkhpIFdpbiwNClRoYW5rIHlvdSBmb3IgdGhl IGFuc3dlcnMuIEluIHRoYXQgY2FzZSwgUEUtcnMgc2hvdWxkIGNvbmZpZ3VyZSB0aGUgcm9vdC9s ZWFmIHByb3BlcnRpZXMgb2YgVlBXUywgbm90IG9uIHRoZSByZW1vdGUgUEUgb2YgVlBXUy4gQW5k IHVzdWFsbHkgb24gUEUtcnMsIHlvdSBjb3VsZCBub3QgZmlndXJlIG91dCB0aGUgYWNjZXNzaW5n IHNwb2tlIFBXIGlzIGZyb20gUEUtciBvZiBWUFdTIG9yIE1UVS1zLiBVbmxlc3MgaGF2aW5nIHNv bWUgYWRkaXRpb25hbCBpbmRpY2F0aW9uIGluIE5NUywgeW91IGV2ZW4gZG9uJ3Qga25vdyB3aGlj aCBzcG9rZSBQVyBuZWVkcyB0byBkbyBWTEFOIG1hbmlwdWxhdGlvbi4gSSBhbSBub3Qgc3VyZSBz dWNoIFIvTCBjb25maWd1cmF0aW9uIGNvdWxkIGJlIGFjY2VwdGVkIGZyb20gb3BlcmF0aW9uYWwg dmlldy4gSG9wZSB0byBzZWUgbW9yZSBjb21tZW50cy4NCg0KUmVnYXJkcw0KTGl6aG9uZw0KDQoN CuWcqCAyMDEy5bm0NOaciDIx5pel5pif5pyf5YWt77yMSGVuZGVyaWNreCwgV2ltIChXaW0pIDx3 aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOndpbS5oZW5kZXJpY2t4QGFs Y2F0ZWwtbHVjZW50LmNvbT4+IOWGmemBk++8mg0KPiBUaGUgVlBXUyB3aGljaCB0ZXJtaW5hdGVz IGF0IHRoZSBILVZQTFMgbm9kZSBpcyBpbmRpY2F0ZWQgdG8gYmUgcm9vdCBvciBsZWFmIGFuZCB0 aGUgcHJvY2VkdXJlcyBhc3NvY2lhdGVkIHdpbGwgZG8gdGhlIFZMQU4gbWFuaXB1bGF0aW9uDQo+ DQo+DQo+DQo+IEZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJvdW5j ZXNAaWV0Zi5vcmc+IFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bDJ2cG4t Ym91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBMaXpob25nIEppbg0KPiBTZW50OiB2cmlq ZGFnIDIwIGFwcmlsIDIwMTIgMTg6MzgNCj4gVG86IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZw bkBpZXRmLm9yZz47IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4NCj4gQ2M6IHl1cXVuLmNhb0BnbWFpbC5jb208 bWFpbHRvOnl1cXVuLmNhb0BnbWFpbC5jb20+DQo+IFN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9m IHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+DQo+DQo+DQo+IEhpLCBh bGwsDQo+IFRoZSBkaWZmZXJlbmNlIGJldHdlZW4gMi1WTEFOIGFuZCBDVyBhcHByb2FjaCBpcyB3 aG8gd2lsbCBwcm92aWRlIHRoZSBSL0wgaW5mb3JtYXRpb24sIGN1c3RvbWVyIHBheWxvYWQgb3Ig UFc/IFRoZSBjdXN0b21lciBwYXlsb2FkIHdpbGwgYmUgYWx3YXlzIG1vZGlmaWVkIHRvIGNhcnJ5 IFIvTCBpbmZvcm1hdGlvbiBpbiAyLVZMQU4gYXBwcm9hY2gsIHdoaWxlIFBXIHdpdGggQ1cgd2ls bCBjYXJyeSBSL0wgaW5mb3JtYXRpb24gZm9yIENXIGFwcHJvYWNoLg0KPiBJIGhhdmUgYSBxdWVz dGlvbiB3aXRoIHRoZSAyLVZMQU4gYXBwcm9hY2ggaW4gSC1WUExTIHdoZXJlIEgtVlBMUyBpcyBh Y2Nlc3NlZCBieSBWUFdTIGFzIGRlc2NyaWJlZCBpbiBSRkM0NjcyIHNlY3Rpb24gMTAuMS4zLiBJ ZiBWUFdTIGlzIHVzZWQgdG8gYWNjZXNzIEgtVlBMUywgaG93IGNvdWxkIHRoZSBQRSBvbiBWUFdT IHNpZGUgYWRkcyBWTEFOIHRvIGluZGljYXRlIFIvTCBpbmZvcm1hdGlvbj8NCj4NCj4gVGhhbmtz DQo+IExpemhvbmcNCj4NCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4NCj4+ IE1lc3NhZ2U6IDINCj4+IERhdGU6IFRodSwgMTkgQXByIDIwMTIgMDQ6Mzg6MzYgKzAwMDANCj4+ IEZyb206IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+Pg0KPj4gVG86ICJS b2dlcnMsIEpvc2giIDxqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbTxtYWlsdG86am9zaC5yb2dlcnNA dHdjYWJsZS5jb20+PiwgTHVjeSB5b25nDQo+PiAgICAgICAgPGx1Y3kueW9uZ0BodWF3ZWkuY29t PG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+LCBEYW5pZWwgQ29obiA8RGFuaWVsQ0BvcmNr aXQuY29tPG1haWx0bzpEYW5pZWxDQG9yY2tpdC5jb20+PiwgU2FtIENhbw0KPj4gICAgICAgIDx5 dXF1bi5jYW9AZ21haWwuY29tPG1haWx0bzp5dXF1bi5jYW9AZ21haWwuY29tPj4NCj4+IENjOiAi bDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPiIgPGwydnBuQGlldGYub3JnPG1h aWx0bzpsMnZwbkBpZXRmLm9yZz4+DQo+PiBTdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUg YXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4gTWVzc2FnZS1JRDoNCj4+ICAg ICAgICA8RjkzMzY1NzE3MzFBREU0MkE1Mzk3RkM4MzFDRUFBMDIwMzQxOTJARlJJRFdQUE1CMDAy LmVjaXRlbGUuY29tPG1haWx0bzpGOTMzNjU3MTczMUFERTQyQTUzOTdGQzgzMUNFQUEwMjAzNDE5 MkBGUklEV1BQTUIwMDIuZWNpdGVsZS5jb20+Pg0KPj4gQ29udGVudC1UeXBlOiB0ZXh0L3BsYWlu OyBjaGFyc2V0PSJ1cy1hc2NpaSINCj4+DQo+PiBIaSBhbGwsDQo+PiBJIGZ1bGx5IHVuZGVyc3Rh bmQgdGhhdCB0aGF0IHdoYXQgSSBhbSBnb2luZyB0byBzYXkgaXMgbm90IHZlcnkgcG9wdWxhciwg YnV0Og0KPj4NCj4+IElNTyBvbmUgb2YgdGhlIGFkdmFudGFnZXMgb2YgdGhlIENXLWJhc2VkIHNv bHV0aW9uIGlzIHRoYXQgaXQgaXMgb3J0aG9nb25hbCB0byB1c2FnZSAob3Igbm9uLXVzYWdlKSBv ZiBQMk1QIFBXcyBmb3IgZWZmZWN0aXZlIGRlbGl2ZXJ5IG9mIEJVTiB0cmFmZmljLg0KPj4NCj4+ IEFub3RoZXIgYWR2YW50YWdlIGlzIHByZXNlcnZhdGlvbiBvZiBmdWxsIG1lc2ggb2YgUDJQIFBX cyBpbiBhIFZQTFMsIGFuZCwgaW4gYSBtb3JlIGdlbmVyaWMgd2F5LCBsb2NhbGl6YXRpb24gb2Yg ZWZmZWN0cyBvZiBjaGFuZ2VzIGluIHRoZSBQRSBjb25maWd1cmF0aW9uLg0KPj4NCj4+IEluIHBh cnRpY3VsYXIsIGFkZGluZyBhIExlYWYgQUMgdG8gYSBQRSB0aGF0IHByZXZpb3VzbHkgaGFzIGJl ZW4gb25seSBzdXBwb3J0aW5nIFJvb3QgQUNzIChvciB2aWNlIHZlcnNhKSwgcmVtb3ZhbCBvZiB0 aGUgbGFzdCBMZWFmIG9yIGxhc3QgUm9vdCBBQyBmcm9tIGEgUEUgdGhhdCBwcmV2aW91c2x5IGhh cyBiZWVuIHN1cHBvcnRpbmcgYSBtaXggZXRjLiBhZmZlY3Qgb25seSB0aGUgUEUgd2hlcmUgdGhp cyBvcGVyYXRpb24gaGFwcGVucyBhbmQgbm90IHRoZSByZXN0IG9mIHRoZSBQRXMuDQo+Pg0KPj4g QXMgZm9yIHRoZSBuZWVkIGZvciBIVyBjaGFuZ2VzIHRoYXQgaGF2ZSBiZWVuIG1lbnRpb25lZCBh cyBhIG1haW4gZGlzYWR2YW50YWdlIG9mIHRoZSBDVy1iYXNlZCBhcHByb2FjaCAtIEkgYmVsaWV2 ZSBpdCBzdHJvbmdseSBkZXBlbmRzIG9uIHNwZWNpZmljIGltcGxlbWVudGF0aW9ucy4gQW5kIHNv bWUgY2hhbmdlcyBpbiB0aGUgZm9yd2FyZGluZyBwcm9jZXNzIGFyZSByZXF1aXJlZCBpbiBhbnkg c29sdXRpb24uDQo+Pg0KPj4gTXkgMmMsDQo+PiAgICAgU2FzaGENCj4+DQo+Pg0KPj4NCj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IEZyb206IGwydnBuLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc+IFtsMnZwbi1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnPl0gb24gYmVoYWxmIG9m IFJvZ2VycywgSm9zaCBbam9zaC5yb2dlcnNAdHdjYWJsZS5jb208bWFpbHRvOmpvc2gucm9nZXJz QHR3Y2FibGUuY29tPl0NCj4+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTgsIDIwMTIgOTo1NyBQ TQ0KPj4gVG86IEx1Y3kgeW9uZzsgRGFuaWVsIENvaG47IFNhbSBDYW8NCj4+IENjOiBsMnZwbkBp ZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBSZTogVGhlIHN0YXR1 cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4NCj4+IEFnYWlu LCB0aGUgUDJNUCBzaXR1YXRpb24gdGhyb3dzIG1lLiAgSXMgdGhpcyBzb21ldGhpbmcgdGhhdCBp cyB1c2VkDQo+PiBjb21tb25seT8NCj4+DQo+PiBJJ20gdW5kZXIgdGhlIGltcHJlc3Npb24gdGhh dCBhZGRpbmcgUDJNUCB0byBhbnkgbW9kZWwgcmVzdWx0cyBpbiBhIG1vcmUNCj4+IGNvbXBsZXgg bW9kZWwuICBXZXRoZXIgb3V0c2lkZSBzLXRhZyBpcyB1c2VkIHRvIGRpZmZlcmVudGlhdGUsIG9y DQo+PiBkZWRpY2F0ZWQgcHcncyBhcmUgdXNlZCBmb3IgdGhlIHNhbWUgcHVycG9zZSwgaXQgc2Vl bXMgYm90aCBiZWNvbWUgbW9yZQ0KPj4gY29tcGxleC4NCj4+DQo+PiBHaWxlJ3MgY29tcGFyaXNv biBzbGlkZSBzdGlsbCBjb25jaXNlbHkgY2FwdHVyZXMgdGhlIGRpZmZlcmVuY2VzIGJldHdlZW4N Cj4+IHRoZXNlIG1ldGhvZHMsIGluIG15IG9waW5pb24uICBJIGhhdmVuJ3Qgc2VlbiBhbnkgbmV3 IGlkZWFzIG9yIHRob3VnaHRzDQo+PiBicm91Z2h0IHRvIHRoZSBncm91cCBpbiB0aGUgcGFzdCB3 ZWVrIG9yIHR3byBvbiB0aGUgc3ViamVjdC4gIEkgd291bGQgaGF0ZQ0KPj4gZm9yIGJvdGggcHJv cG9zZWQgbWV0aG9kcyB0byBkaWUgb24gdGhlIHZpbmUgYmVjYXVzZSB3ZSBjb3VsZG4ndCBkZWNp ZGUNCj4+IGJldHdlZW4gdHdvIG1ldGhvZHMgdGhhdCBoYXZlIG5vdGhpbmcgaW5oZXJlbnRseSB3 cm9uZyB3aXRoIGVpdGhlci4NCj4+DQo+PiAtSm9zaA0KPj4NCj4+DQo+PiBPbiA0LzE4LzEyIDE6 NTMgUE0sICJMdWN5IHlvbmciIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25n QGh1YXdlaS5jb20+PiB3cm90ZToNCj4+DQo+Pj5TZW5kIHRoaXMgYWdhaW4uDQo+Pj4NCj4+PlR3 byBQVyBhcHByb2FjaCBjYW4gYmUgY29tcGxleCB0b28gaWYgdGhlIFZQTFMgaW5zdGFuY2UgZm9y IEUtVHJlZSB1c2VzDQo+Pj5QMlAgUFcgZm8NCg0KVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRl bmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucyBpbmZvcm1hdGlvbiB3aGlj aCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVs ZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBs ZWFzZSBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0 aGUgb3JpZ2luYWwgYW5kIGFsbCBjb3BpZXMgdGhlcmVvZi4NCg0KVGhpcyBlLW1haWwgbWVzc2Fn ZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucyBpbmZvcm1h dGlvbiB3aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0 byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4g ZXJyb3IsIHBsZWFzZSBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVu IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFsbCBjb3BpZXMgdGhlcmVvZi4NCg== --_000_B17A6910EEDD1F45980687268941550FACAFF4MISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8IS0tW2lmICFtc29dPg0KPHN0eWxlPg0Kdlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZN TCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6 dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9 DQo8L3N0eWxlPg0KPCFbZW5kaWZdLS0+PHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlv bnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1 IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0K CXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1 IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgUEdvdGhpYyI7DQoJcGFu b3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc WzhiTzUzIjt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTrlrovkvZM7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQog cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJNUyBQR290aGljIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJNUyBQR290aGlj Iiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQ YXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21z by1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Ik1TIFBHb3RoaWMi LCJzZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAu ZWN4bXNvbm9ybWFsLCBsaS5lY3htc29ub3JtYWwsIGRpdi5lY3htc29ub3JtYWwNCgl7bXNvLXN0 eWxlLW5hbWU6ZWN4bXNvbm9ybWFsOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJNUyBQR290aGljIiwic2VyaWYiO30NCnAuZWN4bXNvbm9ybWFsMSwgbGkuZWN4bXNv bm9ybWFsMSwgZGl2LmVjeG1zb25vcm1hbDENCgl7bXNvLXN0eWxlLW5hbWU6ZWN4bXNvbm9ybWFs MTsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlxbOGJPNTMiO30NCnAuYmFsbG9vbnRleHQsIGxpLmJhbGxvb250ZXh0LCBkaXYuYmFsbG9v bnRleHQNCgl7bXNvLXN0eWxlLW5hbWU6YmFsbG9vbnRleHQ7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6Ik1TIFBHb3RoaWMiLCJzZXJpZiI7fQ0KcC5iYWxsb29udGV4 dDAsIGxpLmJhbGxvb250ZXh0MCwgZGl2LmJhbGxvb250ZXh0MA0KCXttc28tc3R5bGUtbmFtZTpi YWxsb29udGV4dDA7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Ik1T IFBHb3RoaWMiLCJzZXJpZiI7fQ0Kc3Bhbi5iYWxsb29udGV4dGNoYXIwDQoJe21zby1zdHlsZS1u YW1lOmJhbGxvb250ZXh0Y2hhcjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uYmFsbG9vbnRleHRjaGFyMDANCgl7bXNv LXN0eWxlLW5hbWU6YmFsbG9vbnRleHRjaGFyMDsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uZWN4bXNvaHlwZXJsaW5r MQ0KCXttc28tc3R5bGUtbmFtZTplY3htc29oeXBlcmxpbmsxOw0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmVjeG1zb2h5cGVybGlua2ZvbGxvd2VkMQ0K CXttc28tc3R5bGUtbmFtZTplY3htc29oeXBlcmxpbmtmb2xsb3dlZDE7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uZWN4ZW1haWxzdHlsZTE3MQ0KCXtt c28tc3R5bGUtbmFtZTplY3hlbWFpbHN0eWxlMTcxOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOm5hdnk7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzANCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6bmF2eTt9DQpzcGFuLkVtYWlsU3R5bGUzMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi5FbWFpbFN0eWxlMzINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6bmF2eTt9DQpzcGFuLkVtYWlsU3R5bGUz Mw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzQNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTM1DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOm5hdnk7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMzcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NTk1LjNwdCA4NDEuOXB0Ow0KCW1h cmdpbjoxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KIC8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCiBAbGlzdCBsMA0KCXtt c28tbGlzdC1pZDo1MjUyMTM0NjM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOi0zMDE1MzY3NDAgLTc0MTg1OTE4NiAxNjA5ODUzODgyIDU1Nzg5OTc0MCAy MDc3MDEyNDY2IDIyMjgyMzkxNiAtMTQzMDMyODM5MCAtMTAxOTk4NTIxOCAxNjAwNjMwOTYgLTE4 MTcxNTY4MjQ7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrigKI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCkBsaXN0IGwwOmxldmVsMg0K CXttc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVs LXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoy LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw3 DQoJe21zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTA4Nzc3NDYzMjsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NDA1NDMzMTY4IC0xMjM5MDA2MjM2 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6 NTsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6LjI1aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCW1hcmdpbi1sZWZ0Oi4yNWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpTaW1T dW47fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDQN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZl bC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVs OQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT4NCjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJibHVlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 DQpjb2xvcjojMUY0OTdEIj5TYW0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IENvbW1lbnRzIEluLUxpbmUuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgSmltIFV0dGFybzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU2FtIENhbyBbbWFpbHRvOnl1 cXVuLmNhb0BnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAyMywg MjAxMiAxMjowNiBBTTxicj4NCjxiPlRvOjwvYj4gVVRUQVJPLCBKQU1FUzsgJ0FsZXhhbmRlciBW YWluc2h0ZWluJzxicj4NCjxiPkNjOjwvYj4gbDJ2cG5AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1 dGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjpuYXZ5Ij5IaSBKaW0sPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0K Y29sb3I6bmF2eSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6bmF2eSI+VGhhbmsgeW91IHZl cnkgbXVjaCBmb3IgeW91ciBjb21tZW50cy4gQnV0IHdoYXQgd2UgZGlkIGlzIGEgbGl0dGxlIGRp ZmZlcmVudCBmcm9tIHlvdXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOm5hdnkiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsNCmNvbG9yOm5hdnkiPk11bHRpLVBXIGNhcnJpZXMgQUMgdHlwZSBpbiDigJxMYXll cjIgSW5mbyBFeHRlbmRlZCBDb21tdW5pdHnigJ0sIE5PVCBkaWZmZXJlbnQgUlQsIGFuZCBjb250 cm9sIHBsYW5lIHdpbGwgdHJhbnNsYXRlIGl0LCBidXQgd2UgZG9u4oCZdCBzZXBhcmF0ZSBpdCBp bnRvIDIgVlJGcyAoVlNJIGluDQogdGhlIGRyYWZ0KS4gVGhleSBiZWxvbmcgdG8gb25lIFZTSS4g PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ow0KY29sb3I6bmF2eSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6bmF2 eSI+SSBndWVzcyB5b3VyIEUtVHJlZSBkZXBsb3ltZW50IHZpYSBCR1AtQUQgaXMsIGFzc2lnbiBv bmUgUm9vdC1SVCAoc2FtZSBpbiBhbGwgVlBMQS1QRSBpbiBWUExTIGRvbWFpbiksIGFuZCBhc3Np Z24gZGlmZmVyZW50IExlYWYgUlQgZm9yIGVhY2ggTGVhZi1vbmx5IFBFLCB0aGVuDQogd2Ugd2ls bCBub3Qgc2V0dXAgUFcgYmV0d2VlbiBMZWFmLW9ubHkgUEVzLCB0aGVuIHdlIGNhbiBicmVhayB0 aGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIExlYWYtT25seSBQRXMuIElzIG15IHVuZGVyc3RhbmRp bmcgY29ycmVjdCBvciBub3Q/IFRoaXMgaXMgSHViLVNwb2tlIGRlcGxveW1lbnQsIGFuZCBjdXJy ZW50IHNvbHV0aW9uIGNhbiBzdXBwb3J0IHRoaXMuIEJ1dCBpdCBjYW4gbm90IGNvdmVyIGFsbCBj YXNlcy4NCjwvc3Bhbj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ow0KZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5bSmltIFUmZ3Q7XQ0KPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoYXQgaXMgdGhlIGFwcHJvYWNoIGJ1dCBhcyB5b3Ugbm90ZSBpdCBk b2VzIG5vdCBjb3ZlciBhbGwgY2FzZXMuLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6bmF2eSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6bmF2eSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ow0KY29sb3I6bmF2eSI+SSBhZ3JlZSB3aXRoIHNvbWUgcmVxdWlyZW1lbnRzIG9uIEUtVHJlZSBp biB5b3VyIG1haWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6bmF2eSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi4yNWlu O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6bmF2eSI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0K Y29sb3I6bmF2eSI+UGFydGlhbCBtZXNoIHRvcG9sb2dpZXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LjI1aW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7DQpmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPltTYW1dIEFncmVlLiBOb3cgQ1csIER1 YWwtVkxBTiBvciBEdWFsLVBXIGNvbnNpZGVyIHRoaXMgaW4gZHJhZnQsIGJ1dCBmb3IgbWUsIENX IG9yIER1YWwtVkxBTiB3aWxsIGRlcGxveSBwYXJ0aWFsIG1lc2ggaW4geW91ciB3YXkgb3INCiBj b25maWd1cmUgaXQgbWFudWFsbHk7IER1YWwtUFcgY2FuIHN1cHBvcnQgdGhpcyB2aWEgc2lnbmFs aW5nLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjI1aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBs Zm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpuYXZ5Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7DQpjb2xvcjpuYXZ5Ij5TYW1lIFBFIG11c2ggYmUgYWJsZSB0byBob3N0 IFJvb3QgYW5kIExlYWYgU2l0ZXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7DQpmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOm5hdnkiPltTYW1dIEFncmVlLiBUaGlzIGlzIFJvb3QtTGVhZi1NaXhlZCBj YXNlIGluIGFsbCBFLXRyZWUgZHJhZnQ7IEFsbCBkcmFmdHMgc2hvdWxkIHN1cHBvcnQgdGhpcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjI1aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4N CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpuYXZ5 Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjpuYXZ5Ij5EaXNhbGxvd2luZyBvZiBMZWFmIHRvIExlYWYgdHJhZmZp YyBvbiB0aGUgc2FtZSBQRSBtdXN0IGJlIGRvbmUgdXNpbmcgUFcgc2VtYW50aWNzLg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50 Oi4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ow0KZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij5bU2FtXSBKaW0s IGNhbiBub3QgZnVsbHkgdW5kZXJzdGFuZCB0aGlzIGNhc2UuIElmIG9uIHNhbWUgUEUsIHRoaXMg aXMgbG9jYWwgYmVoYXZpb3IsIGlzIGl0IGNvcnJlY3Q/IERvIHlvdSBtZWFuIHdlIG5lZWQgdG8g c2V0dXAgb25lDQogZHVtbXkgUFcgb24gYW55IFBFIGlmIGl0IGhvc3RzIFJvb3QgYW5kIExlYWYg c2l0ZXM/IFNoYWxsIHdlIGRlc2NyaWJlIGluIGRyYWZ0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsN CmNvbG9yOiMxRjQ5N0QiPltKaW0gVSZndDtdIElmIHR3byBWUkZzIG9uZSBMZWFmIGFuZCBvbmUg Um9vdCBvbiBhIGNvbW1vbiBQRSB0cmFmZmljIHdoZW4gc2VudCBmcm9tIHRoZSBMZWFmIHRvIHRo ZSBSb290IGNvbnRleHQgbXVzdCBub3QgYmUgdHJlYXRlZCBhcyBuYXRpdmUgZXRoZXJuZXQNCiB0 cmFmZmljIGFzIGl0IHdvdWxkIHRoZW4g4oCcYXBwZWFy4oCdIHRoZSBzYW1lIGFzIHRyYWZmaWMg YXJyaXZpbmcgZnJvbSBleHRlcm5hbCBldGhlcm5ldCBpbnRlcmZhY2VzLi4gSW4gdGhpcyByZWdh cmQgeW91IGxvc2UgdGhlIG5vdGlvbiB0aGF0IGEgbGVhZiBzZW1hbnRpYyBpcyBhc3NvY2lhdGVk IHdpdGggdGhhdCB0cmFmZmljLi4NCjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW47dGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwxIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4t PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjpuYXZ5Ij5XaGVuIFJvb3Qg YW5kIExlYWYgc2l0ZXMgYXJlIGRlcGxveWVkIG9uIHRoZSBzYW1lIFBFIHRoZSBwYWNrZXRzIGJl dHdlZW4gdGhlbSBzaG91bGQgb2JleSB0aGUgc2FtZSBzZW1hbnRpY3MgYXMgaWYgdGhleSBoYWQg dHJhdmVyc2VkIGEgUFcgaS5lICggU3BsaXQNCiBIb3Jpem9uLCBObyBMYWJlbCBSZS1JbXBvc2l0 aW9uIGV0Y+KApiApLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0idGV4dC1pbmRlbnQ6LjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 DQpmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOm5hdnkiPltTYW1dIFNhbWUgcXVlc3Rpb24gYXMgYWJvdmUuIEFueXdheSwg4oCcU3BsaXQg SG9yaXpvbuKAnSBpcyBiYXNpYyBydWxlIGZvciBhbGwgZHJhZnRzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsNCmNvbG9yOiMxRjQ5N0QiPltKaW0gVSZndDtdIFNlZSBhYm92ZS4uIFNvcnQgb2YgdGhl IHNhbWUgcmVxdWlyZW1lbnQgYXMgc3RhdGVkIGFib3ZlLi4gSSBiZWxpZXZlIHRoYXQgdGhlIGxv Y2FsIGJlaGF2aW9yIGludHJhLVBFIGJldHdlZW4gYSBMZWFmIGFuZCBhIFJvb3Qgc2hvdWxkIG1p bWljDQogdGhlIGJlaGF2aW9yIGFzIGlmIHRoZSB0cmFmZmljIGFycml2ZWQgZnJvbSBhIGRpZmZl cmVudCBQRSZndDsuLjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omwx IGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpuYXZ5Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjpuYXZ5Ij5JZiBQRSBoYXMgYSByb290IGFu ZCBsZWFmIHNpdGUgYW5kIHNlbmRzIHRyYWZmaWMgdG8gUEUxLiBQRTEgc2hvdWxkIGJlIGFibGUg dG8gZGVjaWRlIGlmIHRoZSB0cmFmZmljIHdhcyBzb3VyY2VkIGZyb20gdGhlIHJvb3Qgb3IgbGVh ZiBzaXRlLiBJZiBmcm9tIFBFOkxlYWYNCiB0aGVuIHRoZSB0cmFmZmljIHNob3VsZCBub3QgYmUg cmVzb2x2ZWQgaW4gUEUxOkxlYWYuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDouMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDsNCmZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6bmF2eSI+W1NhbV0gWWVzLCB3aGF0IHdlIGFyZSBkb2luZyBpcyB0byBzb2x2 ZSB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPltKaW0gVSZndDtd IEkgaGF2ZSBub3QgYmVlbiBmb2xsb3dpbmcgRS1UcmVlIHRvbyBjbG9zZWx5IGlzIHRoaXMgd2hl cmUgdGhlIHNvbHV0aW9uIHNwYWNlIGlzIG11bHRpcGxlIFBXcyBvciBpbmZlcnJpbmcgY29udGV4 dCBmcm9tIGRhdGEgdHJhZmZpYz8NCjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOm5hdnkiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsNCmNvbG9yOm5hdnkiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjpu YXZ5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjpuYXZ5Ij5TYW08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls ZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0i Y2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IFVUVEFSTywgSkFNRVMgW21haWx0bzpqdTE3MzhAYXR0LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9i PiBNb25kYXksIEFwcmlsIDIzLCAyMDEyIDc6MjcgQU08YnI+DQo8Yj5Ubzo8L2I+ICdBbGV4YW5k ZXIgVmFpbnNodGVpbic7IFNhbSBDYW88YnI+DQo8Yj5DYzo8L2I+IGwydnBuQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRo ZSBFLVRyZWUgc29sdXRpb24/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkZvciBhIGdpdmVu IFBFLCBJZiB5b3UgdXNlIEJHUCBhbmQgZGVmaW5lIHNlcGFyYXRlIFZSRnMgb25lIGZvciB0aGUg bGVhZnMgYW5kIG9uZSBmb3Igcm9vdHMgdGhhbiB0aGUgc2VtYW50aWMgcHJvdmlkZWQgYnkgdGhl IFJUIGFzc2lnbm1lbnQgc2hvdWxkIGJlIHRyYW5zbGF0ZWQNCiBjb3JyZWN0bHkgaW4gdG8gdGhl IGZvcndhcmRpbmcgcHJvZ3JhbW1lZC4uIFRoaXMgbWVhbnMgdGhhdCBpbnRyYS1QRSBiZXR3ZWVu IHRoZSBsZWFmIGFuZCByb290IFZSRiBzaG91bGQgYmUgdHJlYXRlZCBhcyBhIExhYmVsZWQgUFcu IElmIHRyZWF0ZWQgYXMgYSByZWd1bGFyIGV0aGVybmV0IGludGVyZmFjZSB0aGFuIGEgbGVhZiBv biBWUkYgUzEgY2FuIGZvcndhcmQgdHJhZmZpYyBvbiBWUkYgSDEgYW5kIHRoZW4gb250byBhIGRp ZmZlcmVudCBQRXMNCiBsZWFmIFZSRuKApiBJIGJlbGlldmUgd2UgaGFkIGEgdmVyeSBzaW1pbGFy IGNvbnZlcnNhdGlvbiBvdmVyIGEgeWVhciBhZ28gYWJvdXQgRS1UcmVl4oCmDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0 OTdEIj5TbywgaGVyZSBhcmUgdGhlIHJlcXMgSSBzaGFyZWQNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlz dDpsMCBsZXZlbDEgbGZvNCI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+4oCiPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToNCiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5FLVRyZWUvUGFydGlhbCBtZXNoIHRvcG9sb2dpZXMgbmVl ZCB0byBiZSByZWFsaXplZCBpbiB0aGUgY29udHJvbCBwbGFuZSBieSBjb25zdHJ1Y3RpbmcgUFdz LiBUaGUgZGF0YSBwbGFuZSBzaG91bGQgbm90IGluZmVyIGEgdG9wb2xvZ3kuIEluIG90aGVyDQog d29yZHMgZGF0YSBzaG91bGQgbm90IGhhdmUgdG8gYmUgaW5zcGVjdGVkIHRvIGRldGVybWluZSBp ZiB0aGUgcGFja2V0IGlzIHNvdXJjZWQgZnJvbSBhIGxlYWYgb3IgYSByb290PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7igKI8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Og0KJnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBzYW1lIFBF IG11c3QgYmUgYWJsZSB0byBob3N0IFJvb3QgYW5kIExlYWYgc2l0ZXMuDQo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3Rl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvNCI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+4oCiPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToNCiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EaXNhbGxvd2lu ZyBvZiBMZWFmIHRvIExlYWYgdHJhZmZpYyBvbiB0aGUgc2FtZSBQRSBtdXN0IGJlIGRvbmUgdXNp bmcgUFcgc2VtYW50aWNzLjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omww IGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7i gKI8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5Og0KJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPldoZW4gUm9vdCBhbmQgTGVhZiBzaXRlcyBhcmUgZGVwbG95ZWQg b24gdGhlIHNhbWUgUEUgdGhlIHBhY2tldHMgYmV0d2VlbiB0aGVtIHNob3VsZCBvYmV5IHRoZSBz YW1lIHNlbWFudGljcyBhcyBpZiB0aGV5IGhhZCB0cmF2ZXJzZWQgYSBQVyBpLmUNCiAoIFNwbGl0 IEhvcml6b24sIE5vIExhYmVsIFJlLUltcG9zaXRpb24gZXRj4oCmICk8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzQiPg0KPCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPuKAojxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6DQomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgUEUgaGFzIGEgcm9v dCBhbmQgbGVhZiBzaXRlIGFuZCBzZW5kcyB0cmFmZmljIHRvIFBFMS4gUEUxIHNob3VsZCBiZSBh YmxlIHRvIGRlY2lkZSBpZiB0aGUgdHJhZmZpYyB3YXMgc291cmNlZCBmcm9tIHRoZSByb290IG9y IGxlYWYgc2l0ZS4NCiBJZiBmcm9tIFBFOkxlYWYgdGhlbiB0aGUgdHJhZmZpYyBzaG91bGQgbm90 IGJlIHJlc29sdmVkIGluIFBFMTpMZWFmLjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ow0KY29sb3I6IzFGNDk3RCI+SmltIFV0dGFybzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFsZXhhbmRlciBWYWluc2h0ZWluPGJy Pg0KPGI+U2VudDo8L2I+IFN1bmRheSwgQXByaWwgMjIsIDIwMTIgMTA6NTcgQU08YnI+DQo8Yj5U bzo8L2I+IFNhbSBDYW88YnI+DQo8Yj5DYzo8L2I+IGwydnBuQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUg c29sdXRpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+U2FtLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkkgd2lsbCB0cnkgdG8gZXhwbGFpbiBteXNlbGYuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29s b3I6IzFGNDk3RCI+SSBoYXZlIG1pc3Nwb2tlbiBiZWZvcmUsIGFuZCBJIG93ZSB5b3UgYW4gYXBv bG9neS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7DQpjb2xvcjojMUY0OTdEIj5BIHRydWUgbGVnYWN5IFBFIGNhbm5vdCBvcGVyYXRlIGFzIGEg TWl4ZWQgUEUgZm9yIEUtdHJlZSBzaW5jZSB0aGlzIG9wZXJhdGlvbiByZXF1aXJlcyBzb21lIGNo YW5nZXMgaW4gdGhlIGZvcndhcmRpbmcgYmVoYXZpb3IuIFRoaXMgaXMgSU1ITyBjb3JyZWN0DQo8 aT5yZWdhcmRsZXNzIG9mIHRoZSBzcGVjaWZpYyBFLXRyZWUgc29sdXRpb24gdGhhdCBpcyBpbXBs ZW1lbnRlZCBieSB0aGUgcmVzdCBvZiB0aGUgUEVzPC9pPiAoQ1ctYmFzZWQsIGR1YWwgUFctYmFz ZWQgb3IgVkxBTi1iYXNlZCkuIEkuZS4gd2l0aG91dCBzb21lIGFkZGl0aW9uYWwgaW1wbGVtZW50 YXRpb24tc3BlY2lmaWMgdHJpY2tzIGl0IGNhbiBiZSBlaXRoZXIgYSBSb290LW9ubHkgUEUgb3Ig YSBMZWFmLW9ubHkgUEUgaW4gdGhlIFZQTFMgdGhhdA0KIGRvZXMgbm90IGNvbnRhaW4gTWl4ZWQg UEVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTYXNoYTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU2FtIENhbyBbbWFpbHRvOnl1 cXVuLmNhb0BnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBBcHJpbCAyMiwg MjAxMiA1OjIyIFBNPGJyPg0KPGI+VG86PC9iPiBBbGV4YW5kZXIgVmFpbnNodGVpbjxicj4NCjxi PkNjOjwvYj4gbDJ2cG5AaWV0Zi5vcmc7ICdSYXltb25kIEtleSc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlv bj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjpuYXZ5Ij5TYXNoYSw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xv cjpuYXZ5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjpuYXZ5Ij5JIGFncmVlIHdpdGggeW91 ciBjb21tZW50cy4gQnV0IG1heWJlIEkgZG9u4oCZdCBtYWtlIG15c2VsZiB1bmRlcnN0b29kLiBJ IG1ha2UgaXQgY2xlYXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6bmF2eSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ow0KY29sb3I6bmF2eSI+SWYgb25lIGNoaXAgY2FuIG5vdCBzdXBwb3J0IGNvbnRyb2wgd29y ZCwgdGhlbiBvbmUgc3dpdGNoIHdoaWNoIHVzZXMgdGhpcyBjaGlwIGNhbiBub3Qgd29yayBhcyBS b290LUxlYWYtTWl4ZWQgUEUgc2luY2Ugd2UgY2FuIG5vdCBleHRlbmQgaXQuIElzIHRoaXMgY29y cmVjdD8gSXMNCiB0aGlzIHJlYXNvbmFibGU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6bmF2eSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6bmF2eSI+QW55d2F5LCBjaGlwIGxpbWl0IGlzIGJpZyBw cm9ibGVtIGZvciBDVyBhcHByb2FjaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjpuYXZ5Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6bmF2eSI+UmVnYXJkcyw8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOm5hdnkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7DQpjb2xvcjpuYXZ5Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOm5hdnkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOm5hdnkiPll1cXVuIChTYW0p IENhbzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6bmF2eSI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29s b3I6bmF2eSI+RS1tYWlsOiA8YSBocmVmPSJtYWlsdG86WXVxdW4uY2FvQGdtYWlsLmNvbSI+DQpZ dXF1bi5jYW9AZ21haWwuY29tPC9hPiA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOm5hdnkiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 DQpjb2xvcjpuYXZ5Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWdu OmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQWxleGFuZGVyIFZh aW5zaHRlaW4gW21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0NCjxicj4N CjxiPlNlbnQ6PC9iPiBTdW5kYXksIEFwcmlsIDIyLCAyMDEyIDk6NTYgUE08YnI+DQo8Yj5Ubzo8 L2I+IFNhbSBDYW88YnI+DQo8Yj5DYzo8L2I+IGwydnBuQGlldGYub3JnOyAnUmF5bW9uZCBLZXkn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRv IHRoZSBFLVRyZWUgc29sdXRpb24/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPlNhbSw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5Zb3XigJl2ZSBhc2tlZDo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjBGMCI+SWYgaXQgb25s eSBzdXBwb3J0cyBWUExTLCBvaywgaXQgY2FuIHdvcmsgYXMgUm9vdC1vbmx5LCBidXQgd2h5IGl0 IGNhbm5vdCB3b3JrIGFzIFJvb3QtTGVhZi1NaXhlZCBvciBMZWFmLW9ubHkgaWYgaXQgY2Fubm90 IHN1cHBvcnQNCiBDVz88bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+SU1ITyBh bmQgRldJVyB0aGVyZSBpcyBub3QgdG9vIG11Y2ggeW91IGNhbiBleHBlY3QgZnJvbSBhIHRydWUg bGVnYWN5IFBFIChpLmUuIGEgUEUgdGhhdCBkaWQgbm90IGNoYW5nZSBpdHMgZm9yd2FyZGluZyBi ZWhhdmlvcik6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6DQox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjEuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkl0IGNhbiBv YnZpb3VzbHkgc3VwcG9ydCBSb290LW9ubHkgZnVuY3Rpb25hbGl0eTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4y NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOg0KMTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4yLjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7DQpjb2xvcjojMUY0OTdEIj5JdCBjYW4gc3VwcG9ydCBMZWFmLW9ubHkgZnVuY3Rpb25h bGl0eSBpZiB0aGVyZSBhcmUgbm8gTWl4ZWQgYnkgcHJldmVudGluZyBzZXR1cCBQVyAoYnkgbm90 IHNldHRpbmcgdXAgUFdzIHRvIG90aGVyIExlYWYtb25seSBQRXMpLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsN CmNvbG9yOiMxRjQ5N0QiPkFueXRoaW5nIGJleW9uZCB0aGF0IHdvdWxkIGJlIHZlcnkgbXVjaCBp bXBsZW1lbnRhdGlvbi1zcGVjaWZpYy4gRS5nLiwgSSBhbSBhd2FyZSBvZiBsZWdhY3kgaW1wbGVt ZW50YXRpb25zIHRoYXQgY291bGQgc3VwcG9ydCBmdW5jdGlvbmFsaXR5IG9mIGEgTWl4ZWQgUEUN CiBwcm92aWRlZCB0aGF0IGl0IHdvdWxkIGJlIHRoZSBvbmx5IE1peGVkIFBFIGluIHRoZSBWUExT IGluc3RhbmNlLCBhbmQgb3RoZXIgbGVnYWN5IGltcGxlbWVudGF0aW9ucyB0aGF0IGFyZSwgYXMg bGVnYWN5LCBmdWxseSBpbnRlcm9wZXJhYmxlIHdpdGggdGhlc2Ugb25lcyBidXQgY291bGQgbm90 IHN1cHBvcnQgc3VjaCBmdW5jdGlvbmFsaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5NeSAyYyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg U2FzaGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1yaWdodDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmdd DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlNhbSBDYW88YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBB cHJpbCAyMiwgMjAxMiA0OjQxIFBNPGJyPg0KPGI+VG86PC9iPiAnUmF5bW9uZCBLZXknPGJyPg0K PGI+Q2M6PC9iPiBsMnZwbkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogVGhlIHN0 YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJheW1vbmQsPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xv cjpuYXZ5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjpuYXZ5Ij5OZXR3b3JrIGVmZmljaWVu Y3k6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6bmF2eSI+W1NhbV0gTGVhZi9Sb290IGNvbmZpZ3VyYXRp b24gaXMgbG9jYWwgY29uZmlndXJhdGlvbiwgYW5kIFBFIGNhbiBub3Qga25vdyByZW1vdGUgQUMg dHlwZSBjb25maWd1cmF0aW9uLiBUaGlzIGlzIENXIEZ1bmRhbWVudGFscy4gU28gZXZlbiBpZiBD VyBhcHByb2FjaCBkZWZpbmVzDQogb3B0aW9uYWwgZW5oYW5jZW1lbnQgZm9yIExlYWYtT25seSBQ RSwgYnV0IGNhbiBub3Qgc2lnbmFsIGl0IGJldHdlZW4gTGVhZi1Pbmx5IFBFcywgc28gdGhlcmUg aXMgbm8gZ29vZCB3YXkgdG8gc3VwcG9ydCB0aGlzLiBUaGUgcG9zc2libGUgc29sdXRpb24gaXMs IG1hbnVhbGx5IGNvbmZpZ3VyZSBodWItc3Bva2UgdG9wb2xvZ3ksIGJ1dCBpZiB3ZSBkbyBsaWtl IHRoaXMsIGN1cnJlbnQgc29sdXRpb25zIGhhdmUgc3VwcG9ydCBtb3N0IEUtVHJlZQ0KIGNhc2Vz IHdpdGggSHViLVNwb2tlIGNvbmZpZ3VyYXRpb24uIExpemhvbmcgbWVudGlvbmVkIHRoaXMgaW4g b25lIG1haWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6bmF2eSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0K Y29sb3I6bmF2eSI+QmFja3dhcmRzIGNvbXBhdGliaWxpdHk6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6 bmF2eSI+W1NhbV0gWWVzLCBuZXcgZHJhZnQgY29uc2lkZXJzIGJhY2t3YXJkIGNvbXBhdGliaWxp dHksIGJ1dCBpdCBtYWtlcyBwcmVjb25kaXRpb246IFRoZSBQRSB3aGljaCBjYW4gbm90IHN1cHBv cnQgQ29udHJvbCB3b3JkIG9ubHkgd29ya3MgYXMgUm9vdC1vbmx5IFBFLiBUaGlzIGRvZXMNCiBu b3QgbWFrZSBzZW5zZSBmb3IgbWUuIElmIGl0IG9ubHkgc3VwcG9ydHMgVlBMUywgb2ssIGl0IGNh biB3b3JrIGFzIFJvb3Qtb25seSwgYnV0IHdoeSBpdCBjYW4gbm90IHdvcmsgYXMgUm9vdC1MZWFm LU1peGVkIG9yIExlYWYtb25seSBpZiBpdCBjYW4gbm90IHN1cHBvcnQgQ1c/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ow0KY29sb3I6bmF2eSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOm5hdnki PlJlZ2FyZHMsPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpuYXZ5Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ow0KY29sb3I6bmF2eSI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpuYXZ5Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtj b2xvcjpuYXZ5Ij5ZdXF1biAoU2FtKSBDYW88L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOm5hdnki PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2NvbG9yOm5hdnkiPkUtbWFpbDogPGEgaHJlZj0ibWFpbHRvOll1 cXVuLmNhb0BnbWFpbC5jb20iPg0KWXVxdW4uY2FvQGdtYWlsLmNvbTwvYT4gPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpuYXZ5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ow0KY29sb3I6bmF2eSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2Vu dGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAl IiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IHJheW1vbmQua2V5QGhvdG1haWwuY29tIFttYWlsdG86cmF5bW9uZC5rZXlAaG90 bWFpbC5jb21dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJheW1vbmQgS2V5PGJyPg0KPGI+U2VudDo8 L2I+IFNhdHVyZGF5LCBBcHJpbCAyMSwgMjAxMiAxMTozMiBQTTxicj4NCjxiPlRvOjwvYj4geXVx dW4uY2FvQGdtYWlsLmNvbTxicj4NCjxiPkNjOjwvYj4gbDJ2cG5AaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJl ZSBzb2x1dGlvbj88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+U29tZSBjbGFyaWZpY2F0aW9uczxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzwv c3Bhbj5bUktdIGluc2VydGVkIGJlbG93PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJheW1vbmQgS2V5PGVtPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtNUyBQR290aGljJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L2VtPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3 aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+RnJvbTogeXVxdW4uY2FvQGdtYWlsLmNvbTxi cj4NClRvOiBsaXpoby5qaW5AZ21haWwuY29tOyB3aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1Y2Vu dC5jb208YnI+DQpTdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0 aGUgRS1UcmVlIHNvbHV0aW9uPzxicj4NCkRhdGU6IFNhdCwgMjEgQXByIDIwMTIgMjI6NTE6Mjgg JiM0MzswODAwPGJyPg0KQ0M6IGwydnBuQGlldGYub3JnPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9ImVjeG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSBhbGws PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImVjeG1zb25vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i ZWN4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldlIHJlYWNoIGFuIGltcGFz c2U8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpXaW5nZGlu Z3MiPko8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4uICZuYnNwO0JUVywgTWVldGlu ZyBtaW51dGVzDQogaXMgcmVhZHkgbm93LiBXZSBjYW4gZ2V0IEUtdHJlZSBzdW1tYXJ5IGZyb20g SUVURiBzaXRlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJlY3htc29ub3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9ImVjeG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Ub2RheSBJ IGNvbGxlY3RlZCBhbGwgaXRlbXMgd2UgZGlzY3Vzc2VkIGJlZm9yZS4gVGhleSBhcmUsPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImVjeG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZWN4bXNv bm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW47dGV4dC1pbmRlbnQ6LS4yNWluIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjEpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPlNpbGljb24gaXNzdWUgb3IgY2hpcCBsaW1pdDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iZWN4bXNvbm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjI1aW47dGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjIpPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk5ldHdvcmsg ZWZmaWNpZW5jeTs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZWN4bXNvbm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW47dGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjMpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkVuY2Fwc3VsYXRpb24gbW9kZSwgdGFnIG9yIHJhdzs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iZWN4bXNvbm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1 aW47dGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjQpPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkgtVlBMUzs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZWN4bXNvbm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjI1aW47dGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjUpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkJh Y2t3YXJkcyBjb21wYXRpYmlsaXR5LCBlc3BlY2lhbGx5IGxlZ2FjeSBQRSBvciBOb24tc3VwcG9y dGluZyBQRSB3aXRoIElFRUUgRS10cmVlIHN1cHBvcnQgam9pbnMgRS1UcmVlIGRvbWFpbjs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZWN4bXNvbm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjI1aW47dGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjYpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNv bmZpZ3VyYXRpb24gY2hhbmdlIGluIG9wZXJhdGlvbiwgZm9yIGV4YW1wbGUsIExlYWYtb25seSAt Jmd0OyBSb290LUxlYWYtTWl4ZWQ7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImVj eG1zb25vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi4yNWluO3RleHQtaW5kZW50Oi0uMjVpbiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij43KTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TLVZMQU4gcHJlc2VydmF0aW9uIHN1cHBvcnQ7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImVjeG1zb25vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi4yNWluO3RleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij44 KTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5NdWx0 aS1zZWdtZW50IFBXOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJlY3htc29ub3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouMjVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+OSk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+VkxBTiBJRCBhbGxvY2F0aW9uIChPbmx5IGZvciBEdWFsLVZMQU4pOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJlY3htc29ub3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouMjVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+MTApPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsN Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk11bHRpLUFTIGRlcGxveW1lbnQ7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImVjeG1zb25vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi4yNWluO3RleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4xMSk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOw0K PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RUNNUDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iZWN4bXNvbm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW47dGV4 dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjEyKTwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5QMk1QLVBXOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJlY3htc29ub3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouMjVpbjt0ZXh0LWluZGVudDotLjI1 aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+MTMpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkV0aGVybmV0IE9BTTs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZWN4bXNv bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjpuYXZ5Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZWN4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7DQpjb2xvcjpuYXZ5Ij5JZiB3ZSByZXZpZXcgdGhlIG1haWwtbGlzdCwgQ1cg YXBwcm9hY2ggaGFzIHRoZSBmb2xsb3dpbmcgbGltaXRzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJlY3htc29ub3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouMjVpbjt0ZXh0LWlu ZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij4xKTwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 DQpjb2xvcjpuYXZ5Ij5DaGlwIGxpbWl0LiBQbGVhc2UgcmVhZCByZXBseSBmcm9tIEdpbGVzIGFu ZCBXaW07PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImVjeG1zb25vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi4yNWluO3RleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOm5hdnkiPjIpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOm5hdnkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOm5hdnkiPk5ldHdvcmsgZWZmaWNp ZW5jeTogVGhlcmUgYXJlIGdhcmJhZ2UgZmFtZXMgd2hpY2ggd2lsbCBiZSBkcm9wcGVkIG9uIGVn cmVzcyBQRSBzaW5jZSBvbmx5IGVncmVzcyBQRSBjYW4gZGVjaWRlIGZvcndhcmQgb3IgZHJvcCBm cmFtZXMgd2hpbGUgaXQgcmVjZWl2ZXMgZnJhbWVzLiBJbmdyZXNzIFBFIGNhbg0KIG5vdCBkZWNp ZGUgZm9yd2FyZCBvciBub3QuIFllcywgY3VycmVudCBzb2x1dGlvbiBjYW4gc3VwcG9ydCBIdWIt U3Bva2UgY29uZmlndXJhdGlvbiwgYnV0IGFzIHdlIGtub3csIHRoZSBjb25maWd1cmF0aW9uIGlz IG5vdCBlYXN5IGlmIHRoZSBuZXR3b3JrIGlzIGJpZy4gRHVhbC1WTEFOIG9yIE11bHRpLVBXIGFw cHJvYWNoIGNhbiBicmVhayBjb21tdW5pY2F0aW9uIGJldHdlZW4gTGVhZi1Pbmx5IFBFcyB2aWEg c2lnbmFsaW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJlY3htc29ub3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouMjVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOm5hdnkiPltSS10gSXQgc2VlbXMgdG8gbWUgdGhpcyBpcyBub3QgdGhlIGNhc2UuIFNlY3Rp b24gNiBvZiB0aGUgZHJhZnQgaGFzIHNvbWUgZGlzY3Vzc2lvbnMgb24gdGhpcy48YnI+DQo8YSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rZXktbDJ2cG4tdnBscy1ldHJl ZS0wNyNzZWN0aW9uLTYiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWtleS1sMnZw bi12cGxzLWV0cmVlLTA3I3NlY3Rpb24tNjwvYT48YnI+DQo2LiBPcHRpb25hbCBFbmhhbmNlbWVu dHMgZm9yIExlYWYtb25seSBQRTxicj4NCjYuMS4gTm8gUFcgYmV0d2VlbiBMZWFmLW9ubHkgUEVz PGJyPg0KNi4yLiBOb3QgRm9yd2FyZCBGcmFtZSBmcm9tIExlYWYgQUMgdG8gTGVhZi1vbmx5IFBF PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImVjeG1zb25vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi4yNWluO3RleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImVjeG1zb25vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi4yNWluO3RleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOm5hdnkiPjMpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv bG9yOm5hdnkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOm5hdnkiPkJhY2t3YXJkcyBjb21wYXRpYmls aXR5OiBOb3QgYWxsIFBFcyBzdXBwb3J0cyBjb250cm9sIHdvcmQuIElmIG9uZSBjYW4gbm90IHN1 cHBvcnQgY29udHJvbCB3b3JkLCBpdCB3aWxsIG5vdCBqb2luIEUtVHJlZSBkb21haW47PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImVjeG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImVjeG1zb25vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6bmF2eSI+W1JLXSBJdCBzZWVtcyB0byBtZSB0aGlzIGlzIG5vdCB0aGUgY2Fz ZS4gU2VjdGlvbiA1IG9mIHRoZSBkcmFmdCBoYXMgc29tZSBkaXNjdXNzaW9ucyBvbiB0aGlzLjxi cj4NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWtleS1sMnZwbi12 cGxzLWV0cmVlLTA3I3NlY3Rpb24tNSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt a2V5LWwydnBuLXZwbHMtZXRyZWUtMDcjc2VjdGlvbi01PC9hPjxicj4NCjUuIEJhY2t3YXJkIENv bXBhdGliaWxpdHk8YnI+DQo1LjEuIEFDIFR5cGU8YnI+DQo1LjIuIENvbnRyb2wgV29yZDxicj4N CjUuMy4gQWRkaXRpb25hbCBBY3Rpb24gaW4gRGF0YSBGb3J3YXJkaW5nPGJyPg0KNS4zLjEuIElu Z3Jlc3MgUEUgU3VwcG9ydGluZyB0aGUgRXh0ZW5zaW9uIGJ1dCBFZ3Jlc3MgUEUgTm90PGJyPg0K NS4zLjIuIEVncmVzcyBQRSBTdXBwb3J0aW5nIHRoZSBFeHRlbnNpb24gYnV0IEluZ3Jlc3MgUEUg Tm90PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImVjeG1zb25vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6bmF2eSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9ImVjeG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0K Y29sb3I6bmF2eSI+RHVhbCBWTEFOIGhhcyBmb2xsb3dpbmcgbGltaXRzOjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJlY3htc29ub3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouMjVp bjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpuYXZ5 Ij4xKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjpuYXZ5Ij5DaGlwIGxpbWl0OiBBcyB3ZSBrbm93LCB3ZSBuZWVkIHRv IHB1c2ggb25lIFZMQU4gaW50byBmcmFtZXMgYmVmb3JlIE1QTFMgZW5jYXBzdWxhdGlvbiBvbiBp bmdyZXNzIFBFIGFuZCBzdHJpcGUgaXQgb3V0IG9uIGVncmVzcyBQRS4gVGhpcyBpcyBub24tc3Rh bmRhcmQgb3BlcmF0aW9uLiBXYWl0IGZvcg0KIGNvbmZpcm1hdGlvbiBmcm9tIGNoaXAgdmVuZG9y Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJlY3htc29ub3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouMjVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpuYXZ5Ij4yKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjpuYXZ5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjpuYXZ5Ij5IVlBMUzogSWYgd2UgZm9sbG93 IEZpZyAzIG9yIEZpZyA0IGluIFJGQyA0NzYyIHRvIGRlcGxveSBIVlBMUywgUEUtcnMgd29ya3Mg aW4gZGlmZmVyZW50IG1hbm5lciwgUEUtcnMgc2hvdWxkIGZpZ3VyZSBvdXQgQUMgdHlwZSBpbiBW UFdTIGNhc2UsIGJ1dCBjYW4gTk9UIGNvbmZpZ3VyZSBpdCBhdCBhbGwNCiBpbiBTcG9rZSBQVyBj YXNlOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJlY3htc29ub3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouMjVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpuYXZ5Ij4zKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjpuYXZ5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjpuYXZ5Ij5NdWx0aS1QVzogUmFmaSBm aWd1cmVzIHRoaXMgb3V0LCBidXQgd2UgZG9u4oCZdCB0aGluayB0aGlzIG92ZXIgYXQgdGhhdCB0 aW1lLiBJIHRoaW5rIHRoYXQgaXQgYWxzbyBoYXMgc2FtZSBwcm9ibGVtIGFzIEgtVlBMUyBoYXMu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImVjeG1zb25vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi4yNWluO3RleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOm5hdnkiPjQpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv bG9yOm5hdnkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOm5hdnkiPkVuY2Fwc3VsYXRpb24gbW9kZTog SWYgZGVwbG95IEdWUExTIHdpdGggU3Bva2UgUFcgbW9kZSwgUEUtcnMgc2hvdWxkIHdvcmsgaW4g dGFnZ2VkIG1vZGUsIG90aGVyd2lzZSBQRS1ycyBvciBlZ3Jlc3MgUEUgd2lsbCBzdHJpcGUgUy1W TEFOIElEOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJlY3htc29ub3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouMjVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij41KTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjpuYXZ5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjpuYXZ5Ij5CYWNrd2FyZCBDb21w YXRpYmlsaXR5OiBKdXN0IGFzIERhbmllbCBtZW50aW9uZWQsIHRoZXJlIGlzIGNvbXBhdGliaWxp dHkgaXNzdWUgaWYgbGVnYWN5IFBFIGpvaW5zIEUtVHJlZSBkb21haW4uIEZvciBtZSwgSSBkb27i gJl0IGdldCBjbGVhciByZXNwb25zZSBmcm9tIGNvLWF1dGhvcnMgb2YgRHVhbC1WTEFOLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJlY3htc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OzsNCmNvbG9yOm5hdnkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJlY3htc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOm5h dnkiPkZvciBhbGwgYXBwcm9hY2hlcywgd2UgZG9u4oCZdCBjb3ZlciBFQ01QIC8gRXRoZXJuZXQg T0FNIHRpbGwgbm93Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImVjeG1zb25v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6bmF2eSI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImVjeG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ow0KY29sb3I6bmF2eSI+SXMgdGhlcmUgYW55dGhpbmcgbWlzc2VkPw0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImVjeG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ow0KY29sb3I6bmF2eSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJlY3htc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjpuYXZ5Ij5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJlY3htc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7DQpjb2xvcjpuYXZ5 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZWN4bXNvbm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6bmF2 eSI+WXVxdW4gKFNhbSkgQ2FvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImVjeG1z b25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2T O2NvbG9yOm5hdnkiPkUtbWFpbDoNCjxhIGhyZWY9Im1haWx0bzpZdXF1bi5jYW9AZ21haWwuY29t Ij5ZdXF1bi5jYW9AZ21haWwuY29tPC9hPiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iZWN4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ow0KY29sb3I6bmF2eSI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTrlrovkvZMiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVy Ij4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJlY3htc29ub3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBMaXpob25nIEppbiBbbWFpbHRvOmxpemhvLmppbkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gU2F0dXJkYXksIEFwcmlsIDIxLCAyMDEyIDExOjU5IEFNPGJyPg0KPGI+VG86PC9i PiBIZW5kZXJpY2t4LCBXaW0gKFdpbSk8YnI+DQo8Yj5DYzo8L2I+IGwydnBuQGlldGYub3JnOyBB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTsgeXVxdW4uY2FvQGdtYWlsLmNvbTxicj4N CjxiPlN1YmplY3Q6PC9iPiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUg RS1UcmVlIHNvbHV0aW9uPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 ImVjeG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9ImVjeG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OuWui+S9 kyI+SGkgV2luLDxicj4NClRoYW5rIHlvdSBmb3IgdGhlIGFuc3dlcnMuIEluIHRoYXQgY2FzZSwg UEUtcnMgc2hvdWxkIGNvbmZpZ3VyZSB0aGUgcm9vdC9sZWFmIHByb3BlcnRpZXMgb2YgVlBXUywg bm90IG9uIHRoZSByZW1vdGUgUEUgb2YgVlBXUy4gQW5kIHVzdWFsbHkgb24gUEUtcnMsIHlvdSBj b3VsZCBub3QgZmlndXJlIG91dCB0aGUgYWNjZXNzaW5nIHNwb2tlIFBXIGlzIGZyb20gUEUtciBv ZiBWUFdTIG9yIE1UVS1zLiBVbmxlc3MgaGF2aW5nIHNvbWUgYWRkaXRpb25hbA0KIGluZGljYXRp b24gaW4gTk1TLCB5b3UgZXZlbiBkb24ndCBrbm93IHdoaWNoIHNwb2tlIFBXIG5lZWRzIHRvIGRv IFZMQU4gbWFuaXB1bGF0aW9uLiBJIGFtIG5vdCBzdXJlIHN1Y2ggUi9MIGNvbmZpZ3VyYXRpb24g Y291bGQgYmUgYWNjZXB0ZWQgZnJvbSBvcGVyYXRpb25hbCB2aWV3LiBIb3BlIHRvIHNlZSBtb3Jl IGNvbW1lbnRzLjxicj4NCjxicj4NClJlZ2FyZHM8YnI+DQpMaXpob25nPGJyPg0KPGJyPg0KPGJy Pg0KPC9zcGFuPjxzcGFuIGxhbmc9IkpBIj7lnKg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OuWui+S9kyI+IDIwMTI8L3NwYW4+PHNwYW4gbGFuZz0iSkEiPuW5tDwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk65a6L5L2TIj40PC9zcGFuPjxzcGFuIGxhbmc9IkpBIj7mnIg8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OuWui+S9kyI+MjE8L3NwYW4+PHNwYW4gbGFuZz0i SkEiPuaXpeaYn+acn+WFre+8jDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2T Ij5IZW5kZXJpY2t4LA0KIFdpbSAoV2ltKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOndpbS5oZW5kZXJp Y2t4QGFsY2F0ZWwtbHVjZW50LmNvbSI+d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29t PC9hPiZndDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJKQSI+5YaZ6YGT77yaPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTrlrovkvZMiPjxicj4NCiZndDsgVGhlIFZQV1Mgd2hpY2ggdGVybWlu YXRlcyBhdCB0aGUgSC1WUExTIG5vZGUgaXMgaW5kaWNhdGVkIHRvIGJlIHJvb3Qgb3IgbGVhZiBh bmQgdGhlIHByb2NlZHVyZXMgYXNzb2NpYXRlZCB3aWxsIGRvIHRoZSBWTEFOIG1hbmlwdWxhdGlv bjxicj4NCiZndDs8YnI+DQomZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OuWui+S9kyI+PGJyPg0KJmd0Ozxicj4NCiZndDsgRnJv bTogPGEgaHJlZj0ibWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmciPmwydnBuLWJvdW5jZXNA aWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5v cmciPmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTGl6aG9uZyBKaW48 YnI+DQomZ3Q7IFNlbnQ6IHZyaWpkYWcgMjAgYXByaWwgMjAxMiAxODozODxicj4NCiZndDsgVG86 IDxhIGhyZWY9Im1haWx0bzpsMnZwbkBpZXRmLm9yZyI+bDJ2cG5AaWV0Zi5vcmc8L2E+OyA8YSBo cmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20iPg0KQWxleGFuZGVy LlZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+PGJyPg0KJmd0OyBDYzogPGEgaHJlZj0ibWFpbHRv Onl1cXVuLmNhb0BnbWFpbC5jb20iPnl1cXVuLmNhb0BnbWFpbC5jb208L2E+PGJyPg0KJmd0OyBT dWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNv bHV0aW9uPzxicj4NCiZndDs8YnI+DQomZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OuWui+S9kyI+PGJyPg0KJmd0Ozxicj4NCiZn dDsgSGksIGFsbCw8YnI+DQomZ3Q7IFRoZSBkaWZmZXJlbmNlIGJldHdlZW4gMi1WTEFOIGFuZCBD VyBhcHByb2FjaCBpcyB3aG8gd2lsbCBwcm92aWRlIHRoZSBSL0wgaW5mb3JtYXRpb24sIGN1c3Rv bWVyIHBheWxvYWQgb3IgUFc/IFRoZSBjdXN0b21lciBwYXlsb2FkIHdpbGwgYmUgYWx3YXlzIG1v ZGlmaWVkIHRvIGNhcnJ5IFIvTCBpbmZvcm1hdGlvbiBpbiAyLVZMQU4gYXBwcm9hY2gsIHdoaWxl IFBXIHdpdGggQ1cgd2lsbCBjYXJyeSBSL0wgaW5mb3JtYXRpb24gZm9yIENXIGFwcHJvYWNoLjxi cj4NCiZndDsgSSBoYXZlIGEgcXVlc3Rpb24gd2l0aCB0aGUgMi1WTEFOIGFwcHJvYWNoIGluIEgt VlBMUyB3aGVyZSBILVZQTFMgaXMgYWNjZXNzZWQgYnkgVlBXUyBhcyBkZXNjcmliZWQgaW4gUkZD NDY3MiBzZWN0aW9uIDEwLjEuMy4gSWYgVlBXUyBpcyB1c2VkIHRvIGFjY2VzcyBILVZQTFMsIGhv dyBjb3VsZCB0aGUgUEUgb24gVlBXUyBzaWRlIGFkZHMgVkxBTiB0byBpbmRpY2F0ZSBSL0wgaW5m b3JtYXRpb24/PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzPGJyPg0KJmd0OyBMaXpob25nPGJy Pg0KJmd0Ozxicj4NCiZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgTWVzc2FnZTogMjxicj4NCiZndDsmZ3Q7IERhdGU6IFRo dSwgMTkgQXByIDIwMTIgMDQ6Mzg6MzYgJiM0MzswMDAwPGJyPg0KJmd0OyZndDsgRnJvbTogQWxl eGFuZGVyIFZhaW5zaHRlaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbSI+QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+Jmd0Ozxi cj4NCiZndDsmZ3Q7IFRvOiAmcXVvdDtSb2dlcnMsIEpvc2gmcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbSI+am9zaC5yb2dlcnNAdHdjYWJsZS5jb208L2E+ Jmd0OywgTHVjeSB5b25nPGJyPg0KJmd0OyZndDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TIj4NCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OuWui+S9kyI+DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTrlrovkvZMiPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk65a6L5L2TIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmx1Y3kueW9uZ0BodWF3 ZWkuY29tIj5sdWN5LnlvbmdAaHVhd2VpLmNvbTwvYT4mZ3Q7LCBEYW5pZWwgQ29obiAmbHQ7PGEg aHJlZj0ibWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbSI+RGFuaWVsQ0BvcmNraXQuY29tPC9hPiZn dDssIFNhbSBDYW88YnI+DQomZ3Q7Jmd0OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZMiPg0KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TIj4NCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OuWu i+S9kyI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTrlrovkvZMiPiZsdDs8YSBocmVmPSJtYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNv bSI+eXVxdW4uY2FvQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgQ2M6ICZxdW90Ozxh IGhyZWY9Im1haWx0bzpsMnZwbkBpZXRmLm9yZyI+bDJ2cG5AaWV0Zi5vcmc8L2E+JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86bDJ2cG5AaWV0Zi5vcmciPmwydnBuQGlldGYub3JnPC9hPiZndDs8 YnI+DQomZ3Q7Jmd0OyBTdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0 byB0aGUgRS1UcmVlIHNvbHV0aW9uPzxicj4NCiZndDsmZ3Q7IE1lc3NhZ2UtSUQ6PGJyPg0KJmd0 OyZndDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk65a6L5L2TIj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OuWui+S9kyI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZMiPg0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TIj4m bHQ7PGEgaHJlZj0ibWFpbHRvOkY5MzM2NTcxNzMxQURFNDJBNTM5N0ZDODMxQ0VBQTAyMDM0MTky QEZSSURXUFBNQjAwMi5lY2l0ZWxlLmNvbSI+RjkzMzY1NzE3MzFBREU0MkE1Mzk3RkM4MzFDRUFB MDIwMzQxOTJARlJJRFdQUE1CMDAyLmVjaXRlbGUuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyBD b250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9JnF1b3Q7dXMtYXNjaWkmcXVvdDs8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7Jmd0OyBJIGZ1bGx5IHVu ZGVyc3RhbmQgdGhhdCB0aGF0IHdoYXQgSSBhbSBnb2luZyB0byBzYXkgaXMgbm90IHZlcnkgcG9w dWxhciwgYnV0Ojxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSU1PIG9uZSBvZiB0aGUgYWR2 YW50YWdlcyBvZiB0aGUgQ1ctYmFzZWQgc29sdXRpb24gaXMgdGhhdCBpdCBpcyBvcnRob2dvbmFs IHRvIHVzYWdlIChvciBub24tdXNhZ2UpIG9mIFAyTVAgUFdzIGZvciBlZmZlY3RpdmUgZGVsaXZl cnkgb2YgQlVOIHRyYWZmaWMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBBbm90aGVyIGFk dmFudGFnZSBpcyBwcmVzZXJ2YXRpb24gb2YgZnVsbCBtZXNoIG9mIFAyUCBQV3MgaW4gYSBWUExT LCBhbmQsIGluIGEgbW9yZSBnZW5lcmljIHdheSwgbG9jYWxpemF0aW9uIG9mIGVmZmVjdHMgb2Yg Y2hhbmdlcyBpbiB0aGUgUEUgY29uZmlndXJhdGlvbi48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7IEluIHBhcnRpY3VsYXIsIGFkZGluZyBhIExlYWYgQUMgdG8gYSBQRSB0aGF0IHByZXZpb3Vz bHkgaGFzIGJlZW4gb25seSBzdXBwb3J0aW5nIFJvb3QgQUNzIChvciB2aWNlIHZlcnNhKSwgcmVt b3ZhbCBvZiB0aGUgbGFzdCBMZWFmIG9yIGxhc3QgUm9vdCBBQyBmcm9tIGEgUEUgdGhhdCBwcmV2 aW91c2x5IGhhcyBiZWVuIHN1cHBvcnRpbmcgYSBtaXggZXRjLiBhZmZlY3Qgb25seSB0aGUgUEUg d2hlcmUgdGhpcyBvcGVyYXRpb24gaGFwcGVucyBhbmQNCiBub3QgdGhlIHJlc3Qgb2YgdGhlIFBF cy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEFzIGZvciB0aGUgbmVlZCBmb3IgSFcgY2hh bmdlcyB0aGF0IGhhdmUgYmVlbiBtZW50aW9uZWQgYXMgYSBtYWluIGRpc2FkdmFudGFnZSBvZiB0 aGUgQ1ctYmFzZWQgYXBwcm9hY2ggLSBJIGJlbGlldmUgaXQgc3Ryb25nbHkgZGVwZW5kcyBvbiBz cGVjaWZpYyBpbXBsZW1lbnRhdGlvbnMuIEFuZCBzb21lIGNoYW5nZXMgaW4gdGhlIGZvcndhcmRp bmcgcHJvY2VzcyBhcmUgcmVxdWlyZWQgaW4gYW55IHNvbHV0aW9uLjxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgTXkgMmMsPGJyPg0KJmd0OyZndDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TIj4NCjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OuWui+S9kyI+ IFNhc2hhPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsm Z3Q7IEZyb206IDxhIGhyZWY9Im1haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnIj5sMnZwbi1i b3VuY2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5v cmciPmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBvbiBiZWhhbGYgb2YgUm9nZXJzLCBKb3No IFs8YSBocmVmPSJtYWlsdG86am9zaC5yb2dlcnNAdHdjYWJsZS5jb20iPmpvc2gucm9nZXJzQHR3 Y2FibGUuY29tPC9hPl08YnI+DQomZ3Q7Jmd0OyBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDE4LCAy MDEyIDk6NTcgUE08YnI+DQomZ3Q7Jmd0OyBUbzogTHVjeSB5b25nOyBEYW5pZWwgQ29objsgU2Ft IENhbzxicj4NCiZndDsmZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86bDJ2cG5AaWV0Zi5vcmciPmwy dnBuQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBUaGUgc3RhdHVzIG9m IHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyBBZ2FpbiwgdGhlIFAyTVAgc2l0dWF0aW9uIHRocm93cyBtZS4gPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseToNCiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrlrovk vZMiPklzIHRoaXMgc29tZXRoaW5nIHRoYXQgaXMgdXNlZDxicj4NCiZndDsmZ3Q7IGNvbW1vbmx5 Pzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSdtIHVuZGVyIHRoZSBpbXByZXNzaW9uIHRo YXQgYWRkaW5nIFAyTVAgdG8gYW55IG1vZGVsIHJlc3VsdHMgaW4gYSBtb3JlPGJyPg0KJmd0OyZn dDsgY29tcGxleCBtb2RlbC4gPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TIj5XZXRoZXIgb3V0c2lkZSBzLXRhZyBpcyB1c2Vk IHRvIGRpZmZlcmVudGlhdGUsIG9yPGJyPg0KJmd0OyZndDsgZGVkaWNhdGVkIHB3J3MgYXJlIHVz ZWQgZm9yIHRoZSBzYW1lIHB1cnBvc2UsIGl0IHNlZW1zIGJvdGggYmVjb21lIG1vcmU8YnI+DQom Z3Q7Jmd0OyBjb21wbGV4Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgR2lsZSdzIGNvbXBh cmlzb24gc2xpZGUgc3RpbGwgY29uY2lzZWx5IGNhcHR1cmVzIHRoZSBkaWZmZXJlbmNlcyBiZXR3 ZWVuPGJyPg0KJmd0OyZndDsgdGhlc2UgbWV0aG9kcywgaW4gbXkgb3Bpbmlvbi4gPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2T Ij5JIGhhdmVuJ3Qgc2VlbiBhbnkgbmV3IGlkZWFzIG9yIHRob3VnaHRzPGJyPg0KJmd0OyZndDsg YnJvdWdodCB0byB0aGUgZ3JvdXAgaW4gdGhlIHBhc3Qgd2VlayBvciB0d28gb24gdGhlIHN1Ympl Y3QuIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OuWui+S9kyI+SSB3b3VsZCBoYXRlPGJyPg0KJmd0OyZndDsgZm9yIGJvdGggcHJvcG9z ZWQgbWV0aG9kcyB0byBkaWUgb24gdGhlIHZpbmUgYmVjYXVzZSB3ZSBjb3VsZG4ndCBkZWNpZGU8 YnI+DQomZ3Q7Jmd0OyBiZXR3ZWVuIHR3byBtZXRob2RzIHRoYXQgaGF2ZSBub3RoaW5nIGluaGVy ZW50bHkgd3Jvbmcgd2l0aCBlaXRoZXIuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAtSm9z aDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBPbiA0LzE4LzEyIDE6 NTMgUE0sICZxdW90O0x1Y3kgeW9uZyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmx1Y3kueW9u Z0BodWF3ZWkuY29tIj5sdWN5LnlvbmdAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7U2VuZCB0aGlzIGFnYWluLjxicj4NCiZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0O1R3byBQVyBhcHByb2FjaCBjYW4gYmUgY29tcGxleCB0b28gaWYg dGhlIFZQTFMgaW5zdGFuY2UgZm9yIEUtVHJlZSB1c2VzPGJyPg0KJmd0OyZndDsmZ3Q7UDJQIFBX IGZvIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cD5UaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVj aXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElB TCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBi eSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlDQogdGhlIG9yaWdpbmFsIGFu ZCBhbGwgY29waWVzIHRoZXJlb2YuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cD5UaGlzIGUt bWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRh aW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHBy b3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5z bWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZh eCwgYW5kIHRoZW4gZGVsZXRlDQogdGhlIG9yaWdpbmFsIGFuZCBhbGwgY29waWVzIHRoZXJlb2Yu IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B17A6910EEDD1F45980687268941550FACAFF4MISOUT7MSGUSR9IIT_-- From lucy.yong@huawei.com Mon Apr 23 08:53:32 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CD721F875E for ; Mon, 23 Apr 2012 08:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=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 GL-PrV42yUJi for ; Mon, 23 Apr 2012 08:53:27 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 80D8221F875B for ; Mon, 23 Apr 2012 08:53:17 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFD59006; Mon, 23 Apr 2012 11:53:17 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Apr 2012 08:51:10 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Mon, 23 Apr 2012 08:51:11 -0700 From: Lucy yong To: Daniel Cohn , "Rogers, Josh" , Shahram Davari , Lizhong Jin , "l2vpn@ietf.org" , "Alexander.Vainshtein@ecitele.com" Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEA= Date: Mon, 23 Apr 2012 15:51:10 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264B32D@dfweml505-mbx> References: <4A6CE49E6084B141B15C0713B8993F28021737@SJEXCHMB12.corp.ad.broadcom.com> <44F4E579A764584EA9BDFD07D0CA08130777C3C1@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130777C3C1@tlvmail1> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.147.30] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D3264B32Ddfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "yuqun.cao@gmail.com" X-BeenThere: l2vpn@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, 23 Apr 2012 15:53:32 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D3264B32Ddfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Daniel, MEF has worked in ENNI interface for a long time with many service provider= s' inputs. It had a fair reason to assume S-VLAN over ENNI by then. It may = open B-VLAN for the future. It is better for us not to discuss a future fr= amework here, because it will lead us to nowhere. Here, we want to extend V= PLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Va= inshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume tha= t the VLAN tags at the E-NNI will always be according to the current MEF mo= del? Or should we try to be as transparent as possible to user VLAN encapsu= lation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case VLAN t= ag) to signal VPLS information (in this case root/leaf origin) is necessari= ly tied to specific assumptions on user payload encapsulation (in this case= , that S-VLAN tag is "available" to encode root/leaf). I don't think this i= s a future-proof assumption, it's very likely that other network models wil= l come up that require S-VLAN preservation, which in the 2-VLAN approach wo= uld necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, "l2vpn@i= etf.org" >, "A= lexander.Vainshtein@ecitele.com" <= Alexander.Vainshtein@ecitele.com> Cc: "yuqun.cao@gmail.com" > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic alrea= dy has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com= Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L i= nformation, customer payload or PW? The customer payload will be always mod= ified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is access= ed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informati= on? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > > To: "Rogers, Josh" >, Lucy yong > >, Daniel Cohn <= DanielC@orckit.com>, Sam Cao > > > Cc: "l2vpn@ietf.org" > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, = but: > > IMO one of the advantages of the CW-based solution is that it is orthogon= al to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffi= c. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and,= in a more generic way, localization of effects of changes in the PE config= uration. > > In particular, adding a Leaf AC to a PE that previously has been only sup= porting Root ACs (or vice versa), removal of the last Leaf or last Root AC = from a PE that previously has been supporting a mix etc. affect only the PE= where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadva= ntage of the CW-based approach - I believe it strongly depends on specific = implementations. And some changes in the forwarding process are required in= any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounce= s@ietf.org] on behalf of Rogers, Josh [josh.= rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a more > complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become more > complex. > > Gile's comparison slide still concisely captures the differences between > these methods, in my opinion. I haven't seen any new ideas or thoughts > brought to the group in the past week or two on the subject. I would hat= e > for both proposed methods to die on the vine because we couldn't decide > between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may double >>all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the processing >>in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >>traffic coming from a root AC) >>[[LY]] Not that simple. You construct either two P2MP PWs to all other >>PEs and let egress PE performing filtering, or construct one P2MP PW to >>leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >>perform forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so don't >>feel terribly strong about this objection. Is this a real problem for >>others (now or in the future), or is this objection in the weeds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. I >>encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>>giles.heron@gmail.com; simon.delord@gmail.= com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com<= mailto:Vladimir.Kleiner@ecitele.com>; >>>Andrew.Sergeev@ecitele.com; Idan.Kasp= it@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Coh= en@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs after >>>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>>P2MP >>>PWs if need. There is no difference between P2MP or normal PW setup. But= , >>>can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>>both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; Alexander.Vainsht= ein@ecitele.com; Sam Cao >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com<= mailto:Vladimir.Kleiner@ecitele.com>; >>>Andrew.Sergeev@ecitele.com; Idan.Kasp= it@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Coh= en@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong [mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; simon.delord@gmail.= com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com<= mailto:Vladimir.Kleiner@ecitele.com>; >>>Andrew.Sergeev@ecitele.com; Idan.Kasp= it@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Coh= en@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, both >>>approaches can benefit from it. I was off for a while and captures some >>>discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues with >>>silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>>not clear on all the issues. Could you be more specific? As I mentioned >>>in below, two PW approach makes VPLS transport construction and packet >>>forwarding more complex, I can see potential backward compatibility >>>issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>>traffic, and some P2MP PWs for multicast traffic. It may double all of >>>them. >>> >>>E-tree is an Ethernet service and there is already VLAN based solution >>>in IEEE, can we just utilize it without complicating VPLS transport >>>construction? This also makes interworking with Eth only network easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vain= shtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.c= om'; >>>'Andrew.Sergeev@ecitele.com'; 'Idan.K= aspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are you >>>saying that you no longer are interested in that method in preference of >>>the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org [mailto:l2vp= n-bounces@ietf.org] On Behalf >>>Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; 'simon.delord= @gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.c= om'; >>>'Andrew.Sergeev@ecitele.com'; 'Idan.K= aspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron [mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord >= ; Alexander Vainshtein >>>> >>>Cc: l2vpn@ietf.org >; Vladimir Kleiner >>>>; And= rew Sergeev >>>>; Idan Ka= spit >; >>>Mishael Wexler >; Rotem Cohen >>>> >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly have >>>put in a third column on the CW approach. And hopefully the minutes >>>will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to be >>>forming around the two alternatives of two PWEs or two VLANs. I believe >>>three of the authors of the CW approach are also authors of the two VLAN >>>approach and one is also an author of the two PWE approach. So perhaps >>>it's best to let those four individuals say which approach they prefer >>>and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of various >>>> solution drafts off the mailing list. As far as I know, no consensus >>>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>>> think the CW approach has not been rejected by the WG yet, or the WG >>>> has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein > >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree approaches >>>>> based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in the >>>>> PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>>> wonder whether the WG has taken a decision to reject the approach >>>>> based on the CW usage? I do not remember any recent discussion of >>>>> this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and contains >>>>> information which is CONFIDENTIAL and which may be proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original and >>>>> all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action taken >>>in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use of the individual or entity to which it is addressed. If you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** --_000_2691CE0099834E4A9C5044EEC662BB9D3264B32Ddfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Daniel,=

 <= /p>

MEF has worked in ENNI in= terface for a long time with many service providers’ inputs. It had a= fair reason to assume S-VLAN over ENNI by then. It may open B-VLAN for the future. It is better for us not to discuss  a future framewor= k here, because it will lead us to nowhere. Here, we want to extend VPLS in= supporting E-Tree.

 <= /p>

Best Regards,<= /span>

Lucy

 <= /p>

From: l2vpn-bo= unces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn
Sent: Sunday, April 22, 2012 7:34 AM
To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexa= nder.Vainshtein@ecitele.com
Cc: yuqun.cao@gmail.com
Subject: RE: The status of the approaches to the E-Tree solution?

 

Shahram and all,

 <= /p>

This question already cam= e up in our discussions - is it safe to assume that the VLAN tags at the E-= NNI will always be according to the current MEF model? Or should we try to be as transparent as possible to user VLAN encapsulation = at the E-NNI, to accommodate future frameworks?

I believe that any approa= ch that looks at user payload (in this case VLAN tag) to signal VPLS inform= ation (in this case root/leaf origin) is necessarily tied to specific assumptions on user payload encapsulation (in this case, that = S-VLAN tag is “available” to encode root/leaf). I don’t t= hink this is a future-proof assumption, it’s very likely that other n= etwork models will come up that require S-VLAN preservation, which in the 2-VLAN approach would necessitate adding a third VLAN-ID.

 <= /p>

Daniel

 

 

Hi,

 

I also have a question re= garding 2-VLAN. What if the customer traffic already has an S-VLAN? Do we n= eed a 3rd VLAN to identify the L/R?

 

Thx

Shahram

 

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin
Sent: Friday, April 20, 2012 9:38 AM
To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com
Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution?

 =

Hi, all,
The difference between 2-VLAN and CW approach is who will provide the R/L i= nformation, customer payload or PW? The customer payload will be always mod= ified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach.
I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is access= ed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informati= on?

Thanks
Lizhong

> ------------------------------
>
> Message: 2
> Date: Thu, 19 Apr 2012 04:38:36 +0000
> From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
> To: "Rogers, Josh" <josh.rogers@twcable.com>, Lucy yong
>        <lucy.yong@huawei.com>, Daniel Cohn <DanielC@orckit.com>, Sam Cao
>        <= yuqun.cao@gmail.com>
> Cc: "l2vpn@ietf.org" &= lt;l2vpn@ietf.org>
> Subject: RE: The status of the approaches to the E-Tree solution?
> Message-ID:
>        <F9336571731ADE42A5397FC831CEAA0= 2034192@FRIDWPPMB002.ecitele.com>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> Hi all,
> I fully understand that that what I am going to say is not very popula= r, but:
>
> IMO one of the advantages of the CW-based solution is that it is ortho= gonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN tra= ffic.
>
> Another advantage is preservation of full mesh of P2P PWs in a VPLS, a= nd, in a more generic way, localization of effects of changes in the PE con= figuration.
>
> In particular, adding a Leaf AC to a PE that previously has been only = supporting Root ACs (or vice versa), removal of the last Leaf or last Root = AC from a PE that previously has been supporting a mix etc. affect only the= PE where this operation happens and not the rest of the PEs.
>
> As for the need for HW changes that have been mentioned as a main disa= dvantage of the CW-based approach - I believe it strongly depends on specif= ic implementations. And some changes in the forwarding process are required= in any solution.
>
> My 2c,
>     Sasha
>
>
>
> ________________________________________
> From: l2vpn-bounces@ietf.org= [l2vpn-bounces@ietf.org]= on behalf of Rogers, Josh [josh= .rogers@twcable.com]
> Sent: Wednesday, April 18, 2012 9:57 PM
> To: Lucy yong; Daniel Cohn; Sam Cao
> Cc: l2vpn@ietf.org
> Subject: Re: The status of the approaches to the E-Tree solution?
>
> Again, the P2MP situation throws me.  Is this something that is u= sed
> commonly?
>
> I'm under the impression that adding P2MP to any model results in a mo= re
> complex model.  Wether outside s-tag is used to differentiate, or=
> dedicated pw's are used for the same purpose, it seems both become mor= e
> complex.
>
> Gile's comparison slide still concisely captures the differences betwe= en
> these methods, in my opinion.  I haven't seen any new ideas or th= oughts
> brought to the group in the past week or two on the subject.  I w= ould hate
> for both proposed methods to die on the vine because we couldn't decid= e
> between two methods that have nothing inherently wrong with either. >
> -Josh
>
>
> On 4/18/12 1:53 PM, "Lucy yong" <lucy.yong@huawei.com> wrote:
>
>>Send this again.
>>
>>Two PW approach can be complex too if the VPLS instance for E-Tree = uses
>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may do= uble
>>all of them.
>>
>>Lucy
>>
>>-----Original Message-----
>>From: Daniel Cohn [mailto:Dan= ielC@orckit.com]
>>Sent: Wednesday, April 18, 2012 1:42 PM
>>To: Lucy yong; Rogers, Josh; Sam Cao
>>Cc: l2vpn@ietf.org
>>Subject: RE: The status of the approaches to the E-Tree solution? >>
>>I think the first option its the natural way to go. How is the proc= essing
>>in this case more complex?
>>
>>Thumb typed - please be tolerant
>>
>>Lucy yong <lucy.yong@hua= wei.com> wrote:
>>
>>
>>
>>Snipped..
>>
>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P= 2MP PW
>>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (f= or
>>traffic coming from a root AC)
>>[[LY]] Not that simple. You construct either two P2MP PWs to all ot= her
>>PEs and let egress PE performing filtering, or construct one P2MP P= W to
>>leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress= PE
>>perform forwarding and filtering. Both make node process complex. >>
>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW f= or
>>delivering the frames to remote PEs. We should utilize them with th= e
>>minimized changes. Dual VLAN solution is simpler than Dual PW.
>>
>>Regards,
>>Lucy
>>
>>
>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. &n= bsp;I
>>haven't had any first hand experience with P2MP PW's, however, so d= on't
>>feel terribly strong about this objection.  Is this a real pro= blem for
>>others (now or in the future), or is this objection in the weeds? >>
>>I'm not sure the 'additional complexity' is notable, or even releva= nt.  I
>>encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for = it.
>>
>>Thanks,
>>Josh
>>
>>
>>
>>On 4/18/12 10:30 AM, "Lucy yong" <lucy.yong@huawei.com> wrote:
>>
>>>Please see inline.
>>>
>>>-----Original Message-----
>>>From: Sam Cao [mailto:yu= qun.cao@gmail.com]
>>>Sent: Tuesday, April 17, 2012 7:14 AM
>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim = (Wim)';
>>>giles.heron@gmail.com<= /a>; simon.delord@gmail.com;
>>>Alexander.V= ainshtein@ecitele.com
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com;
>>>Andrew.Sergeev@ec= itele.com; Idan.Kaspit@ecitele.com;
>>>Mishael.Wexler@ec= itele.com; Rotem.Cohen@ecitele.com
>>>Subject: RE: The status of the approaches to the E-Tree solutio= n?
>>>
>>>Yes, 2 pws are only needed between pes with both root and leaf = acs after
>>>improving Dual-PW approach. If consider P2MP, Dual-PW approach = setup 2
>>>P2MP
>>>PWs if need. There is no difference between P2MP or normal PW s= etup. But,
>>>can Leaf-ACs be bound to Root PE of P2MP PW?
>>>
>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE = with both
>>>root and leaf ACs set up two or one P2MP PW to other PEs (some = PE have
>>>both root and leaf AC and some only have leaf ACs)?
>>>Regards,
>>>Lucy
>>>
>>>Regards,
>>>
>>>Yuqun (Sam) Cao
>>>E-mail: Yuqun.cao@gmail.= com
>>>
>>>
>>>-----Original Message-----
>>>From: Daniel Cohn [mailto:DanielC@orckit.com]
>>>Sent: Tuesday, April 17, 2012 4:56 PM
>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim);
>>>giles.heron@gmail.com<= /a>;
>>>simon.delord@gmail.co= m; Alexander.Vainshtein@ecitele.com; Sam Cao
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com;
>>>Andrew.Sergeev@ec= itele.com; Idan.Kaspit@ecitele.com;
>>>Mishael.Wexler@ec= itele.com; Rotem.Cohen@ecitele.com
>>>Subject: RE: The status of the approaches to the E-Tree solutio= n?
>>>
>>>Adding Sam (as l2vpn@ is holding messages)
>>>
>>>DC
>>>
>>>-----Original Message-----
>>>From: Lucy yong [mailto:lucy.yong@huawei.com]
>>>Sent: Tuesday, April 17, 2012 12:39 AM
>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim);
>>>giles.heron@gmail.com<= /a>; simon.delord@gmail.com;
>>>Alexander.V= ainshtein@ecitele.com
>>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com;
>>>Andrew.Sergeev@ec= itele.com; Idan.Kaspit@ecitele.com;
>>>Mishael.Wexler@ec= itele.com; Rotem.Cohen@ecitele.com
>>>Subject: RE: The status of the approaches to the E-Tree solutio= n?
>>>
>>>
>>>Snipped,
>>>
>>>As we discussed extensively in the list, and as reflected in gi= les
>>>slide, 2 pws are only needed between pes with both root and lea= f acs,
>>>which will typically be a small minority.
>>>[[LY]] Don't know if the assumption is true. Even it is the cas= e, both
>>>approaches can benefit from it. I was off for a while and captu= res some
>>>discussions now.
>>>
>>>Also as per giles slide, dual vlan can have scalability issues = due to
>>>additional lookup and double use of vlans in internal emulated = lan
>>>interface. Also there are potential backward compatibility issu= es with
>>>silicon that doesn't support vlan mapping.
>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minu= tes. I am
>>>not clear on all the issues. Could you be more specific? As I m= entioned
>>>in below, two PW approach makes VPLS transport construction and= packet
>>>forwarding more complex, I can see potential backward compatibi= lity
>>>issues with 2 PW solution.
>>>
>>>Regards,
>>>Lucy
>>>
>>>Regards,
>>>
>>>Daniel
>>>
>>>Thumb typed - please be tolerant
>>>
>>>Lucy yong <lucy.yong= @huawei.com> wrote:
>>>
>>>In my mind, the VLAN approach means dual vlan method.
>>>
>>>The main concern for CW approach is hardware support.
>>>
>>>Two PW approach can be complex too if the VPLS instance for E-T= ree uses
>>>P2P PW for unicast traffic and P2MP PW for broadcast and unknow= n unicast
>>>traffic, and some P2MP PWs for multicast traffic. It may double= all of
>>>them.
>>>
>>>E-tree is an Ethernet service and there is already VLAN based s= olution
>>>in IEEE, can we just utilize it without complicating VPLS trans= port
>>>construction? This also makes interworking with Eth only networ= k easier.
>>>
>>>Cheers,
>>>Lucy
>>>
>>>-----Original Message-----
>>>From: Rogers, Josh [mailto:josh.rogers@twcable.com]
>>>Sent: Monday, April 16, 2012 8:35 AM
>>>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com';
>>>'simon.delord@gmail.c= om'; 'Alexander.Vai= nshtein@ecitele.com'
>>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com<= /a>';
>>>'Andrew.Sergeev@e= citele.com'; 'Idan.Kaspit@ec= itele.com';
>>>'Mishael.Wexler@e= citele.com'; 'Rotem.Cohen@ec= itele.com'
>>>Subject: RE: The status of the approaches to the E-Tree solutio= n?
>>>
>>>I believe the initial question was in regard to the CW method. =  Are you
>>>saying that you no longer are interested in that method in pref= erence of
>>>the dual vlan method?
>>>
>>>
>>>
>>>Lucy yong <lucy.yong= @huawei.com> wrote:
>>>
>>>
>>>Agree with Wim. VLAN approach is the best solution for E-Tree.<= br> >>>
>>>Lucy
>>>
>>>-----Original Message-----
>>>From: l2vpn-bounces@i= etf.org [mailto:l2vpn-bounces= @ietf.org] On Behalf
>>>Of Henderickx, Wim (Wim)
>>>Sent: Thursday, April 12, 2012 2:03 AM
>>>To: 'giles.heron@gmail= .com'; 'simon.delord@gmail.co= m';
>>>'Alexander.= Vainshtein@ecitele.com'
>>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com<= /a>';
>>>'Andrew.Sergeev@e= citele.com'; 'Idan.Kaspit@ec= itele.com';
>>>'Mishael.Wexler@e= citele.com'; 'Rotem.Cohen@ec= itele.com'
>>>Subject: Re: The status of the approaches to the E-Tree solutio= n?
>>>
>>>The vlan approach is superior as it also works for eth only net= works,
>>>etc. On top some vendors indicate hw issues with the cw approac= h. As
>>>such we have dropped more or less the cw approach.
>>>
>>>Cheers,
>>>Wim
>>>_________________
>>>sent from blackberry
>>>
>>>----- Original Message -----
>>>From: Giles Heron [mailto:giles.heron@gmail.com]
>>>Sent: Thursday, April 12, 2012 08:22 AM
>>>To: Simon Delord <= simon.delord@gmail.com>; Alexander Vainshtein
>>><Alexand= er.Vainshtein@ecitele.com>
>>>Cc: l2vpn@ietf.org <l2vpn@ietf.org>; Vladimir Kleiner >>><Vladimir.Kl= einer@ecitele.com>; Andrew Sergeev
>>><Andrew.Sergee= v@ecitele.com>; Idan Kaspit <Idan.Kaspit@ecitele.com>;
>>>Mishael Wexler <Mishael.Wexler@ecitele.com>; Rotem Cohen
>>><Rotem.Cohen@ecit= ele.com>
>>>Subject: Re: The status of the approaches to the E-Tree solutio= n?
>>>
>>>Sorry - the "anonymous presentation" was mine.  = I should possibly have
>>>put in a third column on the CW approach.  And hopefully t= he minutes
>>>will be posted soon.
>>>
>>>We had various discussions, as Simon stated, and consensus seem= ed to be
>>>forming around the two alternatives of two PWEs or two VLANs. &= nbsp;I believe
>>>three of the authors of the CW approach are also authors of the= two VLAN
>>>approach and one is also an author of the two PWE approach. So = perhaps
>>>it's best to let those four individuals say which approach they= prefer
>>>and why?
>>>
>>>Giles
>>>
>>>On 10/04/2012 00:45, "Simon Delord" <simon.delord@gmail.com> wrote:
>>>
>>>> Hi Alexander,
>>>>
>>>> You are right, no discussion on the WG mailing list recent= ly, but
>>>> there have been substantial discussions among the authors = of various
>>>> solution drafts off the mailing list. As far as I know, no= consensus
>>>> yet before ietf83, not sure the progress in the Paris WG m= eeting. I
>>>> think the CW approach has not been rejected by the WG yet,= or the WG
>>>> has not yet decided on which one to adopt.
>>>>
>>>> Simon
>>>>
>>>> 2012/4/8 Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
>>>>
>>>>>  Hi all,
>>>>>
>>>>> Unfortunately I have not been able to attend the Paris= IETF.
>>>>>
>>>>> However, looking up the L2VPN proceedings, I've found = a short
>>>>> anonymous presentation called "E-Tree Update"= ;  (
>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx).
>>>>> This presentation discusses the differences of the E-T= ree approaches
>>>>> based on dedicated VLANs (as in
>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>>> ext=3D1) and multiple PWs between the PEs (as in
>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>>> clude_te
>>>>> xt=3D1)
>>>>> and completely ignores the solution based on usage of = the CW in the
>>>>> PWs connecting the PEs (as in
>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>>> ext=3D1
>>>>> ).
>>>>>
>>>>>
>>>>>
>>>>> The Minutes of the Paris L2VPN session are not yet ava= ilable, but I
>>>>> wonder whether the WG has taken a decision to reject t= he approach
>>>>> based on the CW usage? I do not remember any recent di= scussion of
>>>>> this topic on the WG mailing list.
>>>>>
>>>>>
>>>>>
>>>>> Regards, and lots of thanks in advance,
>>>>>
>>>>> Sasha
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This e-mail message is intended for the recipient only= and contains
>>>>> information which is CONFIDENTIAL and which may be pro= prietary to ECI
>>>
>>>>> Telecom. If you have received this transmission in err= or, please
>>>>> inform us by e-mail, phone or fax, and then delete the= original and
>>>>> all copies thereof.
>>>>>
>>>
>>>
>>>
>>>
>>>
>>>This E-mail and any of its attachments may contain Time Warner = Cable
>>>proprietary information, which is privileged, confidential, or = subject
>>>to copyright belonging to Time Warner Cable. This E-mail is int= ended
>>>solely for the use of the individual or entity to which it is a= ddressed.
>>>If you are not the intended recipient of this E-mail, you are h= ereby
>>>notified that any dissemination, distribution, copying, or acti= on taken
>>>in relation to the contents of and attachments to this E-mail i= s
>>>strictly prohibited and may be unlawful. If you have received t= his
>>>E-mail in error, please notify the sender immediately and perma= nently
>>>delete the original and any copy of this E-mail and any printou= t.
>>>
>>
>>
>>This E-mail and any of its attachments may contain Time Warner Cabl= e
>>proprietary information, which is privileged, confidential, or subj= ect to
>>copyright belonging to Time Warner Cable. This E-mail is intended s= olely
>>for the use of the individual or entity to which it is addressed. I= f you
>>are not the intended recipient of this E-mail, you are hereby notif= ied
>>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is stric= tly
>>prohibited and may be unlawful. If you have received this E-mail in=
>>error, please notify the sender immediately and permanently delete = the
>>original and any copy of this E-mail and any printout.
>
>
> This E-mail and any of its attachments may contain Time Warner Cable p= roprietary information, which is privileged, confidential, or subject to co= pyright belonging to Time Warner Cable. This E-mail is intended solely for = the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-= mail, you are hereby notified that any dissemination, distribution, copying= , or action taken in relation to the contents of and attachments to this E-= mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify = the sender immediately and permanently delete the original and any copy of = this E-mail and any printout.
> This e-mail message is intended for the recipient only and contains in= formation which is CONFIDENTIAL and which may be proprietary to ECI Telecom= . If you have received this transmission in error, please inform us by e-ma= il, phone or fax, and then delete the original and all copies thereof.
>
>
>
> ------------------------------
>
> _______________________________________________
> L2vpn mailing list
> L2vpn@ietf.org
> https://www.ie= tf.org/mailman/listinfo/l2vpn
>
>
> End of L2vpn Digest, Vol 95, Issue 25
> ***********************************

--_000_2691CE0099834E4A9C5044EEC662BB9D3264B32Ddfweml505mbx_-- From lizhong.jin@zte.com.cn Mon Apr 23 18:06:29 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E5321F86E2; Mon, 23 Apr 2012 18:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.168 X-Spam-Level: X-Spam-Status: No, score=-100.168 tagged_above=-999 required=5 tests=[AWL=-0.885, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_OBFU_AMP2B=2.555, 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 DnofGQv0McXS; Mon, 23 Apr 2012 18:06:28 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A2A3721F86E4; Mon, 23 Apr 2012 18:06:27 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201974505403; Tue, 24 Apr 2012 08:26:24 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 66762.5191388195; Tue, 24 Apr 2012 09:06:15 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q3O16CBJ044682; Tue, 24 Apr 2012 09:06:12 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: jiangyuanlong@huawei.com, stbryant@cisco.com Subject: Re: [PWE3] Fwd: IPR Statements concerning etree MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Tue, 24 Apr 2012 09:05:33 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-24 09:06:12, Serialize complete at 2012-04-24 09:06:12 Content-Type: multipart/alternative; boundary="=_alternative 00060F9E482579EA_=" X-MAIL: mse02.zte.com.cn q3O16CBJ044682 Cc: l2vpn@ietf.org, l2vpn-chairs@tools.ietf.org, pwe3@ietf.org, pwe3-chairs@tools.ietf.org X-BeenThere: l2vpn@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, 24 Apr 2012 01:06:30 -0000 This is a multipart message in MIME format. --=_alternative 00060F9E482579EA_= Content-Type: text/plain; charset="US-ASCII" I have similar concern, the E-Tree technology has already been deployed before 2006. Lizhong > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 23 Apr 2012 08:34:08 +0000 > From: Jiangyuanlong > To: Stewart Bryant > Cc: "l2vpn@ietf.org" , "l2vpn-chairs@tools.ietf.org" > , pwe3 , > "pwe3-chairs@tools.ietf.org" > Subject: Re: [PWE3] Fwd: IPR Statements concerning etree > Message-ID: > <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EA4B@SZXEML508-MBS.china.huawei.com> > > Content-Type: text/plain; charset="us-ascii" > > As far as I know, tagging E-Tree traffic with different VLANs had > already been published in 2005 (it is called asymmetric VLANs in > IEEE 802.1Q-2005), well ahead of it. > > ------------------------------ > Date: Fri, 20 Apr 2012 15:37:23 +0100 > From: Stewart Bryant > To: "l2vpn@ietf.org" , "l2vpn-chairs@tools.ietf.org" > , pwe3 , > "pwe3-chairs@tools.ietf.org" > Subject: Fwd: IPR Statements concerning etree > Message-ID: <4F9174A3.6000102@cisco.com> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > > WGs, > > You may wish to look at the following IPR statements that were > received yesterday. > > They all relate to etree. > > The stated terms appear to require payment of a royalty. > > Stewart > > > -------- Original Message -------- > Subject: IPR Statements > Date: Thu, 19 Apr 2012 13:04:27 -0400 > From: Russ Housley > To: Stewart Bryant > > > > Begin forwarded message: > > > From: IETF Secretariat > > Date: April 19, 2012 12:14:30 PM EDT > > To: simon.delord@gmail.com, raymond.key@ieee.org, wim. > henderickx@alcatel-lucent.com, lucy.yong@huawei.com, lizhong. > jin@zte.com.cn, frederic.jounay@orange.ch > > Cc: housley@vigilsec.com, ipr-announce@ietf.org > > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about > IPR related to draft-delord-pwe3-cw-bit-etree-07 > > > > > > Dear Simon DeLord, Raymond Key, Wim Henderickx, Lucy Yong, > Lizhong Jin, Frederic JOUNAY: > > > > An IPR disclosure that pertains to your Internet-Draft entitled > "Control Word > > Reserved bit for use in E-Tree" (draft-delord-pwe3-cw-bit-etree) > was submitted > > to the IETF Secretariat on 2012-04-19 and has been posted on the > "IETF Page of > > Intellectual Property Rights Disclosures" (https://datatracker. > ietf.org/ipr/1760/). The title of the IPR disclosure is "Orckit- > Corrigent Ltd's Statement about IPR related to draft-delord-pwe3-cw- > bit-etree-07.""); > > > > The IETF Secretariat > > > Begin forwarded message: > > > From: IETF Secretariat > > Date: April 19, 2012 12:15:08 PM EDT > > To: yuqun.cao@gmail.com > > Cc: housley@vigilsec.com, ipr-announce@ietf.org > > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about > IPR related to draft-cao-l2vpn-vpls-etree-02 > > > > > > Dear Yuqun Cao: > > > > An IPR disclosure that pertains to your Internet-Draft entitled > "Extension to > > VPLS for E-Tree" (draft-cao-l2vpn-vpls-etree) was submitted to the IETF > > Secretariat on 2012-04-19 and has been posted on the "IETF Page > of Intellectual > > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1759/ > ). The title > > of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about > IPR related to > > draft-cao-l2vpn-vpls-etree-02."); > > > > The IETF Secretariat > > > Begin forwarded message: > > > From: IETF Secretariat > > Date: April 19, 2012 12:15:34 PM EDT > > To: chen.ran@zte.com.cn > > Cc: housley@vigilsec.com, ipr-announce@ietf.org > > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about > IPR related to draft-chen-l2vpn-vpls-etree-vlan-01 > > > > > > Dear Ran Chen: > > > > An IPR disclosure that pertains to your Internet-Draft entitled > "Automatic VLAN > > allocation in E-tree" (draft-chen-l2vpn-vpls-etree-vlan) was > submitted to the > > IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of > > Intellectual Property Rights Disclosures" (https://datatracker. > ietf.org/ipr/1758/). The title of the IPR disclosure is "Orckit- > Corrigent Ltd's Statement about IPR related to draft-chen-l2vpn- > vpls-etree-vlan-01."); > > > > The IETF Secretariat > > > Begin forwarded message: > > > From: IETF Secretariat > > Date: April 19, 2012 12:16:29 PM EDT > > To: jiangyuanlong@huawei.com, lucyyong@huawei.com, Manuel. > Paul@telekom.de, frederic.jounay@orange.ch, florin.balus@alcatel- > lucent.com, wim.henderickx@alcatel-lucent.com, sajassi@cisco.com > > Cc: housley@vigilsec.com, ipr-announce@ietf.org > > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about > IPR related to draft-jiang-l2vpn-etree-bgp-00 > > > > > > Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, > Florin Balus, Wim Henderickx, Ali Sajassi: > > > > An IPR disclosure that pertains to your Internet-Draft entitled > "E-Tree Support > > in VPLS with BGP Signaling" (draft-jiang-l2vpn-etree-bgp) was > submitted to the > > IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of > > Intellectual Property Rights Disclosures" (https://datatracker. > ietf.org/ipr/1757/). The title of the IPR disclosure is "Orckit- > Corrigent Ltd's Statement about IPR related to draft-jiang-l2vpn- > etree-bgp-00."); > > > > The IETF Secretariat > > > Begin forwarded message: > > > From: IETF Secretariat > > Date: April 19, 2012 12:17:02 PM EDT > > To: yljiang@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom. > de, frederic.jounay@orange-ftgroup.com, florin.balus@alcatel-lucent. > com, wim.henderickx@alcatel-lucent.com > > Cc: housley@vigilsec.com, ipr-announce@ietf.org > > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about > IPR related to draft-jiang-l2vpn-vpls-pe-etree-05 > > > > > > Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, > Florin Balus, Wim Henderickx: > > > > An IPR disclosure that pertains to your Internet-Draft entitled > "VPLS PE Model > > for E-Tree Support" (draft-jiang-l2vpn-vpls-pe-etree) was > submitted to the IETF > > Secretariat on 2012-04-19 and has been posted on the "IETF Page > of Intellectual > > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1756/ > ). The title > > of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about > IPR related to > > draft-jiang-l2vpn-vpls-pe-etree-05.""); > > > > The IETF Secretariat > > > Begin forwarded message: > > > From: IETF Secretariat > > Date: April 19, 2012 12:17:48 PM EDT > > To: danielc@orckit.com, rafir@orckit.com, pagarwal@broadcom.com, > raymond.key@team.telstra.com > > Cc: housley@vigilsec.com, ipr-announce@ietf.org > > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about > IPR related to draft-ram-l2vpn-ldp-vpls-etree-2pw-02 > > > > > > Dear Daniel Cohn, Rafi Ram, Puneet Agarwal, Raymond Key: > > > > An IPR disclosure that pertains to your Internet-Draft entitled > "Extension to > > LDP-VPLS for E-Tree Using Two PW" (draft-ram-l2vpn-ldp-vpls-etree-2pw) was > > submitted to the IETF Secretariat on 2012-04-19 and has been > posted on the "IETF Page of Intellectual Property Rights Disclosures" > > (https://datatracker.ietf.org/ipr/1755/). The title of the IPR > disclosure is > > "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram- > l2vpn-ldp-vpls- > > etree-2pw-02.""); > > > > The IETF Secretariat > > > Begin forwarded message: > > > From: IETF Secretariat > > Date: April 19, 2012 12:18:32 PM EDT > > To: rafir@orckit.com, danielc@orckit.com, raymond.key@ieee.org, > pagarwal@broadcom.com, josh.rogers@twcable.com > > Cc: housley@vigilsec.com, ipr-announce@ietf.org > > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about > IPR related to draft-ram-l2vpn-etree-multiple-pw-01 > > > > > > Dear Rafi Ram, Daniel Cohn, Raymond Key, Puneet Agarwal, Joshua Rogers: > > > > An IPR disclosure that pertains to your Internet-Draft entitled > "Extension to > > VPLS for E-Tree Using Multiple PWs" (draft-ram-l2vpn-etree-multiple-pw) was > > submitted to the IETF Secretariat on 2012-04-19 and has been > posted on the "IETF > > Page of Intellectual Property Rights Disclosures" > > (https://datatracker.ietf.org/ipr/1754/). The title of the IPR > disclosure is > > "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram- > l2vpn-etree- > > multiple-pw-01.""); > > > > The IETF Secretariat > > > > > > --=_alternative 00060F9E482579EA_= Content-Type: text/html; charset="US-ASCII"
I have similar concern, the E-Tree technology has already been deployed before 2006.

Lizhong

> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 23 Apr 2012 08:34:08 +0000
> From: Jiangyuanlong <jiangyuanlong@huawei.com>
> To: Stewart Bryant <stbryant@cisco.com>
> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>,   "l2vpn-chairs@tools.ietf.org"
>    <l2vpn-chairs@tools.ietf.org>,   pwe3 <pwe3@ietf.org>,
>    "pwe3-chairs@tools.ietf.org" <pwe3-chairs@tools.ietf.org>
> Subject: Re: [PWE3] Fwd: IPR Statements concerning etree
> Message-ID:
>    <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EA4B@SZXEML508-MBS.china.huawei.com>
>    
> Content-Type: text/plain; charset="us-ascii"
>
> As far as I know, tagging E-Tree traffic with different VLANs had
> already been published in 2005 (it is called asymmetric VLANs in
> IEEE 802.1Q-2005), well ahead of it.
>
> ------------------------------
> Date: Fri, 20 Apr 2012 15:37:23 +0100
> From: Stewart Bryant <stbryant@cisco.com>
> To: "l2vpn@ietf.org" <l2vpn@ietf.org>,   "l2vpn-chairs@tools.ietf.org"
>    <l2vpn-chairs@tools.ietf.org>,   pwe3 <pwe3@ietf.org>,
>    "pwe3-chairs@tools.ietf.org" <pwe3-chairs@tools.ietf.org>
> Subject: Fwd: IPR Statements concerning etree
> Message-ID: <4F9174A3.6000102@cisco.com>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
>
> WGs,
>
> You may wish to look at the following IPR statements that were
> received yesterday.
>
> They all relate to etree.
>
> The stated terms appear to require payment of a royalty.
>
> Stewart
>
>
> -------- Original Message --------
> Subject:    IPR Statements
> Date:    Thu, 19 Apr 2012 13:04:27 -0400
> From:    Russ Housley <housley@vigilsec.com>
> To:    Stewart Bryant <stbryant@cisco.com>
>
>
>
> Begin forwarded message:
>
> >  From: IETF Secretariat<ietf-ipr@ietf.org>
> >  Date: April 19, 2012 12:14:30 PM EDT
> >  To: simon.delord@gmail.com, raymond.key@ieee.org, wim.
> henderickx@alcatel-lucent.com, lucy.yong@huawei.com, lizhong.
> jin@zte.com.cn, frederic.jounay@orange.ch
> >  Cc: housley@vigilsec.com, ipr-announce@ietf.org
> >  Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about
> IPR related to draft-delord-pwe3-cw-bit-etree-07
> >
> >
> >  Dear Simon DeLord, Raymond Key, Wim Henderickx, Lucy Yong,
> Lizhong Jin, Frederic JOUNAY:
> >
> >  An IPR disclosure that pertains to your Internet-Draft entitled
> "Control Word
> >  Reserved bit for use in E-Tree" (draft-delord-pwe3-cw-bit-etree)
> was submitted
> >  to the IETF Secretariat on 2012-04-19 and has been posted on the
> "IETF Page of
> >  Intellectual Property Rights Disclosures" (https://datatracker.
> ietf.org/ipr/1760/). The title of the IPR disclosure is "Orckit-
> Corrigent Ltd's Statement about IPR related to draft-delord-pwe3-cw-
> bit-etree-07."");
> >
> >  The IETF Secretariat
> >
> Begin forwarded message:
>
> >  From: IETF Secretariat<ietf-ipr@ietf.org>
> >  Date: April 19, 2012 12:15:08 PM EDT
> >  To: yuqun.cao@gmail.com
> >  Cc: housley@vigilsec.com, ipr-announce@ietf.org
> >  Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about
> IPR related to draft-cao-l2vpn-vpls-etree-02
> >
> >
> >  Dear Yuqun Cao:
> >
> >  An IPR disclosure that pertains to your Internet-Draft entitled
> "Extension to
> >  VPLS for E-Tree" (draft-cao-l2vpn-vpls-etree) was submitted to the IETF
> >  Secretariat on 2012-04-19 and has been posted on the "IETF Page
> of Intellectual
> >  Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1759/
> ). The title
> >  of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about
> IPR related to
> >  draft-cao-l2vpn-vpls-etree-02.");
> >
> >  The IETF Secretariat
> >
> Begin forwarded message:
>
> >  From: IETF Secretariat<ietf-ipr@ietf.org>
> >  Date: April 19, 2012 12:15:34 PM EDT
> >  To: chen.ran@zte.com.cn
> >  Cc: housley@vigilsec.com, ipr-announce@ietf.org
> >  Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about
> IPR related to draft-chen-l2vpn-vpls-etree-vlan-01
> >
> >
> >  Dear Ran Chen:
> >
> >  An IPR disclosure that pertains to your Internet-Draft entitled
> "Automatic VLAN
> >  allocation in E-tree" (draft-chen-l2vpn-vpls-etree-vlan) was
> submitted to the
> >  IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of
> >  Intellectual Property Rights Disclosures" (https://datatracker.
> ietf.org/ipr/1758/). The title of the IPR disclosure is "Orckit-
> Corrigent Ltd's Statement about IPR related to draft-chen-l2vpn-
> vpls-etree-vlan-01.");
> >
> >  The IETF Secretariat
> >
> Begin forwarded message:
>
> >  From: IETF Secretariat<ietf-ipr@ietf.org>
> >  Date: April 19, 2012 12:16:29 PM EDT
> >  To: jiangyuanlong@huawei.com, lucyyong@huawei.com, Manuel.
> Paul@telekom.de, frederic.jounay@orange.ch, florin.balus@alcatel-
> lucent.com, wim.henderickx@alcatel-lucent.com, sajassi@cisco.com
> >  Cc: housley@vigilsec.com, ipr-announce@ietf.org
> >  Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about
> IPR related to draft-jiang-l2vpn-etree-bgp-00
> >
> >
> >  Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY,
> Florin Balus, Wim Henderickx, Ali Sajassi:
> >
> >  An IPR disclosure that pertains to your Internet-Draft entitled
> "E-Tree Support
> >  in VPLS with BGP Signaling" (draft-jiang-l2vpn-etree-bgp) was
> submitted to the
> >  IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of
> >  Intellectual Property Rights Disclosures" (https://datatracker.
> ietf.org/ipr/1757/). The title of the IPR disclosure is "Orckit-
> Corrigent Ltd's Statement about IPR related to draft-jiang-l2vpn-
> etree-bgp-00.");
> >
> >  The IETF Secretariat
> >
> Begin forwarded message:
>
> >  From: IETF Secretariat<ietf-ipr@ietf.org>
> >  Date: April 19, 2012 12:17:02 PM EDT
> >  To: yljiang@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.
> de, frederic.jounay@orange-ftgroup.com, florin.balus@alcatel-lucent.
> com, wim.henderickx@alcatel-lucent.com
> >  Cc: housley@vigilsec.com, ipr-announce@ietf.org
> >  Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about
> IPR related to draft-jiang-l2vpn-vpls-pe-etree-05
> >
> >
> >  Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY,
> Florin Balus, Wim Henderickx:
> >
> >  An IPR disclosure that pertains to your Internet-Draft entitled
> "VPLS PE Model
> >  for E-Tree Support" (draft-jiang-l2vpn-vpls-pe-etree) was
> submitted to the IETF
> >  Secretariat on 2012-04-19 and has been posted on the "IETF Page
> of Intellectual
> >  Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1756/
> ). The title
> >  of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about
> IPR related to
> >  draft-jiang-l2vpn-vpls-pe-etree-05."");
> >
> >  The IETF Secretariat
> >
> Begin forwarded message:
>
> >  From: IETF Secretariat<ietf-ipr@ietf.org>
> >  Date: April 19, 2012 12:17:48 PM EDT
> >  To: danielc@orckit.com, rafir@orckit.com, pagarwal@broadcom.com,
> raymond.key@team.telstra.com
> >  Cc: housley@vigilsec.com, ipr-announce@ietf.org
> >  Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about
> IPR related to draft-ram-l2vpn-ldp-vpls-etree-2pw-02
> >
> >
> >  Dear Daniel Cohn, Rafi Ram, Puneet Agarwal, Raymond Key:
> >
> >  An IPR disclosure that pertains to your Internet-Draft entitled
> "Extension to
> >  LDP-VPLS for E-Tree Using Two PW" (draft-ram-l2vpn-ldp-vpls-etree-2pw) was
> >  submitted to the IETF Secretariat on 2012-04-19 and has been
> posted on the "IETF Page of Intellectual Property Rights Disclosures"
> >  (https://datatracker.ietf.org/ipr/1755/). The title of the IPR
> disclosure is
> >  "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-
> l2vpn-ldp-vpls-
> >  etree-2pw-02."");
> >
> >  The IETF Secretariat
> >
> Begin forwarded message:
>
> >  From: IETF Secretariat<ietf-ipr@ietf.org>
> >  Date: April 19, 2012 12:18:32 PM EDT
> >  To: rafir@orckit.com, danielc@orckit.com, raymond.key@ieee.org,
> pagarwal@broadcom.com, josh.rogers@twcable.com
> >  Cc: housley@vigilsec.com, ipr-announce@ietf.org
> >  Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about
> IPR related to draft-ram-l2vpn-etree-multiple-pw-01
> >
> >
> >  Dear Rafi Ram, Daniel Cohn, Raymond Key, Puneet Agarwal, Joshua Rogers:
> >
> >  An IPR disclosure that pertains to your Internet-Draft entitled
> "Extension to
> >  VPLS for E-Tree Using Multiple PWs" (draft-ram-l2vpn-etree-multiple-pw) was
> >  submitted to the IETF Secretariat on 2012-04-19 and has been
> posted on the "IETF
> >  Page of Intellectual Property Rights Disclosures"
> >  (https://datatracker.ietf.org/ipr/1754/). The title of the IPR
> disclosure is
> >  "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-
> l2vpn-etree-
> >  multiple-pw-01."");
> >
> >  The IETF Secretariat
> >
>
>
>
> --=_alternative 00060F9E482579EA_=-- From jiangyuanlong@huawei.com Mon Apr 23 18:23:59 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A6811E8072 for ; Mon, 23 Apr 2012 18:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599] 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 eZ0YnhtN7ToB for ; Mon, 23 Apr 2012 18:23:58 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC2621F8705 for ; Mon, 23 Apr 2012 18:23:58 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFD90036; Mon, 23 Apr 2012 21:23:57 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Apr 2012 18:21:48 -0700 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Apr 2012 18:21:27 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.137]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Tue, 24 Apr 2012 09:21:24 +0800 From: Jiangyuanlong To: Alexander Vainshtein , Sam Cao Subject: RE: Discussion on E-Tree and H-VPLS Thread-Topic: Discussion on E-Tree and H-VPLS Thread-Index: AQHNIVdJ16/hF2my4UWKy6ZMvPNab5apK6GQ Date: Tue, 24 Apr 2012 01:21:24 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EC3D@SZXEML508-MBS.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E891@SZXEML508-MBS.china.huawei.com> <5C3578E316494634B1DCAC06C15E2C21@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EAE6@SZXEML508-MBS.china.huawei.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EB46@SZXEML508-MBS.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-cr-hashedpuzzle: DcdV ENC+ F1r+ MMc2 M8Bs NSu9 QIWU QK+1 QuN1 Q1by SAEJ TdQK T3Ff V3jR WM5r cM0d; 3; YQBsAGUAeABhAG4AZABlAHIALgB2AGEAaQBuAHMAaAB0AGUAaQBuAEAAZQBjAGkAdABlAGwAZQAuAGMAbwBtADsAbAAyAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAeQB1AHEAdQBuAC4AYwBhAG8AQABnAG0AYQBpAGwALgBjAG8AbQA=; Sosha1_v1; 7; {E18E06D2-E44D-4720-81EF-DC71E4331F55}; agBpAGEAbgBnAHkAdQBhAG4AbABvAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Tue, 24 Apr 2012 01:21:19 GMT; UgBFADoAIABEAGkAcwBjAHUAcwBzAGkAbwBuACAAbwBuACAARQAtAFQAcgBlAGUAIABhAG4AZAAgAEgALQBWAFAATABTAA== x-cr-puzzleid: {E18E06D2-E44D-4720-81EF-DC71E4331F55} x-originating-ip: [10.70.40.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 24 Apr 2012 01:23:59 -0000 Sasha, Dual VLAN will have no impact on the switch fabric as long as Ethernet forw= arding is supported. So the question is, do we really need to develop a solution which is strong= ly dependent on specific implementations when we have other choices? Thanks, Yuanlong -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Monday, April 23, 2012 9:45 PM To: Jiangyuanlong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Yuanlong, Lots of thanks for a prompt response. I think that actual complexity of preserving the flags in the CW when forwa= rding from a core PW to a spoke one (or vice versa) strongly depends on you= r implementation. E.g., in Chassis-based PEs it is quite customary for the = ingress blade to prepend some internal header to the packet(s) it sends acr= oss the Fabric to the egress blade. In this case you need at most to find o= ne unused bit in this header (usually not a big deal), and you can also pos= sibly do without. Of course this implementing this behavior in some tailored HW could be high= ly problematic - but IMHO so would be any approach that has not been taken = into account by the vendor of the specific chip. Regards, Sasha > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, April 23, 2012 3:24 PM > To: Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS >=20 > Sasha, >=20 > Sorry, but I don't think the CW-based solution can preserve the CW in suc= h a > way. In PE-rs, the PW should be terminated and the Ethernet frame needs > to be forwarded with dst MAC lookup. Therefore, we need some tricky bits > in the switch fabric in order to carry the CW information intact across t= he > Ethernet forwarding plane. >=20 > Thanks > Yuanlong >=20 >=20 > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Monday, April 23, 2012 7:33 PM > To: Jiangyuanlong; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS >=20 > Sam, Yuanlong and all, > From my point of view the CW-based solution is by far the simplest way to > deal with H-VPLS: all that is required is preservation of the CW (or, in = the > unlikely case PW sequencing is used, of its flags) when a packet is > forwarded from the "core" PW to a "spoke" one (or vice versa). >=20 > With Dual PWE the situation becomes more complicated IMO. Not sure > about dual VLAN - but may be also tricky. >=20 > Regards, > Sasha >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > > Of Jiangyuanlong > > Sent: Monday, April 23, 2012 2:23 PM > > To: Sam Cao > > Cc: l2vpn@ietf.org > > Subject: Discussion on E-Tree and H-VPLS > > > > Sam, > > > > Please see my comments in line. I also change the title to reflect the = topic. > > > > Regards > > Yuanlong > > > > -----Original Message----- > > From: Sam Cao [mailto:yuqun.cao@gmail.com] > > Sent: Monday, April 23, 2012 11:28 AM > > To: Jiangyuanlong > > Cc: l2vpn@ietf.org > > Subject: RE: L2vpn Digest, Vol 95, Issue 58 > > > > Yuanlong, > > > > I do apologize for my unclear description. I try to make it clear. > > > > VPWS or Spoke PW, PE-rs will take the PW as Spoke PW. Or say, PE-rs > really > > does NOT care remote access is VPWS access (point-to-point, Fig. 3) or > VPLS > > spoke access (Fig. 4). PE-rs just know it is spoke PW and it is ENOUGH,= and > > does NOT care customer payload. is this correct? At least it is correc= t in > > RFC 4762. > > [JY] why divide the remote access to VPWS access and VPLS access? > > > > But, if remote is VPWS access (Fig. 3), PE-rs SHOULD configure AC-type = for > > remote VPWS access although it is still spoke PW in E-Tree. Please refe= r to > > your answer to Josh's question. It seems reasonable. Ok, we think anoth= er > > case in Fig. 4. In Fig. 4, PE-rs CAN NOT configure AC-type at all in th= is > > case. In fact, on MTU-s it is VPLS and we should configure AC type on M= TU- > s. > > [JY] Quite opposite, in case of Fig.4, IMHO, it is better to configure = the E- > > Tree attribute on the PE-rs since the PE-r does not support any bridgin= g > > functions. I think this case is provided in RFC4762 just to be compatib= le > with > > some legacy routers. > > > > > > Ok, problem came up for me. For spoke PW on PE-rs, in one case it shoul= d > > configure AC type and work as agent; in another case, it can NOT config= ure > > AC type and can not work as agent. In fact, PE-rs knows it is spoke PW,= it > > is enough; why spoke-PW has different configuration in same VPLS > instance > > on > > same PE? I am confused although I know why we should configure in that > > way. > > > > I prefer not to configure AC type on PE-rs since we can take it as > > "Switching PE" (NOT pefact here and it is not real "Switching Point") w= hich > > does NOT aware customer payload. Extension to VPWS? Seems not > > reasonable. > > [JY] Not sure I got your points. PE-rs will terminate the PW and switch= the > > Ethernet frames. IMO, whether configuring the E-Tree service on a PE-rs= or > a > > MTU-s is dependent on the topology of the service and how they are > > attached. H-VPLS can be seen as a transparent transport network, or as = a > > service itself. > > > > Thanks, > > > > Sam > > > > -----Original Message----- > > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > > Sent: Monday, April 23, 2012 9:59 AM > > To: Sam Cao > > Cc: l2vpn@ietf.org > > Subject: RE: L2vpn Digest, Vol 95, Issue 58 > > > > Hi Sam, > > > > If E-Tree service is provided in a scenario as Fig. 3 and Fig 4 in RFC = 4762, > > then a CE (leaf or root) is connected to the MTU-s or PE-r, thus the AC > > should be terminated and the E-Tree service should be encapsulated by > the > > MTU-s or PE-r. I don't quite understand why you need to "take VPWS PW > as > > one > > AC", but even in that case, the attribute of the AC may be configured a= t > the > > PE-rs. So what is the problem for H-VPLS? > > > > Thanks > > Yuanlong > > > > Date: Sun, 22 Apr 2012 22:03:52 +0800 > > From: "Sam Cao" > > To: "'Jiangyuanlong'" > > Cc: l2vpn@ietf.org > > Subject: RE: The status of the approaches to the E-Tree solution? > > Message-ID: <962A848896EF4678B17D76C826A7EAEF@v2comsam> > > Content-Type: text/plain; charset=3D"us-ascii" > > > > Yuanlong, > > > > I just collect all issues we discussed before, and we still can not mak= e > > agreement. I gave my comments on 2 items below. I will think other item= s > > over and give my comments tomorrow. > > > > 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, > > PE-rs works in different manner, PE-rs should figure out AC type in VPW= S > > case, but can NOT configure it at all in Spoke PW case; > > [JY] In the first place, why PE-rs need to figure out the AC type for a > > spoke? The VLAN should be processed in the MTU, not in the PE-rs. > > [Sam] Yuanlong, I understand your idea. It does NOT make sense for me. > > First, Fig. 3 and Fig 4 in RFC 4762 are different cases. For VPWS (Fig.= 3), > > we can take VPWS PW as one AC. You know, PE-rs is termination of VPWS, > > so it > > will add VLAN-ID to identify Root/Leaf. BTW, you will map several VLAN > IDs > > into one Root-VLAN ID or Leaf-VLAN ID on PE-rs, so we need to configure > > Root/Leaf on PE-rs (Refer to your reply to Josh's comments). > > > > 4) Encapsulation mode: If deploy HVPLS with Spoke PW mode, PE-rs > > should work in tagged mode, otherwise PE-rs or egress PE will stripe S- > VLAN > > ID; > > [JY] Is anything not working with tagged PW mode? > > [Sam] Tagged mode works. > > > > Regards, > > > > Yuqun (Sam) Cao > > E-mail: Yuqun.cao@gmail.com > > >=20 > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform u= s by > e-mail, phone or fax, and then delete the original and all copies thereof= . This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. From yuqun.cao@gmail.com Mon Apr 23 20:51:33 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574B121F85B8 for ; Mon, 23 Apr 2012 20:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=0.987, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unonhwkGcHTd for ; Mon, 23 Apr 2012 20:51:32 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8445A21F85AE for ; Mon, 23 Apr 2012 20:51:32 -0700 (PDT) Received: by dady13 with SMTP id y13so387463dad.27 for ; Mon, 23 Apr 2012 20:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=MHPCkJrk2+ltZl18CEUumFH2ztHwLQPCwm9AWZmukLs=; b=ezuBAfr0pd52rxaiUpcOqhTCR5jnixxq6nJUqbgX+CcxMiaLII/1JgJOSW2qSit78h k2l8HMlz92ccE1kafdn12tc7m77Yc5zJlmCzAV+iqWrfcDRl259RKoTivaeAgh/l/t88 QZdQZARzje6M4obNHywxOmXNiyedpX7uANsPhuWcRURzAcK3p+4xW/ZUarptmNkapD8U FDsLw5a0oA0lAnmUboCvGiQs0B9Fcc7Lm9ac4ONWzR+st5q3e/rOuKFNebxotwm6io6D RI7rlnCWuYqo9GBDsXF67ViW6Txy7OwQQNx0G3an+4erxHzZ8dtjGlaUQUkmEz3tijgM awyA== Received: by 10.68.213.40 with SMTP id np8mr435787pbc.77.1335239492367; Mon, 23 Apr 2012 20:51:32 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id rg10sm16207059pbc.4.2012.04.23.20.51.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 20:51:31 -0700 (PDT) From: "Sam Cao" To: "'Jiangyuanlong'" References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E891@SZXEML508-MBS.china.huawei.com> <5C3578E316494634B1DCAC06C15E2C21@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EAE6@SZXEML508-MBS.china.huawei.com> Subject: RE: Discussion on E-Tree and H-VPLS Date: Tue, 24 Apr 2012 11:51:26 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EAE6@SZXEML508-MBS.china.huawei.com> Thread-index: AQHNIUN67h0xDILTIEWgVSrvExKN65apTJ4w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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, 24 Apr 2012 03:51:33 -0000 Yuanlong, Ok. Go on H-VPLS discussion although there are so many pending issues on Dual-VLAN.We can go one by one, :) I thought this for many times, it may be disadvantage of Dual-VLAN. In general, if MTU can NOT support Layer 2 switching, we will use P2P access (I called this as VPWS access); if MTU can support Layer 2 switching, we can use P2P or MP2MP access (I called the later as VPLS spoke access). Both are active deployment. Josh has given us one real deployment in real network. We can hold the opposite opinions, but this is really requirements from carriers. In Josh's example, even if MTU-s can support L2 switching, it also should work in VPWS mode. As I know, most vendors support 2 deployments. Then focus on VPWS deployment and PE-rs (Fig.4), we should appoint one VPWS access (On PE-r, it is VPWS; on PE1-rs, it is really Spoke PW. In this case, there is 1 or more PWs between PE-r AND PE1-rs) Root or Leaf. As you know, we can not appoint on PE-r since we have no extension to VPWS. You explained it in your reply to Josh's mail. I agree. Then go to Fig. 3. MTU-s can support L2 switching, so only 1 PW (1 PW is requirement from RFC 4762, but 2 or more PWs has no problem) between MTU-s and PE1-rs. This is also spoke PW. Can we appoint Root/Leaf for the Spoke PW? No. The root cause is, we can not appoint access type, Root or Leaf, anymore since MTU-s has added S-VLAN-ID into frame. This is my question: For VPWS access, we should configure Root/Leaf for Spoke PW; for VPLS access, we CAN NOT configure Root/Leaf for Spoke PW. Multi-PW has no problem on this: Configure Root or Leaf on PE1-rs in the 2 cases since it uses different PATH, not inferring context in frame. Thanks, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Monday, April 23, 2012 7:23 PM To: Sam Cao Cc: l2vpn@ietf.org Subject: Discussion on E-Tree and H-VPLS Sam, Please see my comments in line. I also change the title to reflect the topic. Regards Yuanlong -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com] Sent: Monday, April 23, 2012 11:28 AM To: Jiangyuanlong Cc: l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 95, Issue 58 Yuanlong, I do apologize for my unclear description. I try to make it clear. VPWS or Spoke PW, PE-rs will take the PW as Spoke PW. Or say, PE-rs really does NOT care remote access is VPWS access (point-to-point, Fig. 3) or VPLS spoke access (Fig. 4). PE-rs just know it is spoke PW and it is ENOUGH, and does NOT care customer payload. is this correct? At least it is correct in RFC 4762. [JY] why divide the remote access to VPWS access and VPLS access? But, if remote is VPWS access (Fig. 3), PE-rs SHOULD configure AC-type for remote VPWS access although it is still spoke PW in E-Tree. Please refer to your answer to Josh's question. It seems reasonable. Ok, we think another case in Fig. 4. In Fig. 4, PE-rs CAN NOT configure AC-type at all in this case. In fact, on MTU-s it is VPLS and we should configure AC type on MTU-s. [JY] Quite opposite, in case of Fig.4, IMHO, it is better to configure the E-Tree attribute on the PE-rs since the PE-r does not support any bridging functions. I think this case is provided in RFC4762 just to be compatible with some legacy routers. Ok, problem came up for me. For spoke PW on PE-rs, in one case it should configure AC type and work as agent; in another case, it can NOT configure AC type and can not work as agent. In fact, PE-rs knows it is spoke PW, it is enough; why spoke-PW has different configuration in same VPLS instance on same PE? I am confused although I know why we should configure in that way. I prefer not to configure AC type on PE-rs since we can take it as "Switching PE" (NOT pefact here and it is not real "Switching Point") which does NOT aware customer payload. Extension to VPWS? Seems not reasonable. [JY] Not sure I got your points. PE-rs will terminate the PW and switch the Ethernet frames. IMO, whether configuring the E-Tree service on a PE-rs or a MTU-s is dependent on the topology of the service and how they are attached. H-VPLS can be seen as a transparent transport network, or as a service itself. Thanks, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Monday, April 23, 2012 9:59 AM To: Sam Cao Cc: l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 95, Issue 58 Hi Sam, If E-Tree service is provided in a scenario as Fig. 3 and Fig 4 in RFC 4762, then a CE (leaf or root) is connected to the MTU-s or PE-r, thus the AC should be terminated and the E-Tree service should be encapsulated by the MTU-s or PE-r. I don't quite understand why you need to "take VPWS PW as one AC", but even in that case, the attribute of the AC may be configured at the PE-rs. So what is the problem for H-VPLS? Thanks Yuanlong Date: Sun, 22 Apr 2012 22:03:52 +0800 From: "Sam Cao" To: "'Jiangyuanlong'" Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <962A848896EF4678B17D76C826A7EAEF@v2comsam> Content-Type: text/plain; charset="us-ascii" Yuanlong, I just collect all issues we discussed before, and we still can not make agreement. I gave my comments on 2 items below. I will think other items over and give my comments tomorrow. 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, but can NOT configure it at all in Spoke PW case; [JY] In the first place, why PE-rs need to figure out the AC type for a spoke? The VLAN should be processed in the MTU, not in the PE-rs. [Sam] Yuanlong, I understand your idea. It does NOT make sense for me. First, Fig. 3 and Fig 4 in RFC 4762 are different cases. For VPWS (Fig. 3), we can take VPWS PW as one AC. You know, PE-rs is termination of VPWS, so it will add VLAN-ID to identify Root/Leaf. BTW, you will map several VLAN IDs into one Root-VLAN ID or Leaf-VLAN ID on PE-rs, so we need to configure Root/Leaf on PE-rs (Refer to your reply to Josh's comments). 4) Encapsulation mode: If deploy HVPLS with Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN ID; [JY] Is anything not working with tagged PW mode? [Sam] Tagged mode works. Regards, Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com From yuqun.cao@gmail.com Mon Apr 23 20:59:47 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A44B11E8073 for ; Mon, 23 Apr 2012 20:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[AWL=0.898, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVZLhVsfmM3c for ; Mon, 23 Apr 2012 20:59:46 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id C789D11E8072 for ; Mon, 23 Apr 2012 20:59:46 -0700 (PDT) Received: by dady13 with SMTP id y13so396215dad.27 for ; Mon, 23 Apr 2012 20:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=L7LP02QyKE3eF1MrUVpuCztNxpuXj4BhAuq2+AG+t/Q=; b=WaF5FgHZ2SEq28ujcMVfPVbN+6XN1Qft+fJMA8Tsyxe8C3fbotLEKyrCyMF/trr8wD A41LGHoxTY1gRAHeFcod/0lpCOVnWUIsZ+rfA0OFGS5czvLcpCCa60jOVbaS/c5RrI4f kh+Kl6tK/3Vfqj5pUCJu12kQ9yhBBqoaEv6BnupPoVsHhN26JrjnmNyKobOw0FOYYMHh jNKhX+VOsf9aMYl6IrRXLc1kt+pINYpDz5TS/dlCy2rmwPl8EtVVVwaNUKF7STwIHxmw RcmHUQqEeTMRQlmy/s65+O1hFS2KVBl3V/c/dWdp0Yb0/i5X9/DDKkm+q9DMtSpSYxIH acXw== Received: by 10.68.129.129 with SMTP id nw1mr505192pbb.29.1335239986450; Mon, 23 Apr 2012 20:59:46 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id pn5sm4366551pbb.71.2012.04.23.20.59.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 20:59:45 -0700 (PDT) From: "Sam Cao" To: "'Alexander Vainshtein'" , "'Jiangyuanlong'" References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E891@SZXEML508-MBS.china.huawei.com><5C3578E316494634B1DCAC06C15E2C21@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EAE6@SZXEML508-MBS.china.huawei.com> Subject: RE: Discussion on E-Tree and H-VPLS Date: Tue, 24 Apr 2012 11:59:33 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-index: AQHNIUPk8Ypm+Dwl9keYw7edV1ij15aoRiAQgAETl+A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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, 24 Apr 2012 03:59:47 -0000 Sasha, Just as we discussed for many times, 3 approaches use different identifiers. For me, Multi-PW uses different PATH (Multi-PW), but CW or Dual-VLAN uses inferring context in frames. So CW also has same HVPLS deployment problem. Thanks, Sam -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Monday, April 23, 2012 7:33 PM To: Jiangyuanlong; Sam Cao Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Sam, Yuanlong and all, >From my point of view the CW-based solution is by far the simplest way to deal with H-VPLS: all that is required is preservation of the CW (or, in the unlikely case PW sequencing is used, of its flags) when a packet is forwarded from the "core" PW to a "spoke" one (or vice versa). With Dual PWE the situation becomes more complicated IMO. Not sure about dual VLAN - but may be also tricky. Regards, Sasha > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Jiangyuanlong > Sent: Monday, April 23, 2012 2:23 PM > To: Sam Cao > Cc: l2vpn@ietf.org > Subject: Discussion on E-Tree and H-VPLS > > Sam, > > Please see my comments in line. I also change the title to reflect the topic. > > Regards > Yuanlong > From jiangyuanlong@huawei.com Mon Apr 23 23:02:03 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5920021F85A0 for ; Mon, 23 Apr 2012 23:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599] 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 Lcz1MPOFeBDV for ; Mon, 23 Apr 2012 23:01:56 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 48E8A21F859B for ; Mon, 23 Apr 2012 23:01:56 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFE05329; Tue, 24 Apr 2012 02:01:56 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Apr 2012 23:00:29 -0700 Received: from SZXEML436-HUB.china.huawei.com (10.72.61.64) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Apr 2012 23:00:31 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.137]) by szxeml436-hub.china.huawei.com ([10.72.61.64]) with mapi id 14.01.0323.003; Tue, 24 Apr 2012 14:00:27 +0800 From: Jiangyuanlong To: Sam Cao Subject: RE: Discussion on E-Tree and H-VPLS Thread-Topic: Discussion on E-Tree and H-VPLS Thread-Index: AQHNIc2S0CO7jxHhy0KsNM8pdsvtlZapWjdQ Date: Tue, 24 Apr 2012 06:00:26 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EE04@SZXEML508-MBS.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3E891@SZXEML508-MBS.china.huawei.com> <5C3578E316494634B1DCAC06C15E2C21@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EAE6@SZXEML508-MBS.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-cr-hashedpuzzle: EywT GULz Gh9K H0JP IV2e I1E+ Kr6Z MqU5 OVWH OiUL QFR/ SEsM S8IX T76G Y2OU Y3VD; 2; bAAyAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAeQB1AHEAdQBuAC4AYwBhAG8AQABnAG0AYQBpAGwALgBjAG8AbQA=; Sosha1_v1; 7; {EE55B157-E356-4494-8666-11E9F45485D7}; agBpAGEAbgBnAHkAdQBhAG4AbABvAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Tue, 24 Apr 2012 06:00:22 GMT; UgBFADoAIABEAGkAcwBjAHUAcwBzAGkAbwBuACAAbwBuACAARQAtAFQAcgBlAGUAIABhAG4AZAAgAEgALQBWAFAATABTAA== x-cr-puzzleid: {EE55B157-E356-4494-8666-11E9F45485D7} x-originating-ip: [10.70.40.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 24 Apr 2012 06:02:03 -0000 See my comments in line. -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Tuesday, April 24, 2012 11:51 AM To: Jiangyuanlong Cc: l2vpn@ietf.org Subject: RE: Discussion on E-Tree and H-VPLS Yuanlong, Ok. Go on H-VPLS discussion although there are so many pending issues on Dual-VLAN.We can go one by one, :) I thought this for many times, it may be disadvantage of Dual-VLAN. In general, if MTU can NOT support Layer 2 switching, we will use P2P acces= s (I called this as VPWS access); if MTU can support Layer 2 switching, we ca= n use P2P or MP2MP access (I called the later as VPLS spoke access). Both are active deployment. Josh has given us one real deployment in real network. W= e can hold the opposite opinions, but this is really requirements from carriers. In Josh's example, even if MTU-s can support L2 switching, it als= o should work in VPWS mode. As I know, most vendors support 2 deployments. Then focus on VPWS deploymen= t and PE-rs (Fig.4), we should appoint one VPWS access (On PE-r, it is VPWS; on PE1-rs, it is really Spoke PW. In this case, there is 1 or more PWs between PE-r AND PE1-rs) Root or Leaf. As you know, we can not appoint on PE-r since we have no extension to VPWS. You explained it in your reply to Josh's mail. I agree. Then go to Fig. 3. MTU-s can support L2 switching, so only 1 PW (1 PW is requirement from RFC 4762, but 2 or more PWs has no problem) between MTU-s and PE1-rs. This is also spoke PW. Can we appoint Root/Leaf for the Spoke PW? No. The root cause is, we can not appoint acces= s type, Root or Leaf, anymore since MTU-s has added S-VLAN-ID into frame. Thi= s is my question: For VPWS access, we should configure Root/Leaf for Spoke PW= ; for VPLS access, we CAN NOT configure Root/Leaf for Spoke PW. [JY] Not sure I understand the whole section, are you concerned with H-VPLS= use cases with QinQ spoke access? If that is the case, the S-VLAN is just = like the PW label in the case of PW spoke, it should be removed at the PE-r= s. Multi-PW has no problem on this: Configure Root or Leaf on PE1-rs in the 2 cases since it uses different PATH, not inferring context in frame. Thanks, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Monday, April 23, 2012 7:23 PM To: Sam Cao Cc: l2vpn@ietf.org Subject: Discussion on E-Tree and H-VPLS Sam, Please see my comments in line. I also change the title to reflect the topic. Regards Yuanlong -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Monday, April 23, 2012 11:28 AM To: Jiangyuanlong Cc: l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 95, Issue 58 Yuanlong, I do apologize for my unclear description. I try to make it clear. VPWS or Spoke PW, PE-rs will take the PW as Spoke PW. Or say, PE-rs really does NOT care remote access is VPWS access (point-to-point, Fig. 3) or VPLS spoke access (Fig. 4). PE-rs just know it is spoke PW and it is ENOUGH, and does NOT care customer payload. is this correct? At least it is correct in RFC 4762.=20 [JY] why divide the remote access to VPWS access and VPLS access? But, if remote is VPWS access (Fig. 3), PE-rs SHOULD configure AC-type for remote VPWS access although it is still spoke PW in E-Tree. Please refer to your answer to Josh's question. It seems reasonable. Ok, we think another case in Fig. 4. In Fig. 4, PE-rs CAN NOT configure AC-type at all in this case. In fact, on MTU-s it is VPLS and we should configure AC type on MTU-s= . [JY] Quite opposite, in case of Fig.4, IMHO, it is better to configure the E-Tree attribute on the PE-rs since the PE-r does not support any bridging functions. I think this case is provided in RFC4762 just to be compatible with some legacy routers. Ok, problem came up for me. For spoke PW on PE-rs, in one case it should configure AC type and work as agent; in another case, it can NOT configure AC type and can not work as agent. In fact, PE-rs knows it is spoke PW, it is enough; why spoke-PW has different configuration in same VPLS instance o= n same PE? I am confused although I know why we should configure in that way. I prefer not to configure AC type on PE-rs since we can take it as "Switching PE" (NOT pefact here and it is not real "Switching Point") which does NOT aware customer payload. Extension to VPWS? Seems not reasonable. [JY] Not sure I got your points. PE-rs will terminate the PW and switch the Ethernet frames. IMO, whether configuring the E-Tree service on a PE-rs or = a MTU-s is dependent on the topology of the service and how they are attached= . H-VPLS can be seen as a transparent transport network, or as a service itself. Thanks, Sam -----Original Message----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20 Sent: Monday, April 23, 2012 9:59 AM To: Sam Cao Cc: l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 95, Issue 58 Hi Sam, If E-Tree service is provided in a scenario as Fig. 3 and Fig 4 in RFC 4762= , then a CE (leaf or root) is connected to the MTU-s or PE-r, thus the AC should be terminated and the E-Tree service should be encapsulated by the MTU-s or PE-r. I don't quite understand why you need to "take VPWS PW as on= e AC", but even in that case, the attribute of the AC may be configured at th= e PE-rs. So what is the problem for H-VPLS? Thanks Yuanlong Date: Sun, 22 Apr 2012 22:03:52 +0800 From: "Sam Cao" To: "'Jiangyuanlong'" Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <962A848896EF4678B17D76C826A7EAEF@v2comsam> Content-Type: text/plain; charset=3D"us-ascii" Yuanlong, I just collect all issues we discussed before, and we still can not make agreement. I gave my comments on 2 items below. I will think other items over and give my comments tomorrow. 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, but can NOT configure it at all in Spoke PW case;=20 [JY] In the first place, why PE-rs need to figure out the AC type for a spoke? The VLAN should be processed in the MTU, not in the PE-rs. [Sam] Yuanlong, I understand your idea. It does NOT make sense for me. First, Fig. 3 and Fig 4 in RFC 4762 are different cases. For VPWS (Fig. 3), we can take VPWS PW as one AC. You know, PE-rs is termination of VPWS, so i= t will add VLAN-ID to identify Root/Leaf. BTW, you will map several VLAN IDs into one Root-VLAN ID or Leaf-VLAN ID on PE-rs, so we need to configure Root/Leaf on PE-rs (Refer to your reply to Josh's comments). 4) Encapsulation mode: If deploy HVPLS with Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN ID; [JY] Is anything not working with tagged PW mode? [Sam] Tagged mode works.=20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 From DanielC@orckit.com Tue Apr 24 00:17:38 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E7011E80B0 for ; Tue, 24 Apr 2012 00:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.71 X-Spam-Level: * X-Spam-Status: No, score=1.71 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_ILLEGAL_IP=1.908, RCVD_NUMERIC_HELO=2.067] 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 R2IvIsPGcfft for ; Tue, 24 Apr 2012 00:17:36 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id DEFD811E80AC for ; Tue, 24 Apr 2012 00:17:35 -0700 (PDT) Received: from 1.1.40.5 ([1.1.40.5]) by tlvmail1.corrigent.com ([1.1.40.5]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Apr 2012 07:19:41 +0000 Date: Tue, 24 Apr 2012 10:11:55 +0300 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <161901cd21ea$9d7d8486$05280101@corrigent.com> Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IA== X-MimeOLE: Produced By Microsoft Exchange V6.5 Importance: normal From: "Daniel Cohn" To: "Lucy yong" , "Rogers, Josh" , "Shahram Davari" , "Lizhong Jin" , , MIME-Version: 1.0 Cc: yuqun.cao@gmail.com X-BeenThere: l2vpn@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, 24 Apr 2012 07:17:38 -0000 Lucy,=0A= =0A= even if the current MEF framework doesn't require s-vlan preservation, I = believe it's to the industry's benefit to adopt a solution that is not = constrained to a specific enni model that, like all things networking, = is likely to evolve. Especially when such a solution is available.=0A= =0A= Daniel=0A= =0A= Thumb typed - please be tolerant=0A= =0A= Lucy yong wrote:=0A= =0A= Daniel, MEF has worked in ENNI interface for a long time with many service = providers' inputs. It had a fair reason to assume S-VLAN over ENNI by = then. It may open B-VLAN for the future. It is better for us not to = discuss a future framework here, because it will lead us to nowhere. = Here, we want to extend VPLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Daniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; = Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume = that the VLAN tags at the E-NNI will always be according to the current = MEF model? Or should we try to be as transparent as possible to user = VLAN encapsulation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case = VLAN tag) to signal VPLS information (in this case root/leaf origin) is = necessarily tied to specific assumptions on user payload encapsulation = (in this case, that S-VLAN tag is "available" to encode root/leaf). I = don't think this is a future-proof assumption, it's very likely that = other network models will come up that require S-VLAN preservation, = which in the 2-VLAN approach would necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, = "l2vpn@ietf.org" = >, = "Alexander.Vainshtein@ecitele.com" = > Cc: "yuqun.cao@gmail.com" = > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic = already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; = Alexander.Vainshtein@ecitele.com= Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the = R/L information, customer payload or PW? The customer payload will be = always modified to carry R/L information in 2-VLAN approach, while PW = with CW will carry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is = accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used = to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate = R/L information? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein = > > To: "Rogers, Josh" = >, Lucy yong > >, Daniel = Cohn >, Sam Cao > > > Cc: "l2vpn@ietf.org" = > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > = > > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very = popular, but: > > IMO one of the advantages of the CW-based solution is that it is = orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, = and, in a more generic way, localization of effects of changes in the PE = configuration. > > In particular, adding a Leaf AC to a PE that previously has been only = supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect = only the PE where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main = disadvantage of the CW-based approach - I believe it strongly depends on = specific implementations. And some changes in the forwarding process are = required in any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org = [l2vpn-bounces@ietf.org] on behalf of = Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a = more > complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become = more > complex. > > Gile's comparison slide still concisely captures the differences = between > these methods, in my opinion. I haven't seen any new ideas or = thoughts > brought to the group in the past week or two on the subject. I would = hate > for both proposed methods to die on the vine because we couldn't = decide > between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" = > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree = uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may = double >>all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn = [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the = processing >>in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP = PW >>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >>traffic coming from a root AC) >>[[LY]] Not that simple. You construct either two P2MP PWs to all other >>PEs and let egress PE performing filtering, or construct one P2MP PW = to >>leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >>perform forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so = don't >>feel terribly strong about this objection. Is this a real problem for >>others (now or in the future), or is this objection in the weeds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. = I >>encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" = > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao = [mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim = (Wim)'; >>>giles.heron@gmail.com; = simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; = Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; = Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; = Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs = after >>>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup = 2 >>>P2MP >>>PWs if need. There is no difference between P2MP or normal PW setup. = But, >>>can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with = both >>>root and leaf ACs set up two or one P2MP PW to other PEs (some PE = have >>>both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn = [mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; = Alexander.Vainshtein@ecitele.com= ; Sam Cao >>>Cc: l2vpn@ietf.org; = Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; = Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; = Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong = [mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; = simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; = Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; = Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; = Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, = both >>>approaches can benefit from it. I was off for a while and captures = some >>>discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues = with >>>silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I = am >>>not clear on all the issues. Could you be more specific? As I = mentioned >>>in below, two PW approach makes VPLS transport construction and = packet >>>forwarding more complex, I can see potential backward compatibility >>>issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree = uses >>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown = unicast >>>traffic, and some P2MP PWs for multicast traffic. It may double all = of >>>them. >>> >>>E-tree is an Ethernet service and there is already VLAN based = solution >>>in IEEE, can we just utilize it without complicating VPLS transport >>>construction? This also makes interworking with Eth only network = easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh = [mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); = 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; = 'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; = 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; = 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; = 'Rotem.Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are = you >>>saying that you no longer are interested in that method in preference = of >>>the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org] On Behalf >>>Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; = 'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; = 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; = 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; = 'Rotem.Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron = [mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord = >; Alexander = Vainshtein >>>> >>>Cc: l2vpn@ietf.org = >; Vladimir Kleiner >>>>; = Andrew Sergeev >>>>; Idan = Kaspit >; >>>Mishael Wexler = >; Rotem = Cohen >>>> >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly = have >>>put in a third column on the CW approach. And hopefully the minutes >>>will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to = be >>>forming around the two alternatives of two PWEs or two VLANs. I = believe >>>three of the authors of the CW approach are also authors of the two = VLAN >>>approach and one is also an author of the two PWE approach. So = perhaps >>>it's best to let those four individuals say which approach they = prefer >>>and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" = > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of = various >>>> solution drafts off the mailing list. As far as I know, no = consensus >>>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>>> think the CW approach has not been rejected by the WG yet, or the = WG >>>> has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein = > >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree = approaches >>>>> based on dedicated VLANs (as in >>>>> = http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> = http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in = the >>>>> PWs connecting the PEs (as in >>>>> = http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but = I >>>>> wonder whether the WG has taken a decision to reject the approach >>>>> based on the CW usage? I do not remember any recent discussion of >>>>> this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and = contains >>>>> information which is CONFIDENTIAL and which may be proprietary to = ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original = and >>>>> all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or = subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is = addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action = taken >>>in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject = to >>copyright belonging to Time Warner Cable. This E-mail is intended = solely >>for the use of the individual or entity to which it is addressed. If = you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies = thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** From giles.heron@gmail.com Tue Apr 24 01:35:13 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7366621F870F for ; Tue, 24 Apr 2012 01:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+7p-aUFdMzl for ; Tue, 24 Apr 2012 01:35:12 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A8FE721F8707 for ; Tue, 24 Apr 2012 01:35:11 -0700 (PDT) Received: by werb10 with SMTP id b10so306186wer.31 for ; Tue, 24 Apr 2012 01:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=1Yu/G90+CyXJZ2Kj1L3xC/rRJXQrYqfSPEHIbTreeG4=; b=gIed15NnOeypTqMIBNEqm0TrZJ+X0wkqk5EXC5/fe7Cc+jHmMwmgLGkMCD7H0+Uvoc QwAHX/4RT+yeBVy7COjX8zhrFQyp6yuqMnn4xhp0SnkOHunrJB1H3Bh73Gah4661caDK 7XGwu4nitZwSq7uUaBxPiEP/xuxnhy3r3bXY2bjXqmDkqZ95llg1LzkG/gpackRuq0D6 QrS8Fo+8CMC+mvWFpUGNMRZkLXdXQ8a9bEOoxZ4yrTtrhiHgfuk+3FE3KDheoJ+yqocL 3+HYKo0d+kudl7EHPgN8ISdd5Ex3xiuuBeC6e8eEduHl4/amL+QUQKOWxAr0Cihk3soX 1qUA== Received: by 10.180.98.8 with SMTP id ee8mr438638wib.14.1335256510651; Tue, 24 Apr 2012 01:35:10 -0700 (PDT) Received: from [10.147.56.203] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id gd4sm44625052wib.6.2012.04.24.01.35.06 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Apr 2012 01:35:07 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 24 Apr 2012 08:43:46 +0100 Subject: Re: The status of the approaches to the E-Tree solution? From: Giles Heron To: "Henderickx, Wim (Wim)" , "Rogers, Josh" , Lucy yong , Daniel Cohn , Sam Cao Message-ID: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0dnXD9UVUxLczlQcuCg6PfIJz+AwAS5//wAQE6bI8= In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D670129623CA0@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 24 Apr 2012 08:35:13 -0000 On 19/04/2012 06:03, "Henderickx, Wim (Wim)" wrote: > > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > Rogers, Josh > Sent: woensdag 18 april 2012 21:57 > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > WH> we have a number of customers using it, which also want to deploy ETREE > with it. They use it mainly to Optimize BUM and multicast traffic. Which makes sense. And on that basis I'd expect to see more requirement for P2MP from root to leaves than the reverse. Firstly because there tend to be more leaves than roots (so there's more benefit in efficient replication), and secondly because many providers want to stream IP multicast from roots to leaves. > I'm under the impression that adding P2MP to any model results in a more > complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become more > complex. > > Gile's comparison slide still concisely captures the differences between > these methods, in my opinion. I haven't seen any new ideas or thoughts > brought to the group in the past week or two on the subject. I would hate > for both proposed methods to die on the vine because we couldn't decide > between two methods that have nothing inherently wrong with either. > > WH> I don't think we want to kill both but the idea is to come to 1 solution. > As I expressed before the VLAN approach is naturally supporting P2P or P2MP > LSPs since it is independent of the PW construction since the ETREE decision > is taken outside the PW. Right. Giles > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" wrote: > >> Send this again. >> >> Two PW approach can be complex too if the VPLS instance for E-Tree uses >> P2P PW for unicast traffic and P2MP PW for broadcast and unknown >> unicast traffic, and some P2MP PWs for multicast traffic. It may double >> all of them. >> >> Lucy >> >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: Wednesday, April 18, 2012 1:42 PM >> To: Lucy yong; Rogers, Josh; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> I think the first option its the natural way to go. How is the processing >> in this case more complex? >> >> Thumb typed - please be tolerant >> >> Lucy yong wrote: >> >> >> >> Snipped.. >> >> Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >> (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >> traffic coming from a root AC) >> [[LY]] Not that simple. You construct either two P2MP PWs to all other >> PEs and let egress PE performing filtering, or construct one P2MP PW to >> leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >> perform forwarding and filtering. Both make node process complex. >> >> [[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >> delivering the frames to remote PEs. We should utilize them with the >> minimized changes. Dual VLAN solution is simpler than Dual PW. >> >> Regards, >> Lucy >> >> >> I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >> haven't had any first hand experience with P2MP PW's, however, so don't >> feel terribly strong about this objection. Is this a real problem for >> others (now or in the future), or is this objection in the weeds? >> >> I'm not sure the 'additional complexity' is notable, or even relevant. I >> encourage others to speak up if they disagree, as P2MP PW is only >> conceptual to me, and I am unfamiliar with real-life use cases for it. >> >> Thanks, >> Josh >> >> >> >> On 4/18/12 10:30 AM, "Lucy yong" wrote: >> >>> Please see inline. >>> >>> -----Original Message----- >>> From: Sam Cao [mailto:yuqun.cao@gmail.com] >>> Sent: Tuesday, April 17, 2012 7:14 AM >>> To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>> giles.heron@gmail.com; simon.delord@gmail.com; >>> Alexander.Vainshtein@ecitele.com >>> Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>> Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>> Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> Yes, 2 pws are only needed between pes with both root and leaf acs after >>> improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>> P2MP >>> PWs if need. There is no difference between P2MP or normal PW setup. But, >>> can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>> [[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>> root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>> both root and leaf AC and some only have leaf ACs)? >>> Regards, >>> Lucy >>> >>> Regards, >>> >>> Yuqun (Sam) Cao >>> E-mail: Yuqun.cao@gmail.com >>> >>> >>> -----Original Message----- >>> From: Daniel Cohn [mailto:DanielC@orckit.com] >>> Sent: Tuesday, April 17, 2012 4:56 PM >>> To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>> giles.heron@gmail.com; >>> simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >>> Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>> Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>> Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> Adding Sam (as l2vpn@ is holding messages) >>> >>> DC >>> >>> -----Original Message----- >>> From: Lucy yong [mailto:lucy.yong@huawei.com] >>> Sent: Tuesday, April 17, 2012 12:39 AM >>> To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>> giles.heron@gmail.com; simon.delord@gmail.com; >>> Alexander.Vainshtein@ecitele.com >>> Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>> Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>> Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>> Snipped, >>> >>> As we discussed extensively in the list, and as reflected in giles >>> slide, 2 pws are only needed between pes with both root and leaf acs, >>> which will typically be a small minority. >>> [[LY]] Don't know if the assumption is true. Even it is the case, both >>> approaches can benefit from it. I was off for a while and captures some >>> discussions now. >>> >>> Also as per giles slide, dual vlan can have scalability issues due to >>> additional lookup and double use of vlans in internal emulated lan >>> interface. Also there are potential backward compatibility issues with >>> silicon that doesn't support vlan mapping. >>> [[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>> not clear on all the issues. Could you be more specific? As I mentioned >>> in below, two PW approach makes VPLS transport construction and packet >>> forwarding more complex, I can see potential backward compatibility >>> issues with 2 PW solution. >>> >>> Regards, >>> Lucy >>> >>> Regards, >>> >>> Daniel >>> >>> Thumb typed - please be tolerant >>> >>> Lucy yong wrote: >>> >>> In my mind, the VLAN approach means dual vlan method. >>> >>> The main concern for CW approach is hardware support. >>> >>> Two PW approach can be complex too if the VPLS instance for E-Tree uses >>> P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>> traffic, and some P2MP PWs for multicast traffic. It may double all of >>> them. >>> >>> E-tree is an Ethernet service and there is already VLAN based solution >>> in IEEE, can we just utilize it without complicating VPLS transport >>> construction? This also makes interworking with Eth only network easier. >>> >>> Cheers, >>> Lucy >>> >>> -----Original Message----- >>> From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>> Sent: Monday, April 16, 2012 8:35 AM >>> To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>> 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>> Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>> 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>> 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> I believe the initial question was in regard to the CW method. Are you >>> saying that you no longer are interested in that method in preference of >>> the dual vlan method? >>> >>> >>> >>> Lucy yong wrote: >>> >>> >>> Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>> Lucy >>> >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>> Of Henderickx, Wim (Wim) >>> Sent: Thursday, April 12, 2012 2:03 AM >>> To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>> 'Alexander.Vainshtein@ecitele.com' >>> Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>> 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>> 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>> Subject: Re: The status of the approaches to the E-Tree solution? >>> >>> The vlan approach is superior as it also works for eth only networks, >>> etc. On top some vendors indicate hw issues with the cw approach. As >>> such we have dropped more or less the cw approach. >>> >>> Cheers, >>> Wim >>> _________________ >>> sent from blackberry >>> >>> ----- Original Message ----- >>> From: Giles Heron [mailto:giles.heron@gmail.com] >>> Sent: Thursday, April 12, 2012 08:22 AM >>> To: Simon Delord ; Alexander Vainshtein >>> >>> Cc: l2vpn@ietf.org ; Vladimir Kleiner >>> ; Andrew Sergeev >>> ; Idan Kaspit ; >>> Mishael Wexler ; Rotem Cohen >>> >>> Subject: Re: The status of the approaches to the E-Tree solution? >>> >>> Sorry - the "anonymous presentation" was mine. I should possibly have >>> put in a third column on the CW approach. And hopefully the minutes >>> will be posted soon. >>> >>> We had various discussions, as Simon stated, and consensus seemed to be >>> forming around the two alternatives of two PWEs or two VLANs. I believe >>> three of the authors of the CW approach are also authors of the two VLAN >>> approach and one is also an author of the two PWE approach. So perhaps >>> it's best to let those four individuals say which approach they prefer >>> and why? >>> >>> Giles >>> >>> On 10/04/2012 00:45, "Simon Delord" wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of various >>>> solution drafts off the mailing list. As far as I know, no consensus >>>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>>> think the CW approach has not been rejected by the WG yet, or the WG >>>> has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree approaches >>>>> based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>>> ext=1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>>> clude_te >>>>> xt=1) >>>>> and completely ignores the solution based on usage of the CW in the >>>>> PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>>> ext=1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>>> wonder whether the WG has taken a decision to reject the approach >>>>> based on the CW usage? I do not remember any recent discussion of >>>>> this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and contains >>>>> information which is CONFIDENTIAL and which may be proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original and >>>>> all copies thereof. >>>>> >>> >>> >>> >>> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>> proprietary information, which is privileged, confidential, or subject >>> to copyright belonging to Time Warner Cable. This E-mail is intended >>> solely for the use of the individual or entity to which it is addressed. >>> If you are not the intended recipient of this E-mail, you are hereby >>> notified that any dissemination, distribution, copying, or action taken >>> in relation to the contents of and attachments to this E-mail is >>> strictly prohibited and may be unlawful. If you have received this >>> E-mail in error, please notify the sender immediately and permanently >>> delete the original and any copy of this E-mail and any printout. >>> >> >> >> This E-mail and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or subject to >> copyright belonging to Time Warner Cable. This E-mail is intended solely >> for the use of the individual or entity to which it is addressed. If you >> are not the intended recipient of this E-mail, you are hereby notified >> that any dissemination, distribution, copying, or action taken in >> relation to the contents of and attachments to this E-mail is strictly >> prohibited and may be unlawful. If you have received this E-mail in >> error, please notify the sender immediately and permanently delete the >> original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely for > the use of the individual or entity to which it is addressed. If you are not > the intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify the sender > immediately and permanently delete the original and any copy of this E-mail > and any printout. From giles.heron@gmail.com Tue Apr 24 01:35:18 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84EAA21F871E for ; Tue, 24 Apr 2012 01:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clkoeZMAOT0a for ; Tue, 24 Apr 2012 01:35:17 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 42E3B21F8715 for ; Tue, 24 Apr 2012 01:35:17 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id b10so306186wer.31 for ; Tue, 24 Apr 2012 01:35:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=ucsfw9kFVxifCwL83A/qN88oDBG4V9irmy9fRK5NzfU=; b=j5e7dxkT+Wo7FsPqVYOpc1lTod9C0graBvQa/ibMb6z6syjKct+AoIw6/qR/DqipG2 Up2kSV+vR1JXJZ5/Iv+WQYgoFLxN0ZGLrDbVXYWc/CeCdDSr9XY2Cy0vV2v/VkVo8+Qb y4dwf2ruMGcBDqSj2eI3aPeEp7KtQD5++1pjfg2pNzmZtoeRAmJy7rwt6by3YBeF4scx YhQp8Q/GBe3hO5CHWVJ726MiIvnS+S000U9vSOmuxzUe2KE6diWFRrFZOBbDkZ9Y7Dnu r4eHOiSqCmMxmldOTGxesw+cMLq13DXzC1AlhyawgFbxD2bAEW2vuVdylA21iTxPx9Lq r1xg== Received: by 10.180.100.2 with SMTP id eu2mr29117569wib.1.1335256516697; Tue, 24 Apr 2012 01:35:16 -0700 (PDT) Received: from [10.147.56.203] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id gd4sm44625052wib.6.2012.04.24.01.35.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Apr 2012 01:35:15 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 24 Apr 2012 08:46:13 +0100 Subject: Re: The status of the approaches to the E-Tree solution? From: Giles Heron To: Lizhong Jin , Message-ID: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0h7lJI+IXiwds5xUmtcx6SZR/UZA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: l2vpn@ietf.org, yuqun.cao@gmail.com X-BeenThere: l2vpn@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, 24 Apr 2012 08:35:18 -0000 On 19/04/2012 08:21, "Lizhong Jin" wrote: > [snipped...] >> Yes, 2 pws are only needed between pes with both root and leaf acs after >> improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 > P2MP >> PWs if need. There is no difference between P2MP or normal PW setup. > But, >> can Leaf-ACs be bound to Root PE of P2MP PW? >> >> [[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >> both root and leaf ACs set up two or one P2MP PW to other PEs (some >> PE have both root and leaf AC and some only have leaf ACs)? >> Regards, >> Lucy > [Lizhong] a bit arbitrary to say "complex" here. Both have PROS and CONS. > If 2-PW approach uses two P2MP PW, the BUM traffic from leaf would be only > to root, and BUM traffic from root would be only to leaf. While if 2-VLAN > approach uses only one P2MP PW, the BUM traffic from leaf would be also to > other leaf only nodes, and filtered at egress node, which wastes the > traffic bandwidth in the network. As I said in my last email I'm not sure there's a great need for P2MP from leaves. And P2MP from roots needs to go to all roots and leaves of course. But there would be a slight inefficiency if a node with roots and leaves sent leaf traffic over a P2MP PW to all other nodes - as leaf-only nodes wouldn't need to see those packets. > Thanks > Lizhong > > >> >> Regards, >> >> Yuqun (Sam) Cao >> E-mail: Yuqun.cao@gmail.com >> >> >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: Tuesday, April 17, 2012 4:56 PM >> To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); > giles.heron@gmail.com; >> simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >> Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >> Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >> Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> Adding Sam (as l2vpn@ is holding messages) >> >> DC >> >> -----Original Message----- >> From: Lucy yong [mailto:lucy.yong@huawei.com] >> Sent: Tuesday, April 17, 2012 12:39 AM >> To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >> giles.heron@gmail.com; simon.delord@gmail.com; >> Alexander.Vainshtein@ecitele.com >> Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >> Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >> Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> >> Snipped, >> >> As we discussed extensively in the list, and as reflected in giles >> slide, 2 pws are only needed between pes with both root and leaf acs, >> which will typically be a small minority. >> [[LY]] Don't know if the assumption is true. Even it is the case, both >> approaches can benefit from it. I was off for a while and captures some >> discussions now. >> >> Also as per giles slide, dual vlan can have scalability issues due to >> additional lookup and double use of vlans in internal emulated lan >> interface. Also there are potential backward compatibility issues with >> silicon that doesn't support vlan mapping. >> [[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >> not clear on all the issues. Could you be more specific? As I mentioned >> in below, two PW approach makes VPLS transport construction and packet >> forwarding more complex, I can see potential backward compatibility >> issues with 2 PW solution. >> >> Regards, >> Lucy >> >> Regards, >> >> Daniel >> >> Thumb typed - please be tolerant >> >> Lucy yong wrote: >> >> In my mind, the VLAN approach means dual vlan method. >> >> The main concern for CW approach is hardware support. >> >> Two PW approach can be complex too if the VPLS instance for E-Tree uses >> P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >> traffic, and some P2MP PWs for multicast traffic. It may double all of >> them. >> >> E-tree is an Ethernet service and there is already VLAN based solution >> in IEEE, can we just utilize it without complicating VPLS transport >> construction? This also makes interworking with Eth only network easier. >> >> Cheers, >> Lucy >> >> -----Original Message----- >> From: Rogers, Josh [mailto:josh.rogers@twcable.com] >> Sent: Monday, April 16, 2012 8:35 AM >> To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >> 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >> Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >> 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >> 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >> Subject: RE: The status of the approaches to the E-Tree solution? >> >> I believe the initial question was in regard to the CW method. Are you >> saying that you no longer are interested in that method in preference of >> the dual vlan method? >> >> >> >> Lucy yong wrote: >> >> >> Agree with Wim. VLAN approach is the best solution for E-Tree. >> >> Lucy >> >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Henderickx, Wim (Wim) >> Sent: Thursday, April 12, 2012 2:03 AM >> To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >> 'Alexander.Vainshtein@ecitele.com' >> Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >> 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >> 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> The vlan approach is superior as it also works for eth only networks, >> etc. On top some vendors indicate hw issues with the cw approach. As >> such we have dropped more or less the cw approach. >> >> Cheers, >> Wim >> _________________ >> sent from blackberry >> >> ----- Original Message ----- >> From: Giles Heron [mailto:giles.heron@gmail.com] >> Sent: Thursday, April 12, 2012 08:22 AM >> To: Simon Delord ; Alexander Vainshtein >> >> Cc: l2vpn@ietf.org ; Vladimir Kleiner >> ; Andrew Sergeev >> ; Idan Kaspit ; >> Mishael Wexler ; Rotem Cohen >> >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Sorry - the "anonymous presentation" was mine. I should possibly have >> put in a third column on the CW approach. And hopefully the minutes >> will be posted soon. >> >> We had various discussions, as Simon stated, and consensus seemed to be >> forming around the two alternatives of two PWEs or two VLANs. I believe >> three of the authors of the CW approach are also authors of the two VLAN >> approach and one is also an author of the two PWE approach. So perhaps >> it's best to let those four individuals say which approach they prefer >> and why? >> >> Giles >> >> On 10/04/2012 00:45, "Simon Delord" wrote: >> >>> Hi Alexander, >>> >>> You are right, no discussion on the WG mailing list recently, but >>> there have been substantial discussions among the authors of various >>> solution drafts off the mailing list. As far as I know, no consensus >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>> think the CW approach has not been rejected by the WG yet, or the WG >>> has not yet decided on which one to adopt. >>> >>> Simon >>> >>> 2012/4/8 Alexander Vainshtein >>> >>>> Hi all, >>>> >>>> Unfortunately I have not been able to attend the Paris IETF. >>>> >>>> However, looking up the L2VPN proceedings, I've found a short >>>> anonymous presentation called "E-Tree Update" ( >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>> This presentation discusses the differences of the E-Tree approaches >>>> based on dedicated VLANs (as in >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>> ext=1) and multiple PWs between the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>> clude_te >>>> xt=1) >>>> and completely ignores the solution based on usage of the CW in the >>>> PWs connecting the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>> ext=1 >>>> ). >>>> >>>> >>>> >>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>> wonder whether the WG has taken a decision to reject the approach >>>> based on the CW usage? I do not remember any recent discussion of >>>> this topic on the WG mailing list. >>>> >>>> >>>> >>>> Regards, and lots of thanks in advance, >>>> >>>> Sasha >>>> >>>> >>>> >>>> >>>> >>>> This e-mail message is intended for the recipient only and contains >>>> information which is CONFIDENTIAL and which may be proprietary to ECI >> >>>> Telecom. If you have received this transmission in error, please >>>> inform us by e-mail, phone or fax, and then delete the original and >>>> all copies thereof. >>>> >> >> >> >> From yuqun.cao@gmail.com Mon Apr 23 20:04:33 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9F211E8073 for ; Mon, 23 Apr 2012 20:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.753 X-Spam-Level: X-Spam-Status: No, score=-0.753 tagged_above=-999 required=5 tests=[AWL=-1.089, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, MIME_CHARSET_FARAWAY=2.45, 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 EdnKY+kmD6w0 for ; Mon, 23 Apr 2012 20:04:23 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D92BA11E8072 for ; Mon, 23 Apr 2012 20:04:22 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so4615355pbb.31 for ; Mon, 23 Apr 2012 20:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:x-mailer:in-reply-to:thread-index:x-mimeole; bh=m7kOfHbNtfaqvOiZ+1QAimMz0uRo8NKzihlCgveBoyU=; b=hjukoEo3P9mdT5hLONQF3ErlKihcg0Jgvm5Si1NRjwwT4dFjUK1WioA6dpEq7g6i7b CgWpMK1iyplFPpJR+8rjjJIuKCKd0F1OAEA62CbUON4QVz12SnwFCZPwJ6CZjLB8RVga nUJXgTHT2CMc63YnMeYTRztqiCr+X9vLlj2DfQ8LwGuYeYdQMXpqB716hzV2mWQeGoDO 6Jih0pap2sPyw8Z4xyddg3PLvvUWqRDijO6HvD1XIsxCRmbAqwAo9jlu/Muw244vH/0r 1+NH6HZ16Z5+fdwQPSZzyb9tnJaKmrL6FWQYVyTcWMfZ7mJCs0I4IXoTU4Lob1ejXXb4 RpjQ== Received: by 10.68.220.232 with SMTP id pz8mr158761pbc.87.1335236662434; Mon, 23 Apr 2012 20:04:22 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id qs6sm16100348pbb.29.2012.04.23.20.04.06 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 20:04:20 -0700 (PDT) From: "Sam Cao" To: "'UTTARO, JAMES'" , "'Alexander Vainshtein'" References: , <14C7F4F06DB5814AB0DE29716C4F6D6701296244C3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>, , <1B88357C808B432E871CA9D678305B7C@v2comsam><6F9ADEDA06A04AB98C247D303AFE93BE@v2comsam> <13822856E9C84A49BBF95D1867C5FF11@R01842> Subject: RE: The status of the approaches to the E-Tree solution? Date: Tue, 24 Apr 2012 11:04:03 +0800 Message-ID: <2020DC11F96047A18EA2288A9F6EDB97@R01842> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01CD2209.FC83AB70" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-index: AQHNHxPnxbisvEh3kk6CwsWQjlzY35akOniAgACwqQCAALY7AIAAC0AAgAFzRgCAAARQAIAAB2IAgAAJkwCAAEmWAIAARubAgACsKxCAANRbYA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Mailman-Approved-At: Tue, 24 Apr 2012 01:56:15 -0700 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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, 24 Apr 2012 03:04:33 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002B_01CD2209.FC83AB70 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Jim, =20 I see. Let me summarize what we discussed. =20 You gave me one new solution to implement E-Tree: create 2 VSIs (VRF in = your mail) on a common PE, one for Root, and another for Leaf. If so, one =A1=B0DUMMY=A1=B1 or =A1=B0NATIVE=A1=B1 PW should be established (then = it =A1=B0appears=A1=B1 same as frames from external interface), VSI management is a little = difficult, and we also need to update our data plane to support this. In addition, encapsulation and decapsulation are needed for native forwarding. But as = I know, most vendors do NOT support this, CW. Dual-VLAN or multi-PW = approach would implement E-Tree in one VSI, not separate it into 2 VSIs. For me, = ONE VSI is a little better.=20 =20 Solution space of Multi-PW approach is =A1=B0Multi-PW=A1=B1, or say, = different =A1=B0PATH=A1=B1, not inferring context from data traffic. CW or = Dual-VLAN uses inferring context from data traffic: CW uses one LEAF bit in = control-word, and Dual-VLAN uses 2 S-VLAN-ID in the frames. =20 Thanks, =20 Sam _____ =20 From: UTTARO, JAMES [mailto:ju1738@att.com]=20 Sent: Monday, April 23, 2012 9:56 PM To: 'Sam Cao'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? =20 Sam, =20 Comments In-Line.. =20 Thanks, Jim Uttaro =20 From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Monday, April 23, 2012 12:06 AM To: UTTARO, JAMES; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? =20 Hi Jim, =20 Thank you very much for your comments. But what we did is a little = different from yours. =20 Multi-PW carries AC type in =A1=B0Layer2 Info Extended Community=A1=B1, = NOT different RT, and control plane will translate it, but we don=A1=AFt = separate it into 2 VRFs (VSI in the draft). They belong to one VSI.=20 =20 I guess your E-Tree deployment via BGP-AD is, assign one Root-RT (same = in all VPLA-PE in VPLS domain), and assign different Leaf RT for each = Leaf-only PE, then we will not setup PW between Leaf-only PEs, then we can break = the communication between Leaf-Only PEs. Is my understanding correct or not? This is Hub-Spoke deployment, and current solution can support this. But = it can not cover all cases. [Jim U>] That is the approach but as you note = it does not cover all cases.. =20 I agree with some requirements on E-Tree in your mail. =20 - Partial mesh topologies.=20 [Sam] Agree. Now CW, Dual-VLAN or Dual-PW consider this in draft, but = for me, CW or Dual-VLAN will deploy partial mesh in your way or configure it manually; Dual-PW can support this via signaling.=20 - Same PE mush be able to host Root and Leaf Sites.=20 [Sam] Agree. This is Root-Leaf-Mixed case in all E-tree draft; All = drafts should support this. - Disallowing of Leaf to Leaf traffic on the same PE must be = done using PW semantics.=20 [Sam] Jim, can not fully understand this case. If on same PE, this is = local behavior, is it correct? Do you mean we need to setup one dummy PW on = any PE if it hosts Root and Leaf sites? Shall we describe in draft? [Jim U>] If two VRFs one Leaf and one Root on a common PE traffic when = sent from the Leaf to the Root context must not be treated as native ethernet traffic as it would then =A1=B0appear=A1=B1 the same as traffic arriving = from external ethernet interfaces.. In this regard you lose the notion that a leaf semantic is associated with that traffic..=20 - When Root and Leaf sites are deployed on the same PE the = packets between them should obey the same semantics as if they had traversed a = PW i. e ( Split Horizon, No Label Re-Imposition etc=A1=AD ).=20 [Sam] Same question as above. Anyway, =A1=B0Split Horizon=A1=B1 is basic = rule for all drafts. [Jim U>] See above.. Sort of the same requirement as stated above.. I believe that the local behavior intra-PE between a Leaf and a Root = should mimic the behavior as if the traffic arrived from a different PE>.. - If PE has a root and leaf site and sends traffic to PE1. PE1 should be able to decide if the traffic was sourced from the root or = leaf site. If from PE:Leaf then the traffic should not be resolved in = PE1:Leaf.=20 [Sam] Yes, what we are doing is to solve this. [Jim U>] I have not been following E-Tree too closely is this where the solution space is multiple PWs or inferring context from data traffic?=20 =20 Thanks, =20 Sam _____ =20 From: UTTARO, JAMES [mailto:ju1738@att.com]=20 Sent: Monday, April 23, 2012 7:27 AM To: 'Alexander Vainshtein'; Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? =20 For a given PE, If you use BGP and define separate VRFs one for the = leafs and one for roots than the semantic provided by the RT assignment should = be translated correctly in to the forwarding programmed.. This means that intra-PE between the leaf and root VRF should be treated as a Labeled = PW. If treated as a regular ethernet interface than a leaf on VRF S1 can = forward traffic on VRF H1 and then onto a different PEs leaf VRF=A1=AD I believe = we had a very similar conversation over a year ago about E-Tree=A1=AD=20 =20 So, here are the reqs I shared=20 =20 * E-Tree/Partial mesh topologies need to be realized in the = control plane by constructing PWs. The data plane should not infer a topology. = In other words data should not have to be inspected to determine if the = packet is sourced from a leaf or a root * The same PE must be able to host Root and Leaf sites.=20 * Disallowing of Leaf to Leaf traffic on the same PE must be = done using PW semantics. * When Root and Leaf sites are deployed on the same PE the = packets between them should obey the same semantics as if they had traversed a = PW i. e ( Split Horizon, No Label Re-Imposition etc=A1=AD ) * If PE has a root and leaf site and sends traffic to PE1. PE1 should be able to decide if the traffic was sourced from the root or = leaf site. If from PE:Leaf then the traffic should not be resolved in = PE1:Leaf. =20 =20 Jim Uttaro From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Alexander Vainshtein Sent: Sunday, April 22, 2012 10:57 AM To: Sam Cao Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? =20 Sam, I will try to explain myself. =20 I have misspoken before, and I owe you an apology. =20 A true legacy PE cannot operate as a Mixed PE for E-tree since this operation requires some changes in the forwarding behavior. This is IMHO correct regardless of the specific E-tree solution that is implemented = by the rest of the PEs (CW-based, dual PW-based or VLAN-based). I.e. = without some additional implementation-specific tricks it can be either a = Root-only PE or a Leaf-only PE in the VPLS that does not contain Mixed PEs. =20 Regards, Sasha =20 From: Sam Cao [mailto:yuqun.cao@gmail.com]=20 Sent: Sunday, April 22, 2012 5:22 PM To: Alexander Vainshtein Cc: l2vpn@ietf.org; 'Raymond Key' Subject: RE: The status of the approaches to the E-Tree solution? =20 Sasha, =20 I agree with your comments. But maybe I don=A1=AFt make myself = understood. I make it clear. =20 If one chip can not support control word, then one switch which uses = this chip can not work as Root-Leaf-Mixed PE since we can not extend it. Is = this correct? Is this reasonable? =20 Anyway, chip limit is big problem for CW approach. =20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 _____ =20 From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Sunday, April 22, 2012 9:56 PM To: Sam Cao Cc: l2vpn@ietf.org; 'Raymond Key' Subject: RE: The status of the approaches to the E-Tree solution? =20 Sam, You=A1=AFve asked: If it only supports VPLS, ok, it can work as Root-only, but why it = cannot work as Root-Leaf-Mixed or Leaf-only if it cannot support CW? IMHO and FWIW there is not too much you can expect from a true legacy PE = (i. e. a PE that did not change its forwarding behavior): 1. It can obviously support Root-only functionality 2. It can support Leaf-only functionality if there are no Mixed by preventing setup PW (by not setting up PWs to other Leaf-only PEs). Anything beyond that would be very much implementation-specific. E.g., I = am aware of legacy implementations that could support functionality of a = Mixed PE provided that it would be the only Mixed PE in the VPLS instance, and other legacy implementations that are, as legacy, fully interoperable = with these ones but could not support such functionality. =20 My 2c, Sasha =20 From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Sam Cao Sent: Sunday, April 22, 2012 4:41 PM To: 'Raymond Key' Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? =20 Raymond, =20 Network efficiency: [Sam] Leaf/Root configuration is local configuration, and PE can not = know remote AC type configuration. This is CW Fundamentals. So even if CW approach defines optional enhancement for Leaf-Only PE, but can not = signal it between Leaf-Only PEs, so there is no good way to support this. The possible solution is, manually configure hub-spoke topology, but if we = do like this, current solutions have support most E-Tree cases with = Hub-Spoke configuration. Lizhong mentioned this in one mail. =20 Backwards compatibility: [Sam] Yes, new draft considers backward compatibility, but it makes precondition: The PE which can not support Control word only works as Root-only PE. This does not make sense for me. If it only supports VPLS, = ok, it can work as Root-only, but why it can not work as Root-Leaf-Mixed or Leaf-only if it can not support CW? =20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 _____ =20 From: raymond.key@hotmail.com [mailto:raymond.key@hotmail.com] On Behalf = Of Raymond Key Sent: Saturday, April 21, 2012 11:32 PM To: yuqun.cao@gmail.com Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? =20 Some clarifications [RK] inserted below Thanks Raymond Key _____ =20 From: yuqun.cao@gmail.com To: lizho.jin@gmail.com; wim.henderickx@alcatel-lucent.com Subject: RE: The status of the approaches to the E-Tree solution? Date: Sat, 21 Apr 2012 22:51:28 +0800 CC: l2vpn@ietf.org Hi all, =20 We reach an impasse:-). BTW, Meeting minutes is ready now. We can get E-tree summary from IETF site. =20 Today I collected all items we discussed before. They are, =20 1) Silicon issue or chip limit; 2) Network efficiency; 3) Encapsulation mode, tag or raw; 4) H-VPLS; 5) Backwards compatibility, especially legacy PE or Non-supporting = PE with IEEE E-tree support joins E-Tree domain; 6) Configuration change in operation, for example, Leaf-only -> Root-Leaf-Mixed; 7) S-VLAN preservation support; 8) Multi-segment PW; 9) VLAN ID allocation (Only for Dual-VLAN); 10) Multi-AS deployment; 11) ECMP; 12) P2MP-PW; 13) Ethernet OAM; =20 If we review the mail-list, CW approach has the following limits: 1) Chip limit. Please read reply from Giles and Wim; 2) Network efficiency: There are garbage fames which will be = dropped on egress PE since only egress PE can decide forward or drop frames = while it receives frames. Ingress PE can not decide forward or not. Yes, current solution can support Hub-Spoke configuration, but as we know, the configuration is not easy if the network is big. Dual-VLAN or Multi-PW approach can break communication between Leaf-Only PEs via signaling. [RK] It seems to me this is not the case. Section 6 of the draft has = some discussions on this. http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-6 6. Optional Enhancements for Leaf-only PE 6.1. No PW between Leaf-only PEs 6.2. Not Forward Frame from Leaf AC to Leaf-only PE =20 3) Backwards compatibility: Not all PEs supports control word. If = one can not support control word, it will not join E-Tree domain; =20 [RK] It seems to me this is not the case. Section 5 of the draft has = some discussions on this. http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-5 5. Backward Compatibility 5.1. AC Type 5.2. Control Word 5.3. Additional Action in Data Forwarding 5.3.1. Ingress PE Supporting the Extension but Egress PE Not 5.3.2. Egress PE Supporting the Extension but Ingress PE Not =20 Dual VLAN has following limits: 1) Chip limit: As we know, we need to push one VLAN into frames = before MPLS encapsulation on ingress PE and stripe it out on egress PE. This is non-standard operation. Wait for confirmation from chip vendor; 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, but can NOT configure it at all in Spoke PW case; 3) Multi-PW: Rafi figures this out, but we don=A1=AFt think this = over at that time. I think that it also has same problem as H-VPLS has. 4) Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will stripe = S-VLAN ID; 5) Backward Compatibility: Just as Daniel mentioned, there is compatibility issue if legacy PE joins E-Tree domain. For me, I = don=A1=AFt get clear response from co-authors of Dual-VLAN. =20 For all approaches, we don=A1=AFt cover ECMP / Ethernet OAM till now.=20 =20 Is there anything missed?=20 =20 Regards, =20 Yuqun (Sam) Cao E-mail: Yuqun.cao@gmail.com=20 =20 _____ =20 From: Lizhong Jin [mailto:lizho.jin@gmail.com]=20 Sent: Saturday, April 21, 2012 11:59 AM To: Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; = yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? =20 Hi Win, Thank you for the answers. In that case, PE-rs should configure the root/leaf properties of VPWS, not on the remote PE of VPWS. And usually = on PE-rs, you could not figure out the accessing spoke PW is from PE-r of = VPWS or MTU-s. Unless having some additional indication in NMS, you even = don't know which spoke PW needs to do VLAN manipulation. I am not sure such = R/L configuration could be accepted from operational view. Hope to see more comments. Regards Lizhong =D4=DA 2012=C4=EA4=D4=C221=C8=D5=D0=C7=C6=DA=C1=F9=A3=ACHenderickx, Wim = (Wim) =D0=B4=B5=C0=A3=BA > The VPWS which terminates at the H-VPLS node is indicated to be root = or leaf and the procedures associated will do the VLAN manipulation > > =20 > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Lizhong Jin > Sent: vrijdag 20 april 2012 18:38 > To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com > Cc: yuqun.cao@gmail.com > Subject: RE: The status of the approaches to the E-Tree solution? > > =20 > > Hi, all, > The difference between 2-VLAN and CW approach is who will provide the = R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW = will carry R/L information for CW approach. > I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used = to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information? > > Thanks > Lizhong > >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 Apr 2012 04:38:36 +0000 >> From: Alexander Vainshtein >> To: "Rogers, Josh" , Lucy yong >> , Daniel Cohn , Sam = Cao >> >> Cc: "l2vpn@ietf.org" >> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID: >> = >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi all, >> I fully understand that that what I am going to say is not very = popular, but: >> >> IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, = and, in a more generic way, localization of effects of changes in the PE configuration. >> >> In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect only = the PE where this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a = more >> complex model. Wether outside s-tag is used to differentiate, or >> dedicated pw's are used for the same purpose, it seems both become = more >> complex. >> >> Gile's comparison slide still concisely captures the differences = between >> these methods, in my opinion. I haven't seen any new ideas or = thoughts >> brought to the group in the past week or two on the subject. I would hate >> for both proposed methods to die on the vine because we couldn't = decide >> between two methods that have nothing inherently wrong with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" wrote: >> >>>Send this again. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree = uses >>>P2P PW fo=20 This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies thereof.=20 This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies thereof.=20 ------=_NextPart_000_002B_01CD2209.FC83AB70 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable

Jim,

 <= /span>

I see. Let me = summarize what we discussed.

 <= /span>

You gave me one = new solution to implement E-Tree: create 2 VSIs (VRF in your mail) on a common PE, = one for Root, and another for Leaf. If so, one =A1=B0DUMMY=A1=B1 or = =A1=B0NATIVE=A1=B1 PW should be established (then it =A1=B0appears=A1=B1 same as frames from external = interface), VSI management is a little difficult, and we also need to update our data plane to = support this. In addition, encapsulation and decapsulation are needed for native forwarding. But as I know, most vendors do NOT support this, CW. = Dual-VLAN or multi-PW approach would implement E-Tree in one VSI, not separate it = into 2 VSIs. For me, ONE VSI is a little better.

 <= /span>

Solution space of = Multi-PW approach is =A1=B0Multi-PW=A1=B1, or say, different =A1=B0PATH=A1=B1, = not inferring context from data traffic. CW or Dual-VLAN uses inferring context from data traffic: = CW uses one LEAF bit in control-word, and Dual-VLAN uses 2 S-VLAN-ID in the = frames.

 <= /span>

Thanks,=

 <= /span>

Sam

From: UTTARO, JAMES [mailto:ju1738@att.com]
Sent: Monday, April 23, = 2012 9:56 PM
To: 'Sam Cao'; 'Alexander Vainshtein'
Cc: l2vpn@ietf.org
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Sam,

 <= /o:p>

  =             &= nbsp; Comments In-Line..

 <= /o:p>

Thanks,=

  =             &= nbsp; Jim Uttaro

 <= /o:p>

From: Sam Cao [mailto:yuqun.cao@gmail.com]
Sent: Monday, April 23, = 2012 12:06 AM
To: UTTARO, JAMES; = 'Alexander Vainshtein'
Cc: l2vpn@ietf.org
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Hi = Jim,

 <= /span>

Thank you very = much for your comments. But what we did is a little different from = yours.

 <= /span>

Multi-PW carries = AC type in =A1=B0Layer2 Info Extended Community=A1=B1, NOT different RT, and = control plane will translate it, but we don=A1=AFt separate it into 2 VRFs (VSI in the = draft). They belong to one VSI.

 <= /span>

I guess your = E-Tree deployment via BGP-AD is, assign one Root-RT (same in all VPLA-PE in = VPLS domain), and assign different Leaf RT for each Leaf-only PE, then we = will not setup PW between Leaf-only PEs, then we can break the communication = between Leaf-Only PEs. Is my understanding correct or not? This is Hub-Spoke deployment, and current solution can support this. But it can not cover = all cases. [Jim U>] That is the approach but as you note it does not = cover all cases..=

 <= /span>

I agree with some requirements on E-Tree in your mail.

 <= /span>

-          Partial mesh topologies.

[Sam] Agree. Now CW, Dual-VLAN or Dual-PW consider this in = draft, but for me, CW or Dual-VLAN will deploy partial mesh in your way or = configure it manually; Dual-PW can support this via signaling. =

-          Same PE mush be able to host Root and Leaf Sites. =

[Sam] Agree. This is Root-Leaf-Mixed case in all E-tree = draft; All drafts should support this.

-          Disallowing of Leaf to Leaf traffic on the same PE must be = done using PW semantics.

[Sam] Jim, can not fully understand this case. If on same = PE, this is local behavior, is it correct? Do you mean we need to setup one dummy = PW on any PE if it hosts Root and Leaf sites? Shall we describe in = draft?

[Jim U>] If two VRFs one Leaf and = one Root on a common PE traffic when sent from the Leaf to the Root context = must not be treated as native ethernet traffic as it would then = =A1=B0appear=A1=B1 the same as traffic arriving from external ethernet interfaces.. In this regard you = lose the notion that a leaf semantic is associated with that traffic.. =

-          When Root and Leaf sites are deployed on the same PE the = packets between them should obey the same semantics as if they had traversed a = PW i.e ( Split Horizon, No Label Re-Imposition etc=A1=AD ). =

[Sam] Same question as above. Anyway, =A1=B0Split = Horizon=A1=B1 is basic rule for all drafts.

[Jim U>] See above.. Sort of the = same requirement as stated above.. I believe that the local behavior intra-PE between a Leaf and a Root should mimic the behavior as if the traffic = arrived from a different PE>..

-          If PE has a root and leaf site and sends traffic to PE1. PE1 = should be able to decide if the traffic was sourced from the root or leaf site. = If from PE:Leaf then the traffic should not be resolved in PE1:Leaf. =

[Sam] Yes, what we are doing is to solve = this.

[Jim U>] I have not been = following E-Tree too closely is this where the solution space is multiple PWs or inferring context from data traffic?

 <= /span>

Thanks,=

 <= /span>

Sam

From: UTTARO, JAMES [mailto:ju1738@att.com]
Sent: Monday, April 23, = 2012 7:27 AM
To: 'Alexander = Vainshtein'; Sam Cao
Cc: l2vpn@ietf.org
Subject: RE: The status = of the approaches to the E-Tree solution?

 

For a given = PE, If you use BGP and define separate VRFs one for the leafs and one for roots = than the semantic provided by the RT assignment should be translated = correctly in to the forwarding programmed.. This means that intra-PE between the leaf = and root VRF should be treated as a Labeled PW. If treated as a regular ethernet = interface than a leaf on VRF S1 can forward traffic on VRF H1 and then onto a = different PEs leaf VRF=A1=AD I believe we had a very similar conversation over a = year ago about E-Tree=A1=AD

 <= /o:p>

So, here = are the reqs I shared

 <= /o:p>

•          E-Tree/Partial mesh topologies need to = be realized in the control plane by constructing PWs. The data plane should = not infer a topology. In other words data should not have to be inspected to determine if the packet is sourced from a leaf or a = root

•          The same PE must be able to host Root = and Leaf sites. <= /span>

•          Disallowing of Leaf to Leaf traffic on = the same PE must be done using PW semantics.

•          When Root and Leaf sites are deployed on = the same PE the packets between them should obey the same semantics as if = they had traversed a PW i.e ( Split Horizon, No Label Re-Imposition etc=A1=AD )

•          If PE has a root and leaf site and sends traffic to PE1. PE1 should be able to decide if the traffic was sourced = from the root or leaf site. If from PE:Leaf then the traffic should not be = resolved in PE1:Leaf.<= /span>

 <= /o:p>

 <= /o:p>

Jim = Uttaro

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander = Vainshtein
Sent: Sunday, April 22, = 2012 10:57 AM
To: Sam Cao
Cc: l2vpn@ietf.org
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Sam,

I will try = to explain myself.

 <= /o:p>

I have = misspoken before, and I owe you an apology.

 <= /o:p>

A true = legacy PE cannot operate as a Mixed PE for E-tree since this operation requires = some changes in the forwarding behavior. This is IMHO correct regardless of the specific E-tree solution = that is implemented by the rest of the PEs (CW-based, dual PW-based = or VLAN-based). I.e. without some additional implementation-specific tricks = it can be either a Root-only PE or a Leaf-only PE in the VPLS that does not = contain Mixed PEs.

 <= /o:p>

Regards,

  =    Sasha

 <= /o:p>

From: Sam Cao [mailto:yuqun.cao@gmail.com]
Sent: Sunday, April 22, = 2012 5:22 PM
To: Alexander = Vainshtein
Cc: l2vpn@ietf.org; = 'Raymond Key'
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Sasha,<= /span>

 <= /span>

I agree with your comments. But maybe I don=A1=AFt make myself understood. I make it = clear.

 <= /span>

If one chip can = not support control word, then one switch which uses this chip can not work = as Root-Leaf-Mixed PE since we can not extend it. Is this correct? Is this reasonable?

 <= /span>

Anyway, chip = limit is big problem for CW approach.

 <= /span>

Regards,

 

Yuqun (Sam) Cao

E-mail: Yuqun.cao@gmail.com

 

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Sunday, April 22, = 2012 9:56 PM
To: Sam Cao
Cc: l2vpn@ietf.org; = 'Raymond Key'
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Sam,

You=A1=AFve = asked:

If it only supports VPLS, ok, it can = work as Root-only, but why it cannot work as Root-Leaf-Mixed or Leaf-only if it = cannot support CW?

IMHO and = FWIW there is not too much you can expect from a true legacy PE (i.e. a PE that did = not change its forwarding behavior):

1.       = It can obviously support Root-only functionality

2.       = It can support Leaf-only = functionality if there are no Mixed by preventing setup PW (by not setting up PWs to = other Leaf-only PEs).

Anything = beyond that would be very much implementation-specific. E.g., I am aware of legacy implementations that could support functionality of a Mixed PE provided = that it would be the only Mixed PE in the VPLS instance, and other = legacy implementations that are, as legacy, fully interoperable with these ones = but could not support such functionality.

 <= /o:p>

My = 2c,

  =    Sasha

 <= /o:p>

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Sam Cao
Sent: Sunday, April 22, = 2012 4:41 PM
To: 'Raymond Key'
Cc: l2vpn@ietf.org
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Raymond,

 <= /span>

Network = efficiency:

[Sam] Leaf/Root configuration is local configuration, and PE can not know remote AC type configuration. This is CW Fundamentals. So even if CW approach defines = optional enhancement for Leaf-Only PE, but can not signal it between Leaf-Only = PEs, so there is no good way to support this. The possible solution is, manually configure hub-spoke topology, but if we do like this, current solutions = have support most E-Tree cases with Hub-Spoke configuration. Lizhong = mentioned this in one mail.

 <= /span>

Backwards = compatibility:

[Sam] Yes, new = draft considers backward compatibility, but it makes precondition: The PE = which can not support Control word only works as Root-only PE. This does not make = sense for me. If it only supports VPLS, ok, it can work as Root-only, but why = it can not work as Root-Leaf-Mixed or Leaf-only if it can not support = CW?

 <= /span>

Regards,

 

Yuqun (Sam) Cao

E-mail: Yuqun.cao@gmail.com

 

From: raymond.key@hotmail.com [mailto:raymond.key@hotmail.com] On Behalf Of Raymond Key
Sent: Saturday, April 21, = 2012 11:32 PM
To: = yuqun.cao@gmail.com
Cc: l2vpn@ietf.org
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Some clarifications [RK] inserted below

Thanks

Raymond Key

From: yuqun.cao@gmail.com
To: lizho.jin@gmail.com; wim.henderickx@alcatel-lucent.com
Subject: RE: The status of the approaches to the E-Tree solution?
Date: Sat, 21 Apr 2012 22:51:28 +0800
CC: l2vpn@ietf.org

Hi all,

 

We reach an = impasseJ.  BTW, Meeting minutes is ready now. We can get E-tree summary from = IETF site.

 

Today I collected all items = we discussed before. They are,

 

1)       = Silicon issue or chip limit;

2)       = Network efficiency;

3)       = Encapsulation mode, tag or raw;

4)       = H-VPLS;

5)       = Backwards compatibility, especially legacy PE or Non-supporting PE with IEEE = E-tree support joins E-Tree domain;

6)       = Configuration change in operation, for example, Leaf-only -> = Root-Leaf-Mixed;

7)       = S-VLAN preservation support;

8)       = Multi-segment PW;

9)       = VLAN ID allocation (Only for Dual-VLAN);

10)   Multi-AS deployment;

11)   ECMP;

12)   P2MP-PW;

13)   Ethernet OAM;

 

If we review the mail-list, CW approach has the following limits:

1)       = Chip limit. Please read reply from Giles = and Wim;

2)       = Network efficiency: There are garbage = fames which will be dropped on egress PE since only egress PE can decide forward or = drop frames while it receives frames. Ingress PE can not decide = forward or not. Yes, current solution can support Hub-Spoke configuration, but as we = know, the configuration is not easy if the network is big. Dual-VLAN or Multi-PW = approach can break communication between Leaf-Only PEs via = signaling.

[RK] It seems to me this is not the case. = Section 6 of the draft has some discussions on this.
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-6=
6. Optional Enhancements for Leaf-only PE
6.1. No PW between Leaf-only PEs
6.2. Not Forward Frame from Leaf AC to Leaf-only PE

 

3)       = Backwards compatibility: Not all PEs = supports control word. If one can not support control word, it will not join = E-Tree domain;

 

[RK] It seems to = me this is not the case. Section 5 of the draft has some discussions on = this.
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-5=
5. Backward Compatibility
5.1. AC Type
5.2. Control Word
5.3. Additional Action in Data Forwarding
5.3.1. Ingress PE Supporting the Extension but Egress PE Not
5.3.2. Egress PE Supporting the Extension but Ingress PE Not

 

Dual VLAN has = following limits:

1)       = Chip limit: As we know, we need to push = one VLAN into frames before MPLS encapsulation on ingress PE and stripe it out on = egress PE. This is non-standard operation. Wait for confirmation from chip = vendor;

2)       = HVPLS: If we follow Fig 3 or Fig = 4 in RFC 4762 to deploy = HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, = but can NOT configure it at all in Spoke PW case;

3)       = Multi-PW: Rafi figures this out, but we = don=A1=AFt think this over at that time. I think that it also has same problem as = H-VPLS has.

4)       = Encapsulation mode: If deploy GVPLS with = Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE = will stripe S-VLAN ID;

5)       = Backward Compatibility: Just as Daniel = mentioned, there is compatibility issue if legacy PE joins E-Tree domain. For me, I = don=A1=AFt get clear response from co-authors of Dual-VLAN.

 

For all = approaches, we don=A1=AFt cover ECMP / Ethernet OAM till now.

 

Is there anything = missed?

 

Regards,

 

Yuqun = (Sam) Cao

E-mail: = Yuqun.cao@gmail.com =

 

From: Lizhong Jin [mailto:lizho.jin@gmail.com]
Sent: Saturday, April 21, = 2012 11:59 AM
To: Henderickx, Wim = (Wim)
Cc: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com; yuqun.cao@gmail.com
Subject: RE: The status = of the approaches to the E-Tree solution?

 

Hi Win,
Thank you for the answers. In that case, PE-rs should configure the = root/leaf properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, = you could not figure out the accessing spoke PW is from PE-r of VPWS or = MTU-s. Unless having some additional indication in NMS, you even don't know = which spoke PW needs to do VLAN manipulation. I am not sure such R/L = configuration could be accepted from operational view. Hope to see more comments.

Regards
Lizhong


=D4=DA 2012=C4=EA4=D4=C221=C8=D5=D0=C7=C6=DA=C1=F9=A3=ACHenderickx, Wim (Wim) <wim.henderickx@alcatel-= lucent.com> =D0=B4=B5=C0=A3=BA
> The VPWS which terminates at the H-VPLS node is indicated to be = root or leaf and the procedures associated will do the VLAN manipulation
>
>  
>
> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin
> Sent: vrijdag 20 april 2012 18:38
> To: l2vpn@ietf.org; Alexander.Vainshtein@eci= tele.com
> Cc: yuqun.cao@gmail.com
> Subject: RE: The status of the approaches to the E-Tree = solution?
>
>  
>
> Hi, all,
> The difference between 2-VLAN and CW approach is who will provide = the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW = will carry R/L information for CW approach.
> I have a question with the 2-VLAN approach in H-VPLS where H-VPLS = is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds = VLAN to indicate R/L information?
>
> Thanks
> Lizhong
>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 19 Apr 2012 04:38:36 +0000
>> From: Alexander Vainshtein <Alexander.Vainshtein@eci= tele.com>
>> To: "Rogers, Josh" <josh.rogers@twcable.com>, = Lucy yong
>>        <lucy.yong@huawei.com>, = Daniel Cohn <DanielC@orckit.com>, = Sam Cao
>>        <yuqun.cao@gmail.com>
>> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
>> Subject: RE: The status of the approaches to the E-Tree = solution?
>> Message-ID:
>>        <F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>
>> Content-Type: text/plain; charset=3D"us-ascii"
>>
>> Hi all,
>> I fully understand that that what I am going to say is not very popular, but:
>>
>> IMO one of the advantages of the CW-based solution is that it = is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic.
>>
>> Another advantage is preservation of full mesh of P2P PWs in a = VPLS, and, in a more generic way, localization of effects of changes in the PE = configuration.
>>
>> In particular, adding a Leaf AC to a PE that previously has = been only supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect only the = PE where this operation happens and not the rest of the PEs.
>>
>> As for the need for HW changes that have been mentioned as a = main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution.
>>
>> My 2c,
>>     Sasha
>>
>>
>>
>> ________________________________________
>> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] = on behalf of Rogers, Josh [josh.rogers@twcable.com]
>> Sent: Wednesday, April 18, 2012 9:57 PM
>> To: Lucy yong; Daniel Cohn; Sam Cao
>> Cc: l2vpn@ietf.org
>> Subject: Re: The status of the approaches to the E-Tree = solution?
>>
>> Again, the P2MP situation throws me.  Is this something that is used
>> commonly?
>>
>> I'm under the impression that adding P2MP to any model results = in a more
>> complex model.  Wether outside s-tag is used to differentiate, or
>> dedicated pw's are used for the same purpose, it seems both = become more
>> complex.
>>
>> Gile's comparison slide still concisely captures the = differences between
>> these methods, in my opinion.  I haven't seen any new ideas or thoughts
>> brought to the group in the past week or two on the subject. =  I would hate
>> for both proposed methods to die on the vine because we = couldn't decide
>> between two methods that have nothing inherently wrong with = either.
>>
>> -Josh
>>
>>
>> On 4/18/12 1:53 PM, "Lucy yong" <lucy.yong@huawei.com> = wrote:
>>
>>>Send this again.
>>>
>>>Two PW approach can be complex too if the VPLS instance for = E-Tree uses
>>>P2P PW fo

This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, phone = or fax, and then delete the original and all copies thereof. =

This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, phone = or fax, and then delete the original and all copies thereof. =

------=_NextPart_000_002B_01CD2209.FC83AB70-- From nurit.sprecher@nsn.com Tue Apr 24 04:02:15 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C9A21F86C7 for ; Tue, 24 Apr 2012 04:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 AXDwGLriW968 for ; Tue, 24 Apr 2012 04:02:00 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED6521F867E for ; Tue, 24 Apr 2012 04:01:59 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q3OB1ew2016324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Apr 2012 13:01:40 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q3OB1dxh032019; Tue, 24 Apr 2012 13:01:40 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Apr 2012 13:01:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: The status of the approaches to the E-Tree solution? Date: Tue, 24 Apr 2012 13:01:38 +0200 Message-ID: In-Reply-To: <161901cd21ea$9d7d8486$05280101@corrigent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IAAHuPxA References: <161901cd21ea$9d7d8486$05280101@corrigent.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Daniel Cohn" , "Lucy yong" , "Rogers, Josh" , "Shahram Davari" , "Lizhong Jin" , , X-OriginalArrivalTime: 24 Apr 2012 11:01:39.0415 (UTC) FILETIME=[9FC4FE70:01CD2209] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 31908 X-purgate-ID: 151667::1335265300-00007D3F-9A866289/0-0/0-0 Cc: yuqun.cao@gmail.com X-BeenThere: l2vpn@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, 24 Apr 2012 11:02:15 -0000 RGFuaWVsLA0KSXMgaXQgc28gdGhhdCB5b3UgY29uc2lkZXIgUy1WQUwgc3RhY2tpbmc/DQpJZiB0 aGlzIGlzIHRoZSBjYXNlLCBhcmUgeW91IGF3YXJlIHRoYXQgdGhpcyBpcyBub3QgaW4tbGluZSB3 aXRoIHRoZSBJRUVFIHNwZWNpZmljYXRpb25zPw0KQmVzdCByZWdhcmQsDQpOdXJpdA0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgRGFuaWVsIENvaG4N ClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDI0LCAyMDEyIDEwOjEyIEFNDQpUbzogTHVjeSB5b25nOyBS b2dlcnMsIEpvc2g7IFNoYWhyYW0gRGF2YXJpOyBMaXpob25nIEppbjsgbDJ2cG5AaWV0Zi5vcmc7 IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQpDYzogeXVxdW4uY2FvQGdtYWlsLmNv bQ0KU3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJl ZSBzb2x1dGlvbj8NCg0KTHVjeSwNCg0KZXZlbiBpZiB0aGUgY3VycmVudCBNRUYgZnJhbWV3b3Jr IGRvZXNuJ3QgcmVxdWlyZSBzLXZsYW4gcHJlc2VydmF0aW9uLCBJIGJlbGlldmUgaXQncyB0byB0 aGUgaW5kdXN0cnkncyBiZW5lZml0IHRvIGFkb3B0IGEgc29sdXRpb24gdGhhdCBpcyBub3QgY29u c3RyYWluZWQgdG8gYSBzcGVjaWZpYyBlbm5pIG1vZGVsIHRoYXQsIGxpa2UgYWxsIHRoaW5ncyBu ZXR3b3JraW5nLCBpcyBsaWtlbHkgdG8gZXZvbHZlLiBFc3BlY2lhbGx5IHdoZW4gc3VjaCBhIHNv bHV0aW9uIGlzIGF2YWlsYWJsZS4NCg0KRGFuaWVsDQoNClRodW1iIHR5cGVkIC0gcGxlYXNlIGJl IHRvbGVyYW50DQoNCkx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb20+IHdyb3RlOg0KDQpE YW5pZWwsDQoNCk1FRiBoYXMgd29ya2VkIGluIEVOTkkgaW50ZXJmYWNlIGZvciBhIGxvbmcgdGlt ZSB3aXRoIG1hbnkgc2VydmljZSBwcm92aWRlcnMnIGlucHV0cy4gSXQgaGFkIGEgZmFpciByZWFz b24gdG8gYXNzdW1lIFMtVkxBTiBvdmVyIEVOTkkgYnkgdGhlbi4gSXQgbWF5IG9wZW4gQi1WTEFO IGZvciB0aGUgZnV0dXJlLiBJdCBpcyBiZXR0ZXIgZm9yIHVzIG5vdCB0byBkaXNjdXNzICBhIGZ1 dHVyZSBmcmFtZXdvcmsgaGVyZSwgYmVjYXVzZSBpdCB3aWxsIGxlYWQgdXMgdG8gbm93aGVyZS4g SGVyZSwgd2Ugd2FudCB0byBleHRlbmQgVlBMUyBpbiBzdXBwb3J0aW5nIEUtVHJlZS4NCg0KQmVz dCBSZWdhcmRzLA0KTHVjeQ0KDQpGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhbmllbCBDb2huDQpTZW50OiBT dW5kYXksIEFwcmlsIDIyLCAyMDEyIDc6MzQgQU0NClRvOiBSb2dlcnMsIEpvc2g7IFNoYWhyYW0g RGF2YXJpOyBMaXpob25nIEppbjsgbDJ2cG5AaWV0Zi5vcmc7IEFsZXhhbmRlci5WYWluc2h0ZWlu QGVjaXRlbGUuY29tDQpDYzogeXVxdW4uY2FvQGdtYWlsLmNvbQ0KU3ViamVjdDogUkU6IFRoZSBz dGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCg0KU2hhaHJh bSBhbmQgYWxsLA0KDQpUaGlzIHF1ZXN0aW9uIGFscmVhZHkgY2FtZSB1cCBpbiBvdXIgZGlzY3Vz c2lvbnMgLSBpcyBpdCBzYWZlIHRvIGFzc3VtZSB0aGF0IHRoZSBWTEFOIHRhZ3MgYXQgdGhlIEUt Tk5JIHdpbGwgYWx3YXlzIGJlIGFjY29yZGluZyB0byB0aGUgY3VycmVudCBNRUYgbW9kZWw/IE9y IHNob3VsZCB3ZSB0cnkgdG8gYmUgYXMgdHJhbnNwYXJlbnQgYXMgcG9zc2libGUgdG8gdXNlciBW TEFOIGVuY2Fwc3VsYXRpb24gYXQgdGhlIEUtTk5JLCB0byBhY2NvbW1vZGF0ZSBmdXR1cmUgZnJh bWV3b3Jrcz8NCkkgYmVsaWV2ZSB0aGF0IGFueSBhcHByb2FjaCB0aGF0IGxvb2tzIGF0IHVzZXIg cGF5bG9hZCAoaW4gdGhpcyBjYXNlIFZMQU4gdGFnKSB0byBzaWduYWwgVlBMUyBpbmZvcm1hdGlv biAoaW4gdGhpcyBjYXNlIHJvb3QvbGVhZiBvcmlnaW4pIGlzIG5lY2Vzc2FyaWx5IHRpZWQgdG8g c3BlY2lmaWMgYXNzdW1wdGlvbnMgb24gdXNlciBwYXlsb2FkIGVuY2Fwc3VsYXRpb24gKGluIHRo aXMgY2FzZSwgdGhhdCBTLVZMQU4gdGFnIGlzICJhdmFpbGFibGUiIHRvIGVuY29kZSByb290L2xl YWYpLiBJIGRvbid0IHRoaW5rIHRoaXMgaXMgYSBmdXR1cmUtcHJvb2YgYXNzdW1wdGlvbiwgaXQn cyB2ZXJ5IGxpa2VseSB0aGF0IG90aGVyIG5ldHdvcmsgbW9kZWxzIHdpbGwgY29tZSB1cCB0aGF0 IHJlcXVpcmUgUy1WTEFOIHByZXNlcnZhdGlvbiwgd2hpY2ggaW4gdGhlIDItVkxBTiBhcHByb2Fj aCB3b3VsZCBuZWNlc3NpdGF0ZSBhZGRpbmcgYSB0aGlyZCBWTEFOLUlELg0KDQpEYW5pZWwNCg0K RnJvbTogU2hhaHJhbSBEYXZhcmkgPGRhdmFyaUBicm9hZGNvbS5jb208bWFpbHRvOmRhdmFyaUBi cm9hZGNvbS5jb20+Pg0KVG86IExpemhvbmcgSmluIDxsaXpoby5qaW5AZ21haWwuY29tPG1haWx0 bzpsaXpoby5qaW5AZ21haWwuY29tPj4sICJsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0 Zi5vcmc+IiA8bDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPj4sICJBbGV4YW5k ZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNp dGVsZS5jb20+IiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPj4NCkNjOiAieXVxdW4uY2FvQGdtYWlsLmNvbTxt YWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbT4iIDx5dXF1bi5jYW9AZ21haWwuY29tPG1haWx0bzp5 dXF1bi5jYW9AZ21haWwuY29tPj4NClN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHBy b2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQoNCkhpLA0KDQpJIGFsc28gaGF2ZSBhIHF1 ZXN0aW9uIHJlZ2FyZGluZyAyLVZMQU4uIFdoYXQgaWYgdGhlIGN1c3RvbWVyIHRyYWZmaWMgYWxy ZWFkeSBoYXMgYW4gUy1WTEFOPyBEbyB3ZSBuZWVkIGEgM3JkIFZMQU4gdG8gaWRlbnRpZnkgdGhl IEwvUj8NCg0KVGh4DQpTaGFocmFtDQoNCkZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIExpemhvbmcgSmluDQpTZW50OiBGcmlkYXksIEFwcmlsIDIwLCAyMDEy IDk6MzggQU0NClRvOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBBbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb20+DQpDYzogeXVxdW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86eXVxdW4uY2FvQGdt YWlsLmNvbT4NClN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRo ZSBFLVRyZWUgc29sdXRpb24/DQoNCkhpLCBhbGwsDQpUaGUgZGlmZmVyZW5jZSBiZXR3ZWVuIDIt VkxBTiBhbmQgQ1cgYXBwcm9hY2ggaXMgd2hvIHdpbGwgcHJvdmlkZSB0aGUgUi9MIGluZm9ybWF0 aW9uLCBjdXN0b21lciBwYXlsb2FkIG9yIFBXPyBUaGUgY3VzdG9tZXIgcGF5bG9hZCB3aWxsIGJl IGFsd2F5cyBtb2RpZmllZCB0byBjYXJyeSBSL0wgaW5mb3JtYXRpb24gaW4gMi1WTEFOIGFwcHJv YWNoLCB3aGlsZSBQVyB3aXRoIENXIHdpbGwgY2FycnkgUi9MIGluZm9ybWF0aW9uIGZvciBDVyBh cHByb2FjaC4NCkkgaGF2ZSBhIHF1ZXN0aW9uIHdpdGggdGhlIDItVkxBTiBhcHByb2FjaCBpbiBI LVZQTFMgd2hlcmUgSC1WUExTIGlzIGFjY2Vzc2VkIGJ5IFZQV1MgYXMgZGVzY3JpYmVkIGluIFJG QzQ2NzIgc2VjdGlvbiAxMC4xLjMuIElmIFZQV1MgaXMgdXNlZCB0byBhY2Nlc3MgSC1WUExTLCBo b3cgY291bGQgdGhlIFBFIG9uIFZQV1Mgc2lkZSBhZGRzIFZMQU4gdG8gaW5kaWNhdGUgUi9MIGlu Zm9ybWF0aW9uPw0KDQpUaGFua3MNCkxpemhvbmcNCg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4NCj4gTWVzc2FnZTogMg0KPiBEYXRlOiBUaHUsIDE5IEFwciAyMDEyIDA0OjM4 OjM2ICswMDAwDQo+IEZyb206IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNo dGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+ Pg0KPiBUbzogIlJvZ2VycywgSm9zaCIgPGpvc2gucm9nZXJzQHR3Y2FibGUuY29tPG1haWx0bzpq b3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbT4+LCBMdWN5IHlvbmcNCj4gICAgICAgIDxsdWN5LnlvbmdA aHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiwgRGFuaWVsIENvaG4gPERh bmllbENAb3Jja2l0LmNvbTxtYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tPj4sIFNhbSBDYW8NCj4g ICAgICAgIDx5dXF1bi5jYW9AZ21haWwuY29tPG1haWx0bzp5dXF1bi5jYW9AZ21haWwuY29tPj4N Cj4gQ2M6ICJsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+IiA8bDJ2cG5AaWV0 Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPj4NCj4gU3ViamVjdDogUkU6IFRoZSBzdGF0dXMg b2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4gTWVzc2FnZS1JRDoN Cj4gICAgICAgIDxGOTMzNjU3MTczMUFERTQyQTUzOTdGQzgzMUNFQUEwMjAzNDE5MkBGUklEV1BQ TUIwMDIuZWNpdGVsZS5jb208bWFpbHRvOkY5MzM2NTcxNzMxQURFNDJBNTM5N0ZDODMxQ0VBQTAy MDM0MTkyQEZSSURXUFBNQjAwMi5lY2l0ZWxlLmNvbT4+DQo+IENvbnRlbnQtVHlwZTogdGV4dC9w bGFpbjsgY2hhcnNldD0idXMtYXNjaWkiDQo+DQo+IEhpIGFsbCwNCj4gSSBmdWxseSB1bmRlcnN0 YW5kIHRoYXQgdGhhdCB3aGF0IEkgYW0gZ29pbmcgdG8gc2F5IGlzIG5vdCB2ZXJ5IHBvcHVsYXIs IGJ1dDoNCj4NCj4gSU1PIG9uZSBvZiB0aGUgYWR2YW50YWdlcyBvZiB0aGUgQ1ctYmFzZWQgc29s dXRpb24gaXMgdGhhdCBpdCBpcyBvcnRob2dvbmFsIHRvIHVzYWdlIChvciBub24tdXNhZ2UpIG9m IFAyTVAgUFdzIGZvciBlZmZlY3RpdmUgZGVsaXZlcnkgb2YgQlVOIHRyYWZmaWMuDQo+DQo+IEFu b3RoZXIgYWR2YW50YWdlIGlzIHByZXNlcnZhdGlvbiBvZiBmdWxsIG1lc2ggb2YgUDJQIFBXcyBp biBhIFZQTFMsIGFuZCwgaW4gYSBtb3JlIGdlbmVyaWMgd2F5LCBsb2NhbGl6YXRpb24gb2YgZWZm ZWN0cyBvZiBjaGFuZ2VzIGluIHRoZSBQRSBjb25maWd1cmF0aW9uLg0KPg0KPiBJbiBwYXJ0aWN1 bGFyLCBhZGRpbmcgYSBMZWFmIEFDIHRvIGEgUEUgdGhhdCBwcmV2aW91c2x5IGhhcyBiZWVuIG9u bHkgc3VwcG9ydGluZyBSb290IEFDcyAob3IgdmljZSB2ZXJzYSksIHJlbW92YWwgb2YgdGhlIGxh c3QgTGVhZiBvciBsYXN0IFJvb3QgQUMgZnJvbSBhIFBFIHRoYXQgcHJldmlvdXNseSBoYXMgYmVl biBzdXBwb3J0aW5nIGEgbWl4IGV0Yy4gYWZmZWN0IG9ubHkgdGhlIFBFIHdoZXJlIHRoaXMgb3Bl cmF0aW9uIGhhcHBlbnMgYW5kIG5vdCB0aGUgcmVzdCBvZiB0aGUgUEVzLg0KPg0KPiBBcyBmb3Ig dGhlIG5lZWQgZm9yIEhXIGNoYW5nZXMgdGhhdCBoYXZlIGJlZW4gbWVudGlvbmVkIGFzIGEgbWFp biBkaXNhZHZhbnRhZ2Ugb2YgdGhlIENXLWJhc2VkIGFwcHJvYWNoIC0gSSBiZWxpZXZlIGl0IHN0 cm9uZ2x5IGRlcGVuZHMgb24gc3BlY2lmaWMgaW1wbGVtZW50YXRpb25zLiBBbmQgc29tZSBjaGFu Z2VzIGluIHRoZSBmb3J3YXJkaW5nIHByb2Nlc3MgYXJlIHJlcXVpcmVkIGluIGFueSBzb2x1dGlv bi4NCj4NCj4gTXkgMmMsDQo+ICAgICBTYXNoYQ0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc+IFtsMnZwbi1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnPl0gb24gYmVoYWxmIG9mIFJvZ2VycywgSm9zaCBb am9zaC5yb2dlcnNAdHdjYWJsZS5jb208bWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29tPl0N Cj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxOCwgMjAxMiA5OjU3IFBNDQo+IFRvOiBMdWN5IHlv bmc7IERhbmllbCBDb2huOyBTYW0gQ2FvDQo+IENjOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2 cG5AaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVz IHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+DQo+IEFnYWluLCB0aGUgUDJNUCBzaXR1YXRpb24g dGhyb3dzIG1lLiAgSXMgdGhpcyBzb21ldGhpbmcgdGhhdCBpcyB1c2VkDQo+IGNvbW1vbmx5Pw0K Pg0KPiBJJ20gdW5kZXIgdGhlIGltcHJlc3Npb24gdGhhdCBhZGRpbmcgUDJNUCB0byBhbnkgbW9k ZWwgcmVzdWx0cyBpbiBhIG1vcmUNCj4gY29tcGxleCBtb2RlbC4gIFdldGhlciBvdXRzaWRlIHMt dGFnIGlzIHVzZWQgdG8gZGlmZmVyZW50aWF0ZSwgb3INCj4gZGVkaWNhdGVkIHB3J3MgYXJlIHVz ZWQgZm9yIHRoZSBzYW1lIHB1cnBvc2UsIGl0IHNlZW1zIGJvdGggYmVjb21lIG1vcmUNCj4gY29t cGxleC4NCj4NCj4gR2lsZSdzIGNvbXBhcmlzb24gc2xpZGUgc3RpbGwgY29uY2lzZWx5IGNhcHR1 cmVzIHRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVuDQo+IHRoZXNlIG1ldGhvZHMsIGluIG15IG9waW5p b24uICBJIGhhdmVuJ3Qgc2VlbiBhbnkgbmV3IGlkZWFzIG9yIHRob3VnaHRzDQo+IGJyb3VnaHQg dG8gdGhlIGdyb3VwIGluIHRoZSBwYXN0IHdlZWsgb3IgdHdvIG9uIHRoZSBzdWJqZWN0LiAgSSB3 b3VsZCBoYXRlDQo+IGZvciBib3RoIHByb3Bvc2VkIG1ldGhvZHMgdG8gZGllIG9uIHRoZSB2aW5l IGJlY2F1c2Ugd2UgY291bGRuJ3QgZGVjaWRlDQo+IGJldHdlZW4gdHdvIG1ldGhvZHMgdGhhdCBo YXZlIG5vdGhpbmcgaW5oZXJlbnRseSB3cm9uZyB3aXRoIGVpdGhlci4NCj4NCj4gLUpvc2gNCj4N Cj4NCj4gT24gNC8xOC8xMiAxOjUzIFBNLCAiTHVjeSB5b25nIiA8bHVjeS55b25nQGh1YXdlaS5j b208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+DQo+PlNlbmQgdGhpcyBh Z2Fpbi4NCj4+DQo+PlR3byBQVyBhcHByb2FjaCBjYW4gYmUgY29tcGxleCB0b28gaWYgdGhlIFZQ TFMgaW5zdGFuY2UgZm9yIEUtVHJlZSB1c2VzDQo+PlAyUCBQVyBmb3IgdW5pY2FzdCB0cmFmZmlj IGFuZCBQMk1QIFBXIGZvciBicm9hZGNhc3QgYW5kIHVua25vd24NCj4+dW5pY2FzdCB0cmFmZmlj LCBhbmQgc29tZSBQMk1QIFBXcyBmb3IgbXVsdGljYXN0IHRyYWZmaWMuIEl0IG1heSBkb3VibGUN Cj4+YWxsIG9mIHRoZW0uDQo+Pg0KPj5MdWN5DQo+Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPj5Gcm9tOiBEYW5pZWwgQ29obiBbbWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbTxtYWls dG86RGFuaWVsQ0BvcmNraXQuY29tPl0NCj4+U2VudDogV2VkbmVzZGF5LCBBcHJpbCAxOCwgMjAx MiAxOjQyIFBNDQo+PlRvOiBMdWN5IHlvbmc7IFJvZ2VycywgSm9zaDsgU2FtIENhbw0KPj5DYzog bDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPg0KPj5TdWJqZWN0OiBSRTogVGhl IHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4NCj4+ SSB0aGluayB0aGUgZmlyc3Qgb3B0aW9uIGl0cyB0aGUgbmF0dXJhbCB3YXkgdG8gZ28uIEhvdyBp cyB0aGUgcHJvY2Vzc2luZw0KPj5pbiB0aGlzIGNhc2UgbW9yZSBjb21wbGV4Pw0KPj4NCj4+VGh1 bWIgdHlwZWQgLSBwbGVhc2UgYmUgdG9sZXJhbnQNCj4+DQo+Pkx1Y3kgeW9uZyA8bHVjeS55b25n QGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+Pg0KPj4N Cj4+DQo+PlNuaXBwZWQuLg0KPj4NCj4+TXVsdGktUFcgLSBPbiBpbmdyZXNzIFBFLCBmcmFtZSBp cyBwbGFjZWQgb250byBlaXRoZXIgYSBMZWFmLW9ubHkgUDJNUCBQVw0KPj4oZm9yIHRyYWZmaWMg Y29taW5nIGZyb20gYSBsZWFmIEFDKSwgb3Igb250byBhIFJvb3QvTGVhZiBQMk1QIFBXIChmb3IN Cj4+dHJhZmZpYyBjb21pbmcgZnJvbSBhIHJvb3QgQUMpDQo+PltbTFldXSBOb3QgdGhhdCBzaW1w bGUuIFlvdSBjb25zdHJ1Y3QgZWl0aGVyIHR3byBQMk1QIFBXcyB0byBhbGwgb3RoZXINCj4+UEVz IGFuZCBsZXQgZWdyZXNzIFBFIHBlcmZvcm1pbmcgZmlsdGVyaW5nLCBvciBjb25zdHJ1Y3Qgb25l IFAyTVAgUFcgdG8NCj4+bGVhZi1vbmx5IFBFcyBhbmQgdHdvIFAyTVAgUFdzIHRvIHJvb3QgYW5k IGxlYWYgUEVzIGFuZCBsZXQgaW5ncmVzcyBQRQ0KPj5wZXJmb3JtIGZvcndhcmRpbmcgYW5kIGZp bHRlcmluZy4gQm90aCBtYWtlIG5vZGUgcHJvY2VzcyBjb21wbGV4Lg0KPj4NCj4+W1tMWV1dIFZQ TFMgaXMgYnVpbHQgd2l0aCB0aGUgbWVjaGFuaXNtIHV0aWxpemluZyBQMlAgYW5kIFAyTVAgUFcg Zm9yDQo+PmRlbGl2ZXJpbmcgdGhlIGZyYW1lcyB0byByZW1vdGUgUEVzLiBXZSBzaG91bGQgdXRp bGl6ZSB0aGVtIHdpdGggdGhlDQo+Pm1pbmltaXplZCBjaGFuZ2VzLiBEdWFsIFZMQU4gc29sdXRp b24gaXMgc2ltcGxlciB0aGFuIER1YWwgUFcuDQo+Pg0KPj5SZWdhcmRzLA0KPj5MdWN5DQo+Pg0K Pj4NCj4+SSBzZWUgaG93IDJWTEFOIGlzIHNpbXBsZXIgd2hlbiBQMk1QIFBXJ3MgYXJlIGludm9s dmVkLCBJIHRoaW5rLiAgSQ0KPj5oYXZlbid0IGhhZCBhbnkgZmlyc3QgaGFuZCBleHBlcmllbmNl IHdpdGggUDJNUCBQVydzLCBob3dldmVyLCBzbyBkb24ndA0KPj5mZWVsIHRlcnJpYmx5IHN0cm9u ZyBhYm91dCB0aGlzIG9iamVjdGlvbi4gIElzIHRoaXMgYSByZWFsIHByb2JsZW0gZm9yDQo+Pm90 aGVycyAobm93IG9yIGluIHRoZSBmdXR1cmUpLCBvciBpcyB0aGlzIG9iamVjdGlvbiBpbiB0aGUg d2VlZHM/DQo+Pg0KPj5JJ20gbm90IHN1cmUgdGhlICdhZGRpdGlvbmFsIGNvbXBsZXhpdHknIGlz IG5vdGFibGUsIG9yIGV2ZW4gcmVsZXZhbnQuICBJDQo+PmVuY291cmFnZSBvdGhlcnMgdG8gc3Bl YWsgdXAgaWYgdGhleSBkaXNhZ3JlZSwgYXMgUDJNUCBQVyBpcyBvbmx5DQo+PmNvbmNlcHR1YWwg dG8gbWUsIGFuZCBJIGFtIHVuZmFtaWxpYXIgd2l0aCByZWFsLWxpZmUgdXNlIGNhc2VzIGZvciBp dC4NCj4+DQo+PlRoYW5rcywNCj4+Sm9zaA0KPj4NCj4+DQo+Pg0KPj5PbiA0LzE4LzEyIDEwOjMw IEFNLCAiTHVjeSB5b25nIiA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0Bo dWF3ZWkuY29tPj4gd3JvdGU6DQo+Pg0KPj4+UGxlYXNlIHNlZSBpbmxpbmUuDQo+Pj4NCj4+Pi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBTYW0gQ2FvIFttYWlsdG86eXVxdW4u Y2FvQGdtYWlsLmNvbTxtYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbT5dDQo+Pj5TZW50OiBUdWVz ZGF5LCBBcHJpbCAxNywgMjAxMiA3OjE0IEFNDQo+Pj5UbzogJ0RhbmllbCBDb2huJzsgTHVjeSB5 b25nOyAnUm9nZXJzLCBKb3NoJzsgJ0hlbmRlcmlja3gsIFdpbSAoV2ltKSc7DQo+Pj5naWxlcy5o ZXJvbkBnbWFpbC5jb208bWFpbHRvOmdpbGVzLmhlcm9uQGdtYWlsLmNvbT47IHNpbW9uLmRlbG9y ZEBnbWFpbC5jb208bWFpbHRvOnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+Ow0KPj4+QWxleGFuZGVy LlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRl bGUuY29tPg0KPj4+Q2M6IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz47IFZs YWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJAZWNpdGVs ZS5jb20+Ow0KPj4+QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb208bWFpbHRvOkFuZHJldy5TZXJn ZWV2QGVjaXRlbGUuY29tPjsgSWRhbi5LYXNwaXRAZWNpdGVsZS5jb208bWFpbHRvOklkYW4uS2Fz cGl0QGVjaXRlbGUuY29tPjsNCj4+Pk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPG1haWx0bzpN aXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT47IFJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPG1haWx0 bzpSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbT4NCj4+PlN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9m IHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4NCj4+PlllcywgMiBw d3MgYXJlIG9ubHkgbmVlZGVkIGJldHdlZW4gcGVzIHdpdGggYm90aCByb290IGFuZCBsZWFmIGFj cyBhZnRlcg0KPj4+aW1wcm92aW5nIER1YWwtUFcgYXBwcm9hY2guIElmIGNvbnNpZGVyIFAyTVAs IER1YWwtUFcgYXBwcm9hY2ggc2V0dXAgMg0KPj4+UDJNUA0KPj4+UFdzIGlmIG5lZWQuIFRoZXJl IGlzIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBQMk1QIG9yIG5vcm1hbCBQVyBzZXR1cC4gQnV0LA0K Pj4+Y2FuIExlYWYtQUNzIGJlIGJvdW5kIHRvIFJvb3QgUEUgb2YgUDJNUCBQVz8NCj4+Pg0KPj4+ W1tMWV1dIE5vLCBpdCBtYWtlcyBjb21wbGV4IGluIHNldHRpbmcgdXAgUDJNUCBQVy4gU2hvdWxk IGEgUEUgd2l0aCBib3RoDQo+Pj5yb290IGFuZCBsZWFmIEFDcyBzZXQgdXAgdHdvIG9yIG9uZSBQ Mk1QIFBXIHRvIG90aGVyIFBFcyAoc29tZSBQRSBoYXZlDQo+Pj5ib3RoIHJvb3QgYW5kIGxlYWYg QUMgYW5kIHNvbWUgb25seSBoYXZlIGxlYWYgQUNzKT8NCj4+PlJlZ2FyZHMsDQo+Pj5MdWN5DQo+ Pj4NCj4+PlJlZ2FyZHMsDQo+Pj4NCj4+Pll1cXVuIChTYW0pIENhbw0KPj4+RS1tYWlsOiBZdXF1 bi5jYW9AZ21haWwuY29tPG1haWx0bzpZdXF1bi5jYW9AZ21haWwuY29tPg0KPj4+DQo+Pj4NCj4+ Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBEYW5pZWwgQ29obiBbbWFpbHRv OkRhbmllbENAb3Jja2l0LmNvbTxtYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tPl0NCj4+PlNlbnQ6 IFR1ZXNkYXksIEFwcmlsIDE3LCAyMDEyIDQ6NTYgUE0NCj4+PlRvOiBMdWN5IHlvbmc7IFJvZ2Vy cywgSm9zaDsgSGVuZGVyaWNreCwgV2ltIChXaW0pOw0KPj4+Z2lsZXMuaGVyb25AZ21haWwuY29t PG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+Ow0KPj4+c2ltb24uZGVsb3JkQGdtYWlsLmNv bTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT47IEFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT47IFNhbSBD YW8NCj4+PkNjOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBWbGFkaW1p ci5LbGVpbmVyQGVjaXRlbGUuY29tPG1haWx0bzpWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29t PjsNCj4+PkFuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPG1haWx0bzpBbmRyZXcuU2VyZ2VldkBl Y2l0ZWxlLmNvbT47IElkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0bzpJZGFuLkthc3BpdEBl Y2l0ZWxlLmNvbT47DQo+Pj5NaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbTxtYWlsdG86TWlzaGFl bC5XZXhsZXJAZWNpdGVsZS5jb20+OyBSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbTxtYWlsdG86Um90 ZW0uQ29oZW5AZWNpdGVsZS5jb20+DQo+Pj5TdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUg YXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+DQo+Pj5BZGRpbmcgU2FtIChh cyBsMnZwbkAgaXMgaG9sZGluZyBtZXNzYWdlcykNCj4+Pg0KPj4+REMNCj4+Pg0KPj4+LS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IEx1Y3kgeW9uZyBbbWFpbHRvOmx1Y3kueW9u Z0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT5dDQo+Pj5TZW50OiBUdWVz ZGF5LCBBcHJpbCAxNywgMjAxMiAxMjozOSBBTQ0KPj4+VG86IERhbmllbCBDb2huOyBSb2dlcnMs IEpvc2g7IEhlbmRlcmlja3gsIFdpbSAoV2ltKTsNCj4+PmdpbGVzLmhlcm9uQGdtYWlsLmNvbTxt YWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tPjsgc2ltb24uZGVsb3JkQGdtYWlsLmNvbTxtYWls dG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT47DQo+Pj5BbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0 ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQo+Pj5DYzog bDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPjsgVmxhZGltaXIuS2xlaW5lckBl Y2l0ZWxlLmNvbTxtYWlsdG86VmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbT47DQo+Pj5BbmRy ZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb20+ OyBJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbTxtYWlsdG86SWRhbi5LYXNwaXRAZWNpdGVsZS5jb20+ Ow0KPj4+TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb208bWFpbHRvOk1pc2hhZWwuV2V4bGVyQGVj aXRlbGUuY29tPjsgUm90ZW0uQ29oZW5AZWNpdGVsZS5jb208bWFpbHRvOlJvdGVtLkNvaGVuQGVj aXRlbGUuY29tPg0KPj4+U3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMg dG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4+Pg0KPj4+DQo+Pj5TbmlwcGVkLA0KPj4+DQo+Pj5B cyB3ZSBkaXNjdXNzZWQgZXh0ZW5zaXZlbHkgaW4gdGhlIGxpc3QsIGFuZCBhcyByZWZsZWN0ZWQg aW4gZ2lsZXMNCj4+PnNsaWRlLCAyIHB3cyBhcmUgb25seSBuZWVkZWQgYmV0d2VlbiBwZXMgd2l0 aCBib3RoIHJvb3QgYW5kIGxlYWYgYWNzLA0KPj4+d2hpY2ggd2lsbCB0eXBpY2FsbHkgYmUgYSBz bWFsbCBtaW5vcml0eS4NCj4+PltbTFldXSBEb24ndCBrbm93IGlmIHRoZSBhc3N1bXB0aW9uIGlz IHRydWUuIEV2ZW4gaXQgaXMgdGhlIGNhc2UsIGJvdGgNCj4+PmFwcHJvYWNoZXMgY2FuIGJlbmVm aXQgZnJvbSBpdC4gSSB3YXMgb2ZmIGZvciBhIHdoaWxlIGFuZCBjYXB0dXJlcyBzb21lDQo+Pj5k aXNjdXNzaW9ucyBub3cuDQo+Pj4NCj4+PkFsc28gYXMgcGVyIGdpbGVzIHNsaWRlLCBkdWFsIHZs YW4gY2FuIGhhdmUgc2NhbGFiaWxpdHkgaXNzdWVzIGR1ZSB0bw0KPj4+YWRkaXRpb25hbCBsb29r dXAgYW5kIGRvdWJsZSB1c2Ugb2YgdmxhbnMgaW4gaW50ZXJuYWwgZW11bGF0ZWQgbGFuDQo+Pj5p bnRlcmZhY2UuIEFsc28gdGhlcmUgYXJlIHBvdGVudGlhbCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5 IGlzc3VlcyB3aXRoDQo+Pj5zaWxpY29uIHRoYXQgZG9lc24ndCBzdXBwb3J0IHZsYW4gbWFwcGlu Zy4NCj4+PltbTFldXSBJIHdhcyBub3QgaW4gSUVURjgzIG1lZXRpbmcgYW5kIHdhaXQgb24gdGhl IG1lZXRpbmcgbWludXRlcy4gSSBhbQ0KPj4+bm90IGNsZWFyIG9uIGFsbCB0aGUgaXNzdWVzLiBD b3VsZCB5b3UgYmUgbW9yZSBzcGVjaWZpYz8gQXMgSSBtZW50aW9uZWQNCj4+PmluIGJlbG93LCB0 d28gUFcgYXBwcm9hY2ggbWFrZXMgVlBMUyB0cmFuc3BvcnQgY29uc3RydWN0aW9uIGFuZCBwYWNr ZXQNCj4+PmZvcndhcmRpbmcgbW9yZSBjb21wbGV4LCBJIGNhbiBzZWUgcG90ZW50aWFsIGJhY2t3 YXJkIGNvbXBhdGliaWxpdHkNCj4+Pmlzc3VlcyB3aXRoIDIgUFcgc29sdXRpb24uDQo+Pj4NCj4+ PlJlZ2FyZHMsDQo+Pj5MdWN5DQo+Pj4NCj4+PlJlZ2FyZHMsDQo+Pj4NCj4+PkRhbmllbA0KPj4+ DQo+Pj5UaHVtYiB0eXBlZCAtIHBsZWFzZSBiZSB0b2xlcmFudA0KPj4+DQo+Pj5MdWN5IHlvbmcg PGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+IHdyb3Rl Og0KPj4+DQo+Pj5JbiBteSBtaW5kLCB0aGUgVkxBTiBhcHByb2FjaCBtZWFucyBkdWFsIHZsYW4g bWV0aG9kLg0KPj4+DQo+Pj5UaGUgbWFpbiBjb25jZXJuIGZvciBDVyBhcHByb2FjaCBpcyBoYXJk d2FyZSBzdXBwb3J0Lg0KPj4+DQo+Pj5Ud28gUFcgYXBwcm9hY2ggY2FuIGJlIGNvbXBsZXggdG9v IGlmIHRoZSBWUExTIGluc3RhbmNlIGZvciBFLVRyZWUgdXNlcw0KPj4+UDJQIFBXIGZvciB1bmlj YXN0IHRyYWZmaWMgYW5kIFAyTVAgUFcgZm9yIGJyb2FkY2FzdCBhbmQgdW5rbm93biB1bmljYXN0 DQo+Pj50cmFmZmljLCBhbmQgc29tZSBQMk1QIFBXcyBmb3IgbXVsdGljYXN0IHRyYWZmaWMuIEl0 IG1heSBkb3VibGUgYWxsIG9mDQo+Pj50aGVtLg0KPj4+DQo+Pj5FLXRyZWUgaXMgYW4gRXRoZXJu ZXQgc2VydmljZSBhbmQgdGhlcmUgaXMgYWxyZWFkeSBWTEFOIGJhc2VkIHNvbHV0aW9uDQo+Pj5p biBJRUVFLCBjYW4gd2UganVzdCB1dGlsaXplIGl0IHdpdGhvdXQgY29tcGxpY2F0aW5nIFZQTFMg dHJhbnNwb3J0DQo+Pj5jb25zdHJ1Y3Rpb24/IFRoaXMgYWxzbyBtYWtlcyBpbnRlcndvcmtpbmcg d2l0aCBFdGggb25seSBuZXR3b3JrIGVhc2llci4NCj4+Pg0KPj4+Q2hlZXJzLA0KPj4+THVjeQ0K Pj4+DQo+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+RnJvbTogUm9nZXJzLCBKb3No IFttYWlsdG86am9zaC5yb2dlcnNAdHdjYWJsZS5jb208bWFpbHRvOmpvc2gucm9nZXJzQHR3Y2Fi bGUuY29tPl0NCj4+PlNlbnQ6IE1vbmRheSwgQXByaWwgMTYsIDIwMTIgODozNSBBTQ0KPj4+VG86 IEx1Y3kgeW9uZzsgSGVuZGVyaWNreCwgV2ltIChXaW0pOyAnZ2lsZXMuaGVyb25AZ21haWwuY29t PG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+JzsNCj4+PidzaW1vbi5kZWxvcmRAZ21haWwu Y29tPG1haWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPic7ICdBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+Jw0K Pj4+Q2M6ICdsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+JzsgJ1ZsYWRpbWly LktsZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb20+ JzsNCj4+PidBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3LlNlcmdlZXZA ZWNpdGVsZS5jb20+JzsgJ0lkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0bzpJZGFuLkthc3Bp dEBlY2l0ZWxlLmNvbT4nOw0KPj4+J01pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPG1haWx0bzpN aXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT4nOyAnUm90ZW0uQ29oZW5AZWNpdGVsZS5jb208bWFp bHRvOlJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPicNCj4+PlN1YmplY3Q6IFJFOiBUaGUgc3RhdHVz IG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4NCj4+PkkgYmVs aWV2ZSB0aGUgaW5pdGlhbCBxdWVzdGlvbiB3YXMgaW4gcmVnYXJkIHRvIHRoZSBDVyBtZXRob2Qu ICBBcmUgeW91DQo+Pj5zYXlpbmcgdGhhdCB5b3Ugbm8gbG9uZ2VyIGFyZSBpbnRlcmVzdGVkIGlu IHRoYXQgbWV0aG9kIGluIHByZWZlcmVuY2Ugb2YNCj4+PnRoZSBkdWFsIHZsYW4gbWV0aG9kPw0K Pj4+DQo+Pj4NCj4+Pg0KPj4+THVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86 bHVjeS55b25nQGh1YXdlaS5jb20+PiB3cm90ZToNCj4+Pg0KPj4+DQo+Pj5BZ3JlZSB3aXRoIFdp bS4gVkxBTiBhcHByb2FjaCBpcyB0aGUgYmVzdCBzb2x1dGlvbiBmb3IgRS1UcmVlLg0KPj4+DQo+ Pj5MdWN5DQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBsMnZw bi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRv OmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc+XSBP biBCZWhhbGYNCj4+Pk9mIEhlbmRlcmlja3gsIFdpbSAoV2ltKQ0KPj4+U2VudDogVGh1cnNkYXks IEFwcmlsIDEyLCAyMDEyIDI6MDMgQU0NCj4+PlRvOiAnZ2lsZXMuaGVyb25AZ21haWwuY29tPG1h aWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+JzsgJ3NpbW9uLmRlbG9yZEBnbWFpbC5jb208bWFp bHRvOnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+JzsNCj4+PidBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+Jw0KPj4+ Q2M6ICdsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+JzsgJ1ZsYWRpbWlyLkts ZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb20+JzsN Cj4+PidBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3LlNlcmdlZXZAZWNp dGVsZS5jb20+JzsgJ0lkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0bzpJZGFuLkthc3BpdEBl Y2l0ZWxlLmNvbT4nOw0KPj4+J01pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPG1haWx0bzpNaXNo YWVsLldleGxlckBlY2l0ZWxlLmNvbT4nOyAnUm90ZW0uQ29oZW5AZWNpdGVsZS5jb208bWFpbHRv OlJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPicNCj4+PlN1YmplY3Q6IFJlOiBUaGUgc3RhdHVzIG9m IHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4NCj4+PlRoZSB2bGFu IGFwcHJvYWNoIGlzIHN1cGVyaW9yIGFzIGl0IGFsc28gd29ya3MgZm9yIGV0aCBvbmx5IG5ldHdv cmtzLA0KPj4+ZXRjLiBPbiB0b3Agc29tZSB2ZW5kb3JzIGluZGljYXRlIGh3IGlzc3VlcyB3aXRo IHRoZSBjdyBhcHByb2FjaC4gQXMNCj4+PnN1Y2ggd2UgaGF2ZSBkcm9wcGVkIG1vcmUgb3IgbGVz cyB0aGUgY3cgYXBwcm9hY2guDQo+Pj4NCj4+PkNoZWVycywNCj4+PldpbQ0KPj4+X19fX19fX19f X19fX19fX18NCj4+PnNlbnQgZnJvbSBibGFja2JlcnJ5DQo+Pj4NCj4+Pi0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0NCj4+PkZyb206IEdpbGVzIEhlcm9uIFttYWlsdG86Z2lsZXMuaGVyb25A Z21haWwuY29tPG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+XQ0KPj4+U2VudDogVGh1cnNk YXksIEFwcmlsIDEyLCAyMDEyIDA4OjIyIEFNDQo+Pj5UbzogU2ltb24gRGVsb3JkIDxzaW1vbi5k ZWxvcmRAZ21haWwuY29tPG1haWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPj47IEFsZXhhbmRl ciBWYWluc2h0ZWluDQo+Pj48QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRv OkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPj4NCj4+PkNjOiBsMnZwbkBpZXRmLm9y ZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+IDxsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0 Zi5vcmc+PjsgVmxhZGltaXIgS2xlaW5lcg0KPj4+PFZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5j b208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb20+PjsgQW5kcmV3IFNlcmdlZXYN Cj4+PjxBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3LlNlcmdlZXZAZWNp dGVsZS5jb20+PjsgSWRhbiBLYXNwaXQgPElkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0bzpJ ZGFuLkthc3BpdEBlY2l0ZWxlLmNvbT4+Ow0KPj4+TWlzaGFlbCBXZXhsZXIgPE1pc2hhZWwuV2V4 bGVyQGVjaXRlbGUuY29tPG1haWx0bzpNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT4+OyBSb3Rl bSBDb2hlbg0KPj4+PFJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPG1haWx0bzpSb3RlbS5Db2hlbkBl Y2l0ZWxlLmNvbT4+DQo+Pj5TdWJqZWN0OiBSZTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hl cyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+DQo+Pj5Tb3JyeSAtIHRoZSAiYW5vbnltb3Vz IHByZXNlbnRhdGlvbiIgd2FzIG1pbmUuICBJIHNob3VsZCBwb3NzaWJseSBoYXZlDQo+Pj5wdXQg aW4gYSB0aGlyZCBjb2x1bW4gb24gdGhlIENXIGFwcHJvYWNoLiAgQW5kIGhvcGVmdWxseSB0aGUg bWludXRlcw0KPj4+d2lsbCBiZSBwb3N0ZWQgc29vbi4NCj4+Pg0KPj4+V2UgaGFkIHZhcmlvdXMg ZGlzY3Vzc2lvbnMsIGFzIFNpbW9uIHN0YXRlZCwgYW5kIGNvbnNlbnN1cyBzZWVtZWQgdG8gYmUN Cj4+PmZvcm1pbmcgYXJvdW5kIHRoZSB0d28gYWx0ZXJuYXRpdmVzIG9mIHR3byBQV0VzIG9yIHR3 byBWTEFOcy4gIEkgYmVsaWV2ZQ0KPj4+dGhyZWUgb2YgdGhlIGF1dGhvcnMgb2YgdGhlIENXIGFw cHJvYWNoIGFyZSBhbHNvIGF1dGhvcnMgb2YgdGhlIHR3byBWTEFODQo+Pj5hcHByb2FjaCBhbmQg b25lIGlzIGFsc28gYW4gYXV0aG9yIG9mIHRoZSB0d28gUFdFIGFwcHJvYWNoLiBTbyBwZXJoYXBz DQo+Pj5pdCdzIGJlc3QgdG8gbGV0IHRob3NlIGZvdXIgaW5kaXZpZHVhbHMgc2F5IHdoaWNoIGFw cHJvYWNoIHRoZXkgcHJlZmVyDQo+Pj5hbmQgd2h5Pw0KPj4+DQo+Pj5HaWxlcw0KPj4+DQo+Pj5P biAxMC8wNC8yMDEyIDAwOjQ1LCAiU2ltb24gRGVsb3JkIiA8c2ltb24uZGVsb3JkQGdtYWlsLmNv bTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4+DQo+Pj4+IEhpIEFs ZXhhbmRlciwNCj4+Pj4NCj4+Pj4gWW91IGFyZSByaWdodCwgbm8gZGlzY3Vzc2lvbiBvbiB0aGUg V0cgbWFpbGluZyBsaXN0IHJlY2VudGx5LCBidXQNCj4+Pj4gdGhlcmUgaGF2ZSBiZWVuIHN1YnN0 YW50aWFsIGRpc2N1c3Npb25zIGFtb25nIHRoZSBhdXRob3JzIG9mIHZhcmlvdXMNCj4+Pj4gc29s dXRpb24gZHJhZnRzIG9mZiB0aGUgbWFpbGluZyBsaXN0LiBBcyBmYXIgYXMgSSBrbm93LCBubyBj b25zZW5zdXMNCj4+Pj4geWV0IGJlZm9yZSBpZXRmODMsIG5vdCBzdXJlIHRoZSBwcm9ncmVzcyBp biB0aGUgUGFyaXMgV0cgbWVldGluZy4gSQ0KPj4+PiB0aGluayB0aGUgQ1cgYXBwcm9hY2ggaGFz IG5vdCBiZWVuIHJlamVjdGVkIGJ5IHRoZSBXRyB5ZXQsIG9yIHRoZSBXRw0KPj4+PiBoYXMgbm90 IHlldCBkZWNpZGVkIG9uIHdoaWNoIG9uZSB0byBhZG9wdC4NCj4+Pj4NCj4+Pj4gU2ltb24NCj4+ Pj4NCj4+Pj4gMjAxMi80LzggQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0 ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4+ DQo+Pj4+DQo+Pj4+PiAgSGkgYWxsLA0KPj4+Pj4NCj4+Pj4+IFVuZm9ydHVuYXRlbHkgSSBoYXZl IG5vdCBiZWVuIGFibGUgdG8gYXR0ZW5kIHRoZSBQYXJpcyBJRVRGLg0KPj4+Pj4NCj4+Pj4+IEhv d2V2ZXIsIGxvb2tpbmcgdXAgdGhlIEwyVlBOIHByb2NlZWRpbmdzLCBJJ3ZlIGZvdW5kIGEgc2hv cnQNCj4+Pj4+IGFub255bW91cyBwcmVzZW50YXRpb24gY2FsbGVkICJFLVRyZWUgVXBkYXRlIiAg KA0KPj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84My9zbGlkZXMvc2xpZGVz LTgzLWwydnBuLTEucHB0eCkuDQo+Pj4+PiBUaGlzIHByZXNlbnRhdGlvbiBkaXNjdXNzZXMgdGhl IGRpZmZlcmVuY2VzIG9mIHRoZSBFLVRyZWUgYXBwcm9hY2hlcw0KPj4+Pj4gYmFzZWQgb24gZGVk aWNhdGVkIFZMQU5zIChhcyBpbg0KPj4+Pj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1jYW8tbDJ2cG4tdnBscy1ldHJlZS8/aW5jbHVkZV90DQo+Pj4+PiBleHQ9MSkgYW5k IG11bHRpcGxlIFBXcyBiZXR3ZWVuIHRoZSBQRXMgKGFzIGluDQo+Pj4+PiBodHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJhbS1sMnZwbi1ldHJlZS1tdWx0aXBsZS1wdy8/aW4N Cj4+Pj4+IGNsdWRlX3RlDQo+Pj4+PiB4dD0xKQ0KPj4+Pj4gYW5kIGNvbXBsZXRlbHkgaWdub3Jl cyB0aGUgc29sdXRpb24gYmFzZWQgb24gdXNhZ2Ugb2YgdGhlIENXIGluIHRoZQ0KPj4+Pj4gUFdz IGNvbm5lY3RpbmcgdGhlIFBFcyAoYXMgaW4NCj4+Pj4+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQta2V5LWwydnBuLXZwbHMtZXRyZWUvP2luY2x1ZGVfdA0KPj4+Pj4gZXh0 PTENCj4+Pj4+ICkuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBUaGUgTWludXRlcyBvZiB0 aGUgUGFyaXMgTDJWUE4gc2Vzc2lvbiBhcmUgbm90IHlldCBhdmFpbGFibGUsIGJ1dCBJDQo+Pj4+ PiB3b25kZXIgd2hldGhlciB0aGUgV0cgaGFzIHRha2VuIGEgZGVjaXNpb24gdG8gcmVqZWN0IHRo ZSBhcHByb2FjaA0KPj4+Pj4gYmFzZWQgb24gdGhlIENXIHVzYWdlPyBJIGRvIG5vdCByZW1lbWJl ciBhbnkgcmVjZW50IGRpc2N1c3Npb24gb2YNCj4+Pj4+IHRoaXMgdG9waWMgb24gdGhlIFdHIG1h aWxpbmcgbGlzdC4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFJlZ2FyZHMsIGFuZCBsb3Rz IG9mIHRoYW5rcyBpbiBhZHZhbmNlLA0KPj4+Pj4NCj4+Pj4+IFNhc2hhDQo+Pj4+Pg0KPj4+Pj4N Cj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5k ZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMNCj4+Pj4+IGluZm9ybWF0aW9u IHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVD SQ0KPj4+DQo+Pj4+PiBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlz c2lvbiBpbiBlcnJvciwgcGxlYXNlDQo+Pj4+PiBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBv ciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kDQo+Pj4+PiBhbGwgY29waWVz IHRoZXJlb2YuDQo+Pj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+PlRoaXMgRS1tYWls IGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxl DQo+Pj5wcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlk ZW50aWFsLCBvciBzdWJqZWN0DQo+Pj50byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2Fy bmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZA0KPj4+c29sZWx5IGZvciB0aGUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuDQo+ Pj5JZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5 b3UgYXJlIGhlcmVieQ0KPj4+bm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJp YnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4NCj4+PmluIHJlbGF0aW9uIHRvIHRoZSBj b250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMNCj4+PnN0cmljdGx5 IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cw0KPj4+RS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYW5kIHBlcm1hbmVudGx5DQo+Pj5kZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBv ZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0KPj4+DQo+Pg0KPj4NCj4+VGhpcyBFLW1h aWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2Fi bGUNCj4+cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZp ZGVudGlhbCwgb3Igc3ViamVjdCB0bw0KPj5jb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2Fy bmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkNCj4+Zm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYg eW91DQo+PmFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91 IGFyZSBoZXJlYnkgbm90aWZpZWQNCj4+dGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0 aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4NCj4+cmVsYXRpb24gdG8gdGhlIGNvbnRl bnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseQ0KPj5wcm9o aWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1t YWlsIGluDQo+PmVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5k IHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUNCj4+b3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMg RS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo+DQo+DQo+IFRoaXMgRS1tYWlsIGFuZCBhbnkgb2Yg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5 IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1Ympl Y3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1h aWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQg YW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2Vu IGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBF LW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBh bnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0KPiBUaGlzIGUtbWFpbCBt ZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIGlu Zm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0 YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lv biBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5k IHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYWxsIGNvcGllcyB0aGVyZW9mLg0KPg0KPg0K Pg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTDJ2cG4gbWFpbGluZyBsaXN0DQo+ IEwydnBuQGlldGYub3JnPG1haWx0bzpMMnZwbkBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sMnZwbg0KPg0KPg0KPiBFbmQgb2YgTDJ2cG4gRGlnZXN0 LCBWb2wgOTUsIElzc3VlIDI1DQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq DQo= From jiangyuanlong@huawei.com Tue Apr 24 04:04:01 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5D421F8781 for ; Tue, 24 Apr 2012 04:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599] 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 IxnLRHxdi4TJ for ; Tue, 24 Apr 2012 04:04:00 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEBB21F8776 for ; Tue, 24 Apr 2012 04:04:00 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFE23915; Tue, 24 Apr 2012 07:03:56 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Apr 2012 04:01:32 -0700 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Apr 2012 04:01:34 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.137]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Tue, 24 Apr 2012 19:01:21 +0800 From: Jiangyuanlong To: Daniel Cohn , Lucy yong Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNIgmU1k2aA6Kt3k2K5fa9r1ZLkQ== Date: Tue, 24 Apr 2012 11:01:20 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EE65@SZXEML508-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: BKYe CUEQ C283 EUG8 Ev2u G7IB INaI I8GL I/lF LO0E LjS9 N5LS Rl4q Sgfd UWqP Wch+; 2; ZABhAG4AaQBlAGwAYwBAAG8AcgBjAGsAaQB0AC4AYwBvAG0AOwBsADIAdgBwAG4AQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {8134E663-07BF-44D2-9FA1-06FA13D52DF6}; agBpAGEAbgBnAHkAdQBhAG4AbABvAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Tue, 24 Apr 2012 11:01:17 GMT; UgBFADoAIABUAGgAZQAgAHMAdABhAHQAdQBzACAAbwBmACAAdABoAGUAIABhAHAAcAByAG8AYQBjAGgAZQBzACAAdABvACAAdABoAGUAIABFAC0AVAByAGUAZQAgAHMAbwBsAHUAdABpAG8AbgA/AA== x-cr-puzzleid: {8134E663-07BF-44D2-9FA1-06FA13D52DF6} x-originating-ip: [10.70.40.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 24 Apr 2012 11:04:01 -0000 This WG has already standardized PBB VPLS, and it has some fair enough adva= ntages, can we just reuse it for s-vlan preservation? I believe this will not constrain the possible evolution of the ENNI model. ------------------------------ From: "Daniel Cohn" To: "Lucy yong" , "Rogers, Josh" , "Shahram Davari" , "Lizhong Jin" , , Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <161901cd21ea$9d7d8486$05280101@corrigent.com> Content-Type: text/plain; charset=3D"utf-8" Lucy, even if the current MEF framework doesn't require s-vlan preservation, I be= lieve it's to the industry's benefit to adopt a solution that is not constr= ained to a specific enni model that, like all things networking, is likely = to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service provider= s' inputs. It had a fair reason to assume S-VLAN over ENNI by then. It may = open B-VLAN for the future. It is better for us not to discuss a future fr= amework here, because it will lead us to nowhere. Here, we want to extend V= PLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Va= inshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume tha= t the VLAN tags at the E-NNI will always be according to the current MEF mo= del? Or should we try to be as transparent as possible to user VLAN encapsu= lation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case VLAN t= ag) to signal VPLS information (in this case root/leaf origin) is necessari= ly tied to specific assumptions on user payload encapsulation (in this case= , that S-VLAN tag is "available" to encode root/leaf). I don't think this i= s a future-proof assumption, it's very likely that other network models wil= l come up that require S-VLAN preservation, which in the 2-VLAN approach wo= uld necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, "l2vpn@i= etf.org" >, "A= lexander.Vainshtein@ecitele.com" <= Alexander.Vainshtein@ecitele.com> Cc: "yuqun.cao@gmail.com" > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic alrea= dy has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com= Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L i= nformation, customer payload or PW? The customer payload will be always mod= ified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is access= ed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informati= on? Thanks Lizhong > ------------------------------ From DanielC@orckit.com Tue Apr 24 04:15:00 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FA021F874C for ; Tue, 24 Apr 2012 04:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HS_INDEX_PARAM=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 olRfxYi-X7OA for ; Tue, 24 Apr 2012 04:14:59 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 219B321F86B8 for ; Tue, 24 Apr 2012 04:14:57 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: The status of the approaches to the E-Tree solution? Date: Tue, 24 Apr 2012 14:17:00 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130777C5EE@tlvmail1> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IAAHuPxAAACKFwA= References: <161901cd21ea$9d7d8486$05280101@corrigent.com> From: "Daniel Cohn" To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "Lucy yong" , "Rogers, Josh" , "Shahram Davari" , "Lizhong Jin" , , Cc: yuqun.cao@gmail.com X-BeenThere: l2vpn@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, 24 Apr 2012 11:15:01 -0000 Tm8sIHRoZSBvdGhlciB3YXkgcm91bmQuIEluIHRoZSAyLVZMQU4gc29sdXRpb24sIFMtVkxBTiBJ RCBwcmVzZXJ2YXRpb24gcmVxdWlyZXMgYWRkaW5nIGEgdGhpcmQgVkxBTiBJRC4gSW4gdGhlIG11 bHRpLVBXIHNvbHV0aW9uLCB0aGlzIGlzIG5vdCByZXF1aXJlZC4NCg0KREMNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNwcmVjaGVyLCBOdXJpdCAoTlNOIC0gSUwvSG9kIEhh U2hhcm9uKSBbbWFpbHRvOm51cml0LnNwcmVjaGVyQG5zbi5jb21dIA0KU2VudDogVHVlc2RheSwg QXByaWwgMjQsIDIwMTIgMjowMiBQTQ0KVG86IERhbmllbCBDb2huOyBMdWN5IHlvbmc7IFJvZ2Vy cywgSm9zaDsgU2hhaHJhbSBEYXZhcmk7IExpemhvbmcgSmluOyBsMnZwbkBpZXRmLm9yZzsgQWxl eGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20NCkNjOiB5dXF1bi5jYW9AZ21haWwuY29tDQpT dWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNv bHV0aW9uPw0KDQpEYW5pZWwsDQpJcyBpdCBzbyB0aGF0IHlvdSBjb25zaWRlciBTLVZBTCBzdGFj a2luZz8NCklmIHRoaXMgaXMgdGhlIGNhc2UsIGFyZSB5b3UgYXdhcmUgdGhhdCB0aGlzIGlzIG5v dCBpbi1saW5lIHdpdGggdGhlIElFRUUgc3BlY2lmaWNhdGlvbnM/DQpCZXN0IHJlZ2FyZCwNCk51 cml0DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsMnZwbi1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBE YW5pZWwgQ29obg0KU2VudDogVHVlc2RheSwgQXByaWwgMjQsIDIwMTIgMTA6MTIgQU0NClRvOiBM dWN5IHlvbmc7IFJvZ2VycywgSm9zaDsgU2hhaHJhbSBEYXZhcmk7IExpemhvbmcgSmluOyBsMnZw bkBpZXRmLm9yZzsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20NCkNjOiB5dXF1bi5j YW9AZ21haWwuY29tDQpTdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0 byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KDQpMdWN5LA0KDQpldmVuIGlmIHRoZSBjdXJyZW50IE1F RiBmcmFtZXdvcmsgZG9lc24ndCByZXF1aXJlIHMtdmxhbiBwcmVzZXJ2YXRpb24sIEkgYmVsaWV2 ZSBpdCdzIHRvIHRoZSBpbmR1c3RyeSdzIGJlbmVmaXQgdG8gYWRvcHQgYSBzb2x1dGlvbiB0aGF0 IGlzIG5vdCBjb25zdHJhaW5lZCB0byBhIHNwZWNpZmljIGVubmkgbW9kZWwgdGhhdCwgbGlrZSBh bGwgdGhpbmdzIG5ldHdvcmtpbmcsIGlzIGxpa2VseSB0byBldm9sdmUuIEVzcGVjaWFsbHkgd2hl biBzdWNoIGEgc29sdXRpb24gaXMgYXZhaWxhYmxlLg0KDQpEYW5pZWwNCg0KVGh1bWIgdHlwZWQg LSBwbGVhc2UgYmUgdG9sZXJhbnQNCg0KTHVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbT4g d3JvdGU6DQoNCkRhbmllbCwNCg0KTUVGIGhhcyB3b3JrZWQgaW4gRU5OSSBpbnRlcmZhY2UgZm9y IGEgbG9uZyB0aW1lIHdpdGggbWFueSBzZXJ2aWNlIHByb3ZpZGVycycgaW5wdXRzLiBJdCBoYWQg YSBmYWlyIHJlYXNvbiB0byBhc3N1bWUgUy1WTEFOIG92ZXIgRU5OSSBieSB0aGVuLiBJdCBtYXkg b3BlbiBCLVZMQU4gZm9yIHRoZSBmdXR1cmUuIEl0IGlzIGJldHRlciBmb3IgdXMgbm90IHRvIGRp c2N1c3MgIGEgZnV0dXJlIGZyYW1ld29yayBoZXJlLCBiZWNhdXNlIGl0IHdpbGwgbGVhZCB1cyB0 byBub3doZXJlLiBIZXJlLCB3ZSB3YW50IHRvIGV4dGVuZCBWUExTIGluIHN1cHBvcnRpbmcgRS1U cmVlLg0KDQpCZXN0IFJlZ2FyZHMsDQpMdWN5DQoNCkZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGFuaWVsIENv aG4NClNlbnQ6IFN1bmRheSwgQXByaWwgMjIsIDIwMTIgNzozNCBBTQ0KVG86IFJvZ2VycywgSm9z aDsgU2hhaHJhbSBEYXZhcmk7IExpemhvbmcgSmluOyBsMnZwbkBpZXRmLm9yZzsgQWxleGFuZGVy LlZhaW5zaHRlaW5AZWNpdGVsZS5jb20NCkNjOiB5dXF1bi5jYW9AZ21haWwuY29tDQpTdWJqZWN0 OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9u Pw0KDQpTaGFocmFtIGFuZCBhbGwsDQoNClRoaXMgcXVlc3Rpb24gYWxyZWFkeSBjYW1lIHVwIGlu IG91ciBkaXNjdXNzaW9ucyAtIGlzIGl0IHNhZmUgdG8gYXNzdW1lIHRoYXQgdGhlIFZMQU4gdGFn cyBhdCB0aGUgRS1OTkkgd2lsbCBhbHdheXMgYmUgYWNjb3JkaW5nIHRvIHRoZSBjdXJyZW50IE1F RiBtb2RlbD8gT3Igc2hvdWxkIHdlIHRyeSB0byBiZSBhcyB0cmFuc3BhcmVudCBhcyBwb3NzaWJs ZSB0byB1c2VyIFZMQU4gZW5jYXBzdWxhdGlvbiBhdCB0aGUgRS1OTkksIHRvIGFjY29tbW9kYXRl IGZ1dHVyZSBmcmFtZXdvcmtzPw0KSSBiZWxpZXZlIHRoYXQgYW55IGFwcHJvYWNoIHRoYXQgbG9v a3MgYXQgdXNlciBwYXlsb2FkIChpbiB0aGlzIGNhc2UgVkxBTiB0YWcpIHRvIHNpZ25hbCBWUExT IGluZm9ybWF0aW9uIChpbiB0aGlzIGNhc2Ugcm9vdC9sZWFmIG9yaWdpbikgaXMgbmVjZXNzYXJp bHkgdGllZCB0byBzcGVjaWZpYyBhc3N1bXB0aW9ucyBvbiB1c2VyIHBheWxvYWQgZW5jYXBzdWxh dGlvbiAoaW4gdGhpcyBjYXNlLCB0aGF0IFMtVkxBTiB0YWcgaXMgImF2YWlsYWJsZSIgdG8gZW5j b2RlIHJvb3QvbGVhZikuIEkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBhIGZ1dHVyZS1wcm9vZiBhc3N1 bXB0aW9uLCBpdCdzIHZlcnkgbGlrZWx5IHRoYXQgb3RoZXIgbmV0d29yayBtb2RlbHMgd2lsbCBj b21lIHVwIHRoYXQgcmVxdWlyZSBTLVZMQU4gcHJlc2VydmF0aW9uLCB3aGljaCBpbiB0aGUgMi1W TEFOIGFwcHJvYWNoIHdvdWxkIG5lY2Vzc2l0YXRlIGFkZGluZyBhIHRoaXJkIFZMQU4tSUQuDQoN CkRhbmllbA0KDQpGcm9tOiBTaGFocmFtIERhdmFyaSA8ZGF2YXJpQGJyb2FkY29tLmNvbTxtYWls dG86ZGF2YXJpQGJyb2FkY29tLmNvbT4+DQpUbzogTGl6aG9uZyBKaW4gPGxpemhvLmppbkBnbWFp bC5jb208bWFpbHRvOmxpemhvLmppbkBnbWFpbC5jb20+PiwgImwydnBuQGlldGYub3JnPG1haWx0 bzpsMnZwbkBpZXRmLm9yZz4iIDxsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+ PiwgIkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFp bnNodGVpbkBlY2l0ZWxlLmNvbT4iIDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxt YWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+Pg0KQ2M6ICJ5dXF1bi5jYW9A Z21haWwuY29tPG1haWx0bzp5dXF1bi5jYW9AZ21haWwuY29tPiIgPHl1cXVuLmNhb0BnbWFpbC5j b208bWFpbHRvOnl1cXVuLmNhb0BnbWFpbC5jb20+Pg0KU3ViamVjdDogUkU6IFRoZSBzdGF0dXMg b2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCg0KSGksDQoNCkkgYWxz byBoYXZlIGEgcXVlc3Rpb24gcmVnYXJkaW5nIDItVkxBTi4gV2hhdCBpZiB0aGUgY3VzdG9tZXIg dHJhZmZpYyBhbHJlYWR5IGhhcyBhbiBTLVZMQU4/IERvIHdlIG5lZWQgYSAzcmQgVkxBTiB0byBp ZGVudGlmeSB0aGUgTC9SPw0KDQpUaHgNClNoYWhyYW0NCg0KRnJvbTogbDJ2cG4tYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpsMnZwbi1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGl6aG9uZyBKaW4NClNlbnQ6IEZyaWRheSwgQXBy aWwgMjAsIDIwMTIgOTozOCBBTQ0KVG86IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRm Lm9yZz47IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIu VmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4NCkNjOiB5dXF1bi5jYW9AZ21haWwuY29tPG1haWx0bzp5 dXF1bi5jYW9AZ21haWwuY29tPg0KU3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJv YWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCg0KSGksIGFsbCwNClRoZSBkaWZmZXJlbmNl IGJldHdlZW4gMi1WTEFOIGFuZCBDVyBhcHByb2FjaCBpcyB3aG8gd2lsbCBwcm92aWRlIHRoZSBS L0wgaW5mb3JtYXRpb24sIGN1c3RvbWVyIHBheWxvYWQgb3IgUFc/IFRoZSBjdXN0b21lciBwYXls b2FkIHdpbGwgYmUgYWx3YXlzIG1vZGlmaWVkIHRvIGNhcnJ5IFIvTCBpbmZvcm1hdGlvbiBpbiAy LVZMQU4gYXBwcm9hY2gsIHdoaWxlIFBXIHdpdGggQ1cgd2lsbCBjYXJyeSBSL0wgaW5mb3JtYXRp b24gZm9yIENXIGFwcHJvYWNoLg0KSSBoYXZlIGEgcXVlc3Rpb24gd2l0aCB0aGUgMi1WTEFOIGFw cHJvYWNoIGluIEgtVlBMUyB3aGVyZSBILVZQTFMgaXMgYWNjZXNzZWQgYnkgVlBXUyBhcyBkZXNj cmliZWQgaW4gUkZDNDY3MiBzZWN0aW9uIDEwLjEuMy4gSWYgVlBXUyBpcyB1c2VkIHRvIGFjY2Vz cyBILVZQTFMsIGhvdyBjb3VsZCB0aGUgUEUgb24gVlBXUyBzaWRlIGFkZHMgVkxBTiB0byBpbmRp Y2F0ZSBSL0wgaW5mb3JtYXRpb24/DQoNClRoYW5rcw0KTGl6aG9uZw0KDQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPiBNZXNzYWdlOiAyDQo+IERhdGU6IFRodSwgMTkgQXBy IDIwMTIgMDQ6Mzg6MzYgKzAwMDANCj4gRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbT4+DQo+IFRvOiAiUm9nZXJzLCBKb3NoIiA8am9zaC5yb2dlcnNAdHdjYWJsZS5j b208bWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29tPj4sIEx1Y3kgeW9uZw0KPiAgICAgICAg PGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+LCBEYW5p ZWwgQ29obiA8RGFuaWVsQ0BvcmNraXQuY29tPG1haWx0bzpEYW5pZWxDQG9yY2tpdC5jb20+Piwg U2FtIENhbw0KPiAgICAgICAgPHl1cXVuLmNhb0BnbWFpbC5jb208bWFpbHRvOnl1cXVuLmNhb0Bn bWFpbC5jb20+Pg0KPiBDYzogImwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4i IDxsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+Pg0KPiBTdWJqZWN0OiBSRTog VGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPiBN ZXNzYWdlLUlEOg0KPiAgICAgICAgPEY5MzM2NTcxNzMxQURFNDJBNTM5N0ZDODMxQ0VBQTAyMDM0 MTkyQEZSSURXUFBNQjAwMi5lY2l0ZWxlLmNvbTxtYWlsdG86RjkzMzY1NzE3MzFBREU0MkE1Mzk3 RkM4MzFDRUFBMDIwMzQxOTJARlJJRFdQUE1CMDAyLmVjaXRlbGUuY29tPj4NCj4gQ29udGVudC1U eXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSINCj4NCj4gSGkgYWxsLA0KPiBJIGZ1 bGx5IHVuZGVyc3RhbmQgdGhhdCB0aGF0IHdoYXQgSSBhbSBnb2luZyB0byBzYXkgaXMgbm90IHZl cnkgcG9wdWxhciwgYnV0Og0KPg0KPiBJTU8gb25lIG9mIHRoZSBhZHZhbnRhZ2VzIG9mIHRoZSBD Vy1iYXNlZCBzb2x1dGlvbiBpcyB0aGF0IGl0IGlzIG9ydGhvZ29uYWwgdG8gdXNhZ2UgKG9yIG5v bi11c2FnZSkgb2YgUDJNUCBQV3MgZm9yIGVmZmVjdGl2ZSBkZWxpdmVyeSBvZiBCVU4gdHJhZmZp Yy4NCj4NCj4gQW5vdGhlciBhZHZhbnRhZ2UgaXMgcHJlc2VydmF0aW9uIG9mIGZ1bGwgbWVzaCBv ZiBQMlAgUFdzIGluIGEgVlBMUywgYW5kLCBpbiBhIG1vcmUgZ2VuZXJpYyB3YXksIGxvY2FsaXph dGlvbiBvZiBlZmZlY3RzIG9mIGNoYW5nZXMgaW4gdGhlIFBFIGNvbmZpZ3VyYXRpb24uDQo+DQo+ IEluIHBhcnRpY3VsYXIsIGFkZGluZyBhIExlYWYgQUMgdG8gYSBQRSB0aGF0IHByZXZpb3VzbHkg aGFzIGJlZW4gb25seSBzdXBwb3J0aW5nIFJvb3QgQUNzIChvciB2aWNlIHZlcnNhKSwgcmVtb3Zh bCBvZiB0aGUgbGFzdCBMZWFmIG9yIGxhc3QgUm9vdCBBQyBmcm9tIGEgUEUgdGhhdCBwcmV2aW91 c2x5IGhhcyBiZWVuIHN1cHBvcnRpbmcgYSBtaXggZXRjLiBhZmZlY3Qgb25seSB0aGUgUEUgd2hl cmUgdGhpcyBvcGVyYXRpb24gaGFwcGVucyBhbmQgbm90IHRoZSByZXN0IG9mIHRoZSBQRXMuDQo+ DQo+IEFzIGZvciB0aGUgbmVlZCBmb3IgSFcgY2hhbmdlcyB0aGF0IGhhdmUgYmVlbiBtZW50aW9u ZWQgYXMgYSBtYWluIGRpc2FkdmFudGFnZSBvZiB0aGUgQ1ctYmFzZWQgYXBwcm9hY2ggLSBJIGJl bGlldmUgaXQgc3Ryb25nbHkgZGVwZW5kcyBvbiBzcGVjaWZpYyBpbXBsZW1lbnRhdGlvbnMuIEFu ZCBzb21lIGNoYW5nZXMgaW4gdGhlIGZvcndhcmRpbmcgcHJvY2VzcyBhcmUgcmVxdWlyZWQgaW4g YW55IHNvbHV0aW9uLg0KPg0KPiBNeSAyYywNCj4gICAgIFNhc2hhDQo+DQo+DQo+DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRnJvbTogbDJ2cG4tYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZz4gW2wydnBuLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc+XSBvbiBiZWhhbGYgb2YgUm9n ZXJzLCBKb3NoIFtqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbTxtYWlsdG86am9zaC5yb2dlcnNAdHdj YWJsZS5jb20+XQ0KPiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDE4LCAyMDEyIDk6NTcgUE0NCj4g VG86IEx1Y3kgeW9uZzsgRGFuaWVsIENvaG47IFNhbSBDYW8NCj4gQ2M6IGwydnBuQGlldGYub3Jn PG1haWx0bzpsMnZwbkBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFRoZSBzdGF0dXMgb2YgdGhl IGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4NCj4gQWdhaW4sIHRoZSBQMk1Q IHNpdHVhdGlvbiB0aHJvd3MgbWUuICBJcyB0aGlzIHNvbWV0aGluZyB0aGF0IGlzIHVzZWQNCj4g Y29tbW9ubHk/DQo+DQo+IEknbSB1bmRlciB0aGUgaW1wcmVzc2lvbiB0aGF0IGFkZGluZyBQMk1Q IHRvIGFueSBtb2RlbCByZXN1bHRzIGluIGEgbW9yZQ0KPiBjb21wbGV4IG1vZGVsLiAgV2V0aGVy IG91dHNpZGUgcy10YWcgaXMgdXNlZCB0byBkaWZmZXJlbnRpYXRlLCBvcg0KPiBkZWRpY2F0ZWQg cHcncyBhcmUgdXNlZCBmb3IgdGhlIHNhbWUgcHVycG9zZSwgaXQgc2VlbXMgYm90aCBiZWNvbWUg bW9yZQ0KPiBjb21wbGV4Lg0KPg0KPiBHaWxlJ3MgY29tcGFyaXNvbiBzbGlkZSBzdGlsbCBjb25j aXNlbHkgY2FwdHVyZXMgdGhlIGRpZmZlcmVuY2VzIGJldHdlZW4NCj4gdGhlc2UgbWV0aG9kcywg aW4gbXkgb3Bpbmlvbi4gIEkgaGF2ZW4ndCBzZWVuIGFueSBuZXcgaWRlYXMgb3IgdGhvdWdodHMN Cj4gYnJvdWdodCB0byB0aGUgZ3JvdXAgaW4gdGhlIHBhc3Qgd2VlayBvciB0d28gb24gdGhlIHN1 YmplY3QuICBJIHdvdWxkIGhhdGUNCj4gZm9yIGJvdGggcHJvcG9zZWQgbWV0aG9kcyB0byBkaWUg b24gdGhlIHZpbmUgYmVjYXVzZSB3ZSBjb3VsZG4ndCBkZWNpZGUNCj4gYmV0d2VlbiB0d28gbWV0 aG9kcyB0aGF0IGhhdmUgbm90aGluZyBpbmhlcmVudGx5IHdyb25nIHdpdGggZWl0aGVyLg0KPg0K PiAtSm9zaA0KPg0KPg0KPiBPbiA0LzE4LzEyIDE6NTMgUE0sICJMdWN5IHlvbmciIDxsdWN5Lnlv bmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiB3cm90ZToNCj4NCj4+ U2VuZCB0aGlzIGFnYWluLg0KPj4NCj4+VHdvIFBXIGFwcHJvYWNoIGNhbiBiZSBjb21wbGV4IHRv byBpZiB0aGUgVlBMUyBpbnN0YW5jZSBmb3IgRS1UcmVlIHVzZXMNCj4+UDJQIFBXIGZvciB1bmlj YXN0IHRyYWZmaWMgYW5kIFAyTVAgUFcgZm9yIGJyb2FkY2FzdCBhbmQgdW5rbm93bg0KPj51bmlj YXN0IHRyYWZmaWMsIGFuZCBzb21lIFAyTVAgUFdzIGZvciBtdWx0aWNhc3QgdHJhZmZpYy4gSXQg bWF5IGRvdWJsZQ0KPj5hbGwgb2YgdGhlbS4NCj4+DQo+Pkx1Y3kNCj4+DQo+Pi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IERhbmllbCBDb2huIFttYWlsdG86RGFuaWVsQ0BvcmNr aXQuY29tPG1haWx0bzpEYW5pZWxDQG9yY2tpdC5jb20+XQ0KPj5TZW50OiBXZWRuZXNkYXksIEFw cmlsIDE4LCAyMDEyIDE6NDIgUE0NCj4+VG86IEx1Y3kgeW9uZzsgUm9nZXJzLCBKb3NoOyBTYW0g Q2FvDQo+PkNjOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+DQo+PlN1Ympl Y3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRp b24/DQo+Pg0KPj5JIHRoaW5rIHRoZSBmaXJzdCBvcHRpb24gaXRzIHRoZSBuYXR1cmFsIHdheSB0 byBnby4gSG93IGlzIHRoZSBwcm9jZXNzaW5nDQo+PmluIHRoaXMgY2FzZSBtb3JlIGNvbXBsZXg/ DQo+Pg0KPj5UaHVtYiB0eXBlZCAtIHBsZWFzZSBiZSB0b2xlcmFudA0KPj4NCj4+THVjeSB5b25n IDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiB3cm90 ZToNCj4+DQo+Pg0KPj4NCj4+U25pcHBlZC4uDQo+Pg0KPj5NdWx0aS1QVyAtIE9uIGluZ3Jlc3Mg UEUsIGZyYW1lIGlzIHBsYWNlZCBvbnRvIGVpdGhlciBhIExlYWYtb25seSBQMk1QIFBXDQo+Pihm b3IgdHJhZmZpYyBjb21pbmcgZnJvbSBhIGxlYWYgQUMpLCBvciBvbnRvIGEgUm9vdC9MZWFmIFAy TVAgUFcgKGZvcg0KPj50cmFmZmljIGNvbWluZyBmcm9tIGEgcm9vdCBBQykNCj4+W1tMWV1dIE5v dCB0aGF0IHNpbXBsZS4gWW91IGNvbnN0cnVjdCBlaXRoZXIgdHdvIFAyTVAgUFdzIHRvIGFsbCBv dGhlcg0KPj5QRXMgYW5kIGxldCBlZ3Jlc3MgUEUgcGVyZm9ybWluZyBmaWx0ZXJpbmcsIG9yIGNv bnN0cnVjdCBvbmUgUDJNUCBQVyB0bw0KPj5sZWFmLW9ubHkgUEVzIGFuZCB0d28gUDJNUCBQV3Mg dG8gcm9vdCBhbmQgbGVhZiBQRXMgYW5kIGxldCBpbmdyZXNzIFBFDQo+PnBlcmZvcm0gZm9yd2Fy ZGluZyBhbmQgZmlsdGVyaW5nLiBCb3RoIG1ha2Ugbm9kZSBwcm9jZXNzIGNvbXBsZXguDQo+Pg0K Pj5bW0xZXV0gVlBMUyBpcyBidWlsdCB3aXRoIHRoZSBtZWNoYW5pc20gdXRpbGl6aW5nIFAyUCBh bmQgUDJNUCBQVyBmb3INCj4+ZGVsaXZlcmluZyB0aGUgZnJhbWVzIHRvIHJlbW90ZSBQRXMuIFdl IHNob3VsZCB1dGlsaXplIHRoZW0gd2l0aCB0aGUNCj4+bWluaW1pemVkIGNoYW5nZXMuIER1YWwg VkxBTiBzb2x1dGlvbiBpcyBzaW1wbGVyIHRoYW4gRHVhbCBQVy4NCj4+DQo+PlJlZ2FyZHMsDQo+ Pkx1Y3kNCj4+DQo+Pg0KPj5JIHNlZSBob3cgMlZMQU4gaXMgc2ltcGxlciB3aGVuIFAyTVAgUFcn cyBhcmUgaW52b2x2ZWQsIEkgdGhpbmsuICBJDQo+PmhhdmVuJ3QgaGFkIGFueSBmaXJzdCBoYW5k IGV4cGVyaWVuY2Ugd2l0aCBQMk1QIFBXJ3MsIGhvd2V2ZXIsIHNvIGRvbid0DQo+PmZlZWwgdGVy cmlibHkgc3Ryb25nIGFib3V0IHRoaXMgb2JqZWN0aW9uLiAgSXMgdGhpcyBhIHJlYWwgcHJvYmxl bSBmb3INCj4+b3RoZXJzIChub3cgb3IgaW4gdGhlIGZ1dHVyZSksIG9yIGlzIHRoaXMgb2JqZWN0 aW9uIGluIHRoZSB3ZWVkcz8NCj4+DQo+PkknbSBub3Qgc3VyZSB0aGUgJ2FkZGl0aW9uYWwgY29t cGxleGl0eScgaXMgbm90YWJsZSwgb3IgZXZlbiByZWxldmFudC4gIEkNCj4+ZW5jb3VyYWdlIG90 aGVycyB0byBzcGVhayB1cCBpZiB0aGV5IGRpc2FncmVlLCBhcyBQMk1QIFBXIGlzIG9ubHkNCj4+ Y29uY2VwdHVhbCB0byBtZSwgYW5kIEkgYW0gdW5mYW1pbGlhciB3aXRoIHJlYWwtbGlmZSB1c2Ug Y2FzZXMgZm9yIGl0Lg0KPj4NCj4+VGhhbmtzLA0KPj5Kb3NoDQo+Pg0KPj4NCj4+DQo+Pk9uIDQv MTgvMTIgMTA6MzAgQU0sICJMdWN5IHlvbmciIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86 bHVjeS55b25nQGh1YXdlaS5jb20+PiB3cm90ZToNCj4+DQo+Pj5QbGVhc2Ugc2VlIGlubGluZS4N Cj4+Pg0KPj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IFNhbSBDYW8gW21h aWx0bzp5dXF1bi5jYW9AZ21haWwuY29tPG1haWx0bzp5dXF1bi5jYW9AZ21haWwuY29tPl0NCj4+ PlNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE3LCAyMDEyIDc6MTQgQU0NCj4+PlRvOiAnRGFuaWVsIENv aG4nOyBMdWN5IHlvbmc7ICdSb2dlcnMsIEpvc2gnOyAnSGVuZGVyaWNreCwgV2ltIChXaW0pJzsN Cj4+PmdpbGVzLmhlcm9uQGdtYWlsLmNvbTxtYWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tPjsg c2ltb24uZGVsb3JkQGdtYWlsLmNvbTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT47DQo+ Pj5BbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5z aHRlaW5AZWNpdGVsZS5jb20+DQo+Pj5DYzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGll dGYub3JnPjsgVmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbTxtYWlsdG86VmxhZGltaXIuS2xl aW5lckBlY2l0ZWxlLmNvbT47DQo+Pj5BbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86 QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb20+OyBJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbTxtYWls dG86SWRhbi5LYXNwaXRAZWNpdGVsZS5jb20+Ow0KPj4+TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5j b208bWFpbHRvOk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPjsgUm90ZW0uQ29oZW5AZWNpdGVs ZS5jb208bWFpbHRvOlJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPg0KPj4+U3ViamVjdDogUkU6IFRo ZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4+Pg0K Pj4+WWVzLCAyIHB3cyBhcmUgb25seSBuZWVkZWQgYmV0d2VlbiBwZXMgd2l0aCBib3RoIHJvb3Qg YW5kIGxlYWYgYWNzIGFmdGVyDQo+Pj5pbXByb3ZpbmcgRHVhbC1QVyBhcHByb2FjaC4gSWYgY29u c2lkZXIgUDJNUCwgRHVhbC1QVyBhcHByb2FjaCBzZXR1cCAyDQo+Pj5QMk1QDQo+Pj5QV3MgaWYg bmVlZC4gVGhlcmUgaXMgbm8gZGlmZmVyZW5jZSBiZXR3ZWVuIFAyTVAgb3Igbm9ybWFsIFBXIHNl dHVwLiBCdXQsDQo+Pj5jYW4gTGVhZi1BQ3MgYmUgYm91bmQgdG8gUm9vdCBQRSBvZiBQMk1QIFBX Pw0KPj4+DQo+Pj5bW0xZXV0gTm8sIGl0IG1ha2VzIGNvbXBsZXggaW4gc2V0dGluZyB1cCBQMk1Q IFBXLiBTaG91bGQgYSBQRSB3aXRoIGJvdGgNCj4+PnJvb3QgYW5kIGxlYWYgQUNzIHNldCB1cCB0 d28gb3Igb25lIFAyTVAgUFcgdG8gb3RoZXIgUEVzIChzb21lIFBFIGhhdmUNCj4+PmJvdGggcm9v dCBhbmQgbGVhZiBBQyBhbmQgc29tZSBvbmx5IGhhdmUgbGVhZiBBQ3MpPw0KPj4+UmVnYXJkcywN Cj4+Pkx1Y3kNCj4+Pg0KPj4+UmVnYXJkcywNCj4+Pg0KPj4+WXVxdW4gKFNhbSkgQ2FvDQo+Pj5F LW1haWw6IFl1cXVuLmNhb0BnbWFpbC5jb208bWFpbHRvOll1cXVuLmNhb0BnbWFpbC5jb20+DQo+ Pj4NCj4+Pg0KPj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IERhbmllbCBD b2huIFttYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tPG1haWx0bzpEYW5pZWxDQG9yY2tpdC5jb20+ XQ0KPj4+U2VudDogVHVlc2RheSwgQXByaWwgMTcsIDIwMTIgNDo1NiBQTQ0KPj4+VG86IEx1Y3kg eW9uZzsgUm9nZXJzLCBKb3NoOyBIZW5kZXJpY2t4LCBXaW0gKFdpbSk7DQo+Pj5naWxlcy5oZXJv bkBnbWFpbC5jb208bWFpbHRvOmdpbGVzLmhlcm9uQGdtYWlsLmNvbT47DQo+Pj5zaW1vbi5kZWxv cmRAZ21haWwuY29tPG1haWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPjsgQWxleGFuZGVyLlZh aW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUu Y29tPjsgU2FtIENhbw0KPj4+Q2M6IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9y Zz47IFZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJA ZWNpdGVsZS5jb20+Ow0KPj4+QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb208bWFpbHRvOkFuZHJl dy5TZXJnZWV2QGVjaXRlbGUuY29tPjsgSWRhbi5LYXNwaXRAZWNpdGVsZS5jb208bWFpbHRvOklk YW4uS2FzcGl0QGVjaXRlbGUuY29tPjsNCj4+Pk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPG1h aWx0bzpNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT47IFJvdGVtLkNvaGVuQGVjaXRlbGUuY29t PG1haWx0bzpSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbT4NCj4+PlN1YmplY3Q6IFJFOiBUaGUgc3Rh dHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4NCj4+PkFk ZGluZyBTYW0gKGFzIGwydnBuQCBpcyBob2xkaW5nIG1lc3NhZ2VzKQ0KPj4+DQo+Pj5EQw0KPj4+ DQo+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+RnJvbTogTHVjeSB5b25nIFttYWls dG86bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPl0NCj4+ PlNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE3LCAyMDEyIDEyOjM5IEFNDQo+Pj5UbzogRGFuaWVsIENv aG47IFJvZ2VycywgSm9zaDsgSGVuZGVyaWNreCwgV2ltIChXaW0pOw0KPj4+Z2lsZXMuaGVyb25A Z21haWwuY29tPG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+OyBzaW1vbi5kZWxvcmRAZ21h aWwuY29tPG1haWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPjsNCj4+PkFsZXhhbmRlci5WYWlu c2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bT4NCj4+PkNjOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBWbGFkaW1p ci5LbGVpbmVyQGVjaXRlbGUuY29tPG1haWx0bzpWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29t PjsNCj4+PkFuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPG1haWx0bzpBbmRyZXcuU2VyZ2VldkBl Y2l0ZWxlLmNvbT47IElkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0bzpJZGFuLkthc3BpdEBl Y2l0ZWxlLmNvbT47DQo+Pj5NaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbTxtYWlsdG86TWlzaGFl bC5XZXhsZXJAZWNpdGVsZS5jb20+OyBSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbTxtYWlsdG86Um90 ZW0uQ29oZW5AZWNpdGVsZS5jb20+DQo+Pj5TdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUg YXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+DQo+Pj4NCj4+PlNuaXBwZWQs DQo+Pj4NCj4+PkFzIHdlIGRpc2N1c3NlZCBleHRlbnNpdmVseSBpbiB0aGUgbGlzdCwgYW5kIGFz IHJlZmxlY3RlZCBpbiBnaWxlcw0KPj4+c2xpZGUsIDIgcHdzIGFyZSBvbmx5IG5lZWRlZCBiZXR3 ZWVuIHBlcyB3aXRoIGJvdGggcm9vdCBhbmQgbGVhZiBhY3MsDQo+Pj53aGljaCB3aWxsIHR5cGlj YWxseSBiZSBhIHNtYWxsIG1pbm9yaXR5Lg0KPj4+W1tMWV1dIERvbid0IGtub3cgaWYgdGhlIGFz c3VtcHRpb24gaXMgdHJ1ZS4gRXZlbiBpdCBpcyB0aGUgY2FzZSwgYm90aA0KPj4+YXBwcm9hY2hl cyBjYW4gYmVuZWZpdCBmcm9tIGl0LiBJIHdhcyBvZmYgZm9yIGEgd2hpbGUgYW5kIGNhcHR1cmVz IHNvbWUNCj4+PmRpc2N1c3Npb25zIG5vdy4NCj4+Pg0KPj4+QWxzbyBhcyBwZXIgZ2lsZXMgc2xp ZGUsIGR1YWwgdmxhbiBjYW4gaGF2ZSBzY2FsYWJpbGl0eSBpc3N1ZXMgZHVlIHRvDQo+Pj5hZGRp dGlvbmFsIGxvb2t1cCBhbmQgZG91YmxlIHVzZSBvZiB2bGFucyBpbiBpbnRlcm5hbCBlbXVsYXRl ZCBsYW4NCj4+PmludGVyZmFjZS4gQWxzbyB0aGVyZSBhcmUgcG90ZW50aWFsIGJhY2t3YXJkIGNv bXBhdGliaWxpdHkgaXNzdWVzIHdpdGgNCj4+PnNpbGljb24gdGhhdCBkb2Vzbid0IHN1cHBvcnQg dmxhbiBtYXBwaW5nLg0KPj4+W1tMWV1dIEkgd2FzIG5vdCBpbiBJRVRGODMgbWVldGluZyBhbmQg d2FpdCBvbiB0aGUgbWVldGluZyBtaW51dGVzLiBJIGFtDQo+Pj5ub3QgY2xlYXIgb24gYWxsIHRo ZSBpc3N1ZXMuIENvdWxkIHlvdSBiZSBtb3JlIHNwZWNpZmljPyBBcyBJIG1lbnRpb25lZA0KPj4+ aW4gYmVsb3csIHR3byBQVyBhcHByb2FjaCBtYWtlcyBWUExTIHRyYW5zcG9ydCBjb25zdHJ1Y3Rp b24gYW5kIHBhY2tldA0KPj4+Zm9yd2FyZGluZyBtb3JlIGNvbXBsZXgsIEkgY2FuIHNlZSBwb3Rl bnRpYWwgYmFja3dhcmQgY29tcGF0aWJpbGl0eQ0KPj4+aXNzdWVzIHdpdGggMiBQVyBzb2x1dGlv bi4NCj4+Pg0KPj4+UmVnYXJkcywNCj4+Pkx1Y3kNCj4+Pg0KPj4+UmVnYXJkcywNCj4+Pg0KPj4+ RGFuaWVsDQo+Pj4NCj4+PlRodW1iIHR5cGVkIC0gcGxlYXNlIGJlIHRvbGVyYW50DQo+Pj4NCj4+ Pkx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWku Y29tPj4gd3JvdGU6DQo+Pj4NCj4+PkluIG15IG1pbmQsIHRoZSBWTEFOIGFwcHJvYWNoIG1lYW5z IGR1YWwgdmxhbiBtZXRob2QuDQo+Pj4NCj4+PlRoZSBtYWluIGNvbmNlcm4gZm9yIENXIGFwcHJv YWNoIGlzIGhhcmR3YXJlIHN1cHBvcnQuDQo+Pj4NCj4+PlR3byBQVyBhcHByb2FjaCBjYW4gYmUg Y29tcGxleCB0b28gaWYgdGhlIFZQTFMgaW5zdGFuY2UgZm9yIEUtVHJlZSB1c2VzDQo+Pj5QMlAg UFcgZm9yIHVuaWNhc3QgdHJhZmZpYyBhbmQgUDJNUCBQVyBmb3IgYnJvYWRjYXN0IGFuZCB1bmtu b3duIHVuaWNhc3QNCj4+PnRyYWZmaWMsIGFuZCBzb21lIFAyTVAgUFdzIGZvciBtdWx0aWNhc3Qg dHJhZmZpYy4gSXQgbWF5IGRvdWJsZSBhbGwgb2YNCj4+PnRoZW0uDQo+Pj4NCj4+PkUtdHJlZSBp cyBhbiBFdGhlcm5ldCBzZXJ2aWNlIGFuZCB0aGVyZSBpcyBhbHJlYWR5IFZMQU4gYmFzZWQgc29s dXRpb24NCj4+PmluIElFRUUsIGNhbiB3ZSBqdXN0IHV0aWxpemUgaXQgd2l0aG91dCBjb21wbGlj YXRpbmcgVlBMUyB0cmFuc3BvcnQNCj4+PmNvbnN0cnVjdGlvbj8gVGhpcyBhbHNvIG1ha2VzIGlu dGVyd29ya2luZyB3aXRoIEV0aCBvbmx5IG5ldHdvcmsgZWFzaWVyLg0KPj4+DQo+Pj5DaGVlcnMs DQo+Pj5MdWN5DQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBS b2dlcnMsIEpvc2ggW21haWx0bzpqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbTxtYWlsdG86am9zaC5y b2dlcnNAdHdjYWJsZS5jb20+XQ0KPj4+U2VudDogTW9uZGF5LCBBcHJpbCAxNiwgMjAxMiA4OjM1 IEFNDQo+Pj5UbzogTHVjeSB5b25nOyBIZW5kZXJpY2t4LCBXaW0gKFdpbSk7ICdnaWxlcy5oZXJv bkBnbWFpbC5jb208bWFpbHRvOmdpbGVzLmhlcm9uQGdtYWlsLmNvbT4nOw0KPj4+J3NpbW9uLmRl bG9yZEBnbWFpbC5jb208bWFpbHRvOnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+JzsgJ0FsZXhhbmRl ci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0 ZWxlLmNvbT4nDQo+Pj5DYzogJ2wydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4n OyAnVmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbTxtYWlsdG86VmxhZGltaXIuS2xlaW5lckBl Y2l0ZWxlLmNvbT4nOw0KPj4+J0FuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPG1haWx0bzpBbmRy ZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbT4nOyAnSWRhbi5LYXNwaXRAZWNpdGVsZS5jb208bWFpbHRv OklkYW4uS2FzcGl0QGVjaXRlbGUuY29tPic7DQo+Pj4nTWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5j b208bWFpbHRvOk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPic7ICdSb3RlbS5Db2hlbkBlY2l0 ZWxlLmNvbTxtYWlsdG86Um90ZW0uQ29oZW5AZWNpdGVsZS5jb20+Jw0KPj4+U3ViamVjdDogUkU6 IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4+ Pg0KPj4+SSBiZWxpZXZlIHRoZSBpbml0aWFsIHF1ZXN0aW9uIHdhcyBpbiByZWdhcmQgdG8gdGhl IENXIG1ldGhvZC4gIEFyZSB5b3UNCj4+PnNheWluZyB0aGF0IHlvdSBubyBsb25nZXIgYXJlIGlu dGVyZXN0ZWQgaW4gdGhhdCBtZXRob2QgaW4gcHJlZmVyZW5jZSBvZg0KPj4+dGhlIGR1YWwgdmxh biBtZXRob2Q/DQo+Pj4NCj4+Pg0KPj4+DQo+Pj5MdWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3ZWku Y29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KPj4+DQo+Pj4NCj4+PkFn cmVlIHdpdGggV2ltLiBWTEFOIGFwcHJvYWNoIGlzIHRoZSBiZXN0IHNvbHV0aW9uIGZvciBFLVRy ZWUuDQo+Pj4NCj4+Pkx1Y3kNCj4+Pg0KPj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ PkZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5v cmc+IFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bDJ2cG4tYm91bmNlc0Bp ZXRmLm9yZz5dIE9uIEJlaGFsZg0KPj4+T2YgSGVuZGVyaWNreCwgV2ltIChXaW0pDQo+Pj5TZW50 OiBUaHVyc2RheSwgQXByaWwgMTIsIDIwMTIgMjowMyBBTQ0KPj4+VG86ICdnaWxlcy5oZXJvbkBn bWFpbC5jb208bWFpbHRvOmdpbGVzLmhlcm9uQGdtYWlsLmNvbT4nOyAnc2ltb24uZGVsb3JkQGdt YWlsLmNvbTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT4nOw0KPj4+J0FsZXhhbmRlci5W YWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbT4nDQo+Pj5DYzogJ2wydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4nOyAn VmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbTxtYWlsdG86VmxhZGltaXIuS2xlaW5lckBlY2l0 ZWxlLmNvbT4nOw0KPj4+J0FuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPG1haWx0bzpBbmRyZXcu U2VyZ2VldkBlY2l0ZWxlLmNvbT4nOyAnSWRhbi5LYXNwaXRAZWNpdGVsZS5jb208bWFpbHRvOklk YW4uS2FzcGl0QGVjaXRlbGUuY29tPic7DQo+Pj4nTWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb208 bWFpbHRvOk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPic7ICdSb3RlbS5Db2hlbkBlY2l0ZWxl LmNvbTxtYWlsdG86Um90ZW0uQ29oZW5AZWNpdGVsZS5jb20+Jw0KPj4+U3ViamVjdDogUmU6IFRo ZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4+Pg0K Pj4+VGhlIHZsYW4gYXBwcm9hY2ggaXMgc3VwZXJpb3IgYXMgaXQgYWxzbyB3b3JrcyBmb3IgZXRo IG9ubHkgbmV0d29ya3MsDQo+Pj5ldGMuIE9uIHRvcCBzb21lIHZlbmRvcnMgaW5kaWNhdGUgaHcg aXNzdWVzIHdpdGggdGhlIGN3IGFwcHJvYWNoLiBBcw0KPj4+c3VjaCB3ZSBoYXZlIGRyb3BwZWQg bW9yZSBvciBsZXNzIHRoZSBjdyBhcHByb2FjaC4NCj4+Pg0KPj4+Q2hlZXJzLA0KPj4+V2ltDQo+ Pj5fX19fX19fX19fX19fX19fXw0KPj4+c2VudCBmcm9tIGJsYWNrYmVycnkNCj4+Pg0KPj4+LS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPj4+RnJvbTogR2lsZXMgSGVyb24gW21haWx0bzpn aWxlcy5oZXJvbkBnbWFpbC5jb208bWFpbHRvOmdpbGVzLmhlcm9uQGdtYWlsLmNvbT5dDQo+Pj5T ZW50OiBUaHVyc2RheSwgQXByaWwgMTIsIDIwMTIgMDg6MjIgQU0NCj4+PlRvOiBTaW1vbiBEZWxv cmQgPHNpbW9uLmRlbG9yZEBnbWFpbC5jb208bWFpbHRvOnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+ PjsgQWxleGFuZGVyIFZhaW5zaHRlaW4NCj4+PjxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+Pg0KPj4+Q2M6IGwy dnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4gPGwydnBuQGlldGYub3JnPG1haWx0 bzpsMnZwbkBpZXRmLm9yZz4+OyBWbGFkaW1pciBLbGVpbmVyDQo+Pj48VmxhZGltaXIuS2xlaW5l ckBlY2l0ZWxlLmNvbTxtYWlsdG86VmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbT4+OyBBbmRy ZXcgU2VyZ2Vldg0KPj4+PEFuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPG1haWx0bzpBbmRyZXcu U2VyZ2VldkBlY2l0ZWxlLmNvbT4+OyBJZGFuIEthc3BpdCA8SWRhbi5LYXNwaXRAZWNpdGVsZS5j b208bWFpbHRvOklkYW4uS2FzcGl0QGVjaXRlbGUuY29tPj47DQo+Pj5NaXNoYWVsIFdleGxlciA8 TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb208bWFpbHRvOk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUu Y29tPj47IFJvdGVtIENvaGVuDQo+Pj48Um90ZW0uQ29oZW5AZWNpdGVsZS5jb208bWFpbHRvOlJv dGVtLkNvaGVuQGVjaXRlbGUuY29tPj4NCj4+PlN1YmplY3Q6IFJlOiBUaGUgc3RhdHVzIG9mIHRo ZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4NCj4+PlNvcnJ5IC0gdGhl ICJhbm9ueW1vdXMgcHJlc2VudGF0aW9uIiB3YXMgbWluZS4gIEkgc2hvdWxkIHBvc3NpYmx5IGhh dmUNCj4+PnB1dCBpbiBhIHRoaXJkIGNvbHVtbiBvbiB0aGUgQ1cgYXBwcm9hY2guICBBbmQgaG9w ZWZ1bGx5IHRoZSBtaW51dGVzDQo+Pj53aWxsIGJlIHBvc3RlZCBzb29uLg0KPj4+DQo+Pj5XZSBo YWQgdmFyaW91cyBkaXNjdXNzaW9ucywgYXMgU2ltb24gc3RhdGVkLCBhbmQgY29uc2Vuc3VzIHNl ZW1lZCB0byBiZQ0KPj4+Zm9ybWluZyBhcm91bmQgdGhlIHR3byBhbHRlcm5hdGl2ZXMgb2YgdHdv IFBXRXMgb3IgdHdvIFZMQU5zLiAgSSBiZWxpZXZlDQo+Pj50aHJlZSBvZiB0aGUgYXV0aG9ycyBv ZiB0aGUgQ1cgYXBwcm9hY2ggYXJlIGFsc28gYXV0aG9ycyBvZiB0aGUgdHdvIFZMQU4NCj4+PmFw cHJvYWNoIGFuZCBvbmUgaXMgYWxzbyBhbiBhdXRob3Igb2YgdGhlIHR3byBQV0UgYXBwcm9hY2gu IFNvIHBlcmhhcHMNCj4+Pml0J3MgYmVzdCB0byBsZXQgdGhvc2UgZm91ciBpbmRpdmlkdWFscyBz YXkgd2hpY2ggYXBwcm9hY2ggdGhleSBwcmVmZXINCj4+PmFuZCB3aHk/DQo+Pj4NCj4+PkdpbGVz DQo+Pj4NCj4+Pk9uIDEwLzA0LzIwMTIgMDA6NDUsICJTaW1vbiBEZWxvcmQiIDxzaW1vbi5kZWxv cmRAZ21haWwuY29tPG1haWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPj4gd3JvdGU6DQo+Pj4N Cj4+Pj4gSGkgQWxleGFuZGVyLA0KPj4+Pg0KPj4+PiBZb3UgYXJlIHJpZ2h0LCBubyBkaXNjdXNz aW9uIG9uIHRoZSBXRyBtYWlsaW5nIGxpc3QgcmVjZW50bHksIGJ1dA0KPj4+PiB0aGVyZSBoYXZl IGJlZW4gc3Vic3RhbnRpYWwgZGlzY3Vzc2lvbnMgYW1vbmcgdGhlIGF1dGhvcnMgb2YgdmFyaW91 cw0KPj4+PiBzb2x1dGlvbiBkcmFmdHMgb2ZmIHRoZSBtYWlsaW5nIGxpc3QuIEFzIGZhciBhcyBJ IGtub3csIG5vIGNvbnNlbnN1cw0KPj4+PiB5ZXQgYmVmb3JlIGlldGY4Mywgbm90IHN1cmUgdGhl IHByb2dyZXNzIGluIHRoZSBQYXJpcyBXRyBtZWV0aW5nLiBJDQo+Pj4+IHRoaW5rIHRoZSBDVyBh cHByb2FjaCBoYXMgbm90IGJlZW4gcmVqZWN0ZWQgYnkgdGhlIFdHIHlldCwgb3IgdGhlIFdHDQo+ Pj4+IGhhcyBub3QgeWV0IGRlY2lkZWQgb24gd2hpY2ggb25lIHRvIGFkb3B0Lg0KPj4+Pg0KPj4+ PiBTaW1vbg0KPj4+Pg0KPj4+PiAyMDEyLzQvOCBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFu ZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tPj4NCj4+Pj4NCj4+Pj4+ICBIaSBhbGwsDQo+Pj4+Pg0KPj4+Pj4gVW5mb3J0dW5h dGVseSBJIGhhdmUgbm90IGJlZW4gYWJsZSB0byBhdHRlbmQgdGhlIFBhcmlzIElFVEYuDQo+Pj4+ Pg0KPj4+Pj4gSG93ZXZlciwgbG9va2luZyB1cCB0aGUgTDJWUE4gcHJvY2VlZGluZ3MsIEkndmUg Zm91bmQgYSBzaG9ydA0KPj4+Pj4gYW5vbnltb3VzIHByZXNlbnRhdGlvbiBjYWxsZWQgIkUtVHJl ZSBVcGRhdGUiICAoDQo+Pj4+PiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzgzL3Ns aWRlcy9zbGlkZXMtODMtbDJ2cG4tMS5wcHR4KS4NCj4+Pj4+IFRoaXMgcHJlc2VudGF0aW9uIGRp c2N1c3NlcyB0aGUgZGlmZmVyZW5jZXMgb2YgdGhlIEUtVHJlZSBhcHByb2FjaGVzDQo+Pj4+PiBi YXNlZCBvbiBkZWRpY2F0ZWQgVkxBTnMgKGFzIGluDQo+Pj4+PiBodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWNhby1sMnZwbi12cGxzLWV0cmVlLz9pbmNsdWRlX3QNCj4+Pj4+ IGV4dD0xKSBhbmQgbXVsdGlwbGUgUFdzIGJldHdlZW4gdGhlIFBFcyAoYXMgaW4NCj4+Pj4+IGh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmFtLWwydnBuLWV0cmVlLW11bHRp cGxlLXB3Lz9pbg0KPj4+Pj4gY2x1ZGVfdGUNCj4+Pj4+IHh0PTEpDQo+Pj4+PiBhbmQgY29tcGxl dGVseSBpZ25vcmVzIHRoZSBzb2x1dGlvbiBiYXNlZCBvbiB1c2FnZSBvZiB0aGUgQ1cgaW4gdGhl DQo+Pj4+PiBQV3MgY29ubmVjdGluZyB0aGUgUEVzIChhcyBpbg0KPj4+Pj4gaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rZXktbDJ2cG4tdnBscy1ldHJlZS8/aW5jbHVkZV90 DQo+Pj4+PiBleHQ9MQ0KPj4+Pj4gKS4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFRoZSBN aW51dGVzIG9mIHRoZSBQYXJpcyBMMlZQTiBzZXNzaW9uIGFyZSBub3QgeWV0IGF2YWlsYWJsZSwg YnV0IEkNCj4+Pj4+IHdvbmRlciB3aGV0aGVyIHRoZSBXRyBoYXMgdGFrZW4gYSBkZWNpc2lvbiB0 byByZWplY3QgdGhlIGFwcHJvYWNoDQo+Pj4+PiBiYXNlZCBvbiB0aGUgQ1cgdXNhZ2U/IEkgZG8g bm90IHJlbWVtYmVyIGFueSByZWNlbnQgZGlzY3Vzc2lvbiBvZg0KPj4+Pj4gdGhpcyB0b3BpYyBv biB0aGUgV0cgbWFpbGluZyBsaXN0Lg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gUmVnYXJk cywgYW5kIGxvdHMgb2YgdGhhbmtzIGluIGFkdmFuY2UsDQo+Pj4+Pg0KPj4+Pj4gU2FzaGENCj4+ Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gVGhpcyBlLW1haWwgbWVzc2Fn ZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucw0KPj4+Pj4g aW5mb3JtYXRpb24gd2hpY2ggaXMgQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJp ZXRhcnkgdG8gRUNJDQo+Pj4NCj4+Pj4+IFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UNCj4+Pj4+IGluZm9ybSB1cyBieSBlLW1h aWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQNCj4+Pj4+ IGFsbCBjb3BpZXMgdGhlcmVvZi4NCj4+Pj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+ VGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBX YXJuZXIgQ2FibGUNCj4+PnByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxl Z2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QNCj4+PnRvIGNvcHlyaWdodCBiZWxvbmdpbmcg dG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkDQo+Pj5zb2xlbHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFk ZHJlc3NlZC4NCj4+PklmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhp cyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5DQo+Pj5ub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0 aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbg0KPj4+aW4gcmVsYXRp b24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcw0K Pj4+c3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzDQo+Pj5FLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkNCj4+PmRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5k IGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo+Pj4NCj4+DQo+Pg0K Pj5UaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1l IFdhcm5lciBDYWJsZQ0KPj5wcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmls ZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvDQo+PmNvcHlyaWdodCBiZWxvbmdpbmcg dG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseQ0KPj5m b3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRk cmVzc2VkLiBJZiB5b3UNCj4+YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMg RS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZA0KPj50aGF0IGFueSBkaXNzZW1pbmF0aW9u LCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbg0KPj5yZWxhdGlvbiB0 byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmlj dGx5DQo+PnByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBFLW1haWwgaW4NCj4+ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZQ0KPj5vcmlnaW5hbCBhbmQgYW55IGNv cHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCj4NCj4NCj4gVGhpcyBFLW1haWwg YW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUg cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlh bCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxl LiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90 aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBh Y3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50 cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdm dWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3Jp Z2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo+IFRo aXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQg Y29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggaXMgQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkg YmUgcHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg dHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUg b3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbGwgY29waWVzIHRoZXJl b2YuDQo+DQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMMnZwbiBtYWls aW5nIGxpc3QNCj4gTDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOkwydnBuQGlldGYub3JnPg0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wydnBuDQo+DQo+DQo+IEVuZCBvZiBM MnZwbiBEaWdlc3QsIFZvbCA5NSwgSXNzdWUgMjUNCj4gKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioNCg== From wim.henderickx@alcatel-lucent.com Tue Apr 24 05:41:31 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4CDB21F87C1 for ; Tue, 24 Apr 2012 05:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.018 X-Spam-Level: X-Spam-Status: No, score=-10.018 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 uvRh-nzYlcL3 for ; Tue, 24 Apr 2012 05:41:30 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id A4CA321F87C0 for ; Tue, 24 Apr 2012 05:41:30 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3OCehkp030133 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Apr 2012 14:41:22 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 24 Apr 2012 14:40:49 +0200 From: "Henderickx, Wim (Wim)" To: "'jiangyuanlong@huawei.com'" , "'DanielC@orckit.com'" , "'lucy.yong@huawei.com'" Date: Tue, 24 Apr 2012 14:40:48 +0200 Subject: Re: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNIgmU1k2aA6Kt3k2K5fa9r1ZLkZap6t+P Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D67012961AA80@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EE65@SZXEML508-MBS.china.huawei.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "'l2vpn@ietf.org'" X-BeenThere: l2vpn@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, 24 Apr 2012 12:41:31 -0000 Agreed Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Tuesday, April 24, 2012 01:01 PM=0A= To: Daniel Cohn ; Lucy yong Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? This WG has already standardized PBB VPLS, and it has some fair enough adva= ntages, can we just reuse it for s-vlan preservation? I believe this will not constrain the possible evolution of the ENNI model. ------------------------------ From: "Daniel Cohn" To: "Lucy yong" , "Rogers, Josh" , "Shahram Davari" , "Lizhong Jin" , , Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <161901cd21ea$9d7d8486$05280101@corrigent.com> Content-Type: text/plain; charset=3D"utf-8" Lucy, even if the current MEF framework doesn't require s-vlan preservation, I be= lieve it's to the industry's benefit to adopt a solution that is not constr= ained to a specific enni model that, like all things networking, is likely = to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service provider= s' inputs. It had a fair reason to assume S-VLAN over ENNI by then. It may = open B-VLAN for the future. It is better for us not to discuss a future fr= amework here, because it will lead us to nowhere. Here, we want to extend V= PLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Va= inshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume tha= t the VLAN tags at the E-NNI will always be according to the current MEF mo= del? Or should we try to be as transparent as possible to user VLAN encapsu= lation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case VLAN t= ag) to signal VPLS information (in this case root/leaf origin) is necessari= ly tied to specific assumptions on user payload encapsulation (in this case= , that S-VLAN tag is "available" to encode root/leaf). I don't think this i= s a future-proof assumption, it's very likely that other network models wil= l come up that require S-VLAN preservation, which in the 2-VLAN approach wo= uld necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, "l2vpn@i= etf.org" >, "A= lexander.Vainshtein@ecitele.com" <= Alexander.Vainshtein@ecitele.com> Cc: "yuqun.cao@gmail.com" > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic alrea= dy has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com= Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L i= nformation, customer payload or PW? The customer payload will be always mod= ified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is access= ed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informati= on? Thanks Lizhong > ------------------------------ From david.i.allan@ericsson.com Tue Apr 24 06:05:35 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117D021F880B for ; Tue, 24 Apr 2012 06:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 ByKeUr7GTLJJ for ; Tue, 24 Apr 2012 06:05:32 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id CA26B21F87F7 for ; Tue, 24 Apr 2012 06:05:31 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3OD5MLv027140; Tue, 24 Apr 2012 08:05:26 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.69]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 24 Apr 2012 09:05:17 -0400 From: David Allan I To: Daniel Cohn , "l2vpn@ietf.org" Date: Tue, 24 Apr 2012 09:05:14 -0400 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IAAHuPxAAACKFwAAA6sREA== Message-ID: <60C093A41B5E45409A19D42CF7786DFD52322352CD@EUSAACMS0703.eamcs.ericsson.se> References: <161901cd21ea$9d7d8486$05280101@corrigent.com> <44F4E579A764584EA9BDFD07D0CA08130777C5EE@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130777C5EE@tlvmail1> 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-BeenThere: l2vpn@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, 24 Apr 2012 13:05:35 -0000 Receiver list trimmed as you'll all get this anyway. I'm a bit confused as to what folks mean by S-VLAN preservation. ETREE as implemented in a PB network uses two S-VLANs, but only one S-VID i= s present in the frame at any one time. Similarly SPBM uses two I-SIDs, but= again only one is in the frame at any one time... There is no single S-VLAN associated with the ETREE and there is no extrane= ous stacking here... Cheers Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Tuesday, April 24, 2012 7:17 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Lucy yong; Rogers, Josh; Shahr= am Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? No, the other way round. In the 2-VLAN solution, S-VLAN ID preservation req= uires adding a third VLAN ID. In the multi-PW solution, this is not require= d. DC -----Original Message----- From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.co= m] Sent: Tuesday, April 24, 2012 2:02 PM To: Daniel Cohn; Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vp= n@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Daniel, Is it so that you consider S-VAL stacking? If this is the case, are you aware that this is not in-line with the IEEE s= pecifications? Best regard, Nurit -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of e= xt Daniel Cohn Sent: Tuesday, April 24, 2012 10:12 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, even if the current MEF framework doesn't require s-vlan preservation, I be= lieve it's to the industry's benefit to adopt a solution that is not constr= ained to a specific enni model that, like all things networking, is likely = to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service provider= s' inputs. It had a fair reason to assume S-VLAN over ENNI by then. It may = open B-VLAN for the future. It is better for us not to discuss a future fr= amework here, because it will lead us to nowhere. Here, we want to extend V= PLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Va= inshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume tha= t the VLAN tags at the E-NNI will always be according to the current MEF mo= del? Or should we try to be as transparent as possible to user VLAN encapsu= lation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case VLAN t= ag) to signal VPLS information (in this case root/leaf origin) is necessari= ly tied to specific assumptions on user payload encapsulation (in this case= , that S-VLAN tag is "available" to encode root/leaf). I don't think this i= s a future-proof assumption, it's very likely that other network models wil= l come up that require S-VLAN preservation, which in the 2-VLAN approach wo= uld necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, "l2vpn@i= etf.org" >, "A= lexander.Vainshtein@ecitele.com" <= Alexander.Vainshtein@ecitele.com> Cc: "yuqun.cao@gmail.com" > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic alrea= dy has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com= Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L i= nformation, customer payload or PW? The customer payload will be always mod= ified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is access= ed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informati= on? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > com>> > To: "Rogers, Josh" >, Lucy yong > >, Daniel Cohn <= DanielC@orckit.com>, Sam Cao > > > Cc: "l2vpn@ietf.org" > > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, = but: > > IMO one of the advantages of the CW-based solution is that it is orthogon= al to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffi= c. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and,= in a more generic way, localization of effects of changes in the PE config= uration. > > In particular, adding a Leaf AC to a PE that previously has been only sup= porting Root ACs (or vice versa), removal of the last Leaf or last Root AC = from a PE that previously has been supporting a mix etc. affect only the PE= where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadva= ntage of the CW-based approach - I believe it strongly depends on specific = implementations. And some changes in the forwarding process are required in= any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org > [l2vpn-bounces@ietf.org] on behalf of > Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a > more complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become > more complex. > > Gile's comparison slide still concisely captures the differences > between these methods, in my opinion. I haven't seen any new ideas or > thoughts brought to the group in the past week or two on the subject. > I would hate for both proposed methods to die on the vine because we > couldn't decide between two methods that have nothing inherently wrong wi= th either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree >>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may >>double all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn >>[mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the >>processing in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >>PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW >>(for traffic coming from a root AC) [[LY]] Not that simple. You >>construct either two P2MP PWs to all other PEs and let egress PE >>performing filtering, or construct one P2MP PW to leaf-only PEs and >>two P2MP PWs to root and leaf PEs and let ingress PE perform >>forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so >>don't feel terribly strong about this objection. Is this a real >>problem for others (now or in the future), or is this objection in the we= eds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. >>I encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao >>>[mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>(Wim)'; giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>PE have both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn >>>[mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com>; Sam Cao >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong >>>[mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>both approaches can benefit from it. I was off for a while and >>>captures some discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues >>>with silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >>>am not clear on all the issues. Could you be more specific? As I >>>mentioned in below, two PW approach makes VPLS transport construction >>>and packet forwarding more complex, I can see potential backward >>>compatibility issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>double all of them. >>> >>>E-tree is an Ethernet service and there is already VLAN based >>>solution in IEEE, can we just utilize it without complicating VPLS >>>transport construction? This also makes interworking with Eth only netwo= rk easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh >>>[mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); >>>'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vain= shtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are >>>you saying that you no longer are interested in that method in >>>preference of the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org >>>[mailto:l2vpn-bounces@ietf.org] On >>>Behalf Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron >>>[mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord >>>>; Alexander >>>Vainshtein >>>>>.com>> >>>Cc: l2vpn@ietf.org >>>>; Vladimir Kleiner >>>>; >>>Andrew Sergeev >>>>; Idan >>>Kaspit >; >>>Mishael Wexler >>>>; >>>Rotem Cohen > >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly >>>have put in a third column on the CW approach. And hopefully the >>>minutes will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to >>>be forming around the two alternatives of two PWEs or two VLANs. I >>>believe three of the authors of the CW approach are also authors of >>>the two VLAN approach and one is also an author of the two PWE >>>approach. So perhaps it's best to let those four individuals say >>>which approach they prefer and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of >>>> various solution drafts off the mailing list. As far as I know, no >>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>> meeting. I think the CW approach has not been rejected by the WG >>>> yet, or the WG has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein >>>> >>> le.com>> >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree >>>>> approaches based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/ >>>>> ?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in >>>>> the PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>> I wonder whether the WG has taken a decision to reject the >>>>> approach based on the CW usage? I do not remember any recent >>>>> discussion of this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and >>>>> contains information which is CONFIDENTIAL and which may be >>>>> proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original >>>>> and all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or >>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>intended solely for the use of the individual or entity to which it is a= ddressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail >>>is strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is >>addressed. If you are not the intended recipient of this E-mail, you >>are hereby notified that any dissemination, distribution, copying, or >>action taken in relation to the contents of and attachments to this >>E-mail is strictly prohibited and may be unlawful. If you have >>received this E-mail in error, please notify the sender immediately >>and permanently delete the original and any copy of this E-mail and any p= rintout. > > > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** From enrique.hernandez@alcatel-lucent.com Tue Apr 24 08:24:04 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA5621F8851 for ; Tue, 24 Apr 2012 08:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 qermC+lWz-73 for ; Tue, 24 Apr 2012 08:24:00 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB7F21F8867 for ; Tue, 24 Apr 2012 08:23:58 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q3OFNQmA026247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Apr 2012 10:23:26 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q3OFNM9Y005134 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Apr 2012 10:23:24 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Tue, 24 Apr 2012 10:23:23 -0500 From: "Hernandez-Valencia, Enrique (Enrique)" To: Daniel Cohn , "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , Lucy yong , "Rogers, Josh" , Shahram Davari , Lizhong Jin , "l2vpn@ietf.org" , "Alexander.Vainshtein@ecitele.com" Date: Tue, 24 Apr 2012 10:23:19 -0500 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IAAHuPxAAACKFwAACIeb8A== Message-ID: <25F56B1AA5E4FE48A6E5FD92CA1F958601F0E29465@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <161901cd21ea$9d7d8486$05280101@corrigent.com> <44F4E579A764584EA9BDFD07D0CA08130777C5EE@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130777C5EE@tlvmail1> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "yuqun.cao@gmail.com" X-BeenThere: l2vpn@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, 24 Apr 2012 15:24:04 -0000 VkxBTi1JRCBwcmVzZXJ2YXRpb24gZG9lcyBub3QgbmVjZXNzYXJpbHkgcmVxdWlyZSBhIHRoaXJk IFZMQU4tSUQuIFZMQU4tSUQgdHJhbnNsYXRpb24gaXMgc3VmZmljaWVudC4NCg0KRW5yaXF1ZQ0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYW5pZWwgQ29o bg0KU2VudDogVHVlc2RheSwgQXByaWwgMjQsIDIwMTIgNzoxNyBBTQ0KVG86IFNwcmVjaGVyLCBO dXJpdCAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKTsgTHVjeSB5b25nOyBSb2dlcnMsIEpvc2g7IFNo YWhyYW0gRGF2YXJpOyBMaXpob25nIEppbjsgbDJ2cG5AaWV0Zi5vcmc7IEFsZXhhbmRlci5WYWlu c2h0ZWluQGVjaXRlbGUuY29tDQpDYzogeXVxdW4uY2FvQGdtYWlsLmNvbQ0KU3ViamVjdDogUkU6 IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCg0K Tm8sIHRoZSBvdGhlciB3YXkgcm91bmQuIEluIHRoZSAyLVZMQU4gc29sdXRpb24sIFMtVkxBTiBJ RCBwcmVzZXJ2YXRpb24gcmVxdWlyZXMgYWRkaW5nIGEgdGhpcmQgVkxBTiBJRC4gSW4gdGhlIG11 bHRpLVBXIHNvbHV0aW9uLCB0aGlzIGlzIG5vdCByZXF1aXJlZC4NCg0KREMNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNwcmVjaGVyLCBOdXJpdCAoTlNOIC0gSUwvSG9kIEhh U2hhcm9uKSBbbWFpbHRvOm51cml0LnNwcmVjaGVyQG5zbi5jb21dDQpTZW50OiBUdWVzZGF5LCBB cHJpbCAyNCwgMjAxMiAyOjAyIFBNDQpUbzogRGFuaWVsIENvaG47IEx1Y3kgeW9uZzsgUm9nZXJz LCBKb3NoOyBTaGFocmFtIERhdmFyaTsgTGl6aG9uZyBKaW47IGwydnBuQGlldGYub3JnOyBBbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KQ2M6IHl1cXVuLmNhb0BnbWFpbC5jb20NClN1 YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29s dXRpb24/DQoNCkRhbmllbCwNCklzIGl0IHNvIHRoYXQgeW91IGNvbnNpZGVyIFMtVkFMIHN0YWNr aW5nPw0KSWYgdGhpcyBpcyB0aGUgY2FzZSwgYXJlIHlvdSBhd2FyZSB0aGF0IHRoaXMgaXMgbm90 IGluLWxpbmUgd2l0aCB0aGUgSUVFRSBzcGVjaWZpY2F0aW9ucz8NCkJlc3QgcmVnYXJkLA0KTnVy aXQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGwydnBuLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IERh bmllbCBDb2huDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAyNCwgMjAxMiAxMDoxMiBBTQ0KVG86IEx1 Y3kgeW9uZzsgUm9nZXJzLCBKb3NoOyBTaGFocmFtIERhdmFyaTsgTGl6aG9uZyBKaW47IGwydnBu QGlldGYub3JnOyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KQ2M6IHl1cXVuLmNh b0BnbWFpbC5jb20NClN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRv IHRoZSBFLVRyZWUgc29sdXRpb24/DQoNCkx1Y3ksDQoNCmV2ZW4gaWYgdGhlIGN1cnJlbnQgTUVG IGZyYW1ld29yayBkb2Vzbid0IHJlcXVpcmUgcy12bGFuIHByZXNlcnZhdGlvbiwgSSBiZWxpZXZl IGl0J3MgdG8gdGhlIGluZHVzdHJ5J3MgYmVuZWZpdCB0byBhZG9wdCBhIHNvbHV0aW9uIHRoYXQg aXMgbm90IGNvbnN0cmFpbmVkIHRvIGEgc3BlY2lmaWMgZW5uaSBtb2RlbCB0aGF0LCBsaWtlIGFs bCB0aGluZ3MgbmV0d29ya2luZywgaXMgbGlrZWx5IHRvIGV2b2x2ZS4gRXNwZWNpYWxseSB3aGVu IHN1Y2ggYSBzb2x1dGlvbiBpcyBhdmFpbGFibGUuDQoNCkRhbmllbA0KDQpUaHVtYiB0eXBlZCAt IHBsZWFzZSBiZSB0b2xlcmFudA0KDQpMdWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPiB3 cm90ZToNCg0KRGFuaWVsLA0KDQpNRUYgaGFzIHdvcmtlZCBpbiBFTk5JIGludGVyZmFjZSBmb3Ig YSBsb25nIHRpbWUgd2l0aCBtYW55IHNlcnZpY2UgcHJvdmlkZXJzJyBpbnB1dHMuIEl0IGhhZCBh IGZhaXIgcmVhc29uIHRvIGFzc3VtZSBTLVZMQU4gb3ZlciBFTk5JIGJ5IHRoZW4uIEl0IG1heSBv cGVuIEItVkxBTiBmb3IgdGhlIGZ1dHVyZS4gSXQgaXMgYmV0dGVyIGZvciB1cyBub3QgdG8gZGlz Y3VzcyAgYSBmdXR1cmUgZnJhbWV3b3JrIGhlcmUsIGJlY2F1c2UgaXQgd2lsbCBsZWFkIHVzIHRv IG5vd2hlcmUuIEhlcmUsIHdlIHdhbnQgdG8gZXh0ZW5kIFZQTFMgaW4gc3VwcG9ydGluZyBFLVRy ZWUuDQoNCkJlc3QgUmVnYXJkcywNCkx1Y3kNCg0KRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYW5pZWwgQ29o bg0KU2VudDogU3VuZGF5LCBBcHJpbCAyMiwgMjAxMiA3OjM0IEFNDQpUbzogUm9nZXJzLCBKb3No OyBTaGFocmFtIERhdmFyaTsgTGl6aG9uZyBKaW47IGwydnBuQGlldGYub3JnOyBBbGV4YW5kZXIu VmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KQ2M6IHl1cXVuLmNhb0BnbWFpbC5jb20NClN1YmplY3Q6 IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/ DQoNClNoYWhyYW0gYW5kIGFsbCwNCg0KVGhpcyBxdWVzdGlvbiBhbHJlYWR5IGNhbWUgdXAgaW4g b3VyIGRpc2N1c3Npb25zIC0gaXMgaXQgc2FmZSB0byBhc3N1bWUgdGhhdCB0aGUgVkxBTiB0YWdz IGF0IHRoZSBFLU5OSSB3aWxsIGFsd2F5cyBiZSBhY2NvcmRpbmcgdG8gdGhlIGN1cnJlbnQgTUVG IG1vZGVsPyBPciBzaG91bGQgd2UgdHJ5IHRvIGJlIGFzIHRyYW5zcGFyZW50IGFzIHBvc3NpYmxl IHRvIHVzZXIgVkxBTiBlbmNhcHN1bGF0aW9uIGF0IHRoZSBFLU5OSSwgdG8gYWNjb21tb2RhdGUg ZnV0dXJlIGZyYW1ld29ya3M/DQpJIGJlbGlldmUgdGhhdCBhbnkgYXBwcm9hY2ggdGhhdCBsb29r cyBhdCB1c2VyIHBheWxvYWQgKGluIHRoaXMgY2FzZSBWTEFOIHRhZykgdG8gc2lnbmFsIFZQTFMg aW5mb3JtYXRpb24gKGluIHRoaXMgY2FzZSByb290L2xlYWYgb3JpZ2luKSBpcyBuZWNlc3Nhcmls eSB0aWVkIHRvIHNwZWNpZmljIGFzc3VtcHRpb25zIG9uIHVzZXIgcGF5bG9hZCBlbmNhcHN1bGF0 aW9uIChpbiB0aGlzIGNhc2UsIHRoYXQgUy1WTEFOIHRhZyBpcyAiYXZhaWxhYmxlIiB0byBlbmNv ZGUgcm9vdC9sZWFmKS4gSSBkb24ndCB0aGluayB0aGlzIGlzIGEgZnV0dXJlLXByb29mIGFzc3Vt cHRpb24sIGl0J3MgdmVyeSBsaWtlbHkgdGhhdCBvdGhlciBuZXR3b3JrIG1vZGVscyB3aWxsIGNv bWUgdXAgdGhhdCByZXF1aXJlIFMtVkxBTiBwcmVzZXJ2YXRpb24sIHdoaWNoIGluIHRoZSAyLVZM QU4gYXBwcm9hY2ggd291bGQgbmVjZXNzaXRhdGUgYWRkaW5nIGEgdGhpcmQgVkxBTi1JRC4NCg0K RGFuaWVsDQoNCkZyb206IFNoYWhyYW0gRGF2YXJpIDxkYXZhcmlAYnJvYWRjb20uY29tPG1haWx0 bzpkYXZhcmlAYnJvYWRjb20uY29tPj4NClRvOiBMaXpob25nIEppbiA8bGl6aG8uamluQGdtYWls LmNvbTxtYWlsdG86bGl6aG8uamluQGdtYWlsLmNvbT4+LCAibDJ2cG5AaWV0Zi5vcmc8bWFpbHRv OmwydnBuQGlldGYub3JnPiIgPGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4+ LCAiQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWlu c2h0ZWluQGVjaXRlbGUuY29tPiIgPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1h aWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4+DQpDYzogInl1cXVuLmNhb0Bn bWFpbC5jb208bWFpbHRvOnl1cXVuLmNhb0BnbWFpbC5jb20+IiA8eXVxdW4uY2FvQGdtYWlsLmNv bTxtYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbT4+DQpTdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBv ZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KDQpIaSwNCg0KSSBhbHNv IGhhdmUgYSBxdWVzdGlvbiByZWdhcmRpbmcgMi1WTEFOLiBXaGF0IGlmIHRoZSBjdXN0b21lciB0 cmFmZmljIGFscmVhZHkgaGFzIGFuIFMtVkxBTj8gRG8gd2UgbmVlZCBhIDNyZCBWTEFOIHRvIGlk ZW50aWZ5IHRoZSBML1I/DQoNClRoeA0KU2hhaHJhbQ0KDQpGcm9tOiBsMnZwbi1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmwydnBuLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMaXpob25nIEppbg0KU2VudDogRnJpZGF5LCBBcHJp bCAyMCwgMjAxMiA5OjM4IEFNDQpUbzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYu b3JnPjsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5W YWluc2h0ZWluQGVjaXRlbGUuY29tPg0KQ2M6IHl1cXVuLmNhb0BnbWFpbC5jb208bWFpbHRvOnl1 cXVuLmNhb0BnbWFpbC5jb20+DQpTdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9h Y2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KDQpIaSwgYWxsLA0KVGhlIGRpZmZlcmVuY2Ug YmV0d2VlbiAyLVZMQU4gYW5kIENXIGFwcHJvYWNoIGlzIHdobyB3aWxsIHByb3ZpZGUgdGhlIFIv TCBpbmZvcm1hdGlvbiwgY3VzdG9tZXIgcGF5bG9hZCBvciBQVz8gVGhlIGN1c3RvbWVyIHBheWxv YWQgd2lsbCBiZSBhbHdheXMgbW9kaWZpZWQgdG8gY2FycnkgUi9MIGluZm9ybWF0aW9uIGluIDIt VkxBTiBhcHByb2FjaCwgd2hpbGUgUFcgd2l0aCBDVyB3aWxsIGNhcnJ5IFIvTCBpbmZvcm1hdGlv biBmb3IgQ1cgYXBwcm9hY2guDQpJIGhhdmUgYSBxdWVzdGlvbiB3aXRoIHRoZSAyLVZMQU4gYXBw cm9hY2ggaW4gSC1WUExTIHdoZXJlIEgtVlBMUyBpcyBhY2Nlc3NlZCBieSBWUFdTIGFzIGRlc2Ny aWJlZCBpbiBSRkM0NjcyIHNlY3Rpb24gMTAuMS4zLiBJZiBWUFdTIGlzIHVzZWQgdG8gYWNjZXNz IEgtVlBMUywgaG93IGNvdWxkIHRoZSBQRSBvbiBWUFdTIHNpZGUgYWRkcyBWTEFOIHRvIGluZGlj YXRlIFIvTCBpbmZvcm1hdGlvbj8NCg0KVGhhbmtzDQpMaXpob25nDQoNCj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+IE1lc3NhZ2U6IDINCj4gRGF0ZTogVGh1LCAxOSBBcHIg MjAxMiAwNDozODozNiArMDAwMA0KPiBGcm9tOiBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFu ZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tPj4NCj4gVG86ICJSb2dlcnMsIEpvc2giIDxqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNv bTxtYWlsdG86am9zaC5yb2dlcnNAdHdjYWJsZS5jb20+PiwgTHVjeSB5b25nDQo+ICAgICAgICA8 bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4sIERhbmll bCBDb2huIDxEYW5pZWxDQG9yY2tpdC5jb208bWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbT4+LCBT YW0gQ2FvDQo+ICAgICAgICA8eXVxdW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86eXVxdW4uY2FvQGdt YWlsLmNvbT4+DQo+IENjOiAibDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPiIg PGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4+DQo+IFN1YmplY3Q6IFJFOiBU aGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+IE1l c3NhZ2UtSUQ6DQo+ICAgICAgICA8RjkzMzY1NzE3MzFBREU0MkE1Mzk3RkM4MzFDRUFBMDIwMzQx OTJARlJJRFdQUE1CMDAyLmVjaXRlbGUuY29tPG1haWx0bzpGOTMzNjU3MTczMUFERTQyQTUzOTdG QzgzMUNFQUEwMjAzNDE5MkBGUklEV1BQTUIwMDIuZWNpdGVsZS5jb20+Pg0KPiBDb250ZW50LVR5 cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9InVzLWFzY2lpIg0KPg0KPiBIaSBhbGwsDQo+IEkgZnVs bHkgdW5kZXJzdGFuZCB0aGF0IHRoYXQgd2hhdCBJIGFtIGdvaW5nIHRvIHNheSBpcyBub3QgdmVy eSBwb3B1bGFyLCBidXQ6DQo+DQo+IElNTyBvbmUgb2YgdGhlIGFkdmFudGFnZXMgb2YgdGhlIENX LWJhc2VkIHNvbHV0aW9uIGlzIHRoYXQgaXQgaXMgb3J0aG9nb25hbCB0byB1c2FnZSAob3Igbm9u LXVzYWdlKSBvZiBQMk1QIFBXcyBmb3IgZWZmZWN0aXZlIGRlbGl2ZXJ5IG9mIEJVTiB0cmFmZmlj Lg0KPg0KPiBBbm90aGVyIGFkdmFudGFnZSBpcyBwcmVzZXJ2YXRpb24gb2YgZnVsbCBtZXNoIG9m IFAyUCBQV3MgaW4gYSBWUExTLCBhbmQsIGluIGEgbW9yZSBnZW5lcmljIHdheSwgbG9jYWxpemF0 aW9uIG9mIGVmZmVjdHMgb2YgY2hhbmdlcyBpbiB0aGUgUEUgY29uZmlndXJhdGlvbi4NCj4NCj4g SW4gcGFydGljdWxhciwgYWRkaW5nIGEgTGVhZiBBQyB0byBhIFBFIHRoYXQgcHJldmlvdXNseSBo YXMgYmVlbiBvbmx5IHN1cHBvcnRpbmcgUm9vdCBBQ3MgKG9yIHZpY2UgdmVyc2EpLCByZW1vdmFs IG9mIHRoZSBsYXN0IExlYWYgb3IgbGFzdCBSb290IEFDIGZyb20gYSBQRSB0aGF0IHByZXZpb3Vz bHkgaGFzIGJlZW4gc3VwcG9ydGluZyBhIG1peCBldGMuIGFmZmVjdCBvbmx5IHRoZSBQRSB3aGVy ZSB0aGlzIG9wZXJhdGlvbiBoYXBwZW5zIGFuZCBub3QgdGhlIHJlc3Qgb2YgdGhlIFBFcy4NCj4N Cj4gQXMgZm9yIHRoZSBuZWVkIGZvciBIVyBjaGFuZ2VzIHRoYXQgaGF2ZSBiZWVuIG1lbnRpb25l ZCBhcyBhIG1haW4gZGlzYWR2YW50YWdlIG9mIHRoZSBDVy1iYXNlZCBhcHByb2FjaCAtIEkgYmVs aWV2ZSBpdCBzdHJvbmdseSBkZXBlbmRzIG9uIHNwZWNpZmljIGltcGxlbWVudGF0aW9ucy4gQW5k IHNvbWUgY2hhbmdlcyBpbiB0aGUgZm9yd2FyZGluZyBwcm9jZXNzIGFyZSByZXF1aXJlZCBpbiBh bnkgc29sdXRpb24uDQo+DQo+IE15IDJjLA0KPiAgICAgU2FzaGENCj4NCj4NCj4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBGcm9tOiBsMnZwbi1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnPiBbbDJ2cG4tYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZz5dIG9uIGJlaGFsZiBvZiBSb2dl cnMsIEpvc2ggW2pvc2gucm9nZXJzQHR3Y2FibGUuY29tPG1haWx0bzpqb3NoLnJvZ2Vyc0B0d2Nh YmxlLmNvbT5dDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTgsIDIwMTIgOTo1NyBQTQ0KPiBU bzogTHVjeSB5b25nOyBEYW5pZWwgQ29objsgU2FtIENhbw0KPiBDYzogbDJ2cG5AaWV0Zi5vcmc8 bWFpbHRvOmwydnBuQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogVGhlIHN0YXR1cyBvZiB0aGUg YXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPg0KPiBBZ2FpbiwgdGhlIFAyTVAg c2l0dWF0aW9uIHRocm93cyBtZS4gIElzIHRoaXMgc29tZXRoaW5nIHRoYXQgaXMgdXNlZA0KPiBj b21tb25seT8NCj4NCj4gSSdtIHVuZGVyIHRoZSBpbXByZXNzaW9uIHRoYXQgYWRkaW5nIFAyTVAg dG8gYW55IG1vZGVsIHJlc3VsdHMgaW4gYSBtb3JlDQo+IGNvbXBsZXggbW9kZWwuICBXZXRoZXIg b3V0c2lkZSBzLXRhZyBpcyB1c2VkIHRvIGRpZmZlcmVudGlhdGUsIG9yDQo+IGRlZGljYXRlZCBw dydzIGFyZSB1c2VkIGZvciB0aGUgc2FtZSBwdXJwb3NlLCBpdCBzZWVtcyBib3RoIGJlY29tZSBt b3JlDQo+IGNvbXBsZXguDQo+DQo+IEdpbGUncyBjb21wYXJpc29uIHNsaWRlIHN0aWxsIGNvbmNp c2VseSBjYXB0dXJlcyB0aGUgZGlmZmVyZW5jZXMgYmV0d2Vlbg0KPiB0aGVzZSBtZXRob2RzLCBp biBteSBvcGluaW9uLiAgSSBoYXZlbid0IHNlZW4gYW55IG5ldyBpZGVhcyBvciB0aG91Z2h0cw0K PiBicm91Z2h0IHRvIHRoZSBncm91cCBpbiB0aGUgcGFzdCB3ZWVrIG9yIHR3byBvbiB0aGUgc3Vi amVjdC4gIEkgd291bGQgaGF0ZQ0KPiBmb3IgYm90aCBwcm9wb3NlZCBtZXRob2RzIHRvIGRpZSBv biB0aGUgdmluZSBiZWNhdXNlIHdlIGNvdWxkbid0IGRlY2lkZQ0KPiBiZXR3ZWVuIHR3byBtZXRo b2RzIHRoYXQgaGF2ZSBub3RoaW5nIGluaGVyZW50bHkgd3Jvbmcgd2l0aCBlaXRoZXIuDQo+DQo+ IC1Kb3NoDQo+DQo+DQo+IE9uIDQvMTgvMTIgMTo1MyBQTSwgIkx1Y3kgeW9uZyIgPGx1Y3kueW9u Z0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KPg0KPj5T ZW5kIHRoaXMgYWdhaW4uDQo+Pg0KPj5Ud28gUFcgYXBwcm9hY2ggY2FuIGJlIGNvbXBsZXggdG9v IGlmIHRoZSBWUExTIGluc3RhbmNlIGZvciBFLVRyZWUgdXNlcw0KPj5QMlAgUFcgZm9yIHVuaWNh c3QgdHJhZmZpYyBhbmQgUDJNUCBQVyBmb3IgYnJvYWRjYXN0IGFuZCB1bmtub3duDQo+PnVuaWNh c3QgdHJhZmZpYywgYW5kIHNvbWUgUDJNUCBQV3MgZm9yIG11bHRpY2FzdCB0cmFmZmljLiBJdCBt YXkgZG91YmxlDQo+PmFsbCBvZiB0aGVtLg0KPj4NCj4+THVjeQ0KPj4NCj4+LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogRGFuaWVsIENvaG4gW21haWx0bzpEYW5pZWxDQG9yY2tp dC5jb208bWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbT5dDQo+PlNlbnQ6IFdlZG5lc2RheSwgQXBy aWwgMTgsIDIwMTIgMTo0MiBQTQ0KPj5UbzogTHVjeSB5b25nOyBSb2dlcnMsIEpvc2g7IFNhbSBD YW8NCj4+Q2M6IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4NCj4+U3ViamVj dDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlv bj8NCj4+DQo+PkkgdGhpbmsgdGhlIGZpcnN0IG9wdGlvbiBpdHMgdGhlIG5hdHVyYWwgd2F5IHRv IGdvLiBIb3cgaXMgdGhlIHByb2Nlc3NpbmcNCj4+aW4gdGhpcyBjYXNlIG1vcmUgY29tcGxleD8N Cj4+DQo+PlRodW1iIHR5cGVkIC0gcGxlYXNlIGJlIHRvbGVyYW50DQo+Pg0KPj5MdWN5IHlvbmcg PGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+IHdyb3Rl Og0KPj4NCj4+DQo+Pg0KPj5TbmlwcGVkLi4NCj4+DQo+Pk11bHRpLVBXIC0gT24gaW5ncmVzcyBQ RSwgZnJhbWUgaXMgcGxhY2VkIG9udG8gZWl0aGVyIGEgTGVhZi1vbmx5IFAyTVAgUFcNCj4+KGZv ciB0cmFmZmljIGNvbWluZyBmcm9tIGEgbGVhZiBBQyksIG9yIG9udG8gYSBSb290L0xlYWYgUDJN UCBQVyAoZm9yDQo+PnRyYWZmaWMgY29taW5nIGZyb20gYSByb290IEFDKQ0KPj5bW0xZXV0gTm90 IHRoYXQgc2ltcGxlLiBZb3UgY29uc3RydWN0IGVpdGhlciB0d28gUDJNUCBQV3MgdG8gYWxsIG90 aGVyDQo+PlBFcyBhbmQgbGV0IGVncmVzcyBQRSBwZXJmb3JtaW5nIGZpbHRlcmluZywgb3IgY29u c3RydWN0IG9uZSBQMk1QIFBXIHRvDQo+PmxlYWYtb25seSBQRXMgYW5kIHR3byBQMk1QIFBXcyB0 byByb290IGFuZCBsZWFmIFBFcyBhbmQgbGV0IGluZ3Jlc3MgUEUNCj4+cGVyZm9ybSBmb3J3YXJk aW5nIGFuZCBmaWx0ZXJpbmcuIEJvdGggbWFrZSBub2RlIHByb2Nlc3MgY29tcGxleC4NCj4+DQo+ PltbTFldXSBWUExTIGlzIGJ1aWx0IHdpdGggdGhlIG1lY2hhbmlzbSB1dGlsaXppbmcgUDJQIGFu ZCBQMk1QIFBXIGZvcg0KPj5kZWxpdmVyaW5nIHRoZSBmcmFtZXMgdG8gcmVtb3RlIFBFcy4gV2Ug c2hvdWxkIHV0aWxpemUgdGhlbSB3aXRoIHRoZQ0KPj5taW5pbWl6ZWQgY2hhbmdlcy4gRHVhbCBW TEFOIHNvbHV0aW9uIGlzIHNpbXBsZXIgdGhhbiBEdWFsIFBXLg0KPj4NCj4+UmVnYXJkcywNCj4+ THVjeQ0KPj4NCj4+DQo+Pkkgc2VlIGhvdyAyVkxBTiBpcyBzaW1wbGVyIHdoZW4gUDJNUCBQVydz IGFyZSBpbnZvbHZlZCwgSSB0aGluay4gIEkNCj4+aGF2ZW4ndCBoYWQgYW55IGZpcnN0IGhhbmQg ZXhwZXJpZW5jZSB3aXRoIFAyTVAgUFcncywgaG93ZXZlciwgc28gZG9uJ3QNCj4+ZmVlbCB0ZXJy aWJseSBzdHJvbmcgYWJvdXQgdGhpcyBvYmplY3Rpb24uICBJcyB0aGlzIGEgcmVhbCBwcm9ibGVt IGZvcg0KPj5vdGhlcnMgKG5vdyBvciBpbiB0aGUgZnV0dXJlKSwgb3IgaXMgdGhpcyBvYmplY3Rp b24gaW4gdGhlIHdlZWRzPw0KPj4NCj4+SSdtIG5vdCBzdXJlIHRoZSAnYWRkaXRpb25hbCBjb21w bGV4aXR5JyBpcyBub3RhYmxlLCBvciBldmVuIHJlbGV2YW50LiAgSQ0KPj5lbmNvdXJhZ2Ugb3Ro ZXJzIHRvIHNwZWFrIHVwIGlmIHRoZXkgZGlzYWdyZWUsIGFzIFAyTVAgUFcgaXMgb25seQ0KPj5j b25jZXB0dWFsIHRvIG1lLCBhbmQgSSBhbSB1bmZhbWlsaWFyIHdpdGggcmVhbC1saWZlIHVzZSBj YXNlcyBmb3IgaXQuDQo+Pg0KPj5UaGFua3MsDQo+Pkpvc2gNCj4+DQo+Pg0KPj4NCj4+T24gNC8x OC8xMiAxMDozMCBBTSwgIkx1Y3kgeW9uZyIgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzps dWN5LnlvbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KPj4NCj4+PlBsZWFzZSBzZWUgaW5saW5lLg0K Pj4+DQo+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+RnJvbTogU2FtIENhbyBbbWFp bHRvOnl1cXVuLmNhb0BnbWFpbC5jb208bWFpbHRvOnl1cXVuLmNhb0BnbWFpbC5jb20+XQ0KPj4+ U2VudDogVHVlc2RheSwgQXByaWwgMTcsIDIwMTIgNzoxNCBBTQ0KPj4+VG86ICdEYW5pZWwgQ29o bic7IEx1Y3kgeW9uZzsgJ1JvZ2VycywgSm9zaCc7ICdIZW5kZXJpY2t4LCBXaW0gKFdpbSknOw0K Pj4+Z2lsZXMuaGVyb25AZ21haWwuY29tPG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+OyBz aW1vbi5kZWxvcmRAZ21haWwuY29tPG1haWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPjsNCj4+ PkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNo dGVpbkBlY2l0ZWxlLmNvbT4NCj4+PkNjOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0 Zi5vcmc+OyBWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPG1haWx0bzpWbGFkaW1pci5LbGVp bmVyQGVjaXRlbGUuY29tPjsNCj4+PkFuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPG1haWx0bzpB bmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbT47IElkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0 bzpJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbT47DQo+Pj5NaXNoYWVsLldleGxlckBlY2l0ZWxlLmNv bTxtYWlsdG86TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb20+OyBSb3RlbS5Db2hlbkBlY2l0ZWxl LmNvbTxtYWlsdG86Um90ZW0uQ29oZW5AZWNpdGVsZS5jb20+DQo+Pj5TdWJqZWN0OiBSRTogVGhl IHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+DQo+ Pj5ZZXMsIDIgcHdzIGFyZSBvbmx5IG5lZWRlZCBiZXR3ZWVuIHBlcyB3aXRoIGJvdGggcm9vdCBh bmQgbGVhZiBhY3MgYWZ0ZXINCj4+PmltcHJvdmluZyBEdWFsLVBXIGFwcHJvYWNoLiBJZiBjb25z aWRlciBQMk1QLCBEdWFsLVBXIGFwcHJvYWNoIHNldHVwIDINCj4+PlAyTVANCj4+PlBXcyBpZiBu ZWVkLiBUaGVyZSBpcyBubyBkaWZmZXJlbmNlIGJldHdlZW4gUDJNUCBvciBub3JtYWwgUFcgc2V0 dXAuIEJ1dCwNCj4+PmNhbiBMZWFmLUFDcyBiZSBib3VuZCB0byBSb290IFBFIG9mIFAyTVAgUFc/ DQo+Pj4NCj4+PltbTFldXSBObywgaXQgbWFrZXMgY29tcGxleCBpbiBzZXR0aW5nIHVwIFAyTVAg UFcuIFNob3VsZCBhIFBFIHdpdGggYm90aA0KPj4+cm9vdCBhbmQgbGVhZiBBQ3Mgc2V0IHVwIHR3 byBvciBvbmUgUDJNUCBQVyB0byBvdGhlciBQRXMgKHNvbWUgUEUgaGF2ZQ0KPj4+Ym90aCByb290 IGFuZCBsZWFmIEFDIGFuZCBzb21lIG9ubHkgaGF2ZSBsZWFmIEFDcyk/DQo+Pj5SZWdhcmRzLA0K Pj4+THVjeQ0KPj4+DQo+Pj5SZWdhcmRzLA0KPj4+DQo+Pj5ZdXF1biAoU2FtKSBDYW8NCj4+PkUt bWFpbDogWXVxdW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86WXVxdW4uY2FvQGdtYWlsLmNvbT4NCj4+ Pg0KPj4+DQo+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+RnJvbTogRGFuaWVsIENv aG4gW21haWx0bzpEYW5pZWxDQG9yY2tpdC5jb208bWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbT5d DQo+Pj5TZW50OiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiA0OjU2IFBNDQo+Pj5UbzogTHVjeSB5 b25nOyBSb2dlcnMsIEpvc2g7IEhlbmRlcmlja3gsIFdpbSAoV2ltKTsNCj4+PmdpbGVzLmhlcm9u QGdtYWlsLmNvbTxtYWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tPjsNCj4+PnNpbW9uLmRlbG9y ZEBnbWFpbC5jb208bWFpbHRvOnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+OyBBbGV4YW5kZXIuVmFp bnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b20+OyBTYW0gQ2FvDQo+Pj5DYzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3Jn PjsgVmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbTxtYWlsdG86VmxhZGltaXIuS2xlaW5lckBl Y2l0ZWxlLmNvbT47DQo+Pj5BbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3 LlNlcmdlZXZAZWNpdGVsZS5jb20+OyBJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbTxtYWlsdG86SWRh bi5LYXNwaXRAZWNpdGVsZS5jb20+Ow0KPj4+TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb208bWFp bHRvOk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPjsgUm90ZW0uQ29oZW5AZWNpdGVsZS5jb208 bWFpbHRvOlJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPg0KPj4+U3ViamVjdDogUkU6IFRoZSBzdGF0 dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4+Pg0KPj4+QWRk aW5nIFNhbSAoYXMgbDJ2cG5AIGlzIGhvbGRpbmcgbWVzc2FnZXMpDQo+Pj4NCj4+PkRDDQo+Pj4N Cj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBMdWN5IHlvbmcgW21haWx0 bzpsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+XQ0KPj4+ U2VudDogVHVlc2RheSwgQXByaWwgMTcsIDIwMTIgMTI6MzkgQU0NCj4+PlRvOiBEYW5pZWwgQ29o bjsgUm9nZXJzLCBKb3NoOyBIZW5kZXJpY2t4LCBXaW0gKFdpbSk7DQo+Pj5naWxlcy5oZXJvbkBn bWFpbC5jb208bWFpbHRvOmdpbGVzLmhlcm9uQGdtYWlsLmNvbT47IHNpbW9uLmRlbG9yZEBnbWFp bC5jb208bWFpbHRvOnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+Ow0KPj4+QWxleGFuZGVyLlZhaW5z aHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29t Pg0KPj4+Q2M6IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz47IFZsYWRpbWly LktsZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb20+ Ow0KPj4+QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb208bWFpbHRvOkFuZHJldy5TZXJnZWV2QGVj aXRlbGUuY29tPjsgSWRhbi5LYXNwaXRAZWNpdGVsZS5jb208bWFpbHRvOklkYW4uS2FzcGl0QGVj aXRlbGUuY29tPjsNCj4+Pk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPG1haWx0bzpNaXNoYWVs LldleGxlckBlY2l0ZWxlLmNvbT47IFJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPG1haWx0bzpSb3Rl bS5Db2hlbkBlY2l0ZWxlLmNvbT4NCj4+PlN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBh cHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4NCj4+Pg0KPj4+U25pcHBlZCwN Cj4+Pg0KPj4+QXMgd2UgZGlzY3Vzc2VkIGV4dGVuc2l2ZWx5IGluIHRoZSBsaXN0LCBhbmQgYXMg cmVmbGVjdGVkIGluIGdpbGVzDQo+Pj5zbGlkZSwgMiBwd3MgYXJlIG9ubHkgbmVlZGVkIGJldHdl ZW4gcGVzIHdpdGggYm90aCByb290IGFuZCBsZWFmIGFjcywNCj4+PndoaWNoIHdpbGwgdHlwaWNh bGx5IGJlIGEgc21hbGwgbWlub3JpdHkuDQo+Pj5bW0xZXV0gRG9uJ3Qga25vdyBpZiB0aGUgYXNz dW1wdGlvbiBpcyB0cnVlLiBFdmVuIGl0IGlzIHRoZSBjYXNlLCBib3RoDQo+Pj5hcHByb2FjaGVz IGNhbiBiZW5lZml0IGZyb20gaXQuIEkgd2FzIG9mZiBmb3IgYSB3aGlsZSBhbmQgY2FwdHVyZXMg c29tZQ0KPj4+ZGlzY3Vzc2lvbnMgbm93Lg0KPj4+DQo+Pj5BbHNvIGFzIHBlciBnaWxlcyBzbGlk ZSwgZHVhbCB2bGFuIGNhbiBoYXZlIHNjYWxhYmlsaXR5IGlzc3VlcyBkdWUgdG8NCj4+PmFkZGl0 aW9uYWwgbG9va3VwIGFuZCBkb3VibGUgdXNlIG9mIHZsYW5zIGluIGludGVybmFsIGVtdWxhdGVk IGxhbg0KPj4+aW50ZXJmYWNlLiBBbHNvIHRoZXJlIGFyZSBwb3RlbnRpYWwgYmFja3dhcmQgY29t cGF0aWJpbGl0eSBpc3N1ZXMgd2l0aA0KPj4+c2lsaWNvbiB0aGF0IGRvZXNuJ3Qgc3VwcG9ydCB2 bGFuIG1hcHBpbmcuDQo+Pj5bW0xZXV0gSSB3YXMgbm90IGluIElFVEY4MyBtZWV0aW5nIGFuZCB3 YWl0IG9uIHRoZSBtZWV0aW5nIG1pbnV0ZXMuIEkgYW0NCj4+Pm5vdCBjbGVhciBvbiBhbGwgdGhl IGlzc3Vlcy4gQ291bGQgeW91IGJlIG1vcmUgc3BlY2lmaWM/IEFzIEkgbWVudGlvbmVkDQo+Pj5p biBiZWxvdywgdHdvIFBXIGFwcHJvYWNoIG1ha2VzIFZQTFMgdHJhbnNwb3J0IGNvbnN0cnVjdGlv biBhbmQgcGFja2V0DQo+Pj5mb3J3YXJkaW5nIG1vcmUgY29tcGxleCwgSSBjYW4gc2VlIHBvdGVu dGlhbCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5DQo+Pj5pc3N1ZXMgd2l0aCAyIFBXIHNvbHV0aW9u Lg0KPj4+DQo+Pj5SZWdhcmRzLA0KPj4+THVjeQ0KPj4+DQo+Pj5SZWdhcmRzLA0KPj4+DQo+Pj5E YW5pZWwNCj4+Pg0KPj4+VGh1bWIgdHlwZWQgLSBwbGVhc2UgYmUgdG9sZXJhbnQNCj4+Pg0KPj4+ THVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5j b20+PiB3cm90ZToNCj4+Pg0KPj4+SW4gbXkgbWluZCwgdGhlIFZMQU4gYXBwcm9hY2ggbWVhbnMg ZHVhbCB2bGFuIG1ldGhvZC4NCj4+Pg0KPj4+VGhlIG1haW4gY29uY2VybiBmb3IgQ1cgYXBwcm9h Y2ggaXMgaGFyZHdhcmUgc3VwcG9ydC4NCj4+Pg0KPj4+VHdvIFBXIGFwcHJvYWNoIGNhbiBiZSBj b21wbGV4IHRvbyBpZiB0aGUgVlBMUyBpbnN0YW5jZSBmb3IgRS1UcmVlIHVzZXMNCj4+PlAyUCBQ VyBmb3IgdW5pY2FzdCB0cmFmZmljIGFuZCBQMk1QIFBXIGZvciBicm9hZGNhc3QgYW5kIHVua25v d24gdW5pY2FzdA0KPj4+dHJhZmZpYywgYW5kIHNvbWUgUDJNUCBQV3MgZm9yIG11bHRpY2FzdCB0 cmFmZmljLiBJdCBtYXkgZG91YmxlIGFsbCBvZg0KPj4+dGhlbS4NCj4+Pg0KPj4+RS10cmVlIGlz IGFuIEV0aGVybmV0IHNlcnZpY2UgYW5kIHRoZXJlIGlzIGFscmVhZHkgVkxBTiBiYXNlZCBzb2x1 dGlvbg0KPj4+aW4gSUVFRSwgY2FuIHdlIGp1c3QgdXRpbGl6ZSBpdCB3aXRob3V0IGNvbXBsaWNh dGluZyBWUExTIHRyYW5zcG9ydA0KPj4+Y29uc3RydWN0aW9uPyBUaGlzIGFsc28gbWFrZXMgaW50 ZXJ3b3JraW5nIHdpdGggRXRoIG9ubHkgbmV0d29yayBlYXNpZXIuDQo+Pj4NCj4+PkNoZWVycywN Cj4+Pkx1Y3kNCj4+Pg0KPj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IFJv Z2VycywgSm9zaCBbbWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29tPG1haWx0bzpqb3NoLnJv Z2Vyc0B0d2NhYmxlLmNvbT5dDQo+Pj5TZW50OiBNb25kYXksIEFwcmlsIDE2LCAyMDEyIDg6MzUg QU0NCj4+PlRvOiBMdWN5IHlvbmc7IEhlbmRlcmlja3gsIFdpbSAoV2ltKTsgJ2dpbGVzLmhlcm9u QGdtYWlsLmNvbTxtYWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tPic7DQo+Pj4nc2ltb24uZGVs b3JkQGdtYWlsLmNvbTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT4nOyAnQWxleGFuZGVy LlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRl bGUuY29tPicNCj4+PkNjOiAnbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPic7 ICdWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPG1haWx0bzpWbGFkaW1pci5LbGVpbmVyQGVj aXRlbGUuY29tPic7DQo+Pj4nQW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb208bWFpbHRvOkFuZHJl dy5TZXJnZWV2QGVjaXRlbGUuY29tPic7ICdJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbTxtYWlsdG86 SWRhbi5LYXNwaXRAZWNpdGVsZS5jb20+JzsNCj4+PidNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNv bTxtYWlsdG86TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb20+JzsgJ1JvdGVtLkNvaGVuQGVjaXRl bGUuY29tPG1haWx0bzpSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbT4nDQo+Pj5TdWJqZWN0OiBSRTog VGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+ DQo+Pj5JIGJlbGlldmUgdGhlIGluaXRpYWwgcXVlc3Rpb24gd2FzIGluIHJlZ2FyZCB0byB0aGUg Q1cgbWV0aG9kLiAgQXJlIHlvdQ0KPj4+c2F5aW5nIHRoYXQgeW91IG5vIGxvbmdlciBhcmUgaW50 ZXJlc3RlZCBpbiB0aGF0IG1ldGhvZCBpbiBwcmVmZXJlbmNlIG9mDQo+Pj50aGUgZHVhbCB2bGFu IG1ldGhvZD8NCj4+Pg0KPj4+DQo+Pj4NCj4+Pkx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5j b208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+Pj4NCj4+Pg0KPj4+QWdy ZWUgd2l0aCBXaW0uIFZMQU4gYXBwcm9hY2ggaXMgdGhlIGJlc3Qgc29sdXRpb24gZm9yIEUtVHJl ZS4NCj4+Pg0KPj4+THVjeQ0KPj4+DQo+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ RnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9y Zz4gW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpsMnZwbi1ib3VuY2VzQGll dGYub3JnPl0gT24gQmVoYWxmDQo+Pj5PZiBIZW5kZXJpY2t4LCBXaW0gKFdpbSkNCj4+PlNlbnQ6 IFRodXJzZGF5LCBBcHJpbCAxMiwgMjAxMiAyOjAzIEFNDQo+Pj5UbzogJ2dpbGVzLmhlcm9uQGdt YWlsLmNvbTxtYWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tPic7ICdzaW1vbi5kZWxvcmRAZ21h aWwuY29tPG1haWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPic7DQo+Pj4nQWxleGFuZGVyLlZh aW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUu Y29tPicNCj4+PkNjOiAnbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPic7ICdW bGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPG1haWx0bzpWbGFkaW1pci5LbGVpbmVyQGVjaXRl bGUuY29tPic7DQo+Pj4nQW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb208bWFpbHRvOkFuZHJldy5T ZXJnZWV2QGVjaXRlbGUuY29tPic7ICdJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbTxtYWlsdG86SWRh bi5LYXNwaXRAZWNpdGVsZS5jb20+JzsNCj4+PidNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbTxt YWlsdG86TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb20+JzsgJ1JvdGVtLkNvaGVuQGVjaXRlbGUu Y29tPG1haWx0bzpSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbT4nDQo+Pj5TdWJqZWN0OiBSZTogVGhl IHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+DQo+ Pj5UaGUgdmxhbiBhcHByb2FjaCBpcyBzdXBlcmlvciBhcyBpdCBhbHNvIHdvcmtzIGZvciBldGgg b25seSBuZXR3b3JrcywNCj4+PmV0Yy4gT24gdG9wIHNvbWUgdmVuZG9ycyBpbmRpY2F0ZSBodyBp c3N1ZXMgd2l0aCB0aGUgY3cgYXBwcm9hY2guIEFzDQo+Pj5zdWNoIHdlIGhhdmUgZHJvcHBlZCBt b3JlIG9yIGxlc3MgdGhlIGN3IGFwcHJvYWNoLg0KPj4+DQo+Pj5DaGVlcnMsDQo+Pj5XaW0NCj4+ Pl9fX19fX19fX19fX19fX19fDQo+Pj5zZW50IGZyb20gYmxhY2tiZXJyeQ0KPj4+DQo+Pj4tLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+Pj5Gcm9tOiBHaWxlcyBIZXJvbiBbbWFpbHRvOmdp bGVzLmhlcm9uQGdtYWlsLmNvbTxtYWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tPl0NCj4+PlNl bnQ6IFRodXJzZGF5LCBBcHJpbCAxMiwgMjAxMiAwODoyMiBBTQ0KPj4+VG86IFNpbW9uIERlbG9y ZCA8c2ltb24uZGVsb3JkQGdtYWlsLmNvbTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT4+ OyBBbGV4YW5kZXIgVmFpbnNodGVpbg0KPj4+PEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUu Y29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4+DQo+Pj5DYzogbDJ2 cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPiA8bDJ2cG5AaWV0Zi5vcmc8bWFpbHRv OmwydnBuQGlldGYub3JnPj47IFZsYWRpbWlyIEtsZWluZXINCj4+PjxWbGFkaW1pci5LbGVpbmVy QGVjaXRlbGUuY29tPG1haWx0bzpWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPj47IEFuZHJl dyBTZXJnZWV2DQo+Pj48QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb208bWFpbHRvOkFuZHJldy5T ZXJnZWV2QGVjaXRlbGUuY29tPj47IElkYW4gS2FzcGl0IDxJZGFuLkthc3BpdEBlY2l0ZWxlLmNv bTxtYWlsdG86SWRhbi5LYXNwaXRAZWNpdGVsZS5jb20+PjsNCj4+Pk1pc2hhZWwgV2V4bGVyIDxN aXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbTxtYWlsdG86TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5j b20+PjsgUm90ZW0gQ29oZW4NCj4+PjxSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbTxtYWlsdG86Um90 ZW0uQ29oZW5AZWNpdGVsZS5jb20+Pg0KPj4+U3ViamVjdDogUmU6IFRoZSBzdGF0dXMgb2YgdGhl IGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4+Pg0KPj4+U29ycnkgLSB0aGUg ImFub255bW91cyBwcmVzZW50YXRpb24iIHdhcyBtaW5lLiAgSSBzaG91bGQgcG9zc2libHkgaGF2 ZQ0KPj4+cHV0IGluIGEgdGhpcmQgY29sdW1uIG9uIHRoZSBDVyBhcHByb2FjaC4gIEFuZCBob3Bl ZnVsbHkgdGhlIG1pbnV0ZXMNCj4+PndpbGwgYmUgcG9zdGVkIHNvb24uDQo+Pj4NCj4+PldlIGhh ZCB2YXJpb3VzIGRpc2N1c3Npb25zLCBhcyBTaW1vbiBzdGF0ZWQsIGFuZCBjb25zZW5zdXMgc2Vl bWVkIHRvIGJlDQo+Pj5mb3JtaW5nIGFyb3VuZCB0aGUgdHdvIGFsdGVybmF0aXZlcyBvZiB0d28g UFdFcyBvciB0d28gVkxBTnMuICBJIGJlbGlldmUNCj4+PnRocmVlIG9mIHRoZSBhdXRob3JzIG9m IHRoZSBDVyBhcHByb2FjaCBhcmUgYWxzbyBhdXRob3JzIG9mIHRoZSB0d28gVkxBTg0KPj4+YXBw cm9hY2ggYW5kIG9uZSBpcyBhbHNvIGFuIGF1dGhvciBvZiB0aGUgdHdvIFBXRSBhcHByb2FjaC4g U28gcGVyaGFwcw0KPj4+aXQncyBiZXN0IHRvIGxldCB0aG9zZSBmb3VyIGluZGl2aWR1YWxzIHNh eSB3aGljaCBhcHByb2FjaCB0aGV5IHByZWZlcg0KPj4+YW5kIHdoeT8NCj4+Pg0KPj4+R2lsZXMN Cj4+Pg0KPj4+T24gMTAvMDQvMjAxMiAwMDo0NSwgIlNpbW9uIERlbG9yZCIgPHNpbW9uLmRlbG9y ZEBnbWFpbC5jb208bWFpbHRvOnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+PiB3cm90ZToNCj4+Pg0K Pj4+PiBIaSBBbGV4YW5kZXIsDQo+Pj4+DQo+Pj4+IFlvdSBhcmUgcmlnaHQsIG5vIGRpc2N1c3Np b24gb24gdGhlIFdHIG1haWxpbmcgbGlzdCByZWNlbnRseSwgYnV0DQo+Pj4+IHRoZXJlIGhhdmUg YmVlbiBzdWJzdGFudGlhbCBkaXNjdXNzaW9ucyBhbW9uZyB0aGUgYXV0aG9ycyBvZiB2YXJpb3Vz DQo+Pj4+IHNvbHV0aW9uIGRyYWZ0cyBvZmYgdGhlIG1haWxpbmcgbGlzdC4gQXMgZmFyIGFzIEkg a25vdywgbm8gY29uc2Vuc3VzDQo+Pj4+IHlldCBiZWZvcmUgaWV0ZjgzLCBub3Qgc3VyZSB0aGUg cHJvZ3Jlc3MgaW4gdGhlIFBhcmlzIFdHIG1lZXRpbmcuIEkNCj4+Pj4gdGhpbmsgdGhlIENXIGFw cHJvYWNoIGhhcyBub3QgYmVlbiByZWplY3RlZCBieSB0aGUgV0cgeWV0LCBvciB0aGUgV0cNCj4+ Pj4gaGFzIG5vdCB5ZXQgZGVjaWRlZCBvbiB3aGljaCBvbmUgdG8gYWRvcHQuDQo+Pj4+DQo+Pj4+ IFNpbW9uDQo+Pj4+DQo+Pj4+IDIwMTIvNC84IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5k ZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNp dGVsZS5jb20+Pg0KPj4+Pg0KPj4+Pj4gIEhpIGFsbCwNCj4+Pj4+DQo+Pj4+PiBVbmZvcnR1bmF0 ZWx5IEkgaGF2ZSBub3QgYmVlbiBhYmxlIHRvIGF0dGVuZCB0aGUgUGFyaXMgSUVURi4NCj4+Pj4+ DQo+Pj4+PiBIb3dldmVyLCBsb29raW5nIHVwIHRoZSBMMlZQTiBwcm9jZWVkaW5ncywgSSd2ZSBm b3VuZCBhIHNob3J0DQo+Pj4+PiBhbm9ueW1vdXMgcHJlc2VudGF0aW9uIGNhbGxlZCAiRS1UcmVl IFVwZGF0ZSIgICgNCj4+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODMvc2xp ZGVzL3NsaWRlcy04My1sMnZwbi0xLnBwdHgpLg0KPj4+Pj4gVGhpcyBwcmVzZW50YXRpb24gZGlz Y3Vzc2VzIHRoZSBkaWZmZXJlbmNlcyBvZiB0aGUgRS1UcmVlIGFwcHJvYWNoZXMNCj4+Pj4+IGJh c2VkIG9uIGRlZGljYXRlZCBWTEFOcyAoYXMgaW4NCj4+Pj4+IGh0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtY2FvLWwydnBuLXZwbHMtZXRyZWUvP2luY2x1ZGVfdA0KPj4+Pj4g ZXh0PTEpIGFuZCBtdWx0aXBsZSBQV3MgYmV0d2VlbiB0aGUgUEVzIChhcyBpbg0KPj4+Pj4gaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1yYW0tbDJ2cG4tZXRyZWUtbXVsdGlw bGUtcHcvP2luDQo+Pj4+PiBjbHVkZV90ZQ0KPj4+Pj4geHQ9MSkNCj4+Pj4+IGFuZCBjb21wbGV0 ZWx5IGlnbm9yZXMgdGhlIHNvbHV0aW9uIGJhc2VkIG9uIHVzYWdlIG9mIHRoZSBDVyBpbiB0aGUN Cj4+Pj4+IFBXcyBjb25uZWN0aW5nIHRoZSBQRXMgKGFzIGluDQo+Pj4+PiBodHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtleS1sMnZwbi12cGxzLWV0cmVlLz9pbmNsdWRlX3QN Cj4+Pj4+IGV4dD0xDQo+Pj4+PiApLg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gVGhlIE1p bnV0ZXMgb2YgdGhlIFBhcmlzIEwyVlBOIHNlc3Npb24gYXJlIG5vdCB5ZXQgYXZhaWxhYmxlLCBi dXQgSQ0KPj4+Pj4gd29uZGVyIHdoZXRoZXIgdGhlIFdHIGhhcyB0YWtlbiBhIGRlY2lzaW9uIHRv IHJlamVjdCB0aGUgYXBwcm9hY2gNCj4+Pj4+IGJhc2VkIG9uIHRoZSBDVyB1c2FnZT8gSSBkbyBu b3QgcmVtZW1iZXIgYW55IHJlY2VudCBkaXNjdXNzaW9uIG9mDQo+Pj4+PiB0aGlzIHRvcGljIG9u IHRoZSBXRyBtYWlsaW5nIGxpc3QuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBSZWdhcmRz LCBhbmQgbG90cyBvZiB0aGFua3MgaW4gYWR2YW5jZSwNCj4+Pj4+DQo+Pj4+PiBTYXNoYQ0KPj4+ Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBUaGlzIGUtbWFpbCBtZXNzYWdl IGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zDQo+Pj4+PiBp bmZvcm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmll dGFyeSB0byBFQ0kNCj4+Pg0KPj4+Pj4gVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZQ0KPj4+Pj4gaW5mb3JtIHVzIGJ5IGUtbWFp bCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZA0KPj4+Pj4g YWxsIGNvcGllcyB0aGVyZW9mLg0KPj4+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj5U aGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdh cm5lciBDYWJsZQ0KPj4+cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVn ZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdA0KPj4+dG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0 byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQNCj4+PnNvbGVseSBm b3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRk cmVzc2VkLg0KPj4+SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlz IEUtbWFpbCwgeW91IGFyZSBoZXJlYnkNCj4+Pm5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRp b24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuDQo+Pj5pbiByZWxhdGlv biB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzDQo+ Pj5zdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMNCj4+PkUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseQ0KPj4+ZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQg YW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCj4+Pg0KPj4NCj4+DQo+ PlRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUg V2FybmVyIENhYmxlDQo+PnByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxl Z2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8NCj4+Y29weXJpZ2h0IGJlbG9uZ2luZyB0 byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5DQo+PmZv ciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRy ZXNzZWQuIElmIHlvdQ0KPj5hcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBF LW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkDQo+PnRoYXQgYW55IGRpc3NlbWluYXRpb24s IGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluDQo+PnJlbGF0aW9uIHRv IHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0 bHkNCj4+cHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIEUtbWFpbCBpbg0KPj5lcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlDQo+Pm9yaWdpbmFsIGFuZCBhbnkgY29w eSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0KPg0KPg0KPiBUaGlzIEUtbWFpbCBh bmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBw cm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFs LCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUu IFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZp ZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3Rp ZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFj dGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRz IHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1 bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmln aW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCj4gVGhp cyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBj b250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBi ZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0 cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBv ciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFsbCBjb3BpZXMgdGhlcmVv Zi4NCj4NCj4NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEwydnBuIG1haWxp bmcgbGlzdA0KPiBMMnZwbkBpZXRmLm9yZzxtYWlsdG86TDJ2cG5AaWV0Zi5vcmc+DQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDJ2cG4NCj4NCj4NCj4gRW5kIG9mIEwy dnBuIERpZ2VzdCwgVm9sIDk1LCBJc3N1ZSAyNQ0KPiAqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKg0K From DanielC@orckit.com Tue Apr 24 09:58:46 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A78821E8098 for ; Tue, 24 Apr 2012 09:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.627 X-Spam-Level: * X-Spam-Status: No, score=1.627 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_ILLEGAL_IP=1.908, RCVD_NUMERIC_HELO=2.067] 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 xWEw+VdQitas for ; Tue, 24 Apr 2012 09:58:44 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id C6E2D21E8099 for ; Tue, 24 Apr 2012 09:58:43 -0700 (PDT) Received: from 1.1.40.5 ([1.1.40.5]) by tlvmail1.corrigent.com ([1.1.40.5]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Apr 2012 17:00:49 +0000 Date: Tue, 24 Apr 2012 19:58:12 +0300 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <169401cd223b$cc9400ea$05280101@corrigent.com> Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IAAHuPxAAACKFwAACIeb8AADgRjp X-MimeOLE: Produced By Microsoft Exchange V6.5 Importance: normal From: "Daniel Cohn" To: "Hernandez-Valencia, Enrique (Enrique)" , "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "Lucy yong" , "Rogers, Josh" , "Shahram Davari" , "Lizhong Jin" , , MIME-Version: 1.0 Cc: yuqun.cao@gmail.com X-BeenThere: l2vpn@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, 24 Apr 2012 16:58:46 -0000 I don't know what kind of translation you propose but I don't see how = you can preserve the original s-vlan id plus root/leaf in the same = number of bits=0A= =0A= Thumb typed - please be tolerant=0A= =0A= "Hernandez-Valencia, Enrique (Enrique)" = wrote:=0A= =0A= VLAN-ID preservation does not necessarily require a third VLAN-ID. = VLAN-ID translation is sufficient. Enrique -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Daniel Cohn Sent: Tuesday, April 24, 2012 7:17 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Lucy yong; Rogers, Josh; = Shahram Davari; Lizhong Jin; l2vpn@ietf.org; = Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? No, the other way round. In the 2-VLAN solution, S-VLAN ID preservation = requires adding a third VLAN ID. In the multi-PW solution, this is not = required. DC -----Original Message----- From: Sprecher, Nurit (NSN - IL/Hod HaSharon) = [mailto:nurit.sprecher@nsn.com] Sent: Tuesday, April 24, 2012 2:02 PM To: Daniel Cohn; Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; = l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Daniel, Is it so that you consider S-VAL stacking? If this is the case, are you aware that this is not in-line with the = IEEE specifications? Best regard, Nurit -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of ext Daniel Cohn Sent: Tuesday, April 24, 2012 10:12 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; = l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, even if the current MEF framework doesn't require s-vlan preservation, I = believe it's to the industry's benefit to adopt a solution that is not = constrained to a specific enni model that, like all things networking, = is likely to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service = providers' inputs. It had a fair reason to assume S-VLAN over ENNI by = then. It may open B-VLAN for the future. It is better for us not to = discuss a future framework here, because it will lead us to nowhere. = Here, we want to extend VPLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Daniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; = Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume = that the VLAN tags at the E-NNI will always be according to the current = MEF model? Or should we try to be as transparent as possible to user = VLAN encapsulation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case = VLAN tag) to signal VPLS information (in this case root/leaf origin) is = necessarily tied to specific assumptions on user payload encapsulation = (in this case, that S-VLAN tag is "available" to encode root/leaf). I = don't think this is a future-proof assumption, it's very likely that = other network models will come up that require S-VLAN preservation, = which in the 2-VLAN approach would necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, = "l2vpn@ietf.org" = >, = "Alexander.Vainshtein@ecitele.com" = > Cc: "yuqun.cao@gmail.com" = > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic = already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; = Alexander.Vainshtein@ecitele.com= Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the = R/L information, customer payload or PW? The customer payload will be = always modified to carry R/L information in 2-VLAN approach, while PW = with CW will carry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is = accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used = to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate = R/L information? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein = > > To: "Rogers, Josh" = >, Lucy yong > >, Daniel = Cohn >, Sam Cao > > > Cc: "l2vpn@ietf.org" = > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > = > > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very = popular, but: > > IMO one of the advantages of the CW-based solution is that it is = orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, = and, in a more generic way, localization of effects of changes in the PE = configuration. > > In particular, adding a Leaf AC to a PE that previously has been only = supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect = only the PE where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main = disadvantage of the CW-based approach - I believe it strongly depends on = specific implementations. And some changes in the forwarding process are = required in any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org = [l2vpn-bounces@ietf.org] on behalf of = Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a = more > complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become = more > complex. > > Gile's comparison slide still concisely captures the differences = between > these methods, in my opinion. I haven't seen any new ideas or = thoughts > brought to the group in the past week or two on the subject. I would = hate > for both proposed methods to die on the vine because we couldn't = decide > between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" = > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree = uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may = double >>all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn = [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the = processing >>in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP = PW >>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >>traffic coming from a root AC) >>[[LY]] Not that simple. You construct either two P2MP PWs to all other >>PEs and let egress PE performing filtering, or construct one P2MP PW = to >>leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >>perform forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so = don't >>feel terribly strong about this objection. Is this a real problem for >>others (now or in the future), or is this objection in the weeds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. = I >>encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" = > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao = [mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim = (Wim)'; >>>giles.heron@gmail.com; = simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; = Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; = Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; = Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs = after >>>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup = 2 >>>P2MP >>>PWs if need. There is no difference between P2MP or normal PW setup. = But, >>>can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with = both >>>root and leaf ACs set up two or one P2MP PW to other PEs (some PE = have >>>both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn = [mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; = Alexander.Vainshtein@ecitele.com= ; Sam Cao >>>Cc: l2vpn@ietf.org; = Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; = Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; = Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong = [mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; = simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; = Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; = Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; = Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, = both >>>approaches can benefit from it. I was off for a while and captures = some >>>discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues = with >>>silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I = am >>>not clear on all the issues. Could you be more specific? As I = mentioned >>>in below, two PW approach makes VPLS transport construction and = packet >>>forwarding more complex, I can see potential backward compatibility >>>issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree = uses >>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown = unicast >>>traffic, and some P2MP PWs for multicast traffic. It may double all = of >>>them. >>> >>>E-tree is an Ethernet service and there is already VLAN based = solution >>>in IEEE, can we just utilize it without complicating VPLS transport >>>construction? This also makes interworking with Eth only network = easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh = [mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); = 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; = 'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; = 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; = 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; = 'Rotem.Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are = you >>>saying that you no longer are interested in that method in preference = of >>>the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org] On Behalf >>>Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; = 'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; = 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; = 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; = 'Rotem.Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron = [mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord = >; Alexander = Vainshtein >>>> >>>Cc: l2vpn@ietf.org = >; Vladimir Kleiner >>>>; = Andrew Sergeev >>>>; Idan = Kaspit >; >>>Mishael Wexler = >; Rotem = Cohen >>>> >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly = have >>>put in a third column on the CW approach. And hopefully the minutes >>>will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to = be >>>forming around the two alternatives of two PWEs or two VLANs. I = believe >>>three of the authors of the CW approach are also authors of the two = VLAN >>>approach and one is also an author of the two PWE approach. So = perhaps >>>it's best to let those four individuals say which approach they = prefer >>>and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" = > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of = various >>>> solution drafts off the mailing list. As far as I know, no = consensus >>>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>>> think the CW approach has not been rejected by the WG yet, or the = WG >>>> has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein = > >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree = approaches >>>>> based on dedicated VLANs (as in >>>>> = http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> = http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in = the >>>>> PWs connecting the PEs (as in >>>>> = http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but = I >>>>> wonder whether the WG has taken a decision to reject the approach >>>>> based on the CW usage? I do not remember any recent discussion of >>>>> this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and = contains >>>>> information which is CONFIDENTIAL and which may be proprietary to = ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original = and >>>>> all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or = subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is = addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action = taken >>>in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject = to >>copyright belonging to Time Warner Cable. This E-mail is intended = solely >>for the use of the individual or entity to which it is addressed. If = you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies = thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** From david.i.allan@ericsson.com Tue Apr 24 10:03:21 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5372921E8086 for ; Tue, 24 Apr 2012 10:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 97UUVG4PoXfF for ; Tue, 24 Apr 2012 10:03:19 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2D99C21E8093 for ; Tue, 24 Apr 2012 10:03:19 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3OH3HF7020779; Tue, 24 Apr 2012 12:03:18 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.69]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 24 Apr 2012 13:03:11 -0400 From: David Allan I To: Daniel Cohn , "l2vpn@ietf.org" Date: Tue, 24 Apr 2012 13:02:56 -0400 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IAAHuPxAAACKFwAACIeb8AADgRjpAAAMXHA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD523223562C@EUSAACMS0703.eamcs.ericsson.se> References: <169401cd223b$cc9400ea$05280101@corrigent.com> In-Reply-To: <169401cd223b$cc9400ea$05280101@corrigent.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: l2vpn@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, 24 Apr 2012 17:03:21 -0000 With recipient list trimmed... Why do you think there is ever only one S-VLAN? Is is an ETREE construct Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Tuesday, April 24, 2012 12:58 PM To: Hernandez-Valencia, Enrique (Enrique); Sprecher, Nurit (NSN - IL/Hod Ha= Sharon); Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.o= rg; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? I don't know what kind of translation you propose but I don't see how you c= an preserve the original s-vlan id plus root/leaf in the same number of bit= s Thumb typed - please be tolerant "Hernandez-Valencia, Enrique (Enrique)" wrote: VLAN-ID preservation does not necessarily require a third VLAN-ID. VLAN-ID = translation is sufficient. Enrique -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Tuesday, April 24, 2012 7:17 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Lucy yong; Rogers, Josh; Shahr= am Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? No, the other way round. In the 2-VLAN solution, S-VLAN ID preservation req= uires adding a third VLAN ID. In the multi-PW solution, this is not require= d. DC -----Original Message----- From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.co= m] Sent: Tuesday, April 24, 2012 2:02 PM To: Daniel Cohn; Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vp= n@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Daniel, Is it so that you consider S-VAL stacking? If this is the case, are you aware that this is not in-line with the IEEE s= pecifications? Best regard, Nurit -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of e= xt Daniel Cohn Sent: Tuesday, April 24, 2012 10:12 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, even if the current MEF framework doesn't require s-vlan preservation, I be= lieve it's to the industry's benefit to adopt a solution that is not constr= ained to a specific enni model that, like all things networking, is likely = to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service provider= s' inputs. It had a fair reason to assume S-VLAN over ENNI by then. It may = open B-VLAN for the future. It is better for us not to discuss a future fr= amework here, because it will lead us to nowhere. Here, we want to extend V= PLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Va= inshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume tha= t the VLAN tags at the E-NNI will always be according to the current MEF mo= del? Or should we try to be as transparent as possible to user VLAN encapsu= lation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case VLAN t= ag) to signal VPLS information (in this case root/leaf origin) is necessari= ly tied to specific assumptions on user payload encapsulation (in this case= , that S-VLAN tag is "available" to encode root/leaf). I don't think this i= s a future-proof assumption, it's very likely that other network models wil= l come up that require S-VLAN preservation, which in the 2-VLAN approach wo= uld necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, "l2vpn@i= etf.org" >, "A= lexander.Vainshtein@ecitele.com" <= Alexander.Vainshtein@ecitele.com> Cc: "yuqun.cao@gmail.com" > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic alrea= dy has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com= Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L i= nformation, customer payload or PW? The customer payload will be always mod= ified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is access= ed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informati= on? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > com>> > To: "Rogers, Josh" >, Lucy yong > >, Daniel Cohn <= DanielC@orckit.com>, Sam Cao > > > Cc: "l2vpn@ietf.org" > > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, = but: > > IMO one of the advantages of the CW-based solution is that it is orthogon= al to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffi= c. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and,= in a more generic way, localization of effects of changes in the PE config= uration. > > In particular, adding a Leaf AC to a PE that previously has been only sup= porting Root ACs (or vice versa), removal of the last Leaf or last Root AC = from a PE that previously has been supporting a mix etc. affect only the PE= where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadva= ntage of the CW-based approach - I believe it strongly depends on specific = implementations. And some changes in the forwarding process are required in= any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org > [l2vpn-bounces@ietf.org] on behalf of > Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a > more complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become > more complex. > > Gile's comparison slide still concisely captures the differences > between these methods, in my opinion. I haven't seen any new ideas or > thoughts brought to the group in the past week or two on the subject. > I would hate for both proposed methods to die on the vine because we > couldn't decide between two methods that have nothing inherently wrong wi= th either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree >>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may >>double all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn >>[mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the >>processing in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >>PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW >>(for traffic coming from a root AC) [[LY]] Not that simple. You >>construct either two P2MP PWs to all other PEs and let egress PE >>performing filtering, or construct one P2MP PW to leaf-only PEs and >>two P2MP PWs to root and leaf PEs and let ingress PE perform >>forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so >>don't feel terribly strong about this objection. Is this a real >>problem for others (now or in the future), or is this objection in the we= eds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. >>I encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao >>>[mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>(Wim)'; giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>PE have both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn >>>[mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com>; Sam Cao >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong >>>[mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>both approaches can benefit from it. I was off for a while and >>>captures some discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues >>>with silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >>>am not clear on all the issues. Could you be more specific? As I >>>mentioned in below, two PW approach makes VPLS transport construction >>>and packet forwarding more complex, I can see potential backward >>>compatibility issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>double all of them. >>> >>>E-tree is an Ethernet service and there is already VLAN based >>>solution in IEEE, can we just utilize it without complicating VPLS >>>transport construction? This also makes interworking with Eth only netwo= rk easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh >>>[mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); >>>'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vain= shtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are >>>you saying that you no longer are interested in that method in >>>preference of the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org >>>[mailto:l2vpn-bounces@ietf.org] On >>>Behalf Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron >>>[mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord >>>>; Alexander >>>Vainshtein >>>>>.com>> >>>Cc: l2vpn@ietf.org >>>>; Vladimir Kleiner >>>>; >>>Andrew Sergeev >>>>; Idan >>>Kaspit >; >>>Mishael Wexler >>>>; >>>Rotem Cohen > >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly >>>have put in a third column on the CW approach. And hopefully the >>>minutes will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to >>>be forming around the two alternatives of two PWEs or two VLANs. I >>>believe three of the authors of the CW approach are also authors of >>>the two VLAN approach and one is also an author of the two PWE >>>approach. So perhaps it's best to let those four individuals say >>>which approach they prefer and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of >>>> various solution drafts off the mailing list. As far as I know, no >>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>> meeting. I think the CW approach has not been rejected by the WG >>>> yet, or the WG has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein >>>> >>> le.com>> >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree >>>>> approaches based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/ >>>>> ?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in >>>>> the PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>> I wonder whether the WG has taken a decision to reject the >>>>> approach based on the CW usage? I do not remember any recent >>>>> discussion of this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and >>>>> contains information which is CONFIDENTIAL and which may be >>>>> proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original >>>>> and all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or >>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>intended solely for the use of the individual or entity to which it is a= ddressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail >>>is strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is >>addressed. If you are not the intended recipient of this E-mail, you >>are hereby notified that any dissemination, distribution, copying, or >>action taken in relation to the contents of and attachments to this >>E-mail is strictly prohibited and may be unlawful. If you have >>received this E-mail in error, please notify the sender immediately >>and permanently delete the original and any copy of this E-mail and any p= rintout. > > > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** From donald.fedyk@alcatel-lucent.com Tue Apr 24 10:08:52 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CD421E80A6 for ; Tue, 24 Apr 2012 10:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 FiGlbkT9pdGU for ; Tue, 24 Apr 2012 10:08:49 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id BB5B221E80A1 for ; Tue, 24 Apr 2012 10:08:49 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q3OH8m1I015419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Apr 2012 12:08:48 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q3OH8kAV010132 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Apr 2012 12:08:47 -0500 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.145]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 24 Apr 2012 12:08:47 -0500 From: "Fedyk, Donald (Don)" To: Daniel Cohn , "Hernandez-Valencia, Enrique (Enrique)" , "l2vpn@ietf.org" Date: Tue, 24 Apr 2012 12:08:45 -0500 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IAAHuPxAAACKFwAACIeb8AADgRjpAAAAlvA= Message-ID: References: <169401cd223b$cc9400ea$05280101@corrigent.com> In-Reply-To: <169401cd223b$cc9400ea$05280101@corrigent.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "yuqun.cao@gmail.com" X-BeenThere: l2vpn@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, 24 Apr 2012 17:08:52 -0000 RGFuDQoNCkluIGFuIEUtVHJlZSBNb2RlbCB5b3UgaGF2ZSBsb2dpY2FsbHkgb25lIFZMQU4gb24g aW5ncmVzcyBhbmQgb25lIG9uIEVncmVzcy4gSW4gdGhlIEUtVHJlZSB5b3UgY2FuIHVzZSBhIFJv b3Qgb3IgTGVhZiBWSUQuIChvbmUgb3IgdGhlIG90aGVyLikNCg0KU28geW91IGhhdmU6DQppbmdy ZXNzIFZMQU4gSUQgPC0+IEV0cmVlIFJvb3QvTGVhZiBWSUQgPC0+IEVncmVzcyBWSUQuDQoNCklu Z3Jlc3MgVklEIGRvZXMgbm90IGhhdmUgdG8gZXF1YWwgRWdyZXNzIFZJRCBidXQgcmVnYXJkbGVz cyB0aGVyZSBpcyBvbmx5IGV2ZXIgb25lIFZJRCBvbiBhIGZyYW1lIGF0IGEgdGltZS4NCg0KRG9u DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhbmllbCBD b2huDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAyNCwgMjAxMiAxMjo1OCBQTQ0KVG86IEhlcm5hbmRl ei1WYWxlbmNpYSwgRW5yaXF1ZSAoRW5yaXF1ZSk7IFNwcmVjaGVyLCBOdXJpdCAoTlNOIC0gSUwv SG9kIEhhU2hhcm9uKTsgTHVjeSB5b25nOyBSb2dlcnMsIEpvc2g7IFNoYWhyYW0gRGF2YXJpOyBM aXpob25nIEppbjsgbDJ2cG5AaWV0Zi5vcmc7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUu Y29tDQpDYzogeXVxdW4uY2FvQGdtYWlsLmNvbQ0KU3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2Yg dGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCg0KSSBkb24ndCBrbm93IHdo YXQga2luZCBvZiB0cmFuc2xhdGlvbiB5b3UgcHJvcG9zZSBidXQgSSBkb24ndCBzZWUgaG93IHlv dSBjYW4gcHJlc2VydmUgdGhlIG9yaWdpbmFsIHMtdmxhbiBpZCBwbHVzIHJvb3QvbGVhZiBpbiB0 aGUgc2FtZSBudW1iZXIgb2YgYml0cw0KDQpUaHVtYiB0eXBlZCAtIHBsZWFzZSBiZSB0b2xlcmFu dA0KDQoiSGVybmFuZGV6LVZhbGVuY2lhLCBFbnJpcXVlIChFbnJpcXVlKSIgPGVucmlxdWUuaGVy bmFuZGV6QGFsY2F0ZWwtbHVjZW50LmNvbT4gd3JvdGU6DQoNClZMQU4tSUQgcHJlc2VydmF0aW9u IGRvZXMgbm90IG5lY2Vzc2FyaWx5IHJlcXVpcmUgYSB0aGlyZCBWTEFOLUlELiBWTEFOLUlEIHRy YW5zbGF0aW9uIGlzIHN1ZmZpY2llbnQuDQoNCkVucmlxdWUNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGFuaWVsIENvaG4NClNlbnQ6IFR1ZXNkYXksIEFw cmlsIDI0LCAyMDEyIDc6MTcgQU0NClRvOiBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBI YVNoYXJvbik7IEx1Y3kgeW9uZzsgUm9nZXJzLCBKb3NoOyBTaGFocmFtIERhdmFyaTsgTGl6aG9u ZyBKaW47IGwydnBuQGlldGYub3JnOyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0K Q2M6IHl1cXVuLmNhb0BnbWFpbC5jb20NClN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBh cHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQoNCk5vLCB0aGUgb3RoZXIgd2F5IHJv dW5kLiBJbiB0aGUgMi1WTEFOIHNvbHV0aW9uLCBTLVZMQU4gSUQgcHJlc2VydmF0aW9uIHJlcXVp cmVzIGFkZGluZyBhIHRoaXJkIFZMQU4gSUQuIEluIHRoZSBtdWx0aS1QVyBzb2x1dGlvbiwgdGhp cyBpcyBub3QgcmVxdWlyZWQuDQoNCkRDDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJvbikgW21haWx0bzpudXJp dC5zcHJlY2hlckBuc24uY29tXQ0KU2VudDogVHVlc2RheSwgQXByaWwgMjQsIDIwMTIgMjowMiBQ TQ0KVG86IERhbmllbCBDb2huOyBMdWN5IHlvbmc7IFJvZ2VycywgSm9zaDsgU2hhaHJhbSBEYXZh cmk7IExpemhvbmcgSmluOyBsMnZwbkBpZXRmLm9yZzsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNp dGVsZS5jb20NCkNjOiB5dXF1bi5jYW9AZ21haWwuY29tDQpTdWJqZWN0OiBSRTogVGhlIHN0YXR1 cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KDQpEYW5pZWwsDQpJ cyBpdCBzbyB0aGF0IHlvdSBjb25zaWRlciBTLVZBTCBzdGFja2luZz8NCklmIHRoaXMgaXMgdGhl IGNhc2UsIGFyZSB5b3UgYXdhcmUgdGhhdCB0aGlzIGlzIG5vdCBpbi1saW5lIHdpdGggdGhlIElF RUUgc3BlY2lmaWNhdGlvbnM/DQpCZXN0IHJlZ2FyZCwNCk51cml0DQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4t Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBEYW5pZWwgQ29obg0KU2VudDogVHVl c2RheSwgQXByaWwgMjQsIDIwMTIgMTA6MTIgQU0NClRvOiBMdWN5IHlvbmc7IFJvZ2VycywgSm9z aDsgU2hhaHJhbSBEYXZhcmk7IExpemhvbmcgSmluOyBsMnZwbkBpZXRmLm9yZzsgQWxleGFuZGVy LlZhaW5zaHRlaW5AZWNpdGVsZS5jb20NCkNjOiB5dXF1bi5jYW9AZ21haWwuY29tDQpTdWJqZWN0 OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9u Pw0KDQpMdWN5LA0KDQpldmVuIGlmIHRoZSBjdXJyZW50IE1FRiBmcmFtZXdvcmsgZG9lc24ndCBy ZXF1aXJlIHMtdmxhbiBwcmVzZXJ2YXRpb24sIEkgYmVsaWV2ZSBpdCdzIHRvIHRoZSBpbmR1c3Ry eSdzIGJlbmVmaXQgdG8gYWRvcHQgYSBzb2x1dGlvbiB0aGF0IGlzIG5vdCBjb25zdHJhaW5lZCB0 byBhIHNwZWNpZmljIGVubmkgbW9kZWwgdGhhdCwgbGlrZSBhbGwgdGhpbmdzIG5ldHdvcmtpbmcs IGlzIGxpa2VseSB0byBldm9sdmUuIEVzcGVjaWFsbHkgd2hlbiBzdWNoIGEgc29sdXRpb24gaXMg YXZhaWxhYmxlLg0KDQpEYW5pZWwNCg0KVGh1bWIgdHlwZWQgLSBwbGVhc2UgYmUgdG9sZXJhbnQN Cg0KTHVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQoNCkRhbmllbCwNCg0K TUVGIGhhcyB3b3JrZWQgaW4gRU5OSSBpbnRlcmZhY2UgZm9yIGEgbG9uZyB0aW1lIHdpdGggbWFu eSBzZXJ2aWNlIHByb3ZpZGVycycgaW5wdXRzLiBJdCBoYWQgYSBmYWlyIHJlYXNvbiB0byBhc3N1 bWUgUy1WTEFOIG92ZXIgRU5OSSBieSB0aGVuLiBJdCBtYXkgb3BlbiBCLVZMQU4gZm9yIHRoZSBm dXR1cmUuIEl0IGlzIGJldHRlciBmb3IgdXMgbm90IHRvIGRpc2N1c3MgIGEgZnV0dXJlIGZyYW1l d29yayBoZXJlLCBiZWNhdXNlIGl0IHdpbGwgbGVhZCB1cyB0byBub3doZXJlLiBIZXJlLCB3ZSB3 YW50IHRvIGV4dGVuZCBWUExTIGluIHN1cHBvcnRpbmcgRS1UcmVlLg0KDQpCZXN0IFJlZ2FyZHMs DQpMdWN5DQoNCkZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGFuaWVsIENvaG4NClNlbnQ6IFN1bmRheSwgQXBy aWwgMjIsIDIwMTIgNzozNCBBTQ0KVG86IFJvZ2VycywgSm9zaDsgU2hhaHJhbSBEYXZhcmk7IExp emhvbmcgSmluOyBsMnZwbkBpZXRmLm9yZzsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b20NCkNjOiB5dXF1bi5jYW9AZ21haWwuY29tDQpTdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0 aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KDQpTaGFocmFtIGFuZCBhbGws DQoNClRoaXMgcXVlc3Rpb24gYWxyZWFkeSBjYW1lIHVwIGluIG91ciBkaXNjdXNzaW9ucyAtIGlz IGl0IHNhZmUgdG8gYXNzdW1lIHRoYXQgdGhlIFZMQU4gdGFncyBhdCB0aGUgRS1OTkkgd2lsbCBh bHdheXMgYmUgYWNjb3JkaW5nIHRvIHRoZSBjdXJyZW50IE1FRiBtb2RlbD8gT3Igc2hvdWxkIHdl IHRyeSB0byBiZSBhcyB0cmFuc3BhcmVudCBhcyBwb3NzaWJsZSB0byB1c2VyIFZMQU4gZW5jYXBz dWxhdGlvbiBhdCB0aGUgRS1OTkksIHRvIGFjY29tbW9kYXRlIGZ1dHVyZSBmcmFtZXdvcmtzPw0K SSBiZWxpZXZlIHRoYXQgYW55IGFwcHJvYWNoIHRoYXQgbG9va3MgYXQgdXNlciBwYXlsb2FkIChp biB0aGlzIGNhc2UgVkxBTiB0YWcpIHRvIHNpZ25hbCBWUExTIGluZm9ybWF0aW9uIChpbiB0aGlz IGNhc2Ugcm9vdC9sZWFmIG9yaWdpbikgaXMgbmVjZXNzYXJpbHkgdGllZCB0byBzcGVjaWZpYyBh c3N1bXB0aW9ucyBvbiB1c2VyIHBheWxvYWQgZW5jYXBzdWxhdGlvbiAoaW4gdGhpcyBjYXNlLCB0 aGF0IFMtVkxBTiB0YWcgaXMgImF2YWlsYWJsZSIgdG8gZW5jb2RlIHJvb3QvbGVhZikuIEkgZG9u J3QgdGhpbmsgdGhpcyBpcyBhIGZ1dHVyZS1wcm9vZiBhc3N1bXB0aW9uLCBpdCdzIHZlcnkgbGlr ZWx5IHRoYXQgb3RoZXIgbmV0d29yayBtb2RlbHMgd2lsbCBjb21lIHVwIHRoYXQgcmVxdWlyZSBT LVZMQU4gcHJlc2VydmF0aW9uLCB3aGljaCBpbiB0aGUgMi1WTEFOIGFwcHJvYWNoIHdvdWxkIG5l Y2Vzc2l0YXRlIGFkZGluZyBhIHRoaXJkIFZMQU4tSUQuDQoNCkRhbmllbA0KDQpGcm9tOiBTaGFo cmFtIERhdmFyaSA8ZGF2YXJpQGJyb2FkY29tLmNvbTxtYWlsdG86ZGF2YXJpQGJyb2FkY29tLmNv bT4+DQpUbzogTGl6aG9uZyBKaW4gPGxpemhvLmppbkBnbWFpbC5jb208bWFpbHRvOmxpemhvLmpp bkBnbWFpbC5jb20+PiwgImwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4iIDxs MnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+PiwgIkFsZXhhbmRlci5WYWluc2h0 ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4i IDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5z aHRlaW5AZWNpdGVsZS5jb20+Pg0KQ2M6ICJ5dXF1bi5jYW9AZ21haWwuY29tPG1haWx0bzp5dXF1 bi5jYW9AZ21haWwuY29tPiIgPHl1cXVuLmNhb0BnbWFpbC5jb208bWFpbHRvOnl1cXVuLmNhb0Bn bWFpbC5jb20+Pg0KU3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8g dGhlIEUtVHJlZSBzb2x1dGlvbj8NCg0KSGksDQoNCkkgYWxzbyBoYXZlIGEgcXVlc3Rpb24gcmVn YXJkaW5nIDItVkxBTi4gV2hhdCBpZiB0aGUgY3VzdG9tZXIgdHJhZmZpYyBhbHJlYWR5IGhhcyBh biBTLVZMQU4/IERvIHdlIG5lZWQgYSAzcmQgVkxBTiB0byBpZGVudGlmeSB0aGUgTC9SPw0KDQpU aHgNClNoYWhyYW0NCg0KRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bDJ2cG4t Ym91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgTGl6aG9uZyBKaW4NClNlbnQ6IEZyaWRheSwgQXByaWwgMjAsIDIwMTIgOTozOCBBTQ0K VG86IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz47IEFsZXhhbmRlci5WYWlu c2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bT4NCkNjOiB5dXF1bi5jYW9AZ21haWwuY29tPG1haWx0bzp5dXF1bi5jYW9AZ21haWwuY29tPg0K U3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBz b2x1dGlvbj8NCg0KSGksIGFsbCwNClRoZSBkaWZmZXJlbmNlIGJldHdlZW4gMi1WTEFOIGFuZCBD VyBhcHByb2FjaCBpcyB3aG8gd2lsbCBwcm92aWRlIHRoZSBSL0wgaW5mb3JtYXRpb24sIGN1c3Rv bWVyIHBheWxvYWQgb3IgUFc/IFRoZSBjdXN0b21lciBwYXlsb2FkIHdpbGwgYmUgYWx3YXlzIG1v ZGlmaWVkIHRvIGNhcnJ5IFIvTCBpbmZvcm1hdGlvbiBpbiAyLVZMQU4gYXBwcm9hY2gsIHdoaWxl IFBXIHdpdGggQ1cgd2lsbCBjYXJyeSBSL0wgaW5mb3JtYXRpb24gZm9yIENXIGFwcHJvYWNoLg0K SSBoYXZlIGEgcXVlc3Rpb24gd2l0aCB0aGUgMi1WTEFOIGFwcHJvYWNoIGluIEgtVlBMUyB3aGVy ZSBILVZQTFMgaXMgYWNjZXNzZWQgYnkgVlBXUyBhcyBkZXNjcmliZWQgaW4gUkZDNDY3MiBzZWN0 aW9uIDEwLjEuMy4gSWYgVlBXUyBpcyB1c2VkIHRvIGFjY2VzcyBILVZQTFMsIGhvdyBjb3VsZCB0 aGUgUEUgb24gVlBXUyBzaWRlIGFkZHMgVkxBTiB0byBpbmRpY2F0ZSBSL0wgaW5mb3JtYXRpb24/ DQoNClRoYW5rcw0KTGl6aG9uZw0KDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Pg0KPiBNZXNzYWdlOiAyDQo+IERhdGU6IFRodSwgMTkgQXByIDIwMTIgMDQ6Mzg6MzYgKzAwMDAN Cj4gRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRl bGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4+DQo+IFRvOiAi Um9nZXJzLCBKb3NoIiA8am9zaC5yb2dlcnNAdHdjYWJsZS5jb208bWFpbHRvOmpvc2gucm9nZXJz QHR3Y2FibGUuY29tPj4sIEx1Y3kgeW9uZw0KPiAgICAgICAgPGx1Y3kueW9uZ0BodWF3ZWkuY29t PG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+LCBEYW5pZWwgQ29obiA8RGFuaWVsQ0BvcmNr aXQuY29tPG1haWx0bzpEYW5pZWxDQG9yY2tpdC5jb20+PiwgU2FtIENhbw0KPiAgICAgICAgPHl1 cXVuLmNhb0BnbWFpbC5jb208bWFpbHRvOnl1cXVuLmNhb0BnbWFpbC5jb20+Pg0KPiBDYzogImwy dnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4iIDxsMnZwbkBpZXRmLm9yZzxtYWls dG86bDJ2cG5AaWV0Zi5vcmc+Pg0KPiBTdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBw cm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPiBNZXNzYWdlLUlEOg0KPiAgICAgICAg PEY5MzM2NTcxNzMxQURFNDJBNTM5N0ZDODMxQ0VBQTAyMDM0MTkyQEZSSURXUFBNQjAwMi5lY2l0 ZWxlLmNvbTxtYWlsdG86RjkzMzY1NzE3MzFBREU0MkE1Mzk3RkM4MzFDRUFBMDIwMzQxOTJARlJJ RFdQUE1CMDAyLmVjaXRlbGUuY29tPj4NCj4gQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PSJ1cy1hc2NpaSINCj4NCj4gSGkgYWxsLA0KPiBJIGZ1bGx5IHVuZGVyc3RhbmQgdGhhdCB0 aGF0IHdoYXQgSSBhbSBnb2luZyB0byBzYXkgaXMgbm90IHZlcnkgcG9wdWxhciwgYnV0Og0KPg0K PiBJTU8gb25lIG9mIHRoZSBhZHZhbnRhZ2VzIG9mIHRoZSBDVy1iYXNlZCBzb2x1dGlvbiBpcyB0 aGF0IGl0IGlzIG9ydGhvZ29uYWwgdG8gdXNhZ2UgKG9yIG5vbi11c2FnZSkgb2YgUDJNUCBQV3Mg Zm9yIGVmZmVjdGl2ZSBkZWxpdmVyeSBvZiBCVU4gdHJhZmZpYy4NCj4NCj4gQW5vdGhlciBhZHZh bnRhZ2UgaXMgcHJlc2VydmF0aW9uIG9mIGZ1bGwgbWVzaCBvZiBQMlAgUFdzIGluIGEgVlBMUywg YW5kLCBpbiBhIG1vcmUgZ2VuZXJpYyB3YXksIGxvY2FsaXphdGlvbiBvZiBlZmZlY3RzIG9mIGNo YW5nZXMgaW4gdGhlIFBFIGNvbmZpZ3VyYXRpb24uDQo+DQo+IEluIHBhcnRpY3VsYXIsIGFkZGlu ZyBhIExlYWYgQUMgdG8gYSBQRSB0aGF0IHByZXZpb3VzbHkgaGFzIGJlZW4gb25seSBzdXBwb3J0 aW5nIFJvb3QgQUNzIChvciB2aWNlIHZlcnNhKSwgcmVtb3ZhbCBvZiB0aGUgbGFzdCBMZWFmIG9y IGxhc3QgUm9vdCBBQyBmcm9tIGEgUEUgdGhhdCBwcmV2aW91c2x5IGhhcyBiZWVuIHN1cHBvcnRp bmcgYSBtaXggZXRjLiBhZmZlY3Qgb25seSB0aGUgUEUgd2hlcmUgdGhpcyBvcGVyYXRpb24gaGFw cGVucyBhbmQgbm90IHRoZSByZXN0IG9mIHRoZSBQRXMuDQo+DQo+IEFzIGZvciB0aGUgbmVlZCBm b3IgSFcgY2hhbmdlcyB0aGF0IGhhdmUgYmVlbiBtZW50aW9uZWQgYXMgYSBtYWluIGRpc2FkdmFu dGFnZSBvZiB0aGUgQ1ctYmFzZWQgYXBwcm9hY2ggLSBJIGJlbGlldmUgaXQgc3Ryb25nbHkgZGVw ZW5kcyBvbiBzcGVjaWZpYyBpbXBsZW1lbnRhdGlvbnMuIEFuZCBzb21lIGNoYW5nZXMgaW4gdGhl IGZvcndhcmRpbmcgcHJvY2VzcyBhcmUgcmVxdWlyZWQgaW4gYW55IHNvbHV0aW9uLg0KPg0KPiBN eSAyYywNCj4gICAgIFNhc2hhDQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bDJ2 cG4tYm91bmNlc0BpZXRmLm9yZz4gW2wydnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBu LWJvdW5jZXNAaWV0Zi5vcmc+XSBvbiBiZWhhbGYgb2YgUm9nZXJzLCBKb3NoIFtqb3NoLnJvZ2Vy c0B0d2NhYmxlLmNvbTxtYWlsdG86am9zaC5yb2dlcnNAdHdjYWJsZS5jb20+XQ0KPiBTZW50OiBX ZWRuZXNkYXksIEFwcmlsIDE4LCAyMDEyIDk6NTcgUE0NCj4gVG86IEx1Y3kgeW9uZzsgRGFuaWVs IENvaG47IFNhbSBDYW8NCj4gQ2M6IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9y Zz4NCj4gU3ViamVjdDogUmU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUt VHJlZSBzb2x1dGlvbj8NCj4NCj4gQWdhaW4sIHRoZSBQMk1QIHNpdHVhdGlvbiB0aHJvd3MgbWUu ICBJcyB0aGlzIHNvbWV0aGluZyB0aGF0IGlzIHVzZWQNCj4gY29tbW9ubHk/DQo+DQo+IEknbSB1 bmRlciB0aGUgaW1wcmVzc2lvbiB0aGF0IGFkZGluZyBQMk1QIHRvIGFueSBtb2RlbCByZXN1bHRz IGluIGEgbW9yZQ0KPiBjb21wbGV4IG1vZGVsLiAgV2V0aGVyIG91dHNpZGUgcy10YWcgaXMgdXNl ZCB0byBkaWZmZXJlbnRpYXRlLCBvcg0KPiBkZWRpY2F0ZWQgcHcncyBhcmUgdXNlZCBmb3IgdGhl IHNhbWUgcHVycG9zZSwgaXQgc2VlbXMgYm90aCBiZWNvbWUgbW9yZQ0KPiBjb21wbGV4Lg0KPg0K PiBHaWxlJ3MgY29tcGFyaXNvbiBzbGlkZSBzdGlsbCBjb25jaXNlbHkgY2FwdHVyZXMgdGhlIGRp ZmZlcmVuY2VzIGJldHdlZW4NCj4gdGhlc2UgbWV0aG9kcywgaW4gbXkgb3Bpbmlvbi4gIEkgaGF2 ZW4ndCBzZWVuIGFueSBuZXcgaWRlYXMgb3IgdGhvdWdodHMNCj4gYnJvdWdodCB0byB0aGUgZ3Jv dXAgaW4gdGhlIHBhc3Qgd2VlayBvciB0d28gb24gdGhlIHN1YmplY3QuICBJIHdvdWxkIGhhdGUN Cj4gZm9yIGJvdGggcHJvcG9zZWQgbWV0aG9kcyB0byBkaWUgb24gdGhlIHZpbmUgYmVjYXVzZSB3 ZSBjb3VsZG4ndCBkZWNpZGUNCj4gYmV0d2VlbiB0d28gbWV0aG9kcyB0aGF0IGhhdmUgbm90aGlu ZyBpbmhlcmVudGx5IHdyb25nIHdpdGggZWl0aGVyLg0KPg0KPiAtSm9zaA0KPg0KPg0KPiBPbiA0 LzE4LzEyIDE6NTMgUE0sICJMdWN5IHlvbmciIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86 bHVjeS55b25nQGh1YXdlaS5jb20+PiB3cm90ZToNCj4NCj4+U2VuZCB0aGlzIGFnYWluLg0KPj4N Cj4+VHdvIFBXIGFwcHJvYWNoIGNhbiBiZSBjb21wbGV4IHRvbyBpZiB0aGUgVlBMUyBpbnN0YW5j ZSBmb3IgRS1UcmVlIHVzZXMNCj4+UDJQIFBXIGZvciB1bmljYXN0IHRyYWZmaWMgYW5kIFAyTVAg UFcgZm9yIGJyb2FkY2FzdCBhbmQgdW5rbm93bg0KPj51bmljYXN0IHRyYWZmaWMsIGFuZCBzb21l IFAyTVAgUFdzIGZvciBtdWx0aWNhc3QgdHJhZmZpYy4gSXQgbWF5IGRvdWJsZQ0KPj5hbGwgb2Yg dGhlbS4NCj4+DQo+Pkx1Y3kNCj4+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZy b206IERhbmllbCBDb2huIFttYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tPG1haWx0bzpEYW5pZWxD QG9yY2tpdC5jb20+XQ0KPj5TZW50OiBXZWRuZXNkYXksIEFwcmlsIDE4LCAyMDEyIDE6NDIgUE0N Cj4+VG86IEx1Y3kgeW9uZzsgUm9nZXJzLCBKb3NoOyBTYW0gQ2FvDQo+PkNjOiBsMnZwbkBpZXRm Lm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+DQo+PlN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9m IHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pg0KPj5JIHRoaW5rIHRo ZSBmaXJzdCBvcHRpb24gaXRzIHRoZSBuYXR1cmFsIHdheSB0byBnby4gSG93IGlzIHRoZSBwcm9j ZXNzaW5nDQo+PmluIHRoaXMgY2FzZSBtb3JlIGNvbXBsZXg/DQo+Pg0KPj5UaHVtYiB0eXBlZCAt IHBsZWFzZSBiZSB0b2xlcmFudA0KPj4NCj4+THVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNv bTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiB3cm90ZToNCj4+DQo+Pg0KPj4NCj4+U25p cHBlZC4uDQo+Pg0KPj5NdWx0aS1QVyAtIE9uIGluZ3Jlc3MgUEUsIGZyYW1lIGlzIHBsYWNlZCBv bnRvIGVpdGhlciBhIExlYWYtb25seSBQMk1QIFBXDQo+Pihmb3IgdHJhZmZpYyBjb21pbmcgZnJv bSBhIGxlYWYgQUMpLCBvciBvbnRvIGEgUm9vdC9MZWFmIFAyTVAgUFcgKGZvcg0KPj50cmFmZmlj IGNvbWluZyBmcm9tIGEgcm9vdCBBQykNCj4+W1tMWV1dIE5vdCB0aGF0IHNpbXBsZS4gWW91IGNv bnN0cnVjdCBlaXRoZXIgdHdvIFAyTVAgUFdzIHRvIGFsbCBvdGhlcg0KPj5QRXMgYW5kIGxldCBl Z3Jlc3MgUEUgcGVyZm9ybWluZyBmaWx0ZXJpbmcsIG9yIGNvbnN0cnVjdCBvbmUgUDJNUCBQVyB0 bw0KPj5sZWFmLW9ubHkgUEVzIGFuZCB0d28gUDJNUCBQV3MgdG8gcm9vdCBhbmQgbGVhZiBQRXMg YW5kIGxldCBpbmdyZXNzIFBFDQo+PnBlcmZvcm0gZm9yd2FyZGluZyBhbmQgZmlsdGVyaW5nLiBC b3RoIG1ha2Ugbm9kZSBwcm9jZXNzIGNvbXBsZXguDQo+Pg0KPj5bW0xZXV0gVlBMUyBpcyBidWls dCB3aXRoIHRoZSBtZWNoYW5pc20gdXRpbGl6aW5nIFAyUCBhbmQgUDJNUCBQVyBmb3INCj4+ZGVs aXZlcmluZyB0aGUgZnJhbWVzIHRvIHJlbW90ZSBQRXMuIFdlIHNob3VsZCB1dGlsaXplIHRoZW0g d2l0aCB0aGUNCj4+bWluaW1pemVkIGNoYW5nZXMuIER1YWwgVkxBTiBzb2x1dGlvbiBpcyBzaW1w bGVyIHRoYW4gRHVhbCBQVy4NCj4+DQo+PlJlZ2FyZHMsDQo+Pkx1Y3kNCj4+DQo+Pg0KPj5JIHNl ZSBob3cgMlZMQU4gaXMgc2ltcGxlciB3aGVuIFAyTVAgUFcncyBhcmUgaW52b2x2ZWQsIEkgdGhp bmsuICBJDQo+PmhhdmVuJ3QgaGFkIGFueSBmaXJzdCBoYW5kIGV4cGVyaWVuY2Ugd2l0aCBQMk1Q IFBXJ3MsIGhvd2V2ZXIsIHNvIGRvbid0DQo+PmZlZWwgdGVycmlibHkgc3Ryb25nIGFib3V0IHRo aXMgb2JqZWN0aW9uLiAgSXMgdGhpcyBhIHJlYWwgcHJvYmxlbSBmb3INCj4+b3RoZXJzIChub3cg b3IgaW4gdGhlIGZ1dHVyZSksIG9yIGlzIHRoaXMgb2JqZWN0aW9uIGluIHRoZSB3ZWVkcz8NCj4+ DQo+PkknbSBub3Qgc3VyZSB0aGUgJ2FkZGl0aW9uYWwgY29tcGxleGl0eScgaXMgbm90YWJsZSwg b3IgZXZlbiByZWxldmFudC4gIEkNCj4+ZW5jb3VyYWdlIG90aGVycyB0byBzcGVhayB1cCBpZiB0 aGV5IGRpc2FncmVlLCBhcyBQMk1QIFBXIGlzIG9ubHkNCj4+Y29uY2VwdHVhbCB0byBtZSwgYW5k IEkgYW0gdW5mYW1pbGlhciB3aXRoIHJlYWwtbGlmZSB1c2UgY2FzZXMgZm9yIGl0Lg0KPj4NCj4+ VGhhbmtzLA0KPj5Kb3NoDQo+Pg0KPj4NCj4+DQo+Pk9uIDQvMTgvMTIgMTA6MzAgQU0sICJMdWN5 IHlvbmciIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+ PiB3cm90ZToNCj4+DQo+Pj5QbGVhc2Ugc2VlIGlubGluZS4NCj4+Pg0KPj4+LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IFNhbSBDYW8gW21haWx0bzp5dXF1bi5jYW9AZ21haWwu Y29tPG1haWx0bzp5dXF1bi5jYW9AZ21haWwuY29tPl0NCj4+PlNlbnQ6IFR1ZXNkYXksIEFwcmls IDE3LCAyMDEyIDc6MTQgQU0NCj4+PlRvOiAnRGFuaWVsIENvaG4nOyBMdWN5IHlvbmc7ICdSb2dl cnMsIEpvc2gnOyAnSGVuZGVyaWNreCwgV2ltIChXaW0pJzsNCj4+PmdpbGVzLmhlcm9uQGdtYWls LmNvbTxtYWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tPjsgc2ltb24uZGVsb3JkQGdtYWlsLmNv bTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT47DQo+Pj5BbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQo+ Pj5DYzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPjsgVmxhZGltaXIuS2xl aW5lckBlY2l0ZWxlLmNvbTxtYWlsdG86VmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbT47DQo+ Pj5BbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3LlNlcmdlZXZAZWNpdGVs ZS5jb20+OyBJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbTxtYWlsdG86SWRhbi5LYXNwaXRAZWNpdGVs ZS5jb20+Ow0KPj4+TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb208bWFpbHRvOk1pc2hhZWwuV2V4 bGVyQGVjaXRlbGUuY29tPjsgUm90ZW0uQ29oZW5AZWNpdGVsZS5jb208bWFpbHRvOlJvdGVtLkNv aGVuQGVjaXRlbGUuY29tPg0KPj4+U3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJv YWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4+Pg0KPj4+WWVzLCAyIHB3cyBhcmUgb25s eSBuZWVkZWQgYmV0d2VlbiBwZXMgd2l0aCBib3RoIHJvb3QgYW5kIGxlYWYgYWNzIGFmdGVyDQo+ Pj5pbXByb3ZpbmcgRHVhbC1QVyBhcHByb2FjaC4gSWYgY29uc2lkZXIgUDJNUCwgRHVhbC1QVyBh cHByb2FjaCBzZXR1cCAyDQo+Pj5QMk1QDQo+Pj5QV3MgaWYgbmVlZC4gVGhlcmUgaXMgbm8gZGlm ZmVyZW5jZSBiZXR3ZWVuIFAyTVAgb3Igbm9ybWFsIFBXIHNldHVwLiBCdXQsDQo+Pj5jYW4gTGVh Zi1BQ3MgYmUgYm91bmQgdG8gUm9vdCBQRSBvZiBQMk1QIFBXPw0KPj4+DQo+Pj5bW0xZXV0gTm8s IGl0IG1ha2VzIGNvbXBsZXggaW4gc2V0dGluZyB1cCBQMk1QIFBXLiBTaG91bGQgYSBQRSB3aXRo IGJvdGgNCj4+PnJvb3QgYW5kIGxlYWYgQUNzIHNldCB1cCB0d28gb3Igb25lIFAyTVAgUFcgdG8g b3RoZXIgUEVzIChzb21lIFBFIGhhdmUNCj4+PmJvdGggcm9vdCBhbmQgbGVhZiBBQyBhbmQgc29t ZSBvbmx5IGhhdmUgbGVhZiBBQ3MpPw0KPj4+UmVnYXJkcywNCj4+Pkx1Y3kNCj4+Pg0KPj4+UmVn YXJkcywNCj4+Pg0KPj4+WXVxdW4gKFNhbSkgQ2FvDQo+Pj5FLW1haWw6IFl1cXVuLmNhb0BnbWFp bC5jb208bWFpbHRvOll1cXVuLmNhb0BnbWFpbC5jb20+DQo+Pj4NCj4+Pg0KPj4+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IERhbmllbCBDb2huIFttYWlsdG86RGFuaWVsQ0Bv cmNraXQuY29tPG1haWx0bzpEYW5pZWxDQG9yY2tpdC5jb20+XQ0KPj4+U2VudDogVHVlc2RheSwg QXByaWwgMTcsIDIwMTIgNDo1NiBQTQ0KPj4+VG86IEx1Y3kgeW9uZzsgUm9nZXJzLCBKb3NoOyBI ZW5kZXJpY2t4LCBXaW0gKFdpbSk7DQo+Pj5naWxlcy5oZXJvbkBnbWFpbC5jb208bWFpbHRvOmdp bGVzLmhlcm9uQGdtYWlsLmNvbT47DQo+Pj5zaW1vbi5kZWxvcmRAZ21haWwuY29tPG1haWx0bzpz aW1vbi5kZWxvcmRAZ21haWwuY29tPjsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208 bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPjsgU2FtIENhbw0KPj4+Q2M6 IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz47IFZsYWRpbWlyLktsZWluZXJA ZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb20+Ow0KPj4+QW5k cmV3LlNlcmdlZXZAZWNpdGVsZS5jb208bWFpbHRvOkFuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29t PjsgSWRhbi5LYXNwaXRAZWNpdGVsZS5jb208bWFpbHRvOklkYW4uS2FzcGl0QGVjaXRlbGUuY29t PjsNCj4+Pk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPG1haWx0bzpNaXNoYWVsLldleGxlckBl Y2l0ZWxlLmNvbT47IFJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPG1haWx0bzpSb3RlbS5Db2hlbkBl Y2l0ZWxlLmNvbT4NCj4+PlN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVz IHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4NCj4+PkFkZGluZyBTYW0gKGFzIGwydnBuQCBp cyBob2xkaW5nIG1lc3NhZ2VzKQ0KPj4+DQo+Pj5EQw0KPj4+DQo+Pj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4+RnJvbTogTHVjeSB5b25nIFttYWlsdG86bHVjeS55b25nQGh1YXdlaS5j b208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPl0NCj4+PlNlbnQ6IFR1ZXNkYXksIEFwcmls IDE3LCAyMDEyIDEyOjM5IEFNDQo+Pj5UbzogRGFuaWVsIENvaG47IFJvZ2VycywgSm9zaDsgSGVu ZGVyaWNreCwgV2ltIChXaW0pOw0KPj4+Z2lsZXMuaGVyb25AZ21haWwuY29tPG1haWx0bzpnaWxl cy5oZXJvbkBnbWFpbC5jb20+OyBzaW1vbi5kZWxvcmRAZ21haWwuY29tPG1haWx0bzpzaW1vbi5k ZWxvcmRAZ21haWwuY29tPjsNCj4+PkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1h aWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4NCj4+PkNjOiBsMnZwbkBpZXRm Lm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29t PG1haWx0bzpWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPjsNCj4+PkFuZHJldy5TZXJnZWV2 QGVjaXRlbGUuY29tPG1haWx0bzpBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbT47IElkYW4uS2Fz cGl0QGVjaXRlbGUuY29tPG1haWx0bzpJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbT47DQo+Pj5NaXNo YWVsLldleGxlckBlY2l0ZWxlLmNvbTxtYWlsdG86TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb20+ OyBSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbTxtYWlsdG86Um90ZW0uQ29oZW5AZWNpdGVsZS5jb20+ DQo+Pj5TdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1U cmVlIHNvbHV0aW9uPw0KPj4+DQo+Pj4NCj4+PlNuaXBwZWQsDQo+Pj4NCj4+PkFzIHdlIGRpc2N1 c3NlZCBleHRlbnNpdmVseSBpbiB0aGUgbGlzdCwgYW5kIGFzIHJlZmxlY3RlZCBpbiBnaWxlcw0K Pj4+c2xpZGUsIDIgcHdzIGFyZSBvbmx5IG5lZWRlZCBiZXR3ZWVuIHBlcyB3aXRoIGJvdGggcm9v dCBhbmQgbGVhZiBhY3MsDQo+Pj53aGljaCB3aWxsIHR5cGljYWxseSBiZSBhIHNtYWxsIG1pbm9y aXR5Lg0KPj4+W1tMWV1dIERvbid0IGtub3cgaWYgdGhlIGFzc3VtcHRpb24gaXMgdHJ1ZS4gRXZl biBpdCBpcyB0aGUgY2FzZSwgYm90aA0KPj4+YXBwcm9hY2hlcyBjYW4gYmVuZWZpdCBmcm9tIGl0 LiBJIHdhcyBvZmYgZm9yIGEgd2hpbGUgYW5kIGNhcHR1cmVzIHNvbWUNCj4+PmRpc2N1c3Npb25z IG5vdy4NCj4+Pg0KPj4+QWxzbyBhcyBwZXIgZ2lsZXMgc2xpZGUsIGR1YWwgdmxhbiBjYW4gaGF2 ZSBzY2FsYWJpbGl0eSBpc3N1ZXMgZHVlIHRvDQo+Pj5hZGRpdGlvbmFsIGxvb2t1cCBhbmQgZG91 YmxlIHVzZSBvZiB2bGFucyBpbiBpbnRlcm5hbCBlbXVsYXRlZCBsYW4NCj4+PmludGVyZmFjZS4g QWxzbyB0aGVyZSBhcmUgcG90ZW50aWFsIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXNzdWVzIHdp dGgNCj4+PnNpbGljb24gdGhhdCBkb2Vzbid0IHN1cHBvcnQgdmxhbiBtYXBwaW5nLg0KPj4+W1tM WV1dIEkgd2FzIG5vdCBpbiBJRVRGODMgbWVldGluZyBhbmQgd2FpdCBvbiB0aGUgbWVldGluZyBt aW51dGVzLiBJIGFtDQo+Pj5ub3QgY2xlYXIgb24gYWxsIHRoZSBpc3N1ZXMuIENvdWxkIHlvdSBi ZSBtb3JlIHNwZWNpZmljPyBBcyBJIG1lbnRpb25lZA0KPj4+aW4gYmVsb3csIHR3byBQVyBhcHBy b2FjaCBtYWtlcyBWUExTIHRyYW5zcG9ydCBjb25zdHJ1Y3Rpb24gYW5kIHBhY2tldA0KPj4+Zm9y d2FyZGluZyBtb3JlIGNvbXBsZXgsIEkgY2FuIHNlZSBwb3RlbnRpYWwgYmFja3dhcmQgY29tcGF0 aWJpbGl0eQ0KPj4+aXNzdWVzIHdpdGggMiBQVyBzb2x1dGlvbi4NCj4+Pg0KPj4+UmVnYXJkcywN Cj4+Pkx1Y3kNCj4+Pg0KPj4+UmVnYXJkcywNCj4+Pg0KPj4+RGFuaWVsDQo+Pj4NCj4+PlRodW1i IHR5cGVkIC0gcGxlYXNlIGJlIHRvbGVyYW50DQo+Pj4NCj4+Pkx1Y3kgeW9uZyA8bHVjeS55b25n QGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+Pj4NCj4+ PkluIG15IG1pbmQsIHRoZSBWTEFOIGFwcHJvYWNoIG1lYW5zIGR1YWwgdmxhbiBtZXRob2QuDQo+ Pj4NCj4+PlRoZSBtYWluIGNvbmNlcm4gZm9yIENXIGFwcHJvYWNoIGlzIGhhcmR3YXJlIHN1cHBv cnQuDQo+Pj4NCj4+PlR3byBQVyBhcHByb2FjaCBjYW4gYmUgY29tcGxleCB0b28gaWYgdGhlIFZQ TFMgaW5zdGFuY2UgZm9yIEUtVHJlZSB1c2VzDQo+Pj5QMlAgUFcgZm9yIHVuaWNhc3QgdHJhZmZp YyBhbmQgUDJNUCBQVyBmb3IgYnJvYWRjYXN0IGFuZCB1bmtub3duIHVuaWNhc3QNCj4+PnRyYWZm aWMsIGFuZCBzb21lIFAyTVAgUFdzIGZvciBtdWx0aWNhc3QgdHJhZmZpYy4gSXQgbWF5IGRvdWJs ZSBhbGwgb2YNCj4+PnRoZW0uDQo+Pj4NCj4+PkUtdHJlZSBpcyBhbiBFdGhlcm5ldCBzZXJ2aWNl IGFuZCB0aGVyZSBpcyBhbHJlYWR5IFZMQU4gYmFzZWQgc29sdXRpb24NCj4+PmluIElFRUUsIGNh biB3ZSBqdXN0IHV0aWxpemUgaXQgd2l0aG91dCBjb21wbGljYXRpbmcgVlBMUyB0cmFuc3BvcnQN Cj4+PmNvbnN0cnVjdGlvbj8gVGhpcyBhbHNvIG1ha2VzIGludGVyd29ya2luZyB3aXRoIEV0aCBv bmx5IG5ldHdvcmsgZWFzaWVyLg0KPj4+DQo+Pj5DaGVlcnMsDQo+Pj5MdWN5DQo+Pj4NCj4+Pi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBSb2dlcnMsIEpvc2ggW21haWx0bzpq b3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbTxtYWlsdG86am9zaC5yb2dlcnNAdHdjYWJsZS5jb20+XQ0K Pj4+U2VudDogTW9uZGF5LCBBcHJpbCAxNiwgMjAxMiA4OjM1IEFNDQo+Pj5UbzogTHVjeSB5b25n OyBIZW5kZXJpY2t4LCBXaW0gKFdpbSk7ICdnaWxlcy5oZXJvbkBnbWFpbC5jb208bWFpbHRvOmdp bGVzLmhlcm9uQGdtYWlsLmNvbT4nOw0KPj4+J3NpbW9uLmRlbG9yZEBnbWFpbC5jb208bWFpbHRv OnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+JzsgJ0FsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUu Y29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4nDQo+Pj5DYzogJ2wy dnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4nOyAnVmxhZGltaXIuS2xlaW5lckBl Y2l0ZWxlLmNvbTxtYWlsdG86VmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbT4nOw0KPj4+J0Fu ZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPG1haWx0bzpBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNv bT4nOyAnSWRhbi5LYXNwaXRAZWNpdGVsZS5jb208bWFpbHRvOklkYW4uS2FzcGl0QGVjaXRlbGUu Y29tPic7DQo+Pj4nTWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb208bWFpbHRvOk1pc2hhZWwuV2V4 bGVyQGVjaXRlbGUuY29tPic7ICdSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbTxtYWlsdG86Um90ZW0u Q29oZW5AZWNpdGVsZS5jb20+Jw0KPj4+U3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFw cHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4+Pg0KPj4+SSBiZWxpZXZlIHRoZSBp bml0aWFsIHF1ZXN0aW9uIHdhcyBpbiByZWdhcmQgdG8gdGhlIENXIG1ldGhvZC4gIEFyZSB5b3UN Cj4+PnNheWluZyB0aGF0IHlvdSBubyBsb25nZXIgYXJlIGludGVyZXN0ZWQgaW4gdGhhdCBtZXRo b2QgaW4gcHJlZmVyZW5jZSBvZg0KPj4+dGhlIGR1YWwgdmxhbiBtZXRob2Q/DQo+Pj4NCj4+Pg0K Pj4+DQo+Pj5MdWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdA aHVhd2VpLmNvbT4+IHdyb3RlOg0KPj4+DQo+Pj4NCj4+PkFncmVlIHdpdGggV2ltLiBWTEFOIGFw cHJvYWNoIGlzIHRoZSBiZXN0IHNvbHV0aW9uIGZvciBFLVRyZWUuDQo+Pj4NCj4+Pkx1Y3kNCj4+ Pg0KPj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IGwydnBuLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bDJ2cG4tYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZg0K Pj4+T2YgSGVuZGVyaWNreCwgV2ltIChXaW0pDQo+Pj5TZW50OiBUaHVyc2RheSwgQXByaWwgMTIs IDIwMTIgMjowMyBBTQ0KPj4+VG86ICdnaWxlcy5oZXJvbkBnbWFpbC5jb208bWFpbHRvOmdpbGVz Lmhlcm9uQGdtYWlsLmNvbT4nOyAnc2ltb24uZGVsb3JkQGdtYWlsLmNvbTxtYWlsdG86c2ltb24u ZGVsb3JkQGdtYWlsLmNvbT4nOw0KPj4+J0FsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29t PG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4nDQo+Pj5DYzogJ2wydnBu QGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4nOyAnVmxhZGltaXIuS2xlaW5lckBlY2l0 ZWxlLmNvbTxtYWlsdG86VmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbT4nOw0KPj4+J0FuZHJl dy5TZXJnZWV2QGVjaXRlbGUuY29tPG1haWx0bzpBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbT4n OyAnSWRhbi5LYXNwaXRAZWNpdGVsZS5jb208bWFpbHRvOklkYW4uS2FzcGl0QGVjaXRlbGUuY29t Pic7DQo+Pj4nTWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb208bWFpbHRvOk1pc2hhZWwuV2V4bGVy QGVjaXRlbGUuY29tPic7ICdSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbTxtYWlsdG86Um90ZW0uQ29o ZW5AZWNpdGVsZS5jb20+Jw0KPj4+U3ViamVjdDogUmU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJv YWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4+Pg0KPj4+VGhlIHZsYW4gYXBwcm9hY2gg aXMgc3VwZXJpb3IgYXMgaXQgYWxzbyB3b3JrcyBmb3IgZXRoIG9ubHkgbmV0d29ya3MsDQo+Pj5l dGMuIE9uIHRvcCBzb21lIHZlbmRvcnMgaW5kaWNhdGUgaHcgaXNzdWVzIHdpdGggdGhlIGN3IGFw cHJvYWNoLiBBcw0KPj4+c3VjaCB3ZSBoYXZlIGRyb3BwZWQgbW9yZSBvciBsZXNzIHRoZSBjdyBh cHByb2FjaC4NCj4+Pg0KPj4+Q2hlZXJzLA0KPj4+V2ltDQo+Pj5fX19fX19fX19fX19fX19fXw0K Pj4+c2VudCBmcm9tIGJsYWNrYmVycnkNCj4+Pg0KPj4+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLQ0KPj4+RnJvbTogR2lsZXMgSGVyb24gW21haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb208 bWFpbHRvOmdpbGVzLmhlcm9uQGdtYWlsLmNvbT5dDQo+Pj5TZW50OiBUaHVyc2RheSwgQXByaWwg MTIsIDIwMTIgMDg6MjIgQU0NCj4+PlRvOiBTaW1vbiBEZWxvcmQgPHNpbW9uLmRlbG9yZEBnbWFp bC5jb208bWFpbHRvOnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+PjsgQWxleGFuZGVyIFZhaW5zaHRl aW4NCj4+PjxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVy LlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+Pg0KPj4+Q2M6IGwydnBuQGlldGYub3JnPG1haWx0bzps MnZwbkBpZXRmLm9yZz4gPGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4+OyBW bGFkaW1pciBLbGVpbmVyDQo+Pj48VmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbTxtYWlsdG86 VmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbT4+OyBBbmRyZXcgU2VyZ2Vldg0KPj4+PEFuZHJl dy5TZXJnZWV2QGVjaXRlbGUuY29tPG1haWx0bzpBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbT4+ OyBJZGFuIEthc3BpdCA8SWRhbi5LYXNwaXRAZWNpdGVsZS5jb208bWFpbHRvOklkYW4uS2FzcGl0 QGVjaXRlbGUuY29tPj47DQo+Pj5NaXNoYWVsIFdleGxlciA8TWlzaGFlbC5XZXhsZXJAZWNpdGVs ZS5jb208bWFpbHRvOk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPj47IFJvdGVtIENvaGVuDQo+ Pj48Um90ZW0uQ29oZW5AZWNpdGVsZS5jb208bWFpbHRvOlJvdGVtLkNvaGVuQGVjaXRlbGUuY29t Pj4NCj4+PlN1YmplY3Q6IFJlOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBF LVRyZWUgc29sdXRpb24/DQo+Pj4NCj4+PlNvcnJ5IC0gdGhlICJhbm9ueW1vdXMgcHJlc2VudGF0 aW9uIiB3YXMgbWluZS4gIEkgc2hvdWxkIHBvc3NpYmx5IGhhdmUNCj4+PnB1dCBpbiBhIHRoaXJk IGNvbHVtbiBvbiB0aGUgQ1cgYXBwcm9hY2guICBBbmQgaG9wZWZ1bGx5IHRoZSBtaW51dGVzDQo+ Pj53aWxsIGJlIHBvc3RlZCBzb29uLg0KPj4+DQo+Pj5XZSBoYWQgdmFyaW91cyBkaXNjdXNzaW9u cywgYXMgU2ltb24gc3RhdGVkLCBhbmQgY29uc2Vuc3VzIHNlZW1lZCB0byBiZQ0KPj4+Zm9ybWlu ZyBhcm91bmQgdGhlIHR3byBhbHRlcm5hdGl2ZXMgb2YgdHdvIFBXRXMgb3IgdHdvIFZMQU5zLiAg SSBiZWxpZXZlDQo+Pj50aHJlZSBvZiB0aGUgYXV0aG9ycyBvZiB0aGUgQ1cgYXBwcm9hY2ggYXJl IGFsc28gYXV0aG9ycyBvZiB0aGUgdHdvIFZMQU4NCj4+PmFwcHJvYWNoIGFuZCBvbmUgaXMgYWxz byBhbiBhdXRob3Igb2YgdGhlIHR3byBQV0UgYXBwcm9hY2guIFNvIHBlcmhhcHMNCj4+Pml0J3Mg YmVzdCB0byBsZXQgdGhvc2UgZm91ciBpbmRpdmlkdWFscyBzYXkgd2hpY2ggYXBwcm9hY2ggdGhl eSBwcmVmZXINCj4+PmFuZCB3aHk/DQo+Pj4NCj4+PkdpbGVzDQo+Pj4NCj4+Pk9uIDEwLzA0LzIw MTIgMDA6NDUsICJTaW1vbiBEZWxvcmQiIDxzaW1vbi5kZWxvcmRAZ21haWwuY29tPG1haWx0bzpz aW1vbi5kZWxvcmRAZ21haWwuY29tPj4gd3JvdGU6DQo+Pj4NCj4+Pj4gSGkgQWxleGFuZGVyLA0K Pj4+Pg0KPj4+PiBZb3UgYXJlIHJpZ2h0LCBubyBkaXNjdXNzaW9uIG9uIHRoZSBXRyBtYWlsaW5n IGxpc3QgcmVjZW50bHksIGJ1dA0KPj4+PiB0aGVyZSBoYXZlIGJlZW4gc3Vic3RhbnRpYWwgZGlz Y3Vzc2lvbnMgYW1vbmcgdGhlIGF1dGhvcnMgb2YgdmFyaW91cw0KPj4+PiBzb2x1dGlvbiBkcmFm dHMgb2ZmIHRoZSBtYWlsaW5nIGxpc3QuIEFzIGZhciBhcyBJIGtub3csIG5vIGNvbnNlbnN1cw0K Pj4+PiB5ZXQgYmVmb3JlIGlldGY4Mywgbm90IHN1cmUgdGhlIHByb2dyZXNzIGluIHRoZSBQYXJp cyBXRyBtZWV0aW5nLiBJDQo+Pj4+IHRoaW5rIHRoZSBDVyBhcHByb2FjaCBoYXMgbm90IGJlZW4g cmVqZWN0ZWQgYnkgdGhlIFdHIHlldCwgb3IgdGhlIFdHDQo+Pj4+IGhhcyBub3QgeWV0IGRlY2lk ZWQgb24gd2hpY2ggb25lIHRvIGFkb3B0Lg0KPj4+Pg0KPj4+PiBTaW1vbg0KPj4+Pg0KPj4+PiAy MDEyLzQvOCBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVs ZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPj4NCj4+Pj4NCj4+ Pj4+ICBIaSBhbGwsDQo+Pj4+Pg0KPj4+Pj4gVW5mb3J0dW5hdGVseSBJIGhhdmUgbm90IGJlZW4g YWJsZSB0byBhdHRlbmQgdGhlIFBhcmlzIElFVEYuDQo+Pj4+Pg0KPj4+Pj4gSG93ZXZlciwgbG9v a2luZyB1cCB0aGUgTDJWUE4gcHJvY2VlZGluZ3MsIEkndmUgZm91bmQgYSBzaG9ydA0KPj4+Pj4g YW5vbnltb3VzIHByZXNlbnRhdGlvbiBjYWxsZWQgIkUtVHJlZSBVcGRhdGUiICAoDQo+Pj4+PiBo dHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzgzL3NsaWRlcy9zbGlkZXMtODMtbDJ2cG4t MS5wcHR4KS4NCj4+Pj4+IFRoaXMgcHJlc2VudGF0aW9uIGRpc2N1c3NlcyB0aGUgZGlmZmVyZW5j ZXMgb2YgdGhlIEUtVHJlZSBhcHByb2FjaGVzDQo+Pj4+PiBiYXNlZCBvbiBkZWRpY2F0ZWQgVkxB TnMgKGFzIGluDQo+Pj4+PiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNh by1sMnZwbi12cGxzLWV0cmVlLz9pbmNsdWRlX3QNCj4+Pj4+IGV4dD0xKSBhbmQgbXVsdGlwbGUg UFdzIGJldHdlZW4gdGhlIFBFcyAoYXMgaW4NCj4+Pj4+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtcmFtLWwydnBuLWV0cmVlLW11bHRpcGxlLXB3Lz9pbg0KPj4+Pj4gY2x1 ZGVfdGUNCj4+Pj4+IHh0PTEpDQo+Pj4+PiBhbmQgY29tcGxldGVseSBpZ25vcmVzIHRoZSBzb2x1 dGlvbiBiYXNlZCBvbiB1c2FnZSBvZiB0aGUgQ1cgaW4gdGhlDQo+Pj4+PiBQV3MgY29ubmVjdGlu ZyB0aGUgUEVzIChhcyBpbg0KPj4+Pj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1rZXktbDJ2cG4tdnBscy1ldHJlZS8/aW5jbHVkZV90DQo+Pj4+PiBleHQ9MQ0KPj4+Pj4g KS4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFRoZSBNaW51dGVzIG9mIHRoZSBQYXJpcyBM MlZQTiBzZXNzaW9uIGFyZSBub3QgeWV0IGF2YWlsYWJsZSwgYnV0IEkNCj4+Pj4+IHdvbmRlciB3 aGV0aGVyIHRoZSBXRyBoYXMgdGFrZW4gYSBkZWNpc2lvbiB0byByZWplY3QgdGhlIGFwcHJvYWNo DQo+Pj4+PiBiYXNlZCBvbiB0aGUgQ1cgdXNhZ2U/IEkgZG8gbm90IHJlbWVtYmVyIGFueSByZWNl bnQgZGlzY3Vzc2lvbiBvZg0KPj4+Pj4gdGhpcyB0b3BpYyBvbiB0aGUgV0cgbWFpbGluZyBsaXN0 Lg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gUmVnYXJkcywgYW5kIGxvdHMgb2YgdGhhbmtz IGluIGFkdmFuY2UsDQo+Pj4+Pg0KPj4+Pj4gU2FzaGENCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+ Pj4+DQo+Pj4+Pg0KPj4+Pj4gVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhl IHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucw0KPj4+Pj4gaW5mb3JtYXRpb24gd2hpY2ggaXMg Q09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJDQo+Pj4NCj4+ Pj4+IFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVy cm9yLCBwbGVhc2UNCj4+Pj4+IGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5k IHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQNCj4+Pj4+IGFsbCBjb3BpZXMgdGhlcmVvZi4N Cj4+Pj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+VGhpcyBFLW1haWwgYW5kIGFueSBv ZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUNCj4+PnByb3By aWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9y IHN1YmplY3QNCj4+PnRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUu IFRoaXMgRS1tYWlsIGlzIGludGVuZGVkDQo+Pj5zb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4NCj4+PklmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVy ZWJ5DQo+Pj5ub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNv cHlpbmcsIG9yIGFjdGlvbiB0YWtlbg0KPj4+aW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9m IGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcw0KPj4+c3RyaWN0bHkgcHJvaGliaXRl ZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzDQo+Pj5FLW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVy bWFuZW50bHkNCj4+PmRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1t YWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo+Pj4NCj4+DQo+Pg0KPj5UaGlzIEUtbWFpbCBhbmQgYW55 IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZQ0KPj5wcm9w cmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBv ciBzdWJqZWN0IHRvDQo+PmNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUu IFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseQ0KPj5mb3IgdGhlIHVzZSBvZiB0aGUgaW5k aXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UNCj4+YXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVi eSBub3RpZmllZA0KPj50aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlp bmcsIG9yIGFjdGlvbiB0YWtlbiBpbg0KPj5yZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5k IGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5DQo+PnByb2hpYml0ZWQgYW5k IG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4NCj4+ ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50 bHkgZGVsZXRlIHRoZQ0KPj5vcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5k IGFueSBwcmludG91dC4NCj4NCj4NCj4gVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRp b24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5 cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRl bmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdo aWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2Vt aW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRp b24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBz dHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9m IHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo+IFRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMg aW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24g d2hpY2ggaXMgQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJ IFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9y LCBwbGVhc2UgaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxl dGUgdGhlIG9yaWdpbmFsIGFuZCBhbGwgY29waWVzIHRoZXJlb2YuDQo+DQo+DQo+DQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBMMnZwbiBtYWlsaW5nIGxpc3QNCj4gTDJ2cG5AaWV0 Zi5vcmc8bWFpbHRvOkwydnBuQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2wydnBuDQo+DQo+DQo+IEVuZCBvZiBMMnZwbiBEaWdlc3QsIFZvbCA5NSwg SXNzdWUgMjUNCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg== From david.i.allan@ericsson.com Tue Apr 24 10:01:05 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE1C21F8755 for ; Tue, 24 Apr 2012 10:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 LUC1NB38c0ME for ; Tue, 24 Apr 2012 10:01:03 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id F364321F8709 for ; Tue, 24 Apr 2012 10:01:02 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3OH0iGR020250; Tue, 24 Apr 2012 12:00:51 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.69]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 24 Apr 2012 13:00:43 -0400 From: David Allan I To: Daniel Cohn , "Hernandez-Valencia, Enrique (Enrique)" , "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , Lucy yong , "Rogers, Josh" , Shahram Davari , Lizhong Jin , "l2vpn@ietf.org" , "Alexander.Vainshtein@ecitele.com" Date: Tue, 24 Apr 2012 13:00:41 -0400 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IAAHuPxAAACKFwAACIeb8AADgRjpAAADhdA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD523223561F@EUSAACMS0703.eamcs.ericsson.se> References: <169401cd223b$cc9400ea$05280101@corrigent.com> In-Reply-To: <169401cd223b$cc9400ea$05280101@corrigent.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 24 Apr 2012 10:12:32 -0700 Cc: "yuqun.cao@gmail.com" X-BeenThere: l2vpn@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, 24 Apr 2012 17:01:05 -0000 Why do you think there is ever only one S-VLAN....? Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Tuesday, April 24, 2012 12:58 PM To: Hernandez-Valencia, Enrique (Enrique); Sprecher, Nurit (NSN - IL/Hod Ha= Sharon); Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.o= rg; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? I don't know what kind of translation you propose but I don't see how you c= an preserve the original s-vlan id plus root/leaf in the same number of bit= s Thumb typed - please be tolerant "Hernandez-Valencia, Enrique (Enrique)" wrote: VLAN-ID preservation does not necessarily require a third VLAN-ID. VLAN-ID = translation is sufficient. Enrique -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Tuesday, April 24, 2012 7:17 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Lucy yong; Rogers, Josh; Shahr= am Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? No, the other way round. In the 2-VLAN solution, S-VLAN ID preservation req= uires adding a third VLAN ID. In the multi-PW solution, this is not require= d. DC -----Original Message----- From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.co= m] Sent: Tuesday, April 24, 2012 2:02 PM To: Daniel Cohn; Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vp= n@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Daniel, Is it so that you consider S-VAL stacking? If this is the case, are you aware that this is not in-line with the IEEE s= pecifications? Best regard, Nurit -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of e= xt Daniel Cohn Sent: Tuesday, April 24, 2012 10:12 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, even if the current MEF framework doesn't require s-vlan preservation, I be= lieve it's to the industry's benefit to adopt a solution that is not constr= ained to a specific enni model that, like all things networking, is likely = to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service provider= s' inputs. It had a fair reason to assume S-VLAN over ENNI by then. It may = open B-VLAN for the future. It is better for us not to discuss a future fr= amework here, because it will lead us to nowhere. Here, we want to extend V= PLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Va= inshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume tha= t the VLAN tags at the E-NNI will always be according to the current MEF mo= del? Or should we try to be as transparent as possible to user VLAN encapsu= lation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case VLAN t= ag) to signal VPLS information (in this case root/leaf origin) is necessari= ly tied to specific assumptions on user payload encapsulation (in this case= , that S-VLAN tag is "available" to encode root/leaf). I don't think this i= s a future-proof assumption, it's very likely that other network models wil= l come up that require S-VLAN preservation, which in the 2-VLAN approach wo= uld necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, "l2vpn@i= etf.org" >, "A= lexander.Vainshtein@ecitele.com" <= Alexander.Vainshtein@ecitele.com> Cc: "yuqun.cao@gmail.com" > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic alrea= dy has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com= Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L i= nformation, customer payload or PW? The customer payload will be always mod= ified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is access= ed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informati= on? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > com>> > To: "Rogers, Josh" >, Lucy yong > >, Daniel Cohn <= DanielC@orckit.com>, Sam Cao > > > Cc: "l2vpn@ietf.org" > > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, = but: > > IMO one of the advantages of the CW-based solution is that it is orthogon= al to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffi= c. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and,= in a more generic way, localization of effects of changes in the PE config= uration. > > In particular, adding a Leaf AC to a PE that previously has been only sup= porting Root ACs (or vice versa), removal of the last Leaf or last Root AC = from a PE that previously has been supporting a mix etc. affect only the PE= where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadva= ntage of the CW-based approach - I believe it strongly depends on specific = implementations. And some changes in the forwarding process are required in= any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org > [l2vpn-bounces@ietf.org] on behalf of > Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a > more complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become > more complex. > > Gile's comparison slide still concisely captures the differences > between these methods, in my opinion. I haven't seen any new ideas or > thoughts brought to the group in the past week or two on the subject. > I would hate for both proposed methods to die on the vine because we > couldn't decide between two methods that have nothing inherently wrong wi= th either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree >>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may >>double all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn >>[mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the >>processing in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >>PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW >>(for traffic coming from a root AC) [[LY]] Not that simple. You >>construct either two P2MP PWs to all other PEs and let egress PE >>performing filtering, or construct one P2MP PW to leaf-only PEs and >>two P2MP PWs to root and leaf PEs and let ingress PE perform >>forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so >>don't feel terribly strong about this objection. Is this a real >>problem for others (now or in the future), or is this objection in the we= eds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. >>I encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao >>>[mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>(Wim)'; giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>PE have both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn >>>[mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com>; Sam Cao >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong >>>[mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>both approaches can benefit from it. I was off for a while and >>>captures some discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues >>>with silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >>>am not clear on all the issues. Could you be more specific? As I >>>mentioned in below, two PW approach makes VPLS transport construction >>>and packet forwarding more complex, I can see potential backward >>>compatibility issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>double all of them. >>> >>>E-tree is an Ethernet service and there is already VLAN based >>>solution in IEEE, can we just utilize it without complicating VPLS >>>transport construction? This also makes interworking with Eth only netwo= rk easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh >>>[mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); >>>'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vain= shtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are >>>you saying that you no longer are interested in that method in >>>preference of the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org >>>[mailto:l2vpn-bounces@ietf.org] On >>>Behalf Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron >>>[mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord >>>>; Alexander >>>Vainshtein >>>>>.com>> >>>Cc: l2vpn@ietf.org >>>>; Vladimir Kleiner >>>>; >>>Andrew Sergeev >>>>; Idan >>>Kaspit >; >>>Mishael Wexler >>>>; >>>Rotem Cohen > >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly >>>have put in a third column on the CW approach. And hopefully the >>>minutes will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to >>>be forming around the two alternatives of two PWEs or two VLANs. I >>>believe three of the authors of the CW approach are also authors of >>>the two VLAN approach and one is also an author of the two PWE >>>approach. So perhaps it's best to let those four individuals say >>>which approach they prefer and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of >>>> various solution drafts off the mailing list. As far as I know, no >>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>> meeting. I think the CW approach has not been rejected by the WG >>>> yet, or the WG has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein >>>> >>> le.com>> >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree >>>>> approaches based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/ >>>>> ?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in >>>>> the PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>> I wonder whether the WG has taken a decision to reject the >>>>> approach based on the CW usage? I do not remember any recent >>>>> discussion of this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and >>>>> contains information which is CONFIDENTIAL and which may be >>>>> proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original >>>>> and all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or >>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>intended solely for the use of the individual or entity to which it is a= ddressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail >>>is strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is >>addressed. If you are not the intended recipient of this E-mail, you >>are hereby notified that any dissemination, distribution, copying, or >>action taken in relation to the contents of and attachments to this >>E-mail is strictly prohibited and may be unlawful. If you have >>received this E-mail in error, please notify the sender immediately >>and permanently delete the original and any copy of this E-mail and any p= rintout. > > > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** From davari@broadcom.com Tue Apr 24 10:03:32 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96DF521E809F for ; Tue, 24 Apr 2012 10:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 lCkJGP-P7-3S for ; Tue, 24 Apr 2012 10:03:30 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5F07F21E8086 for ; Tue, 24 Apr 2012 10:03:30 -0700 (PDT) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 24 Apr 2012 10:03:26 -0700 X-Server-Uuid: 72204117-5C29-4314-8910-60DB108979CB Received: from SJEXCHCAS02.corp.ad.broadcom.com (10.16.192.37) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Tue, 24 Apr 2012 10:03:19 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by sjexchcas02.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Tue, 24 Apr 2012 10:03:19 -0700 From: "Shahram Davari" To: "David Allan I" , "Daniel Cohn" , "Hernandez-Valencia, Enrique (Enrique)" , "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "Lucy yong" , "Rogers, Josh" , "Lizhong Jin" , "l2vpn@ietf.org" , "Alexander.Vainshtein@ecitele.com" Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWdjZLWcpAE0uaMYACV/K6GQBXtrWAADjtXEAAIMJ4IAAHuPxAAACKFwAACIeb8AADgRjpAA6p1oAADp2EAA== Date: Tue, 24 Apr 2012 17:03:18 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2802276F@SJEXCHMB12.corp.ad.broadcom.com> References: <169401cd223b$cc9400ea$05280101@corrigent.com> <60C093A41B5E45409A19D42CF7786DFD523223561F@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD523223561F@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.75.60] MIME-Version: 1.0 X-WSS-ID: 638803543IO9569743-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 24 Apr 2012 10:12:32 -0700 Cc: "yuqun.cao@gmail.com" X-BeenThere: l2vpn@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, 24 Apr 2012 17:03:32 -0000 Yes, That is also my question. The E-tree today (using PB or PBB) uses 2xVL= ANs, so I don't see the need for VLAN translation. Thx Shahram -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com]=20 Sent: Tuesday, April 24, 2012 10:01 AM To: Daniel Cohn; Hernandez-Valencia, Enrique (Enrique); Sprecher, Nurit (NS= N - IL/Hod HaSharon); Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin;= l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Why do you think there is ever only one S-VLAN....? Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Tuesday, April 24, 2012 12:58 PM To: Hernandez-Valencia, Enrique (Enrique); Sprecher, Nurit (NSN - IL/Hod Ha= Sharon); Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.o= rg; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? I don't know what kind of translation you propose but I don't see how you c= an preserve the original s-vlan id plus root/leaf in the same number of bit= s Thumb typed - please be tolerant "Hernandez-Valencia, Enrique (Enrique)" wrote: VLAN-ID preservation does not necessarily require a third VLAN-ID. VLAN-ID = translation is sufficient. Enrique -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Tuesday, April 24, 2012 7:17 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Lucy yong; Rogers, Josh; Shahr= am Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? No, the other way round. In the 2-VLAN solution, S-VLAN ID preservation req= uires adding a third VLAN ID. In the multi-PW solution, this is not require= d. DC -----Original Message----- From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.co= m] Sent: Tuesday, April 24, 2012 2:02 PM To: Daniel Cohn; Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vp= n@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Daniel, Is it so that you consider S-VAL stacking? If this is the case, are you aware that this is not in-line with the IEEE s= pecifications? Best regard, Nurit -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of e= xt Daniel Cohn Sent: Tuesday, April 24, 2012 10:12 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, even if the current MEF framework doesn't require s-vlan preservation, I be= lieve it's to the industry's benefit to adopt a solution that is not constr= ained to a specific enni model that, like all things networking, is likely = to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service provider= s' inputs. It had a fair reason to assume S-VLAN over ENNI by then. It may = open B-VLAN for the future. It is better for us not to discuss a future fr= amework here, because it will lead us to nowhere. Here, we want to extend V= PLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Va= inshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume tha= t the VLAN tags at the E-NNI will always be according to the current MEF mo= del? Or should we try to be as transparent as possible to user VLAN encapsu= lation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case VLAN t= ag) to signal VPLS information (in this case root/leaf origin) is necessari= ly tied to specific assumptions on user payload encapsulation (in this case= , that S-VLAN tag is "available" to encode root/leaf). I don't think this i= s a future-proof assumption, it's very likely that other network models wil= l come up that require S-VLAN preservation, which in the 2-VLAN approach wo= uld necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, "l2vpn@i= etf.org" >, "A= lexander.Vainshtein@ecitele.com" <= Alexander.Vainshtein@ecitele.com> Cc: "yuqun.cao@gmail.com" > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic alrea= dy has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com= Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L i= nformation, customer payload or PW? The customer payload will be always mod= ified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is access= ed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informati= on? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > com>> > To: "Rogers, Josh" >, Lucy yong > >, Daniel Cohn <= DanielC@orckit.com>, Sam Cao > > > Cc: "l2vpn@ietf.org" > > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, = but: > > IMO one of the advantages of the CW-based solution is that it is orthogon= al to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffi= c. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and,= in a more generic way, localization of effects of changes in the PE config= uration. > > In particular, adding a Leaf AC to a PE that previously has been only sup= porting Root ACs (or vice versa), removal of the last Leaf or last Root AC = from a PE that previously has been supporting a mix etc. affect only the PE= where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadva= ntage of the CW-based approach - I believe it strongly depends on specific = implementations. And some changes in the forwarding process are required in= any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org > [l2vpn-bounces@ietf.org] on behalf of > Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a > more complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become > more complex. > > Gile's comparison slide still concisely captures the differences > between these methods, in my opinion. I haven't seen any new ideas or > thoughts brought to the group in the past week or two on the subject. > I would hate for both proposed methods to die on the vine because we > couldn't decide between two methods that have nothing inherently wrong wi= th either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree >>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may >>double all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn >>[mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the >>processing in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >>PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW >>(for traffic coming from a root AC) [[LY]] Not that simple. You >>construct either two P2MP PWs to all other PEs and let egress PE >>performing filtering, or construct one P2MP PW to leaf-only PEs and >>two P2MP PWs to root and leaf PEs and let ingress PE perform >>forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so >>don't feel terribly strong about this objection. Is this a real >>problem for others (now or in the future), or is this objection in the we= eds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. >>I encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao >>>[mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>(Wim)'; giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>PE have both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn >>>[mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com>; Sam Cao >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong >>>[mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>both approaches can benefit from it. I was off for a while and >>>captures some discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues >>>with silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >>>am not clear on all the issues. Could you be more specific? As I >>>mentioned in below, two PW approach makes VPLS transport construction >>>and packet forwarding more complex, I can see potential backward >>>compatibility issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>double all of them. >>> >>>E-tree is an Ethernet service and there is already VLAN based >>>solution in IEEE, can we just utilize it without complicating VPLS >>>transport construction? This also makes interworking with Eth only netwo= rk easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh >>>[mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); >>>'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vain= shtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are >>>you saying that you no longer are interested in that method in >>>preference of the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org >>>[mailto:l2vpn-bounces@ietf.org] On >>>Behalf Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron >>>[mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord >>>>; Alexander >>>Vainshtein >>>>>.com>> >>>Cc: l2vpn@ietf.org >>>>; Vladimir Kleiner >>>>; >>>Andrew Sergeev >>>>; Idan >>>Kaspit >; >>>Mishael Wexler >>>>; >>>Rotem Cohen > >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly >>>have put in a third column on the CW approach. And hopefully the >>>minutes will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to >>>be forming around the two alternatives of two PWEs or two VLANs. I >>>believe three of the authors of the CW approach are also authors of >>>the two VLAN approach and one is also an author of the two PWE >>>approach. So perhaps it's best to let those four individuals say >>>which approach they prefer and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of >>>> various solution drafts off the mailing list. As far as I know, no >>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>> meeting. I think the CW approach has not been rejected by the WG >>>> yet, or the WG has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein >>>> >>> le.com>> >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree >>>>> approaches based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/ >>>>> ?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in >>>>> the PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>> I wonder whether the WG has taken a decision to reject the >>>>> approach based on the CW usage? I do not remember any recent >>>>> discussion of this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and >>>>> contains information which is CONFIDENTIAL and which may be >>>>> proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original >>>>> and all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or >>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>intended solely for the use of the individual or entity to which it is a= ddressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail >>>is strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is >>addressed. If you are not the intended recipient of this E-mail, you >>are hereby notified that any dissemination, distribution, copying, or >>action taken in relation to the contents of and attachments to this >>E-mail is strictly prohibited and may be unlawful. If you have >>received this E-mail in error, please notify the sender immediately >>and permanently delete the original and any copy of this E-mail and any p= rintout. > > > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** From DanielC@orckit.com Tue Apr 24 13:11:19 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2082A11E8080 for ; Tue, 24 Apr 2012 13:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.275 X-Spam-Level: ** X-Spam-Status: No, score=2.275 tagged_above=-999 required=5 tests=[AWL=-0.498, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, MIME_QP_LONG_LINE=1.396, RCVD_ILLEGAL_IP=1.908, RCVD_NUMERIC_HELO=2.067] 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 fHf3y9lEKB8K for ; Tue, 24 Apr 2012 13:11:17 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id AA2CB21F8616 for ; Tue, 24 Apr 2012 13:11:16 -0700 (PDT) Received: from 1.1.40.5 ([1.1.40.5]) by tlvmail1.corrigent.com ([1.1.40.5]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Apr 2012 20:13:23 +0000 Date: Tue, 24 Apr 2012 23:11:08 +0300 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <169e01cd2256$b31c5660$05280101@corrigent.com> Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IAAHuPxAAACKFwAACIeb8AADgRjpAAAAlvAABrkMXA== X-MimeOLE: Produced By Microsoft Exchange V6.5 Importance: normal From: "Daniel Cohn" To: "Fedyk, Donald (Don)" , "Hernandez-Valencia, Enrique (Enrique)" , MIME-Version: 1.0 Cc: yuqun.cao@gmail.com X-BeenThere: l2vpn@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, 24 Apr 2012 20:11:19 -0000 Preservation requires egress =3D ingress vid - how does the egress pe = know what the ingress vid was, if the ingress vid was swapped at ingress?=0A= =0A= Thumb typed - please be tolerant=0A= =0A= "Fedyk, Donald (Don)" wrote:=0A= =0A= Dan In an E-Tree Model you have logically one VLAN on ingress and one on = Egress. In the E-Tree you can use a Root or Leaf VID. (one or the = other.) So you have: ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. Ingress VID does not have to equal Egress VID but regardless there is = only ever one VID on a frame at a time. Don -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Daniel Cohn Sent: Tuesday, April 24, 2012 12:58 PM To: Hernandez-Valencia, Enrique (Enrique); Sprecher, Nurit (NSN - IL/Hod = HaSharon); Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; = l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? I don't know what kind of translation you propose but I don't see how = you can preserve the original s-vlan id plus root/leaf in the same = number of bits Thumb typed - please be tolerant "Hernandez-Valencia, Enrique (Enrique)" = wrote: VLAN-ID preservation does not necessarily require a third VLAN-ID. = VLAN-ID translation is sufficient. Enrique -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Daniel Cohn Sent: Tuesday, April 24, 2012 7:17 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Lucy yong; Rogers, Josh; = Shahram Davari; Lizhong Jin; l2vpn@ietf.org; = Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? No, the other way round. In the 2-VLAN solution, S-VLAN ID preservation = requires adding a third VLAN ID. In the multi-PW solution, this is not = required. DC -----Original Message----- From: Sprecher, Nurit (NSN - IL/Hod HaSharon) = [mailto:nurit.sprecher@nsn.com] Sent: Tuesday, April 24, 2012 2:02 PM To: Daniel Cohn; Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; = l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Daniel, Is it so that you consider S-VAL stacking? If this is the case, are you aware that this is not in-line with the = IEEE specifications? Best regard, Nurit -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of ext Daniel Cohn Sent: Tuesday, April 24, 2012 10:12 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; = l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, even if the current MEF framework doesn't require s-vlan preservation, I = believe it's to the industry's benefit to adopt a solution that is not = constrained to a specific enni model that, like all things networking, = is likely to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service = providers' inputs. It had a fair reason to assume S-VLAN over ENNI by = then. It may open B-VLAN for the future. It is better for us not to = discuss a future framework here, because it will lead us to nowhere. = Here, we want to extend VPLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Daniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; = Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume = that the VLAN tags at the E-NNI will always be according to the current = MEF model? Or should we try to be as transparent as possible to user = VLAN encapsulation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case = VLAN tag) to signal VPLS information (in this case root/leaf origin) is = necessarily tied to specific assumptions on user payload encapsulation = (in this case, that S-VLAN tag is "available" to encode root/leaf). I = don't think this is a future-proof assumption, it's very likely that = other network models will come up that require S-VLAN preservation, = which in the 2-VLAN approach would necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, = "l2vpn@ietf.org" = >, = "Alexander.Vainshtein@ecitele.com" = > Cc: "yuqun.cao@gmail.com" = > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic = already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; = Alexander.Vainshtein@ecitele.com= Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the = R/L information, customer payload or PW? The customer payload will be = always modified to carry R/L information in 2-VLAN approach, while PW = with CW will carry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is = accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used = to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate = R/L information? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein = > > To: "Rogers, Josh" = >, Lucy yong > >, Daniel = Cohn >, Sam Cao > > > Cc: "l2vpn@ietf.org" = > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > = > > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very = popular, but: > > IMO one of the advantages of the CW-based solution is that it is = orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, = and, in a more generic way, localization of effects of changes in the PE = configuration. > > In particular, adding a Leaf AC to a PE that previously has been only = supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect = only the PE where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main = disadvantage of the CW-based approach - I believe it strongly depends on = specific implementations. And some changes in the forwarding process are = required in any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org = [l2vpn-bounces@ietf.org] on behalf of = Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a = more > complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become = more > complex. > > Gile's comparison slide still concisely captures the differences = between > these methods, in my opinion. I haven't seen any new ideas or = thoughts > brought to the group in the past week or two on the subject. I would = hate > for both proposed methods to die on the vine because we couldn't = decide > between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" = > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree = uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may = double >>all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn = [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the = processing >>in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP = PW >>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >>traffic coming from a root AC) >>[[LY]] Not that simple. You construct either two P2MP PWs to all other >>PEs and let egress PE performing filtering, or construct one P2MP PW = to >>leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >>perform forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so = don't >>feel terribly strong about this objection. Is this a real problem for >>others (now or in the future), or is this objection in the weeds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. = I >>encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" = > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao = [mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim = (Wim)'; >>>giles.heron@gmail.com; = simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; = Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; = Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; = Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs = after >>>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup = 2 >>>P2MP >>>PWs if need. There is no difference between P2MP or normal PW setup. = But, >>>can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with = both >>>root and leaf ACs set up two or one P2MP PW to other PEs (some PE = have >>>both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn = [mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; = Alexander.Vainshtein@ecitele.com= ; Sam Cao >>>Cc: l2vpn@ietf.org; = Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; = Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; = Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong = [mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; = simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; = Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; = Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; = Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, = both >>>approaches can benefit from it. I was off for a while and captures = some >>>discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues = with >>>silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I = am >>>not clear on all the issues. Could you be more specific? As I = mentioned >>>in below, two PW approach makes VPLS transport construction and = packet >>>forwarding more complex, I can see potential backward compatibility >>>issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree = uses >>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown = unicast >>>traffic, and some P2MP PWs for multicast traffic. It may double all = of >>>them. >>> >>>E-tree is an Ethernet service and there is already VLAN based = solution >>>in IEEE, can we just utilize it without complicating VPLS transport >>>construction? This also makes interworking with Eth only network = easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh = [mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); = 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; = 'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; = 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; = 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; = 'Rotem.Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are = you >>>saying that you no longer are interested in that method in preference = of >>>the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org] On Behalf >>>Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; = 'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; = 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; = 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; = 'Rotem.Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron = [mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord = >; Alexander = Vainshtein >>>> >>>Cc: l2vpn@ietf.org = >; Vladimir Kleiner >>>>; = Andrew Sergeev >>>>; Idan = Kaspit >; >>>Mishael Wexler = >; Rotem = Cohen >>>> >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly = have >>>put in a third column on the CW approach. And hopefully the minutes >>>will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to = be >>>forming around the two alternatives of two PWEs or two VLANs. I = believe >>>three of the authors of the CW approach are also authors of the two = VLAN >>>approach and one is also an author of the two PWE approach. So = perhaps >>>it's best to let those four individuals say which approach they = prefer >>>and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" = > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of = various >>>> solution drafts off the mailing list. As far as I know, no = consensus >>>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>>> think the CW approach has not been rejected by the WG yet, or the = WG >>>> has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein = > >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree = approaches >>>>> based on dedicated VLANs (as in >>>>> = http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> = http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in = the >>>>> PWs connecting the PEs (as in >>>>> = http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but = I >>>>> wonder whether the WG has taken a decision to reject the approach >>>>> based on the CW usage? I do not remember any recent discussion of >>>>> this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and = contains >>>>> information which is CONFIDENTIAL and which may be proprietary to = ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original = and >>>>> all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or = subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is = addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action = taken >>>in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject = to >>copyright belonging to Time Warner Cable. This E-mail is intended = solely >>for the use of the individual or entity to which it is addressed. If = you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies = thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** From david.i.allan@ericsson.com Tue Apr 24 13:17:23 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653C921E8011 for ; Tue, 24 Apr 2012 13:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 ptdXfVsEDrHa for ; Tue, 24 Apr 2012 13:17:21 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 09EBE11E8080 for ; Tue, 24 Apr 2012 13:17:20 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3OKHJ8s003186; Tue, 24 Apr 2012 15:17:20 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.69]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 24 Apr 2012 16:17:14 -0400 From: David Allan I To: Daniel Cohn , "l2vpn@ietf.org" Date: Tue, 24 Apr 2012 16:17:12 -0400 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IAAHuPxAAACKFwAACIeb8AADgRjpAAAAlvAABrkMXAAAGzCA Message-ID: <60C093A41B5E45409A19D42CF7786DFD52322358EB@EUSAACMS0703.eamcs.ericsson.se> References: <169e01cd2256$b31c5660$05280101@corrigent.com> In-Reply-To: <169e01cd2256$b31c5660$05280101@corrigent.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: l2vpn@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, 24 Apr 2012 20:17:23 -0000 Are you referring then to the C-tag.... It is preserved, NP Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Tuesday, April 24, 2012 4:11 PM To: Fedyk, Donald (Don); Hernandez-Valencia, Enrique (Enrique); l2vpn@ietf.= org Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Preservation requires egress =3D ingress vid - how does the egress pe know = what the ingress vid was, if the ingress vid was swapped at ingress? Thumb typed - please be tolerant "Fedyk, Donald (Don)" wrote: Dan In an E-Tree Model you have logically one VLAN on ingress and one on Egress= . In the E-Tree you can use a Root or Leaf VID. (one or the other.) So you have: ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. Ingress VID does not have to equal Egress VID but regardless there is only = ever one VID on a frame at a time. Don -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Tuesday, April 24, 2012 12:58 PM To: Hernandez-Valencia, Enrique (Enrique); Sprecher, Nurit (NSN - IL/Hod Ha= Sharon); Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.o= rg; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? I don't know what kind of translation you propose but I don't see how you c= an preserve the original s-vlan id plus root/leaf in the same number of bit= s Thumb typed - please be tolerant "Hernandez-Valencia, Enrique (Enrique)" wrote: VLAN-ID preservation does not necessarily require a third VLAN-ID. VLAN-ID = translation is sufficient. Enrique -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Tuesday, April 24, 2012 7:17 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Lucy yong; Rogers, Josh; Shahr= am Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? No, the other way round. In the 2-VLAN solution, S-VLAN ID preservation req= uires adding a third VLAN ID. In the multi-PW solution, this is not require= d. DC -----Original Message----- From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.co= m] Sent: Tuesday, April 24, 2012 2:02 PM To: Daniel Cohn; Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vp= n@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Daniel, Is it so that you consider S-VAL stacking? If this is the case, are you aware that this is not in-line with the IEEE s= pecifications? Best regard, Nurit -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of e= xt Daniel Cohn Sent: Tuesday, April 24, 2012 10:12 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, even if the current MEF framework doesn't require s-vlan preservation, I be= lieve it's to the industry's benefit to adopt a solution that is not constr= ained to a specific enni model that, like all things networking, is likely = to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service provider= s' inputs. It had a fair reason to assume S-VLAN over ENNI by then. It may = open B-VLAN for the future. It is better for us not to discuss a future fr= amework here, because it will lead us to nowhere. Here, we want to extend V= PLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Va= inshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume tha= t the VLAN tags at the E-NNI will always be according to the current MEF mo= del? Or should we try to be as transparent as possible to user VLAN encapsu= lation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case VLAN t= ag) to signal VPLS information (in this case root/leaf origin) is necessari= ly tied to specific assumptions on user payload encapsulation (in this case= , that S-VLAN tag is "available" to encode root/leaf). I don't think this i= s a future-proof assumption, it's very likely that other network models wil= l come up that require S-VLAN preservation, which in the 2-VLAN approach wo= uld necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, "l2vpn@i= etf.org" >, "A= lexander.Vainshtein@ecitele.com" <= Alexander.Vainshtein@ecitele.com> Cc: "yuqun.cao@gmail.com" > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic alrea= dy has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com= Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L i= nformation, customer payload or PW? The customer payload will be always mod= ified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is access= ed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informati= on? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > com>> > To: "Rogers, Josh" >, Lucy yong > >, Daniel Cohn <= DanielC@orckit.com>, Sam Cao > > > Cc: "l2vpn@ietf.org" > > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, = but: > > IMO one of the advantages of the CW-based solution is that it is orthogon= al to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffi= c. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and,= in a more generic way, localization of effects of changes in the PE config= uration. > > In particular, adding a Leaf AC to a PE that previously has been only sup= porting Root ACs (or vice versa), removal of the last Leaf or last Root AC = from a PE that previously has been supporting a mix etc. affect only the PE= where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadva= ntage of the CW-based approach - I believe it strongly depends on specific = implementations. And some changes in the forwarding process are required in= any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org > [l2vpn-bounces@ietf.org] on behalf of > Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a > more complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become > more complex. > > Gile's comparison slide still concisely captures the differences > between these methods, in my opinion. I haven't seen any new ideas or > thoughts brought to the group in the past week or two on the subject. > I would hate for both proposed methods to die on the vine because we > couldn't decide between two methods that have nothing inherently wrong wi= th either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree >>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may >>double all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn >>[mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the >>processing in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >>PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW >>(for traffic coming from a root AC) [[LY]] Not that simple. You >>construct either two P2MP PWs to all other PEs and let egress PE >>performing filtering, or construct one P2MP PW to leaf-only PEs and >>two P2MP PWs to root and leaf PEs and let ingress PE perform >>forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so >>don't feel terribly strong about this objection. Is this a real >>problem for others (now or in the future), or is this objection in the we= eds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. >>I encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao >>>[mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>(Wim)'; giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>PE have both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn >>>[mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com>; Sam Cao >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong >>>[mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>both approaches can benefit from it. I was off for a while and >>>captures some discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues >>>with silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >>>am not clear on all the issues. Could you be more specific? As I >>>mentioned in below, two PW approach makes VPLS transport construction >>>and packet forwarding more complex, I can see potential backward >>>compatibility issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>double all of them. >>> >>>E-tree is an Ethernet service and there is already VLAN based >>>solution in IEEE, can we just utilize it without complicating VPLS >>>transport construction? This also makes interworking with Eth only netwo= rk easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh >>>[mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); >>>'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vain= shtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are >>>you saying that you no longer are interested in that method in >>>preference of the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org >>>[mailto:l2vpn-bounces@ietf.org] On >>>Behalf Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron >>>[mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord >>>>; Alexander >>>Vainshtein >>>>>.com>> >>>Cc: l2vpn@ietf.org >>>>; Vladimir Kleiner >>>>; >>>Andrew Sergeev >>>>; Idan >>>Kaspit >; >>>Mishael Wexler >>>>; >>>Rotem Cohen > >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly >>>have put in a third column on the CW approach. And hopefully the >>>minutes will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to >>>be forming around the two alternatives of two PWEs or two VLANs. I >>>believe three of the authors of the CW approach are also authors of >>>the two VLAN approach and one is also an author of the two PWE >>>approach. So perhaps it's best to let those four individuals say >>>which approach they prefer and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of >>>> various solution drafts off the mailing list. As far as I know, no >>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>> meeting. I think the CW approach has not been rejected by the WG >>>> yet, or the WG has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein >>>> >>> le.com>> >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree >>>>> approaches based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/ >>>>> ?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in >>>>> the PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>> I wonder whether the WG has taken a decision to reject the >>>>> approach based on the CW usage? I do not remember any recent >>>>> discussion of this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and >>>>> contains information which is CONFIDENTIAL and which may be >>>>> proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original >>>>> and all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or >>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>intended solely for the use of the individual or entity to which it is a= ddressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail >>>is strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is >>addressed. If you are not the intended recipient of this E-mail, you >>are hereby notified that any dissemination, distribution, copying, or >>action taken in relation to the contents of and attachments to this >>E-mail is strictly prohibited and may be unlawful. If you have >>received this E-mail in error, please notify the sender immediately >>and permanently delete the original and any copy of this E-mail and any p= rintout. > > > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** From donald.fedyk@alcatel-lucent.com Tue Apr 24 13:20:10 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5E421E8032 for ; Tue, 24 Apr 2012 13:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.598 X-Spam-Level: X-Spam-Status: No, score=-8.598 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 S4yekCOnUVA1 for ; Tue, 24 Apr 2012 13:20:08 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0003911E8080 for ; Tue, 24 Apr 2012 13:20:07 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q3OKK5Vn005325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Apr 2012 15:20:06 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q3OKK5ce031405 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Apr 2012 15:20:05 -0500 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.145]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 24 Apr 2012 15:20:05 -0500 From: "Fedyk, Donald (Don)" To: Daniel Cohn , "Hernandez-Valencia, Enrique (Enrique)" , "l2vpn@ietf.org" Date: Tue, 24 Apr 2012 15:20:04 -0500 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IAAHuPxAAACKFwAACIeb8AADgRjpAAAAlvAABrkMXAAAB2eA Message-ID: References: <169e01cd2256$b31c5660$05280101@corrigent.com> In-Reply-To: <169e01cd2256$b31c5660$05280101@corrigent.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "yuqun.cao@gmail.com" X-BeenThere: l2vpn@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, 24 Apr 2012 20:20:11 -0000 RGFuLA0KDQpUaGVyZSBpcyBhIG9uZSB0byBvbmUgbWFwcGluZyBpbiBib3RoIGRpcmVjdGlvbnMu DQpJbmdyZXNzIDwtPiByb290IFZJRCA8LT4gRWdyZXNzIFZJRA0KSW5ncmVzcyA8LT4gbGVhZiBW SUQgPC0+IEVncmVzcyBWSUQNCg0KVGhlcmVmb3JlIGVhY2ggZW5kIGlzIGNvbmZpZ3VyZWQgYW5k IGlmIHlvdSB3YW50IGluZ3Jlc3MgdG8gZXF1YWwgaW5ncmVzcyB0aGVuIHlvdSBjb25maWd1cmUg aXQgdGhhdCB3YXkuDQoNCklmIHlvdSBhcmUgdGhpbmtpbmcgYWJvdXQgYSBtb2RlbCB0aGF0IGVu Y2Fwc3VsYXRlcyBtdWx0aXBsZSBpbmdyZXNzIFZMQU5zIG9uIHRvIGEgRXRyZWUsIHRoZW4geW91 IHdvdWxkIGVuY2Fwc3VsYXRlIGZpcnN0IGFuZCB0aGUgb3V0ZXIgZW5jYXBzdWxhdGlvbiAoUy1U QUcgZm9yIGV4YW1wbGUpIHdvdWxkIGJlIHRoZSBpbmdyZXNzL2VncmVzcyBWSURzLg0KDQpUaGVu IHRoZSBjaG9pY2UgdG8gZW5jYXBzdWxhdGUgaXMgc2VwYXJhdGUgZnJvbSB0aGUgRS1UcmVlIHNl cnZpY2Ugd2hpY2ggc3RpbGwgb25seSB1c2VzIGEgc2luZ2xlIFZJRCBwZXIgZnJhbWUuDQoNCkRv bg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGFuaWVsIENvaG4gW21haWx0 bzpEYW5pZWxDQG9yY2tpdC5jb21dDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAyNCwgMjAxMiA0OjEx IFBNDQpUbzogRmVkeWssIERvbmFsZCAoRG9uKTsgSGVybmFuZGV6LVZhbGVuY2lhLCBFbnJpcXVl IChFbnJpcXVlKTsgbDJ2cG5AaWV0Zi5vcmcNCkNjOiB5dXF1bi5jYW9AZ21haWwuY29tDQpTdWJq ZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0 aW9uPw0KDQpQcmVzZXJ2YXRpb24gcmVxdWlyZXMgZWdyZXNzID0gaW5ncmVzcyB2aWQgLSBob3cg ZG9lcyB0aGUgZWdyZXNzIHBlIGtub3cgd2hhdCB0aGUgaW5ncmVzcyB2aWQgd2FzLCBpZiB0aGUg aW5ncmVzcyB2aWQgd2FzIHN3YXBwZWQgYXQgaW5ncmVzcz8NCg0KVGh1bWIgdHlwZWQgLSBwbGVh c2UgYmUgdG9sZXJhbnQNCg0KIkZlZHlrLCBEb25hbGQgKERvbikiIDxkb25hbGQuZmVkeWtAYWxj YXRlbC1sdWNlbnQuY29tPiB3cm90ZToNCg0KRGFuDQoNCkluIGFuIEUtVHJlZSBNb2RlbCB5b3Ug aGF2ZSBsb2dpY2FsbHkgb25lIFZMQU4gb24gaW5ncmVzcyBhbmQgb25lIG9uIEVncmVzcy4gSW4g dGhlIEUtVHJlZSB5b3UgY2FuIHVzZSBhIFJvb3Qgb3IgTGVhZiBWSUQuIChvbmUgb3IgdGhlIG90 aGVyLikNCg0KU28geW91IGhhdmU6DQppbmdyZXNzIFZMQU4gSUQgPC0+IEV0cmVlIFJvb3QvTGVh ZiBWSUQgPC0+IEVncmVzcyBWSUQuDQoNCkluZ3Jlc3MgVklEIGRvZXMgbm90IGhhdmUgdG8gZXF1 YWwgRWdyZXNzIFZJRCBidXQgcmVnYXJkbGVzcyB0aGVyZSBpcyBvbmx5IGV2ZXIgb25lIFZJRCBv biBhIGZyYW1lIGF0IGEgdGltZS4NCg0KRG9uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIERhbmllbCBDb2huDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAyNCwg MjAxMiAxMjo1OCBQTQ0KVG86IEhlcm5hbmRlei1WYWxlbmNpYSwgRW5yaXF1ZSAoRW5yaXF1ZSk7 IFNwcmVjaGVyLCBOdXJpdCAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKTsgTHVjeSB5b25nOyBSb2dl cnMsIEpvc2g7IFNoYWhyYW0gRGF2YXJpOyBMaXpob25nIEppbjsgbDJ2cG5AaWV0Zi5vcmc7IEFs ZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQpDYzogeXVxdW4uY2FvQGdtYWlsLmNvbQ0K U3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBz b2x1dGlvbj8NCg0KSSBkb24ndCBrbm93IHdoYXQga2luZCBvZiB0cmFuc2xhdGlvbiB5b3UgcHJv cG9zZSBidXQgSSBkb24ndCBzZWUgaG93IHlvdSBjYW4gcHJlc2VydmUgdGhlIG9yaWdpbmFsIHMt dmxhbiBpZCBwbHVzIHJvb3QvbGVhZiBpbiB0aGUgc2FtZSBudW1iZXIgb2YgYml0cw0KDQpUaHVt YiB0eXBlZCAtIHBsZWFzZSBiZSB0b2xlcmFudA0KDQoiSGVybmFuZGV6LVZhbGVuY2lhLCBFbnJp cXVlIChFbnJpcXVlKSIgPGVucmlxdWUuaGVybmFuZGV6QGFsY2F0ZWwtbHVjZW50LmNvbT4gd3Jv dGU6DQoNClZMQU4tSUQgcHJlc2VydmF0aW9uIGRvZXMgbm90IG5lY2Vzc2FyaWx5IHJlcXVpcmUg YSB0aGlyZCBWTEFOLUlELiBWTEFOLUlEIHRyYW5zbGF0aW9uIGlzIHN1ZmZpY2llbnQuDQoNCkVu cmlxdWUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGwydnBuLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGFu aWVsIENvaG4NClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDI0LCAyMDEyIDc6MTcgQU0NClRvOiBTcHJl Y2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJvbik7IEx1Y3kgeW9uZzsgUm9nZXJzLCBK b3NoOyBTaGFocmFtIERhdmFyaTsgTGl6aG9uZyBKaW47IGwydnBuQGlldGYub3JnOyBBbGV4YW5k ZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KQ2M6IHl1cXVuLmNhb0BnbWFpbC5jb20NClN1Ympl Y3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRp b24/DQoNCk5vLCB0aGUgb3RoZXIgd2F5IHJvdW5kLiBJbiB0aGUgMi1WTEFOIHNvbHV0aW9uLCBT LVZMQU4gSUQgcHJlc2VydmF0aW9uIHJlcXVpcmVzIGFkZGluZyBhIHRoaXJkIFZMQU4gSUQuIElu IHRoZSBtdWx0aS1QVyBzb2x1dGlvbiwgdGhpcyBpcyBub3QgcmVxdWlyZWQuDQoNCkRDDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElM L0hvZCBIYVNoYXJvbikgW21haWx0bzpudXJpdC5zcHJlY2hlckBuc24uY29tXQ0KU2VudDogVHVl c2RheSwgQXByaWwgMjQsIDIwMTIgMjowMiBQTQ0KVG86IERhbmllbCBDb2huOyBMdWN5IHlvbmc7 IFJvZ2VycywgSm9zaDsgU2hhaHJhbSBEYXZhcmk7IExpemhvbmcgSmluOyBsMnZwbkBpZXRmLm9y ZzsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20NCkNjOiB5dXF1bi5jYW9AZ21haWwu Y29tDQpTdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1U cmVlIHNvbHV0aW9uPw0KDQpEYW5pZWwsDQpJcyBpdCBzbyB0aGF0IHlvdSBjb25zaWRlciBTLVZB TCBzdGFja2luZz8NCklmIHRoaXMgaXMgdGhlIGNhc2UsIGFyZSB5b3UgYXdhcmUgdGhhdCB0aGlz IGlzIG5vdCBpbi1saW5lIHdpdGggdGhlIElFRUUgc3BlY2lmaWNhdGlvbnM/DQpCZXN0IHJlZ2Fy ZCwNCk51cml0DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsMnZwbi1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IGV4dCBEYW5pZWwgQ29obg0KU2VudDogVHVlc2RheSwgQXByaWwgMjQsIDIwMTIgMTA6MTIgQU0N ClRvOiBMdWN5IHlvbmc7IFJvZ2VycywgSm9zaDsgU2hhaHJhbSBEYXZhcmk7IExpemhvbmcgSmlu OyBsMnZwbkBpZXRmLm9yZzsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20NCkNjOiB5 dXF1bi5jYW9AZ21haWwuY29tDQpTdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9h Y2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KDQpMdWN5LA0KDQpldmVuIGlmIHRoZSBjdXJy ZW50IE1FRiBmcmFtZXdvcmsgZG9lc24ndCByZXF1aXJlIHMtdmxhbiBwcmVzZXJ2YXRpb24sIEkg YmVsaWV2ZSBpdCdzIHRvIHRoZSBpbmR1c3RyeSdzIGJlbmVmaXQgdG8gYWRvcHQgYSBzb2x1dGlv biB0aGF0IGlzIG5vdCBjb25zdHJhaW5lZCB0byBhIHNwZWNpZmljIGVubmkgbW9kZWwgdGhhdCwg bGlrZSBhbGwgdGhpbmdzIG5ldHdvcmtpbmcsIGlzIGxpa2VseSB0byBldm9sdmUuIEVzcGVjaWFs bHkgd2hlbiBzdWNoIGEgc29sdXRpb24gaXMgYXZhaWxhYmxlLg0KDQpEYW5pZWwNCg0KVGh1bWIg dHlwZWQgLSBwbGVhc2UgYmUgdG9sZXJhbnQNCg0KTHVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2Vp LmNvbT4gd3JvdGU6DQoNCkRhbmllbCwNCg0KTUVGIGhhcyB3b3JrZWQgaW4gRU5OSSBpbnRlcmZh Y2UgZm9yIGEgbG9uZyB0aW1lIHdpdGggbWFueSBzZXJ2aWNlIHByb3ZpZGVycycgaW5wdXRzLiBJ dCBoYWQgYSBmYWlyIHJlYXNvbiB0byBhc3N1bWUgUy1WTEFOIG92ZXIgRU5OSSBieSB0aGVuLiBJ dCBtYXkgb3BlbiBCLVZMQU4gZm9yIHRoZSBmdXR1cmUuIEl0IGlzIGJldHRlciBmb3IgdXMgbm90 IHRvIGRpc2N1c3MgIGEgZnV0dXJlIGZyYW1ld29yayBoZXJlLCBiZWNhdXNlIGl0IHdpbGwgbGVh ZCB1cyB0byBub3doZXJlLiBIZXJlLCB3ZSB3YW50IHRvIGV4dGVuZCBWUExTIGluIHN1cHBvcnRp bmcgRS1UcmVlLg0KDQpCZXN0IFJlZ2FyZHMsDQpMdWN5DQoNCkZyb206IGwydnBuLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGFu aWVsIENvaG4NClNlbnQ6IFN1bmRheSwgQXByaWwgMjIsIDIwMTIgNzozNCBBTQ0KVG86IFJvZ2Vy cywgSm9zaDsgU2hhaHJhbSBEYXZhcmk7IExpemhvbmcgSmluOyBsMnZwbkBpZXRmLm9yZzsgQWxl eGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20NCkNjOiB5dXF1bi5jYW9AZ21haWwuY29tDQpT dWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNv bHV0aW9uPw0KDQpTaGFocmFtIGFuZCBhbGwsDQoNClRoaXMgcXVlc3Rpb24gYWxyZWFkeSBjYW1l IHVwIGluIG91ciBkaXNjdXNzaW9ucyAtIGlzIGl0IHNhZmUgdG8gYXNzdW1lIHRoYXQgdGhlIFZM QU4gdGFncyBhdCB0aGUgRS1OTkkgd2lsbCBhbHdheXMgYmUgYWNjb3JkaW5nIHRvIHRoZSBjdXJy ZW50IE1FRiBtb2RlbD8gT3Igc2hvdWxkIHdlIHRyeSB0byBiZSBhcyB0cmFuc3BhcmVudCBhcyBw b3NzaWJsZSB0byB1c2VyIFZMQU4gZW5jYXBzdWxhdGlvbiBhdCB0aGUgRS1OTkksIHRvIGFjY29t bW9kYXRlIGZ1dHVyZSBmcmFtZXdvcmtzPw0KSSBiZWxpZXZlIHRoYXQgYW55IGFwcHJvYWNoIHRo YXQgbG9va3MgYXQgdXNlciBwYXlsb2FkIChpbiB0aGlzIGNhc2UgVkxBTiB0YWcpIHRvIHNpZ25h bCBWUExTIGluZm9ybWF0aW9uIChpbiB0aGlzIGNhc2Ugcm9vdC9sZWFmIG9yaWdpbikgaXMgbmVj ZXNzYXJpbHkgdGllZCB0byBzcGVjaWZpYyBhc3N1bXB0aW9ucyBvbiB1c2VyIHBheWxvYWQgZW5j YXBzdWxhdGlvbiAoaW4gdGhpcyBjYXNlLCB0aGF0IFMtVkxBTiB0YWcgaXMgImF2YWlsYWJsZSIg dG8gZW5jb2RlIHJvb3QvbGVhZikuIEkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBhIGZ1dHVyZS1wcm9v ZiBhc3N1bXB0aW9uLCBpdCdzIHZlcnkgbGlrZWx5IHRoYXQgb3RoZXIgbmV0d29yayBtb2RlbHMg d2lsbCBjb21lIHVwIHRoYXQgcmVxdWlyZSBTLVZMQU4gcHJlc2VydmF0aW9uLCB3aGljaCBpbiB0 aGUgMi1WTEFOIGFwcHJvYWNoIHdvdWxkIG5lY2Vzc2l0YXRlIGFkZGluZyBhIHRoaXJkIFZMQU4t SUQuDQoNCkRhbmllbA0KDQpGcm9tOiBTaGFocmFtIERhdmFyaSA8ZGF2YXJpQGJyb2FkY29tLmNv bTxtYWlsdG86ZGF2YXJpQGJyb2FkY29tLmNvbT4+DQpUbzogTGl6aG9uZyBKaW4gPGxpemhvLmpp bkBnbWFpbC5jb208bWFpbHRvOmxpemhvLmppbkBnbWFpbC5jb20+PiwgImwydnBuQGlldGYub3Jn PG1haWx0bzpsMnZwbkBpZXRmLm9yZz4iIDxsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0 Zi5vcmc+PiwgIkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5k ZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4iIDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+Pg0KQ2M6ICJ5dXF1 bi5jYW9AZ21haWwuY29tPG1haWx0bzp5dXF1bi5jYW9AZ21haWwuY29tPiIgPHl1cXVuLmNhb0Bn bWFpbC5jb208bWFpbHRvOnl1cXVuLmNhb0BnbWFpbC5jb20+Pg0KU3ViamVjdDogUkU6IFRoZSBz dGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCg0KSGksDQoN CkkgYWxzbyBoYXZlIGEgcXVlc3Rpb24gcmVnYXJkaW5nIDItVkxBTi4gV2hhdCBpZiB0aGUgY3Vz dG9tZXIgdHJhZmZpYyBhbHJlYWR5IGhhcyBhbiBTLVZMQU4/IERvIHdlIG5lZWQgYSAzcmQgVkxB TiB0byBpZGVudGlmeSB0aGUgTC9SPw0KDQpUaHgNClNoYWhyYW0NCg0KRnJvbTogbDJ2cG4tYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpsMnZw bi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGl6aG9uZyBKaW4NClNlbnQ6IEZyaWRh eSwgQXByaWwgMjAsIDIwMTIgOTozOCBBTQ0KVG86IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZw bkBpZXRmLm9yZz47IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4NCkNjOiB5dXF1bi5jYW9AZ21haWwuY29tPG1h aWx0bzp5dXF1bi5jYW9AZ21haWwuY29tPg0KU3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhl IGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCg0KSGksIGFsbCwNClRoZSBkaWZm ZXJlbmNlIGJldHdlZW4gMi1WTEFOIGFuZCBDVyBhcHByb2FjaCBpcyB3aG8gd2lsbCBwcm92aWRl IHRoZSBSL0wgaW5mb3JtYXRpb24sIGN1c3RvbWVyIHBheWxvYWQgb3IgUFc/IFRoZSBjdXN0b21l ciBwYXlsb2FkIHdpbGwgYmUgYWx3YXlzIG1vZGlmaWVkIHRvIGNhcnJ5IFIvTCBpbmZvcm1hdGlv biBpbiAyLVZMQU4gYXBwcm9hY2gsIHdoaWxlIFBXIHdpdGggQ1cgd2lsbCBjYXJyeSBSL0wgaW5m b3JtYXRpb24gZm9yIENXIGFwcHJvYWNoLg0KSSBoYXZlIGEgcXVlc3Rpb24gd2l0aCB0aGUgMi1W TEFOIGFwcHJvYWNoIGluIEgtVlBMUyB3aGVyZSBILVZQTFMgaXMgYWNjZXNzZWQgYnkgVlBXUyBh cyBkZXNjcmliZWQgaW4gUkZDNDY3MiBzZWN0aW9uIDEwLjEuMy4gSWYgVlBXUyBpcyB1c2VkIHRv IGFjY2VzcyBILVZQTFMsIGhvdyBjb3VsZCB0aGUgUEUgb24gVlBXUyBzaWRlIGFkZHMgVkxBTiB0 byBpbmRpY2F0ZSBSL0wgaW5mb3JtYXRpb24/DQoNClRoYW5rcw0KTGl6aG9uZw0KDQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPiBNZXNzYWdlOiAyDQo+IERhdGU6IFRodSwg MTkgQXByIDIwMTIgMDQ6Mzg6MzYgKzAwMDANCj4gRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4g PEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNo dGVpbkBlY2l0ZWxlLmNvbT4+DQo+IFRvOiAiUm9nZXJzLCBKb3NoIiA8am9zaC5yb2dlcnNAdHdj YWJsZS5jb208bWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29tPj4sIEx1Y3kgeW9uZw0KPiAg ICAgICAgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+ LCBEYW5pZWwgQ29obiA8RGFuaWVsQ0BvcmNraXQuY29tPG1haWx0bzpEYW5pZWxDQG9yY2tpdC5j b20+PiwgU2FtIENhbw0KPiAgICAgICAgPHl1cXVuLmNhb0BnbWFpbC5jb208bWFpbHRvOnl1cXVu LmNhb0BnbWFpbC5jb20+Pg0KPiBDYzogImwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRm Lm9yZz4iIDxsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+Pg0KPiBTdWJqZWN0 OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9u Pw0KPiBNZXNzYWdlLUlEOg0KPiAgICAgICAgPEY5MzM2NTcxNzMxQURFNDJBNTM5N0ZDODMxQ0VB QTAyMDM0MTkyQEZSSURXUFBNQjAwMi5lY2l0ZWxlLmNvbTxtYWlsdG86RjkzMzY1NzE3MzFBREU0 MkE1Mzk3RkM4MzFDRUFBMDIwMzQxOTJARlJJRFdQUE1CMDAyLmVjaXRlbGUuY29tPj4NCj4gQ29u dGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSINCj4NCj4gSGkgYWxsLA0K PiBJIGZ1bGx5IHVuZGVyc3RhbmQgdGhhdCB0aGF0IHdoYXQgSSBhbSBnb2luZyB0byBzYXkgaXMg bm90IHZlcnkgcG9wdWxhciwgYnV0Og0KPg0KPiBJTU8gb25lIG9mIHRoZSBhZHZhbnRhZ2VzIG9m IHRoZSBDVy1iYXNlZCBzb2x1dGlvbiBpcyB0aGF0IGl0IGlzIG9ydGhvZ29uYWwgdG8gdXNhZ2Ug KG9yIG5vbi11c2FnZSkgb2YgUDJNUCBQV3MgZm9yIGVmZmVjdGl2ZSBkZWxpdmVyeSBvZiBCVU4g dHJhZmZpYy4NCj4NCj4gQW5vdGhlciBhZHZhbnRhZ2UgaXMgcHJlc2VydmF0aW9uIG9mIGZ1bGwg bWVzaCBvZiBQMlAgUFdzIGluIGEgVlBMUywgYW5kLCBpbiBhIG1vcmUgZ2VuZXJpYyB3YXksIGxv Y2FsaXphdGlvbiBvZiBlZmZlY3RzIG9mIGNoYW5nZXMgaW4gdGhlIFBFIGNvbmZpZ3VyYXRpb24u DQo+DQo+IEluIHBhcnRpY3VsYXIsIGFkZGluZyBhIExlYWYgQUMgdG8gYSBQRSB0aGF0IHByZXZp b3VzbHkgaGFzIGJlZW4gb25seSBzdXBwb3J0aW5nIFJvb3QgQUNzIChvciB2aWNlIHZlcnNhKSwg cmVtb3ZhbCBvZiB0aGUgbGFzdCBMZWFmIG9yIGxhc3QgUm9vdCBBQyBmcm9tIGEgUEUgdGhhdCBw cmV2aW91c2x5IGhhcyBiZWVuIHN1cHBvcnRpbmcgYSBtaXggZXRjLiBhZmZlY3Qgb25seSB0aGUg UEUgd2hlcmUgdGhpcyBvcGVyYXRpb24gaGFwcGVucyBhbmQgbm90IHRoZSByZXN0IG9mIHRoZSBQ RXMuDQo+DQo+IEFzIGZvciB0aGUgbmVlZCBmb3IgSFcgY2hhbmdlcyB0aGF0IGhhdmUgYmVlbiBt ZW50aW9uZWQgYXMgYSBtYWluIGRpc2FkdmFudGFnZSBvZiB0aGUgQ1ctYmFzZWQgYXBwcm9hY2gg LSBJIGJlbGlldmUgaXQgc3Ryb25nbHkgZGVwZW5kcyBvbiBzcGVjaWZpYyBpbXBsZW1lbnRhdGlv bnMuIEFuZCBzb21lIGNoYW5nZXMgaW4gdGhlIGZvcndhcmRpbmcgcHJvY2VzcyBhcmUgcmVxdWly ZWQgaW4gYW55IHNvbHV0aW9uLg0KPg0KPiBNeSAyYywNCj4gICAgIFNhc2hhDQo+DQo+DQo+DQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRnJvbTogbDJ2cG4t Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZz4gW2wydnBuLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc+XSBvbiBiZWhhbGYg b2YgUm9nZXJzLCBKb3NoIFtqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbTxtYWlsdG86am9zaC5yb2dl cnNAdHdjYWJsZS5jb20+XQ0KPiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDE4LCAyMDEyIDk6NTcg UE0NCj4gVG86IEx1Y3kgeW9uZzsgRGFuaWVsIENvaG47IFNhbSBDYW8NCj4gQ2M6IGwydnBuQGll dGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFRoZSBzdGF0dXMg b2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4NCj4gQWdhaW4sIHRo ZSBQMk1QIHNpdHVhdGlvbiB0aHJvd3MgbWUuICBJcyB0aGlzIHNvbWV0aGluZyB0aGF0IGlzIHVz ZWQNCj4gY29tbW9ubHk/DQo+DQo+IEknbSB1bmRlciB0aGUgaW1wcmVzc2lvbiB0aGF0IGFkZGlu ZyBQMk1QIHRvIGFueSBtb2RlbCByZXN1bHRzIGluIGEgbW9yZQ0KPiBjb21wbGV4IG1vZGVsLiAg V2V0aGVyIG91dHNpZGUgcy10YWcgaXMgdXNlZCB0byBkaWZmZXJlbnRpYXRlLCBvcg0KPiBkZWRp Y2F0ZWQgcHcncyBhcmUgdXNlZCBmb3IgdGhlIHNhbWUgcHVycG9zZSwgaXQgc2VlbXMgYm90aCBi ZWNvbWUgbW9yZQ0KPiBjb21wbGV4Lg0KPg0KPiBHaWxlJ3MgY29tcGFyaXNvbiBzbGlkZSBzdGls bCBjb25jaXNlbHkgY2FwdHVyZXMgdGhlIGRpZmZlcmVuY2VzIGJldHdlZW4NCj4gdGhlc2UgbWV0 aG9kcywgaW4gbXkgb3Bpbmlvbi4gIEkgaGF2ZW4ndCBzZWVuIGFueSBuZXcgaWRlYXMgb3IgdGhv dWdodHMNCj4gYnJvdWdodCB0byB0aGUgZ3JvdXAgaW4gdGhlIHBhc3Qgd2VlayBvciB0d28gb24g dGhlIHN1YmplY3QuICBJIHdvdWxkIGhhdGUNCj4gZm9yIGJvdGggcHJvcG9zZWQgbWV0aG9kcyB0 byBkaWUgb24gdGhlIHZpbmUgYmVjYXVzZSB3ZSBjb3VsZG4ndCBkZWNpZGUNCj4gYmV0d2VlbiB0 d28gbWV0aG9kcyB0aGF0IGhhdmUgbm90aGluZyBpbmhlcmVudGx5IHdyb25nIHdpdGggZWl0aGVy Lg0KPg0KPiAtSm9zaA0KPg0KPg0KPiBPbiA0LzE4LzEyIDE6NTMgUE0sICJMdWN5IHlvbmciIDxs dWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiB3cm90ZToN Cj4NCj4+U2VuZCB0aGlzIGFnYWluLg0KPj4NCj4+VHdvIFBXIGFwcHJvYWNoIGNhbiBiZSBjb21w bGV4IHRvbyBpZiB0aGUgVlBMUyBpbnN0YW5jZSBmb3IgRS1UcmVlIHVzZXMNCj4+UDJQIFBXIGZv ciB1bmljYXN0IHRyYWZmaWMgYW5kIFAyTVAgUFcgZm9yIGJyb2FkY2FzdCBhbmQgdW5rbm93bg0K Pj51bmljYXN0IHRyYWZmaWMsIGFuZCBzb21lIFAyTVAgUFdzIGZvciBtdWx0aWNhc3QgdHJhZmZp Yy4gSXQgbWF5IGRvdWJsZQ0KPj5hbGwgb2YgdGhlbS4NCj4+DQo+Pkx1Y3kNCj4+DQo+Pi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IERhbmllbCBDb2huIFttYWlsdG86RGFuaWVs Q0BvcmNraXQuY29tPG1haWx0bzpEYW5pZWxDQG9yY2tpdC5jb20+XQ0KPj5TZW50OiBXZWRuZXNk YXksIEFwcmlsIDE4LCAyMDEyIDE6NDIgUE0NCj4+VG86IEx1Y3kgeW9uZzsgUm9nZXJzLCBKb3No OyBTYW0gQ2FvDQo+PkNjOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+DQo+ PlN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUg c29sdXRpb24/DQo+Pg0KPj5JIHRoaW5rIHRoZSBmaXJzdCBvcHRpb24gaXRzIHRoZSBuYXR1cmFs IHdheSB0byBnby4gSG93IGlzIHRoZSBwcm9jZXNzaW5nDQo+PmluIHRoaXMgY2FzZSBtb3JlIGNv bXBsZXg/DQo+Pg0KPj5UaHVtYiB0eXBlZCAtIHBsZWFzZSBiZSB0b2xlcmFudA0KPj4NCj4+THVj eSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+ PiB3cm90ZToNCj4+DQo+Pg0KPj4NCj4+U25pcHBlZC4uDQo+Pg0KPj5NdWx0aS1QVyAtIE9uIGlu Z3Jlc3MgUEUsIGZyYW1lIGlzIHBsYWNlZCBvbnRvIGVpdGhlciBhIExlYWYtb25seSBQMk1QIFBX DQo+Pihmb3IgdHJhZmZpYyBjb21pbmcgZnJvbSBhIGxlYWYgQUMpLCBvciBvbnRvIGEgUm9vdC9M ZWFmIFAyTVAgUFcgKGZvcg0KPj50cmFmZmljIGNvbWluZyBmcm9tIGEgcm9vdCBBQykNCj4+W1tM WV1dIE5vdCB0aGF0IHNpbXBsZS4gWW91IGNvbnN0cnVjdCBlaXRoZXIgdHdvIFAyTVAgUFdzIHRv IGFsbCBvdGhlcg0KPj5QRXMgYW5kIGxldCBlZ3Jlc3MgUEUgcGVyZm9ybWluZyBmaWx0ZXJpbmcs IG9yIGNvbnN0cnVjdCBvbmUgUDJNUCBQVyB0bw0KPj5sZWFmLW9ubHkgUEVzIGFuZCB0d28gUDJN UCBQV3MgdG8gcm9vdCBhbmQgbGVhZiBQRXMgYW5kIGxldCBpbmdyZXNzIFBFDQo+PnBlcmZvcm0g Zm9yd2FyZGluZyBhbmQgZmlsdGVyaW5nLiBCb3RoIG1ha2Ugbm9kZSBwcm9jZXNzIGNvbXBsZXgu DQo+Pg0KPj5bW0xZXV0gVlBMUyBpcyBidWlsdCB3aXRoIHRoZSBtZWNoYW5pc20gdXRpbGl6aW5n IFAyUCBhbmQgUDJNUCBQVyBmb3INCj4+ZGVsaXZlcmluZyB0aGUgZnJhbWVzIHRvIHJlbW90ZSBQ RXMuIFdlIHNob3VsZCB1dGlsaXplIHRoZW0gd2l0aCB0aGUNCj4+bWluaW1pemVkIGNoYW5nZXMu IER1YWwgVkxBTiBzb2x1dGlvbiBpcyBzaW1wbGVyIHRoYW4gRHVhbCBQVy4NCj4+DQo+PlJlZ2Fy ZHMsDQo+Pkx1Y3kNCj4+DQo+Pg0KPj5JIHNlZSBob3cgMlZMQU4gaXMgc2ltcGxlciB3aGVuIFAy TVAgUFcncyBhcmUgaW52b2x2ZWQsIEkgdGhpbmsuICBJDQo+PmhhdmVuJ3QgaGFkIGFueSBmaXJz dCBoYW5kIGV4cGVyaWVuY2Ugd2l0aCBQMk1QIFBXJ3MsIGhvd2V2ZXIsIHNvIGRvbid0DQo+PmZl ZWwgdGVycmlibHkgc3Ryb25nIGFib3V0IHRoaXMgb2JqZWN0aW9uLiAgSXMgdGhpcyBhIHJlYWwg cHJvYmxlbSBmb3INCj4+b3RoZXJzIChub3cgb3IgaW4gdGhlIGZ1dHVyZSksIG9yIGlzIHRoaXMg b2JqZWN0aW9uIGluIHRoZSB3ZWVkcz8NCj4+DQo+PkknbSBub3Qgc3VyZSB0aGUgJ2FkZGl0aW9u YWwgY29tcGxleGl0eScgaXMgbm90YWJsZSwgb3IgZXZlbiByZWxldmFudC4gIEkNCj4+ZW5jb3Vy YWdlIG90aGVycyB0byBzcGVhayB1cCBpZiB0aGV5IGRpc2FncmVlLCBhcyBQMk1QIFBXIGlzIG9u bHkNCj4+Y29uY2VwdHVhbCB0byBtZSwgYW5kIEkgYW0gdW5mYW1pbGlhciB3aXRoIHJlYWwtbGlm ZSB1c2UgY2FzZXMgZm9yIGl0Lg0KPj4NCj4+VGhhbmtzLA0KPj5Kb3NoDQo+Pg0KPj4NCj4+DQo+ Pk9uIDQvMTgvMTIgMTA6MzAgQU0sICJMdWN5IHlvbmciIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxt YWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiB3cm90ZToNCj4+DQo+Pj5QbGVhc2Ugc2VlIGlu bGluZS4NCj4+Pg0KPj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IFNhbSBD YW8gW21haWx0bzp5dXF1bi5jYW9AZ21haWwuY29tPG1haWx0bzp5dXF1bi5jYW9AZ21haWwuY29t Pl0NCj4+PlNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE3LCAyMDEyIDc6MTQgQU0NCj4+PlRvOiAnRGFu aWVsIENvaG4nOyBMdWN5IHlvbmc7ICdSb2dlcnMsIEpvc2gnOyAnSGVuZGVyaWNreCwgV2ltIChX aW0pJzsNCj4+PmdpbGVzLmhlcm9uQGdtYWlsLmNvbTxtYWlsdG86Z2lsZXMuaGVyb25AZ21haWwu Y29tPjsgc2ltb24uZGVsb3JkQGdtYWlsLmNvbTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNv bT47DQo+Pj5BbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVy LlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQo+Pj5DYzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwy dnBuQGlldGYub3JnPjsgVmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbTxtYWlsdG86VmxhZGlt aXIuS2xlaW5lckBlY2l0ZWxlLmNvbT47DQo+Pj5BbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxt YWlsdG86QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb20+OyBJZGFuLkthc3BpdEBlY2l0ZWxlLmNv bTxtYWlsdG86SWRhbi5LYXNwaXRAZWNpdGVsZS5jb20+Ow0KPj4+TWlzaGFlbC5XZXhsZXJAZWNp dGVsZS5jb208bWFpbHRvOk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPjsgUm90ZW0uQ29oZW5A ZWNpdGVsZS5jb208bWFpbHRvOlJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPg0KPj4+U3ViamVjdDog UkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8N Cj4+Pg0KPj4+WWVzLCAyIHB3cyBhcmUgb25seSBuZWVkZWQgYmV0d2VlbiBwZXMgd2l0aCBib3Ro IHJvb3QgYW5kIGxlYWYgYWNzIGFmdGVyDQo+Pj5pbXByb3ZpbmcgRHVhbC1QVyBhcHByb2FjaC4g SWYgY29uc2lkZXIgUDJNUCwgRHVhbC1QVyBhcHByb2FjaCBzZXR1cCAyDQo+Pj5QMk1QDQo+Pj5Q V3MgaWYgbmVlZC4gVGhlcmUgaXMgbm8gZGlmZmVyZW5jZSBiZXR3ZWVuIFAyTVAgb3Igbm9ybWFs IFBXIHNldHVwLiBCdXQsDQo+Pj5jYW4gTGVhZi1BQ3MgYmUgYm91bmQgdG8gUm9vdCBQRSBvZiBQ Mk1QIFBXPw0KPj4+DQo+Pj5bW0xZXV0gTm8sIGl0IG1ha2VzIGNvbXBsZXggaW4gc2V0dGluZyB1 cCBQMk1QIFBXLiBTaG91bGQgYSBQRSB3aXRoIGJvdGgNCj4+PnJvb3QgYW5kIGxlYWYgQUNzIHNl dCB1cCB0d28gb3Igb25lIFAyTVAgUFcgdG8gb3RoZXIgUEVzIChzb21lIFBFIGhhdmUNCj4+PmJv dGggcm9vdCBhbmQgbGVhZiBBQyBhbmQgc29tZSBvbmx5IGhhdmUgbGVhZiBBQ3MpPw0KPj4+UmVn YXJkcywNCj4+Pkx1Y3kNCj4+Pg0KPj4+UmVnYXJkcywNCj4+Pg0KPj4+WXVxdW4gKFNhbSkgQ2Fv DQo+Pj5FLW1haWw6IFl1cXVuLmNhb0BnbWFpbC5jb208bWFpbHRvOll1cXVuLmNhb0BnbWFpbC5j b20+DQo+Pj4NCj4+Pg0KPj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IERh bmllbCBDb2huIFttYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tPG1haWx0bzpEYW5pZWxDQG9yY2tp dC5jb20+XQ0KPj4+U2VudDogVHVlc2RheSwgQXByaWwgMTcsIDIwMTIgNDo1NiBQTQ0KPj4+VG86 IEx1Y3kgeW9uZzsgUm9nZXJzLCBKb3NoOyBIZW5kZXJpY2t4LCBXaW0gKFdpbSk7DQo+Pj5naWxl cy5oZXJvbkBnbWFpbC5jb208bWFpbHRvOmdpbGVzLmhlcm9uQGdtYWlsLmNvbT47DQo+Pj5zaW1v bi5kZWxvcmRAZ21haWwuY29tPG1haWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPjsgQWxleGFu ZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tPjsgU2FtIENhbw0KPj4+Q2M6IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBp ZXRmLm9yZz47IFZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLkts ZWluZXJAZWNpdGVsZS5jb20+Ow0KPj4+QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb208bWFpbHRv OkFuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPjsgSWRhbi5LYXNwaXRAZWNpdGVsZS5jb208bWFp bHRvOklkYW4uS2FzcGl0QGVjaXRlbGUuY29tPjsNCj4+Pk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUu Y29tPG1haWx0bzpNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT47IFJvdGVtLkNvaGVuQGVjaXRl bGUuY29tPG1haWx0bzpSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbT4NCj4+PlN1YmplY3Q6IFJFOiBU aGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4N Cj4+PkFkZGluZyBTYW0gKGFzIGwydnBuQCBpcyBob2xkaW5nIG1lc3NhZ2VzKQ0KPj4+DQo+Pj5E Qw0KPj4+DQo+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+RnJvbTogTHVjeSB5b25n IFttYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29t Pl0NCj4+PlNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE3LCAyMDEyIDEyOjM5IEFNDQo+Pj5UbzogRGFu aWVsIENvaG47IFJvZ2VycywgSm9zaDsgSGVuZGVyaWNreCwgV2ltIChXaW0pOw0KPj4+Z2lsZXMu aGVyb25AZ21haWwuY29tPG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+OyBzaW1vbi5kZWxv cmRAZ21haWwuY29tPG1haWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPjsNCj4+PkFsZXhhbmRl ci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0 ZWxlLmNvbT4NCj4+PkNjOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBW bGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPG1haWx0bzpWbGFkaW1pci5LbGVpbmVyQGVjaXRl bGUuY29tPjsNCj4+PkFuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPG1haWx0bzpBbmRyZXcuU2Vy Z2VldkBlY2l0ZWxlLmNvbT47IElkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0bzpJZGFuLkth c3BpdEBlY2l0ZWxlLmNvbT47DQo+Pj5NaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbTxtYWlsdG86 TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb20+OyBSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbTxtYWls dG86Um90ZW0uQ29oZW5AZWNpdGVsZS5jb20+DQo+Pj5TdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBv ZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+DQo+Pj4NCj4+PlNu aXBwZWQsDQo+Pj4NCj4+PkFzIHdlIGRpc2N1c3NlZCBleHRlbnNpdmVseSBpbiB0aGUgbGlzdCwg YW5kIGFzIHJlZmxlY3RlZCBpbiBnaWxlcw0KPj4+c2xpZGUsIDIgcHdzIGFyZSBvbmx5IG5lZWRl ZCBiZXR3ZWVuIHBlcyB3aXRoIGJvdGggcm9vdCBhbmQgbGVhZiBhY3MsDQo+Pj53aGljaCB3aWxs IHR5cGljYWxseSBiZSBhIHNtYWxsIG1pbm9yaXR5Lg0KPj4+W1tMWV1dIERvbid0IGtub3cgaWYg dGhlIGFzc3VtcHRpb24gaXMgdHJ1ZS4gRXZlbiBpdCBpcyB0aGUgY2FzZSwgYm90aA0KPj4+YXBw cm9hY2hlcyBjYW4gYmVuZWZpdCBmcm9tIGl0LiBJIHdhcyBvZmYgZm9yIGEgd2hpbGUgYW5kIGNh cHR1cmVzIHNvbWUNCj4+PmRpc2N1c3Npb25zIG5vdy4NCj4+Pg0KPj4+QWxzbyBhcyBwZXIgZ2ls ZXMgc2xpZGUsIGR1YWwgdmxhbiBjYW4gaGF2ZSBzY2FsYWJpbGl0eSBpc3N1ZXMgZHVlIHRvDQo+ Pj5hZGRpdGlvbmFsIGxvb2t1cCBhbmQgZG91YmxlIHVzZSBvZiB2bGFucyBpbiBpbnRlcm5hbCBl bXVsYXRlZCBsYW4NCj4+PmludGVyZmFjZS4gQWxzbyB0aGVyZSBhcmUgcG90ZW50aWFsIGJhY2t3 YXJkIGNvbXBhdGliaWxpdHkgaXNzdWVzIHdpdGgNCj4+PnNpbGljb24gdGhhdCBkb2Vzbid0IHN1 cHBvcnQgdmxhbiBtYXBwaW5nLg0KPj4+W1tMWV1dIEkgd2FzIG5vdCBpbiBJRVRGODMgbWVldGlu ZyBhbmQgd2FpdCBvbiB0aGUgbWVldGluZyBtaW51dGVzLiBJIGFtDQo+Pj5ub3QgY2xlYXIgb24g YWxsIHRoZSBpc3N1ZXMuIENvdWxkIHlvdSBiZSBtb3JlIHNwZWNpZmljPyBBcyBJIG1lbnRpb25l ZA0KPj4+aW4gYmVsb3csIHR3byBQVyBhcHByb2FjaCBtYWtlcyBWUExTIHRyYW5zcG9ydCBjb25z dHJ1Y3Rpb24gYW5kIHBhY2tldA0KPj4+Zm9yd2FyZGluZyBtb3JlIGNvbXBsZXgsIEkgY2FuIHNl ZSBwb3RlbnRpYWwgYmFja3dhcmQgY29tcGF0aWJpbGl0eQ0KPj4+aXNzdWVzIHdpdGggMiBQVyBz b2x1dGlvbi4NCj4+Pg0KPj4+UmVnYXJkcywNCj4+Pkx1Y3kNCj4+Pg0KPj4+UmVnYXJkcywNCj4+ Pg0KPj4+RGFuaWVsDQo+Pj4NCj4+PlRodW1iIHR5cGVkIC0gcGxlYXNlIGJlIHRvbGVyYW50DQo+ Pj4NCj4+Pkx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0Bo dWF3ZWkuY29tPj4gd3JvdGU6DQo+Pj4NCj4+PkluIG15IG1pbmQsIHRoZSBWTEFOIGFwcHJvYWNo IG1lYW5zIGR1YWwgdmxhbiBtZXRob2QuDQo+Pj4NCj4+PlRoZSBtYWluIGNvbmNlcm4gZm9yIENX IGFwcHJvYWNoIGlzIGhhcmR3YXJlIHN1cHBvcnQuDQo+Pj4NCj4+PlR3byBQVyBhcHByb2FjaCBj YW4gYmUgY29tcGxleCB0b28gaWYgdGhlIFZQTFMgaW5zdGFuY2UgZm9yIEUtVHJlZSB1c2VzDQo+ Pj5QMlAgUFcgZm9yIHVuaWNhc3QgdHJhZmZpYyBhbmQgUDJNUCBQVyBmb3IgYnJvYWRjYXN0IGFu ZCB1bmtub3duIHVuaWNhc3QNCj4+PnRyYWZmaWMsIGFuZCBzb21lIFAyTVAgUFdzIGZvciBtdWx0 aWNhc3QgdHJhZmZpYy4gSXQgbWF5IGRvdWJsZSBhbGwgb2YNCj4+PnRoZW0uDQo+Pj4NCj4+PkUt dHJlZSBpcyBhbiBFdGhlcm5ldCBzZXJ2aWNlIGFuZCB0aGVyZSBpcyBhbHJlYWR5IFZMQU4gYmFz ZWQgc29sdXRpb24NCj4+PmluIElFRUUsIGNhbiB3ZSBqdXN0IHV0aWxpemUgaXQgd2l0aG91dCBj b21wbGljYXRpbmcgVlBMUyB0cmFuc3BvcnQNCj4+PmNvbnN0cnVjdGlvbj8gVGhpcyBhbHNvIG1h a2VzIGludGVyd29ya2luZyB3aXRoIEV0aCBvbmx5IG5ldHdvcmsgZWFzaWVyLg0KPj4+DQo+Pj5D aGVlcnMsDQo+Pj5MdWN5DQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5G cm9tOiBSb2dlcnMsIEpvc2ggW21haWx0bzpqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbTxtYWlsdG86 am9zaC5yb2dlcnNAdHdjYWJsZS5jb20+XQ0KPj4+U2VudDogTW9uZGF5LCBBcHJpbCAxNiwgMjAx MiA4OjM1IEFNDQo+Pj5UbzogTHVjeSB5b25nOyBIZW5kZXJpY2t4LCBXaW0gKFdpbSk7ICdnaWxl cy5oZXJvbkBnbWFpbC5jb208bWFpbHRvOmdpbGVzLmhlcm9uQGdtYWlsLmNvbT4nOw0KPj4+J3Np bW9uLmRlbG9yZEBnbWFpbC5jb208bWFpbHRvOnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+JzsgJ0Fs ZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbT4nDQo+Pj5DYzogJ2wydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRm Lm9yZz4nOyAnVmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbTxtYWlsdG86VmxhZGltaXIuS2xl aW5lckBlY2l0ZWxlLmNvbT4nOw0KPj4+J0FuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPG1haWx0 bzpBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbT4nOyAnSWRhbi5LYXNwaXRAZWNpdGVsZS5jb208 bWFpbHRvOklkYW4uS2FzcGl0QGVjaXRlbGUuY29tPic7DQo+Pj4nTWlzaGFlbC5XZXhsZXJAZWNp dGVsZS5jb208bWFpbHRvOk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPic7ICdSb3RlbS5Db2hl bkBlY2l0ZWxlLmNvbTxtYWlsdG86Um90ZW0uQ29oZW5AZWNpdGVsZS5jb20+Jw0KPj4+U3ViamVj dDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlv bj8NCj4+Pg0KPj4+SSBiZWxpZXZlIHRoZSBpbml0aWFsIHF1ZXN0aW9uIHdhcyBpbiByZWdhcmQg dG8gdGhlIENXIG1ldGhvZC4gIEFyZSB5b3UNCj4+PnNheWluZyB0aGF0IHlvdSBubyBsb25nZXIg YXJlIGludGVyZXN0ZWQgaW4gdGhhdCBtZXRob2QgaW4gcHJlZmVyZW5jZSBvZg0KPj4+dGhlIGR1 YWwgdmxhbiBtZXRob2Q/DQo+Pj4NCj4+Pg0KPj4+DQo+Pj5MdWN5IHlvbmcgPGx1Y3kueW9uZ0Bo dWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KPj4+DQo+Pj4N Cj4+PkFncmVlIHdpdGggV2ltLiBWTEFOIGFwcHJvYWNoIGlzIHRoZSBiZXN0IHNvbHV0aW9uIGZv ciBFLVRyZWUuDQo+Pj4NCj4+Pkx1Y3kNCj4+Pg0KPj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+PkZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJvdW5jZXNA aWV0Zi5vcmc+IFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bDJ2cG4tYm91 bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZg0KPj4+T2YgSGVuZGVyaWNreCwgV2ltIChXaW0pDQo+ Pj5TZW50OiBUaHVyc2RheSwgQXByaWwgMTIsIDIwMTIgMjowMyBBTQ0KPj4+VG86ICdnaWxlcy5o ZXJvbkBnbWFpbC5jb208bWFpbHRvOmdpbGVzLmhlcm9uQGdtYWlsLmNvbT4nOyAnc2ltb24uZGVs b3JkQGdtYWlsLmNvbTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT4nOw0KPj4+J0FsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbT4nDQo+Pj5DYzogJ2wydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9y Zz4nOyAnVmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbTxtYWlsdG86VmxhZGltaXIuS2xlaW5l ckBlY2l0ZWxlLmNvbT4nOw0KPj4+J0FuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPG1haWx0bzpB bmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbT4nOyAnSWRhbi5LYXNwaXRAZWNpdGVsZS5jb208bWFp bHRvOklkYW4uS2FzcGl0QGVjaXRlbGUuY29tPic7DQo+Pj4nTWlzaGFlbC5XZXhsZXJAZWNpdGVs ZS5jb208bWFpbHRvOk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPic7ICdSb3RlbS5Db2hlbkBl Y2l0ZWxlLmNvbTxtYWlsdG86Um90ZW0uQ29oZW5AZWNpdGVsZS5jb20+Jw0KPj4+U3ViamVjdDog UmU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8N Cj4+Pg0KPj4+VGhlIHZsYW4gYXBwcm9hY2ggaXMgc3VwZXJpb3IgYXMgaXQgYWxzbyB3b3JrcyBm b3IgZXRoIG9ubHkgbmV0d29ya3MsDQo+Pj5ldGMuIE9uIHRvcCBzb21lIHZlbmRvcnMgaW5kaWNh dGUgaHcgaXNzdWVzIHdpdGggdGhlIGN3IGFwcHJvYWNoLiBBcw0KPj4+c3VjaCB3ZSBoYXZlIGRy b3BwZWQgbW9yZSBvciBsZXNzIHRoZSBjdyBhcHByb2FjaC4NCj4+Pg0KPj4+Q2hlZXJzLA0KPj4+ V2ltDQo+Pj5fX19fX19fX19fX19fX19fXw0KPj4+c2VudCBmcm9tIGJsYWNrYmVycnkNCj4+Pg0K Pj4+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPj4+RnJvbTogR2lsZXMgSGVyb24gW21h aWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb208bWFpbHRvOmdpbGVzLmhlcm9uQGdtYWlsLmNvbT5d DQo+Pj5TZW50OiBUaHVyc2RheSwgQXByaWwgMTIsIDIwMTIgMDg6MjIgQU0NCj4+PlRvOiBTaW1v biBEZWxvcmQgPHNpbW9uLmRlbG9yZEBnbWFpbC5jb208bWFpbHRvOnNpbW9uLmRlbG9yZEBnbWFp bC5jb20+PjsgQWxleGFuZGVyIFZhaW5zaHRlaW4NCj4+PjxBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+Pg0KPj4+ Q2M6IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4gPGwydnBuQGlldGYub3Jn PG1haWx0bzpsMnZwbkBpZXRmLm9yZz4+OyBWbGFkaW1pciBLbGVpbmVyDQo+Pj48VmxhZGltaXIu S2xlaW5lckBlY2l0ZWxlLmNvbTxtYWlsdG86VmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbT4+ OyBBbmRyZXcgU2VyZ2Vldg0KPj4+PEFuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPG1haWx0bzpB bmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbT4+OyBJZGFuIEthc3BpdCA8SWRhbi5LYXNwaXRAZWNp dGVsZS5jb208bWFpbHRvOklkYW4uS2FzcGl0QGVjaXRlbGUuY29tPj47DQo+Pj5NaXNoYWVsIFdl eGxlciA8TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb208bWFpbHRvOk1pc2hhZWwuV2V4bGVyQGVj aXRlbGUuY29tPj47IFJvdGVtIENvaGVuDQo+Pj48Um90ZW0uQ29oZW5AZWNpdGVsZS5jb208bWFp bHRvOlJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPj4NCj4+PlN1YmplY3Q6IFJlOiBUaGUgc3RhdHVz IG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4NCj4+PlNvcnJ5 IC0gdGhlICJhbm9ueW1vdXMgcHJlc2VudGF0aW9uIiB3YXMgbWluZS4gIEkgc2hvdWxkIHBvc3Np Ymx5IGhhdmUNCj4+PnB1dCBpbiBhIHRoaXJkIGNvbHVtbiBvbiB0aGUgQ1cgYXBwcm9hY2guICBB bmQgaG9wZWZ1bGx5IHRoZSBtaW51dGVzDQo+Pj53aWxsIGJlIHBvc3RlZCBzb29uLg0KPj4+DQo+ Pj5XZSBoYWQgdmFyaW91cyBkaXNjdXNzaW9ucywgYXMgU2ltb24gc3RhdGVkLCBhbmQgY29uc2Vu c3VzIHNlZW1lZCB0byBiZQ0KPj4+Zm9ybWluZyBhcm91bmQgdGhlIHR3byBhbHRlcm5hdGl2ZXMg b2YgdHdvIFBXRXMgb3IgdHdvIFZMQU5zLiAgSSBiZWxpZXZlDQo+Pj50aHJlZSBvZiB0aGUgYXV0 aG9ycyBvZiB0aGUgQ1cgYXBwcm9hY2ggYXJlIGFsc28gYXV0aG9ycyBvZiB0aGUgdHdvIFZMQU4N Cj4+PmFwcHJvYWNoIGFuZCBvbmUgaXMgYWxzbyBhbiBhdXRob3Igb2YgdGhlIHR3byBQV0UgYXBw cm9hY2guIFNvIHBlcmhhcHMNCj4+Pml0J3MgYmVzdCB0byBsZXQgdGhvc2UgZm91ciBpbmRpdmlk dWFscyBzYXkgd2hpY2ggYXBwcm9hY2ggdGhleSBwcmVmZXINCj4+PmFuZCB3aHk/DQo+Pj4NCj4+ PkdpbGVzDQo+Pj4NCj4+Pk9uIDEwLzA0LzIwMTIgMDA6NDUsICJTaW1vbiBEZWxvcmQiIDxzaW1v bi5kZWxvcmRAZ21haWwuY29tPG1haWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPj4gd3JvdGU6 DQo+Pj4NCj4+Pj4gSGkgQWxleGFuZGVyLA0KPj4+Pg0KPj4+PiBZb3UgYXJlIHJpZ2h0LCBubyBk aXNjdXNzaW9uIG9uIHRoZSBXRyBtYWlsaW5nIGxpc3QgcmVjZW50bHksIGJ1dA0KPj4+PiB0aGVy ZSBoYXZlIGJlZW4gc3Vic3RhbnRpYWwgZGlzY3Vzc2lvbnMgYW1vbmcgdGhlIGF1dGhvcnMgb2Yg dmFyaW91cw0KPj4+PiBzb2x1dGlvbiBkcmFmdHMgb2ZmIHRoZSBtYWlsaW5nIGxpc3QuIEFzIGZh ciBhcyBJIGtub3csIG5vIGNvbnNlbnN1cw0KPj4+PiB5ZXQgYmVmb3JlIGlldGY4Mywgbm90IHN1 cmUgdGhlIHByb2dyZXNzIGluIHRoZSBQYXJpcyBXRyBtZWV0aW5nLiBJDQo+Pj4+IHRoaW5rIHRo ZSBDVyBhcHByb2FjaCBoYXMgbm90IGJlZW4gcmVqZWN0ZWQgYnkgdGhlIFdHIHlldCwgb3IgdGhl IFdHDQo+Pj4+IGhhcyBub3QgeWV0IGRlY2lkZWQgb24gd2hpY2ggb25lIHRvIGFkb3B0Lg0KPj4+ Pg0KPj4+PiBTaW1vbg0KPj4+Pg0KPj4+PiAyMDEyLzQvOCBBbGV4YW5kZXIgVmFpbnNodGVpbiA8 QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0 ZWluQGVjaXRlbGUuY29tPj4NCj4+Pj4NCj4+Pj4+ICBIaSBhbGwsDQo+Pj4+Pg0KPj4+Pj4gVW5m b3J0dW5hdGVseSBJIGhhdmUgbm90IGJlZW4gYWJsZSB0byBhdHRlbmQgdGhlIFBhcmlzIElFVEYu DQo+Pj4+Pg0KPj4+Pj4gSG93ZXZlciwgbG9va2luZyB1cCB0aGUgTDJWUE4gcHJvY2VlZGluZ3Ms IEkndmUgZm91bmQgYSBzaG9ydA0KPj4+Pj4gYW5vbnltb3VzIHByZXNlbnRhdGlvbiBjYWxsZWQg IkUtVHJlZSBVcGRhdGUiICAoDQo+Pj4+PiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdz LzgzL3NsaWRlcy9zbGlkZXMtODMtbDJ2cG4tMS5wcHR4KS4NCj4+Pj4+IFRoaXMgcHJlc2VudGF0 aW9uIGRpc2N1c3NlcyB0aGUgZGlmZmVyZW5jZXMgb2YgdGhlIEUtVHJlZSBhcHByb2FjaGVzDQo+ Pj4+PiBiYXNlZCBvbiBkZWRpY2F0ZWQgVkxBTnMgKGFzIGluDQo+Pj4+PiBodHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNhby1sMnZwbi12cGxzLWV0cmVlLz9pbmNsdWRlX3QN Cj4+Pj4+IGV4dD0xKSBhbmQgbXVsdGlwbGUgUFdzIGJldHdlZW4gdGhlIFBFcyAoYXMgaW4NCj4+ Pj4+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmFtLWwydnBuLWV0cmVl LW11bHRpcGxlLXB3Lz9pbg0KPj4+Pj4gY2x1ZGVfdGUNCj4+Pj4+IHh0PTEpDQo+Pj4+PiBhbmQg Y29tcGxldGVseSBpZ25vcmVzIHRoZSBzb2x1dGlvbiBiYXNlZCBvbiB1c2FnZSBvZiB0aGUgQ1cg aW4gdGhlDQo+Pj4+PiBQV3MgY29ubmVjdGluZyB0aGUgUEVzIChhcyBpbg0KPj4+Pj4gaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rZXktbDJ2cG4tdnBscy1ldHJlZS8/aW5j bHVkZV90DQo+Pj4+PiBleHQ9MQ0KPj4+Pj4gKS4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+ IFRoZSBNaW51dGVzIG9mIHRoZSBQYXJpcyBMMlZQTiBzZXNzaW9uIGFyZSBub3QgeWV0IGF2YWls YWJsZSwgYnV0IEkNCj4+Pj4+IHdvbmRlciB3aGV0aGVyIHRoZSBXRyBoYXMgdGFrZW4gYSBkZWNp c2lvbiB0byByZWplY3QgdGhlIGFwcHJvYWNoDQo+Pj4+PiBiYXNlZCBvbiB0aGUgQ1cgdXNhZ2U/ IEkgZG8gbm90IHJlbWVtYmVyIGFueSByZWNlbnQgZGlzY3Vzc2lvbiBvZg0KPj4+Pj4gdGhpcyB0 b3BpYyBvbiB0aGUgV0cgbWFpbGluZyBsaXN0Lg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4g UmVnYXJkcywgYW5kIGxvdHMgb2YgdGhhbmtzIGluIGFkdmFuY2UsDQo+Pj4+Pg0KPj4+Pj4gU2Fz aGENCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gVGhpcyBlLW1haWwg bWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucw0K Pj4+Pj4gaW5mb3JtYXRpb24gd2hpY2ggaXMgQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUg cHJvcHJpZXRhcnkgdG8gRUNJDQo+Pj4NCj4+Pj4+IFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UNCj4+Pj4+IGluZm9ybSB1cyBi eSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQN Cj4+Pj4+IGFsbCBjb3BpZXMgdGhlcmVvZi4NCj4+Pj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+ Pg0KPj4+VGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g VGltZSBXYXJuZXIgQ2FibGUNCj4+PnByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBw cml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QNCj4+PnRvIGNvcHlyaWdodCBiZWxv bmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkDQo+Pj5z b2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0 IGlzIGFkZHJlc3NlZC4NCj4+PklmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQg b2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5DQo+Pj5ub3RpZmllZCB0aGF0IGFueSBkaXNz ZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbg0KPj4+aW4g cmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFp bCBpcw0KPj4+c3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzDQo+Pj5FLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkNCj4+PmRlbGV0ZSB0aGUgb3JpZ2lu YWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo+Pj4NCj4+ DQo+Pg0KPj5UaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBUaW1lIFdhcm5lciBDYWJsZQ0KPj5wcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMg cHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvDQo+PmNvcHlyaWdodCBiZWxv bmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVs eQ0KPj5mb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQg aXMgYWRkcmVzc2VkLiBJZiB5b3UNCj4+YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9m IHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZA0KPj50aGF0IGFueSBkaXNzZW1p bmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbg0KPj5yZWxh dGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlz IHN0cmljdGx5DQo+PnByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4NCj4+ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZQ0KPj5vcmlnaW5hbCBhbmQg YW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCj4NCj4NCj4gVGhpcyBF LW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIg Q2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZp ZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVy IENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhl IGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJl Ynkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5n LCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRh Y2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUg dW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0 aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQu DQo+IFRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25s eSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggaXMgQ09ORklERU5USUFMIGFuZCB3aGlj aCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5IGUtbWFpbCwg cGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbGwgY29waWVz IHRoZXJlb2YuDQo+DQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMMnZw biBtYWlsaW5nIGxpc3QNCj4gTDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOkwydnBuQGlldGYub3JnPg0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wydnBuDQo+DQo+DQo+IEVu ZCBvZiBMMnZwbiBEaWdlc3QsIFZvbCA5NSwgSXNzdWUgMjUNCj4gKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioNCg== From DanielC@orckit.com Tue Apr 24 13:42:21 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A1A21F863D for ; Tue, 24 Apr 2012 13:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HS_INDEX_PARAM=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 JxJ468oTNjJ1 for ; Tue, 24 Apr 2012 13:42:19 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id F0B4521F8637 for ; Tue, 24 Apr 2012 13:42:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Date: Tue, 24 Apr 2012 23:44:24 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130777C63F@tlvmail1> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD52322358EB@EUSAACMS0703.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IAAHuPxAAACKFwAACIeb8AADgRjpAAAAlvAABrkMXAAAGzCAAAD3VNA= References: <169e01cd2256$b31c5660$05280101@corrigent.com> <60C093A41B5E45409A19D42CF7786DFD52322358EB@EUSAACMS0703.eamcs.ericsson.se> From: "Daniel Cohn" To: "David Allan I" , X-BeenThere: l2vpn@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, 24 Apr 2012 20:42:21 -0000 No, the thread is about S-VLAN ID preservation. -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com]=20 Sent: Tuesday, April 24, 2012 11:17 PM To: Daniel Cohn; l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Are you referring then to the C-tag.... It is preserved, NP Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: Tuesday, April 24, 2012 4:11 PM To: Fedyk, Donald (Don); Hernandez-Valencia, Enrique (Enrique); l2vpn@ietf.org Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Preservation requires egress =3D ingress vid - how does the egress pe = know what the ingress vid was, if the ingress vid was swapped at ingress? Thumb typed - please be tolerant "Fedyk, Donald (Don)" wrote: Dan In an E-Tree Model you have logically one VLAN on ingress and one on Egress. In the E-Tree you can use a Root or Leaf VID. (one or the other.) So you have: ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. Ingress VID does not have to equal Egress VID but regardless there is only ever one VID on a frame at a time. Don -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: Tuesday, April 24, 2012 12:58 PM To: Hernandez-Valencia, Enrique (Enrique); Sprecher, Nurit (NSN - IL/Hod HaSharon); Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? I don't know what kind of translation you propose but I don't see how you can preserve the original s-vlan id plus root/leaf in the same number of bits Thumb typed - please be tolerant "Hernandez-Valencia, Enrique (Enrique)" wrote: VLAN-ID preservation does not necessarily require a third VLAN-ID. VLAN-ID translation is sufficient. Enrique -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: Tuesday, April 24, 2012 7:17 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? No, the other way round. In the 2-VLAN solution, S-VLAN ID preservation requires adding a third VLAN ID. In the multi-PW solution, this is not required. DC -----Original Message----- From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.com] Sent: Tuesday, April 24, 2012 2:02 PM To: Daniel Cohn; Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Daniel, Is it so that you consider S-VAL stacking? If this is the case, are you aware that this is not in-line with the IEEE specifications? Best regard, Nurit -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of ext Daniel Cohn Sent: Tuesday, April 24, 2012 10:12 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, even if the current MEF framework doesn't require s-vlan preservation, I believe it's to the industry's benefit to adopt a solution that is not constrained to a specific enni model that, like all things networking, is likely to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service providers' inputs. It had a fair reason to assume S-VLAN over ENNI by then. It may open B-VLAN for the future. It is better for us not to discuss a future framework here, because it will lead us to nowhere. Here, we want to extend VPLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume that the VLAN tags at the E-NNI will always be according to the current MEF model? Or should we try to be as transparent as possible to user VLAN encapsulation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case VLAN tag) to signal VPLS information (in this case root/leaf origin) is necessarily tied to specific assumptions on user payload encapsulation (in this case, that S-VLAN tag is "available" to encode root/leaf). I don't think this is a future-proof assumption, it's very likely that other network models will come up that require S-VLAN preservation, which in the 2-VLAN approach would necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, "l2vpn@ietf.org" >, "Alexander.Vainshtein@ecitele.com" > Cc: "yuqun.cao@gmail.com" > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW will carry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > com>> > To: "Rogers, Josh" >, Lucy yong > >, Daniel Cohn >, Sam Cao > > > Cc: "l2vpn@ietf.org" > > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, but: > > IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes in the PE configuration. > > In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root AC from a PE that previously has been supporting a mix etc. affect only the PE where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org > [l2vpn-bounces@ietf.org] on behalf of > Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a > more complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become > more complex. > > Gile's comparison slide still concisely captures the differences > between these methods, in my opinion. I haven't seen any new ideas or > thoughts brought to the group in the past week or two on the subject. > I would hate for both proposed methods to die on the vine because we > couldn't decide between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree >>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may >>double all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn >>[mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the >>processing in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >>PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW >>(for traffic coming from a root AC) [[LY]] Not that simple. You >>construct either two P2MP PWs to all other PEs and let egress PE >>performing filtering, or construct one P2MP PW to leaf-only PEs and >>two P2MP PWs to root and leaf PEs and let ingress PE perform >>forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so >>don't feel terribly strong about this objection. Is this a real >>problem for others (now or in the future), or is this objection in the weeds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. >>I encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao >>>[mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>(Wim)'; giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>PE have both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn >>>[mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com>; Sam Cao >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong >>>[mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>both approaches can benefit from it. I was off for a while and >>>captures some discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues >>>with silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >>>am not clear on all the issues. Could you be more specific? As I >>>mentioned in below, two PW approach makes VPLS transport construction >>>and packet forwarding more complex, I can see potential backward >>>compatibility issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>double all of them. >>> >>>E-tree is an Ethernet service and there is already VLAN based >>>solution in IEEE, can we just utilize it without complicating VPLS >>>transport construction? This also makes interworking with Eth only network easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh >>>[mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); >>>'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are >>>you saying that you no longer are interested in that method in >>>preference of the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org >>>[mailto:l2vpn-bounces@ietf.org] On >>>Behalf Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron >>>[mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord >>>>; Alexander >>>Vainshtein >>>>>.com>> >>>Cc: l2vpn@ietf.org >>>>; Vladimir Kleiner >>>>; >>>Andrew Sergeev >>>>; Idan >>>Kaspit >; >>>Mishael Wexler >>>>; >>>Rotem Cohen > >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly >>>have put in a third column on the CW approach. And hopefully the >>>minutes will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to >>>be forming around the two alternatives of two PWEs or two VLANs. I >>>believe three of the authors of the CW approach are also authors of >>>the two VLAN approach and one is also an author of the two PWE >>>approach. So perhaps it's best to let those four individuals say >>>which approach they prefer and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of >>>> various solution drafts off the mailing list. As far as I know, no >>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>> meeting. I think the CW approach has not been rejected by the WG >>>> yet, or the WG has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein >>>> >>> le.com>> >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree >>>>> approaches based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/ >>>>> ?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in >>>>> the PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>> I wonder whether the WG has taken a decision to reject the >>>>> approach based on the CW usage? I do not remember any recent >>>>> discussion of this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and >>>>> contains information which is CONFIDENTIAL and which may be >>>>> proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original >>>>> and all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or >>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>intended solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail >>>is strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is >>addressed. If you are not the intended recipient of this E-mail, you >>are hereby notified that any dissemination, distribution, copying, or >>action taken in relation to the contents of and attachments to this >>E-mail is strictly prohibited and may be unlawful. If you have >>received this E-mail in error, please notify the sender immediately >>and permanently delete the original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** From DanielC@orckit.com Tue Apr 24 13:48:31 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199A411E8079 for ; Tue, 24 Apr 2012 13:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HS_INDEX_PARAM=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 dqY58kJhU4UH for ; Tue, 24 Apr 2012 13:48:29 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1CED911E8074 for ; Tue, 24 Apr 2012 13:48:27 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: The status of the approaches to the E-Tree solution? Date: Tue, 24 Apr 2012 23:50:34 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130777C640@tlvmail1> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IAAHuPxAAACKFwAACIeb8AADgRjpAAAAlvAABrkMXAAAB2eAAAERr7A= References: <169e01cd2256$b31c5660$05280101@corrigent.com> From: "Daniel Cohn" To: "Fedyk, Donald (Don)" , "Hernandez-Valencia, Enrique (Enrique)" , Cc: yuqun.cao@gmail.com X-BeenThere: l2vpn@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, 24 Apr 2012 20:48:31 -0000 Tm93IEkgc2VlIHdoZXJlIHRoZSBtaXN1bmRlcnN0YW5kaW5nIGxpZXMuIA0KDQpXaGVuIHRoZSB0 aHJlYWQgYWJvdXQgUy1WTEFOIHByZXNlcnZhdGlvbiBzdGFydGVkLCB0aGUgcXVlc3Rpb24gd2Fz IG5vdCBob3cgdG8gcHJlc2VydmUgYW4gUy1WTEFOIElEIGFkZGVkIGF0IHRoZSBFLU5OSSB0byBl bmNvZGUgcm9vdC9sZWFmLCBidXQgaG93IHRvIHByZXNlcnZlIGFuIGV4aXN0aW5nIFMtVkxBTiBJ RCB0aGF0IHdhcyBhZGRlZCB3aXRoIGFub3RoZXIsIG5vdCBuZWNlc3NhcmlseSBldHJlZS1yZWxh dGVkIHB1cnBvc2UuDQoNClF1b3RpbmcgU2hhaHJhbSdzIGUtbWFpbCBmcm9tIEFwciAyMCB0aGF0 IHN0YXJ0ZWQgdGhlIHRocmVhZCAtICJJIGFsc28gaGF2ZSBhIHF1ZXN0aW9uIHJlZ2FyZGluZyAy LVZMQU4uIFdoYXQgaWYgdGhlIGN1c3RvbWVyIHRyYWZmaWMgYWxyZWFkeSBoYXMgYW4gUy1WTEFO PyBEbyB3ZSBuZWVkIGEgM3JkIFZMQU4gdG8gaWRlbnRpZnkgdGhlIEwvUj8iDQoNCkhvcGUgdGhp cyBjbGFyaWZpZXMgaXQsDQoNCkRDDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBGZWR5aywgRG9uYWxkIChEb24pIFttYWlsdG86ZG9uYWxkLmZlZHlrQGFsY2F0ZWwtbHVjZW50 LmNvbV0gDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAyNCwgMjAxMiAxMToyMCBQTQ0KVG86IERhbmll bCBDb2huOyBIZXJuYW5kZXotVmFsZW5jaWEsIEVucmlxdWUgKEVucmlxdWUpOyBsMnZwbkBpZXRm Lm9yZw0KQ2M6IHl1cXVuLmNhb0BnbWFpbC5jb20NClN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9m IHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQoNCkRhbiwNCg0KVGhlcmUg aXMgYSBvbmUgdG8gb25lIG1hcHBpbmcgaW4gYm90aCBkaXJlY3Rpb25zLg0KSW5ncmVzcyA8LT4g cm9vdCBWSUQgPC0+IEVncmVzcyBWSUQNCkluZ3Jlc3MgPC0+IGxlYWYgVklEIDwtPiBFZ3Jlc3Mg VklEDQoNClRoZXJlZm9yZSBlYWNoIGVuZCBpcyBjb25maWd1cmVkIGFuZCBpZiB5b3Ugd2FudCBp bmdyZXNzIHRvIGVxdWFsIGluZ3Jlc3MgdGhlbiB5b3UgY29uZmlndXJlIGl0IHRoYXQgd2F5Lg0K DQpJZiB5b3UgYXJlIHRoaW5raW5nIGFib3V0IGEgbW9kZWwgdGhhdCBlbmNhcHN1bGF0ZXMgbXVs dGlwbGUgaW5ncmVzcyBWTEFOcyBvbiB0byBhIEV0cmVlLCB0aGVuIHlvdSB3b3VsZCBlbmNhcHN1 bGF0ZSBmaXJzdCBhbmQgdGhlIG91dGVyIGVuY2Fwc3VsYXRpb24gKFMtVEFHIGZvciBleGFtcGxl KSB3b3VsZCBiZSB0aGUgaW5ncmVzcy9lZ3Jlc3MgVklEcy4NCg0KVGhlbiB0aGUgY2hvaWNlIHRv IGVuY2Fwc3VsYXRlIGlzIHNlcGFyYXRlIGZyb20gdGhlIEUtVHJlZSBzZXJ2aWNlIHdoaWNoIHN0 aWxsIG9ubHkgdXNlcyBhIHNpbmdsZSBWSUQgcGVyIGZyYW1lLg0KDQpEb24NCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERhbmllbCBDb2huIFttYWlsdG86RGFuaWVsQ0BvcmNr aXQuY29tXQ0KU2VudDogVHVlc2RheSwgQXByaWwgMjQsIDIwMTIgNDoxMSBQTQ0KVG86IEZlZHlr LCBEb25hbGQgKERvbik7IEhlcm5hbmRlei1WYWxlbmNpYSwgRW5yaXF1ZSAoRW5yaXF1ZSk7IGwy dnBuQGlldGYub3JnDQpDYzogeXVxdW4uY2FvQGdtYWlsLmNvbQ0KU3ViamVjdDogUkU6IFRoZSBz dGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCg0KUHJlc2Vy dmF0aW9uIHJlcXVpcmVzIGVncmVzcyA9IGluZ3Jlc3MgdmlkIC0gaG93IGRvZXMgdGhlIGVncmVz cyBwZSBrbm93IHdoYXQgdGhlIGluZ3Jlc3MgdmlkIHdhcywgaWYgdGhlIGluZ3Jlc3MgdmlkIHdh cyBzd2FwcGVkIGF0IGluZ3Jlc3M/DQoNClRodW1iIHR5cGVkIC0gcGxlYXNlIGJlIHRvbGVyYW50 DQoNCiJGZWR5aywgRG9uYWxkIChEb24pIiA8ZG9uYWxkLmZlZHlrQGFsY2F0ZWwtbHVjZW50LmNv bT4gd3JvdGU6DQoNCkRhbg0KDQpJbiBhbiBFLVRyZWUgTW9kZWwgeW91IGhhdmUgbG9naWNhbGx5 IG9uZSBWTEFOIG9uIGluZ3Jlc3MgYW5kIG9uZSBvbiBFZ3Jlc3MuIEluIHRoZSBFLVRyZWUgeW91 IGNhbiB1c2UgYSBSb290IG9yIExlYWYgVklELiAob25lIG9yIHRoZSBvdGhlci4pDQoNClNvIHlv dSBoYXZlOg0KaW5ncmVzcyBWTEFOIElEIDwtPiBFdHJlZSBSb290L0xlYWYgVklEIDwtPiBFZ3Jl c3MgVklELg0KDQpJbmdyZXNzIFZJRCBkb2VzIG5vdCBoYXZlIHRvIGVxdWFsIEVncmVzcyBWSUQg YnV0IHJlZ2FyZGxlc3MgdGhlcmUgaXMgb25seSBldmVyIG9uZSBWSUQgb24gYSBmcmFtZSBhdCBh IHRpbWUuDQoNCkRvbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbDJ2cG4t Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBEYW5pZWwgQ29obg0KU2VudDogVHVlc2RheSwgQXByaWwgMjQsIDIwMTIgMTI6NTggUE0N ClRvOiBIZXJuYW5kZXotVmFsZW5jaWEsIEVucmlxdWUgKEVucmlxdWUpOyBTcHJlY2hlciwgTnVy aXQgKE5TTiAtIElML0hvZCBIYVNoYXJvbik7IEx1Y3kgeW9uZzsgUm9nZXJzLCBKb3NoOyBTaGFo cmFtIERhdmFyaTsgTGl6aG9uZyBKaW47IGwydnBuQGlldGYub3JnOyBBbGV4YW5kZXIuVmFpbnNo dGVpbkBlY2l0ZWxlLmNvbQ0KQ2M6IHl1cXVuLmNhb0BnbWFpbC5jb20NClN1YmplY3Q6IFJFOiBU aGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQoNCkkg ZG9uJ3Qga25vdyB3aGF0IGtpbmQgb2YgdHJhbnNsYXRpb24geW91IHByb3Bvc2UgYnV0IEkgZG9u J3Qgc2VlIGhvdyB5b3UgY2FuIHByZXNlcnZlIHRoZSBvcmlnaW5hbCBzLXZsYW4gaWQgcGx1cyBy b290L2xlYWYgaW4gdGhlIHNhbWUgbnVtYmVyIG9mIGJpdHMNCg0KVGh1bWIgdHlwZWQgLSBwbGVh c2UgYmUgdG9sZXJhbnQNCg0KIkhlcm5hbmRlei1WYWxlbmNpYSwgRW5yaXF1ZSAoRW5yaXF1ZSki IDxlbnJpcXVlLmhlcm5hbmRlekBhbGNhdGVsLWx1Y2VudC5jb20+IHdyb3RlOg0KDQpWTEFOLUlE IHByZXNlcnZhdGlvbiBkb2VzIG5vdCBuZWNlc3NhcmlseSByZXF1aXJlIGEgdGhpcmQgVkxBTi1J RC4gVkxBTi1JRCB0cmFuc2xhdGlvbiBpcyBzdWZmaWNpZW50Lg0KDQpFbnJpcXVlDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWls dG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhbmllbCBDb2huDQpTZW50 OiBUdWVzZGF5LCBBcHJpbCAyNCwgMjAxMiA3OjE3IEFNDQpUbzogU3ByZWNoZXIsIE51cml0IChO U04gLSBJTC9Ib2QgSGFTaGFyb24pOyBMdWN5IHlvbmc7IFJvZ2VycywgSm9zaDsgU2hhaHJhbSBE YXZhcmk7IExpemhvbmcgSmluOyBsMnZwbkBpZXRmLm9yZzsgQWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb20NCkNjOiB5dXF1bi5jYW9AZ21haWwuY29tDQpTdWJqZWN0OiBSRTogVGhlIHN0 YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KDQpObywgdGhl IG90aGVyIHdheSByb3VuZC4gSW4gdGhlIDItVkxBTiBzb2x1dGlvbiwgUy1WTEFOIElEIHByZXNl cnZhdGlvbiByZXF1aXJlcyBhZGRpbmcgYSB0aGlyZCBWTEFOIElELiBJbiB0aGUgbXVsdGktUFcg c29sdXRpb24sIHRoaXMgaXMgbm90IHJlcXVpcmVkLg0KDQpEQw0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogU3ByZWNoZXIsIE51cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24p IFttYWlsdG86bnVyaXQuc3ByZWNoZXJAbnNuLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDI0 LCAyMDEyIDI6MDIgUE0NClRvOiBEYW5pZWwgQ29objsgTHVjeSB5b25nOyBSb2dlcnMsIEpvc2g7 IFNoYWhyYW0gRGF2YXJpOyBMaXpob25nIEppbjsgbDJ2cG5AaWV0Zi5vcmc7IEFsZXhhbmRlci5W YWluc2h0ZWluQGVjaXRlbGUuY29tDQpDYzogeXVxdW4uY2FvQGdtYWlsLmNvbQ0KU3ViamVjdDog UkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8N Cg0KRGFuaWVsLA0KSXMgaXQgc28gdGhhdCB5b3UgY29uc2lkZXIgUy1WQUwgc3RhY2tpbmc/DQpJ ZiB0aGlzIGlzIHRoZSBjYXNlLCBhcmUgeW91IGF3YXJlIHRoYXQgdGhpcyBpcyBub3QgaW4tbGlu ZSB3aXRoIHRoZSBJRUVFIHNwZWNpZmljYXRpb25zPw0KQmVzdCByZWdhcmQsDQpOdXJpdA0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgRGFuaWVsIENv aG4NClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDI0LCAyMDEyIDEwOjEyIEFNDQpUbzogTHVjeSB5b25n OyBSb2dlcnMsIEpvc2g7IFNoYWhyYW0gRGF2YXJpOyBMaXpob25nIEppbjsgbDJ2cG5AaWV0Zi5v cmc7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQpDYzogeXVxdW4uY2FvQGdtYWls LmNvbQ0KU3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUt VHJlZSBzb2x1dGlvbj8NCg0KTHVjeSwNCg0KZXZlbiBpZiB0aGUgY3VycmVudCBNRUYgZnJhbWV3 b3JrIGRvZXNuJ3QgcmVxdWlyZSBzLXZsYW4gcHJlc2VydmF0aW9uLCBJIGJlbGlldmUgaXQncyB0 byB0aGUgaW5kdXN0cnkncyBiZW5lZml0IHRvIGFkb3B0IGEgc29sdXRpb24gdGhhdCBpcyBub3Qg Y29uc3RyYWluZWQgdG8gYSBzcGVjaWZpYyBlbm5pIG1vZGVsIHRoYXQsIGxpa2UgYWxsIHRoaW5n cyBuZXR3b3JraW5nLCBpcyBsaWtlbHkgdG8gZXZvbHZlLiBFc3BlY2lhbGx5IHdoZW4gc3VjaCBh IHNvbHV0aW9uIGlzIGF2YWlsYWJsZS4NCg0KRGFuaWVsDQoNClRodW1iIHR5cGVkIC0gcGxlYXNl IGJlIHRvbGVyYW50DQoNCkx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb20+IHdyb3RlOg0K DQpEYW5pZWwsDQoNCk1FRiBoYXMgd29ya2VkIGluIEVOTkkgaW50ZXJmYWNlIGZvciBhIGxvbmcg dGltZSB3aXRoIG1hbnkgc2VydmljZSBwcm92aWRlcnMnIGlucHV0cy4gSXQgaGFkIGEgZmFpciBy ZWFzb24gdG8gYXNzdW1lIFMtVkxBTiBvdmVyIEVOTkkgYnkgdGhlbi4gSXQgbWF5IG9wZW4gQi1W TEFOIGZvciB0aGUgZnV0dXJlLiBJdCBpcyBiZXR0ZXIgZm9yIHVzIG5vdCB0byBkaXNjdXNzICBh IGZ1dHVyZSBmcmFtZXdvcmsgaGVyZSwgYmVjYXVzZSBpdCB3aWxsIGxlYWQgdXMgdG8gbm93aGVy ZS4gSGVyZSwgd2Ugd2FudCB0byBleHRlbmQgVlBMUyBpbiBzdXBwb3J0aW5nIEUtVHJlZS4NCg0K QmVzdCBSZWdhcmRzLA0KTHVjeQ0KDQpGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWls dG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhbmllbCBDb2huDQpTZW50 OiBTdW5kYXksIEFwcmlsIDIyLCAyMDEyIDc6MzQgQU0NClRvOiBSb2dlcnMsIEpvc2g7IFNoYWhy YW0gRGF2YXJpOyBMaXpob25nIEppbjsgbDJ2cG5AaWV0Zi5vcmc7IEFsZXhhbmRlci5WYWluc2h0 ZWluQGVjaXRlbGUuY29tDQpDYzogeXVxdW4uY2FvQGdtYWlsLmNvbQ0KU3ViamVjdDogUkU6IFRo ZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCg0KU2hh aHJhbSBhbmQgYWxsLA0KDQpUaGlzIHF1ZXN0aW9uIGFscmVhZHkgY2FtZSB1cCBpbiBvdXIgZGlz Y3Vzc2lvbnMgLSBpcyBpdCBzYWZlIHRvIGFzc3VtZSB0aGF0IHRoZSBWTEFOIHRhZ3MgYXQgdGhl IEUtTk5JIHdpbGwgYWx3YXlzIGJlIGFjY29yZGluZyB0byB0aGUgY3VycmVudCBNRUYgbW9kZWw/ IE9yIHNob3VsZCB3ZSB0cnkgdG8gYmUgYXMgdHJhbnNwYXJlbnQgYXMgcG9zc2libGUgdG8gdXNl ciBWTEFOIGVuY2Fwc3VsYXRpb24gYXQgdGhlIEUtTk5JLCB0byBhY2NvbW1vZGF0ZSBmdXR1cmUg ZnJhbWV3b3Jrcz8NCkkgYmVsaWV2ZSB0aGF0IGFueSBhcHByb2FjaCB0aGF0IGxvb2tzIGF0IHVz ZXIgcGF5bG9hZCAoaW4gdGhpcyBjYXNlIFZMQU4gdGFnKSB0byBzaWduYWwgVlBMUyBpbmZvcm1h dGlvbiAoaW4gdGhpcyBjYXNlIHJvb3QvbGVhZiBvcmlnaW4pIGlzIG5lY2Vzc2FyaWx5IHRpZWQg dG8gc3BlY2lmaWMgYXNzdW1wdGlvbnMgb24gdXNlciBwYXlsb2FkIGVuY2Fwc3VsYXRpb24gKGlu IHRoaXMgY2FzZSwgdGhhdCBTLVZMQU4gdGFnIGlzICJhdmFpbGFibGUiIHRvIGVuY29kZSByb290 L2xlYWYpLiBJIGRvbid0IHRoaW5rIHRoaXMgaXMgYSBmdXR1cmUtcHJvb2YgYXNzdW1wdGlvbiwg aXQncyB2ZXJ5IGxpa2VseSB0aGF0IG90aGVyIG5ldHdvcmsgbW9kZWxzIHdpbGwgY29tZSB1cCB0 aGF0IHJlcXVpcmUgUy1WTEFOIHByZXNlcnZhdGlvbiwgd2hpY2ggaW4gdGhlIDItVkxBTiBhcHBy b2FjaCB3b3VsZCBuZWNlc3NpdGF0ZSBhZGRpbmcgYSB0aGlyZCBWTEFOLUlELg0KDQpEYW5pZWwN Cg0KRnJvbTogU2hhaHJhbSBEYXZhcmkgPGRhdmFyaUBicm9hZGNvbS5jb208bWFpbHRvOmRhdmFy aUBicm9hZGNvbS5jb20+Pg0KVG86IExpemhvbmcgSmluIDxsaXpoby5qaW5AZ21haWwuY29tPG1h aWx0bzpsaXpoby5qaW5AZ21haWwuY29tPj4sICJsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5A aWV0Zi5vcmc+IiA8bDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPj4sICJBbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb20+IiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFs ZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPj4NCkNjOiAieXVxdW4uY2FvQGdtYWlsLmNv bTxtYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbT4iIDx5dXF1bi5jYW9AZ21haWwuY29tPG1haWx0 bzp5dXF1bi5jYW9AZ21haWwuY29tPj4NClN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBh cHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQoNCkhpLA0KDQpJIGFsc28gaGF2ZSBh IHF1ZXN0aW9uIHJlZ2FyZGluZyAyLVZMQU4uIFdoYXQgaWYgdGhlIGN1c3RvbWVyIHRyYWZmaWMg YWxyZWFkeSBoYXMgYW4gUy1WTEFOPyBEbyB3ZSBuZWVkIGEgM3JkIFZMQU4gdG8gaWRlbnRpZnkg dGhlIEwvUj8NCg0KVGh4DQpTaGFocmFtDQoNCkZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIExpemhvbmcgSmluDQpTZW50OiBGcmlkYXksIEFwcmlsIDIwLCAy MDEyIDk6MzggQU0NClRvOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRl aW5AZWNpdGVsZS5jb20+DQpDYzogeXVxdW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86eXVxdW4uY2Fv QGdtYWlsLmNvbT4NClN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRv IHRoZSBFLVRyZWUgc29sdXRpb24/DQoNCkhpLCBhbGwsDQpUaGUgZGlmZmVyZW5jZSBiZXR3ZWVu IDItVkxBTiBhbmQgQ1cgYXBwcm9hY2ggaXMgd2hvIHdpbGwgcHJvdmlkZSB0aGUgUi9MIGluZm9y bWF0aW9uLCBjdXN0b21lciBwYXlsb2FkIG9yIFBXPyBUaGUgY3VzdG9tZXIgcGF5bG9hZCB3aWxs IGJlIGFsd2F5cyBtb2RpZmllZCB0byBjYXJyeSBSL0wgaW5mb3JtYXRpb24gaW4gMi1WTEFOIGFw cHJvYWNoLCB3aGlsZSBQVyB3aXRoIENXIHdpbGwgY2FycnkgUi9MIGluZm9ybWF0aW9uIGZvciBD VyBhcHByb2FjaC4NCkkgaGF2ZSBhIHF1ZXN0aW9uIHdpdGggdGhlIDItVkxBTiBhcHByb2FjaCBp biBILVZQTFMgd2hlcmUgSC1WUExTIGlzIGFjY2Vzc2VkIGJ5IFZQV1MgYXMgZGVzY3JpYmVkIGlu IFJGQzQ2NzIgc2VjdGlvbiAxMC4xLjMuIElmIFZQV1MgaXMgdXNlZCB0byBhY2Nlc3MgSC1WUExT LCBob3cgY291bGQgdGhlIFBFIG9uIFZQV1Mgc2lkZSBhZGRzIFZMQU4gdG8gaW5kaWNhdGUgUi9M IGluZm9ybWF0aW9uPw0KDQpUaGFua3MNCkxpemhvbmcNCg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4NCj4gTWVzc2FnZTogMg0KPiBEYXRlOiBUaHUsIDE5IEFwciAyMDEyIDA0 OjM4OjM2ICswMDAwDQo+IEZyb206IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFp bnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b20+Pg0KPiBUbzogIlJvZ2VycywgSm9zaCIgPGpvc2gucm9nZXJzQHR3Y2FibGUuY29tPG1haWx0 bzpqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbT4+LCBMdWN5IHlvbmcNCj4gICAgICAgIDxsdWN5Lnlv bmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiwgRGFuaWVsIENvaG4g PERhbmllbENAb3Jja2l0LmNvbTxtYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tPj4sIFNhbSBDYW8N Cj4gICAgICAgIDx5dXF1bi5jYW9AZ21haWwuY29tPG1haWx0bzp5dXF1bi5jYW9AZ21haWwuY29t Pj4NCj4gQ2M6ICJsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+IiA8bDJ2cG5A aWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPj4NCj4gU3ViamVjdDogUkU6IFRoZSBzdGF0 dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4gTWVzc2FnZS1J RDoNCj4gICAgICAgIDxGOTMzNjU3MTczMUFERTQyQTUzOTdGQzgzMUNFQUEwMjAzNDE5MkBGUklE V1BQTUIwMDIuZWNpdGVsZS5jb208bWFpbHRvOkY5MzM2NTcxNzMxQURFNDJBNTM5N0ZDODMxQ0VB QTAyMDM0MTkyQEZSSURXUFBNQjAwMi5lY2l0ZWxlLmNvbT4+DQo+IENvbnRlbnQtVHlwZTogdGV4 dC9wbGFpbjsgY2hhcnNldD0idXMtYXNjaWkiDQo+DQo+IEhpIGFsbCwNCj4gSSBmdWxseSB1bmRl cnN0YW5kIHRoYXQgdGhhdCB3aGF0IEkgYW0gZ29pbmcgdG8gc2F5IGlzIG5vdCB2ZXJ5IHBvcHVs YXIsIGJ1dDoNCj4NCj4gSU1PIG9uZSBvZiB0aGUgYWR2YW50YWdlcyBvZiB0aGUgQ1ctYmFzZWQg c29sdXRpb24gaXMgdGhhdCBpdCBpcyBvcnRob2dvbmFsIHRvIHVzYWdlIChvciBub24tdXNhZ2Up IG9mIFAyTVAgUFdzIGZvciBlZmZlY3RpdmUgZGVsaXZlcnkgb2YgQlVOIHRyYWZmaWMuDQo+DQo+ IEFub3RoZXIgYWR2YW50YWdlIGlzIHByZXNlcnZhdGlvbiBvZiBmdWxsIG1lc2ggb2YgUDJQIFBX cyBpbiBhIFZQTFMsIGFuZCwgaW4gYSBtb3JlIGdlbmVyaWMgd2F5LCBsb2NhbGl6YXRpb24gb2Yg ZWZmZWN0cyBvZiBjaGFuZ2VzIGluIHRoZSBQRSBjb25maWd1cmF0aW9uLg0KPg0KPiBJbiBwYXJ0 aWN1bGFyLCBhZGRpbmcgYSBMZWFmIEFDIHRvIGEgUEUgdGhhdCBwcmV2aW91c2x5IGhhcyBiZWVu IG9ubHkgc3VwcG9ydGluZyBSb290IEFDcyAob3IgdmljZSB2ZXJzYSksIHJlbW92YWwgb2YgdGhl IGxhc3QgTGVhZiBvciBsYXN0IFJvb3QgQUMgZnJvbSBhIFBFIHRoYXQgcHJldmlvdXNseSBoYXMg YmVlbiBzdXBwb3J0aW5nIGEgbWl4IGV0Yy4gYWZmZWN0IG9ubHkgdGhlIFBFIHdoZXJlIHRoaXMg b3BlcmF0aW9uIGhhcHBlbnMgYW5kIG5vdCB0aGUgcmVzdCBvZiB0aGUgUEVzLg0KPg0KPiBBcyBm b3IgdGhlIG5lZWQgZm9yIEhXIGNoYW5nZXMgdGhhdCBoYXZlIGJlZW4gbWVudGlvbmVkIGFzIGEg bWFpbiBkaXNhZHZhbnRhZ2Ugb2YgdGhlIENXLWJhc2VkIGFwcHJvYWNoIC0gSSBiZWxpZXZlIGl0 IHN0cm9uZ2x5IGRlcGVuZHMgb24gc3BlY2lmaWMgaW1wbGVtZW50YXRpb25zLiBBbmQgc29tZSBj aGFuZ2VzIGluIHRoZSBmb3J3YXJkaW5nIHByb2Nlc3MgYXJlIHJlcXVpcmVkIGluIGFueSBzb2x1 dGlvbi4NCj4NCj4gTXkgMmMsDQo+ICAgICBTYXNoYQ0KPg0KPg0KPg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc+IFtsMnZwbi1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnPl0gb24gYmVoYWxmIG9mIFJvZ2VycywgSm9z aCBbam9zaC5yb2dlcnNAdHdjYWJsZS5jb208bWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29t Pl0NCj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxOCwgMjAxMiA5OjU3IFBNDQo+IFRvOiBMdWN5 IHlvbmc7IERhbmllbCBDb2huOyBTYW0gQ2FvDQo+IENjOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86 bDJ2cG5AaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2Fj aGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+DQo+IEFnYWluLCB0aGUgUDJNUCBzaXR1YXRp b24gdGhyb3dzIG1lLiAgSXMgdGhpcyBzb21ldGhpbmcgdGhhdCBpcyB1c2VkDQo+IGNvbW1vbmx5 Pw0KPg0KPiBJJ20gdW5kZXIgdGhlIGltcHJlc3Npb24gdGhhdCBhZGRpbmcgUDJNUCB0byBhbnkg bW9kZWwgcmVzdWx0cyBpbiBhIG1vcmUNCj4gY29tcGxleCBtb2RlbC4gIFdldGhlciBvdXRzaWRl IHMtdGFnIGlzIHVzZWQgdG8gZGlmZmVyZW50aWF0ZSwgb3INCj4gZGVkaWNhdGVkIHB3J3MgYXJl IHVzZWQgZm9yIHRoZSBzYW1lIHB1cnBvc2UsIGl0IHNlZW1zIGJvdGggYmVjb21lIG1vcmUNCj4g Y29tcGxleC4NCj4NCj4gR2lsZSdzIGNvbXBhcmlzb24gc2xpZGUgc3RpbGwgY29uY2lzZWx5IGNh cHR1cmVzIHRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVuDQo+IHRoZXNlIG1ldGhvZHMsIGluIG15IG9w aW5pb24uICBJIGhhdmVuJ3Qgc2VlbiBhbnkgbmV3IGlkZWFzIG9yIHRob3VnaHRzDQo+IGJyb3Vn aHQgdG8gdGhlIGdyb3VwIGluIHRoZSBwYXN0IHdlZWsgb3IgdHdvIG9uIHRoZSBzdWJqZWN0LiAg SSB3b3VsZCBoYXRlDQo+IGZvciBib3RoIHByb3Bvc2VkIG1ldGhvZHMgdG8gZGllIG9uIHRoZSB2 aW5lIGJlY2F1c2Ugd2UgY291bGRuJ3QgZGVjaWRlDQo+IGJldHdlZW4gdHdvIG1ldGhvZHMgdGhh dCBoYXZlIG5vdGhpbmcgaW5oZXJlbnRseSB3cm9uZyB3aXRoIGVpdGhlci4NCj4NCj4gLUpvc2gN Cj4NCj4NCj4gT24gNC8xOC8xMiAxOjUzIFBNLCAiTHVjeSB5b25nIiA8bHVjeS55b25nQGh1YXdl aS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+DQo+PlNlbmQgdGhp cyBhZ2Fpbi4NCj4+DQo+PlR3byBQVyBhcHByb2FjaCBjYW4gYmUgY29tcGxleCB0b28gaWYgdGhl IFZQTFMgaW5zdGFuY2UgZm9yIEUtVHJlZSB1c2VzDQo+PlAyUCBQVyBmb3IgdW5pY2FzdCB0cmFm ZmljIGFuZCBQMk1QIFBXIGZvciBicm9hZGNhc3QgYW5kIHVua25vd24NCj4+dW5pY2FzdCB0cmFm ZmljLCBhbmQgc29tZSBQMk1QIFBXcyBmb3IgbXVsdGljYXN0IHRyYWZmaWMuIEl0IG1heSBkb3Vi bGUNCj4+YWxsIG9mIHRoZW0uDQo+Pg0KPj5MdWN5DQo+Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj5Gcm9tOiBEYW5pZWwgQ29obiBbbWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbTxt YWlsdG86RGFuaWVsQ0BvcmNraXQuY29tPl0NCj4+U2VudDogV2VkbmVzZGF5LCBBcHJpbCAxOCwg MjAxMiAxOjQyIFBNDQo+PlRvOiBMdWN5IHlvbmc7IFJvZ2VycywgSm9zaDsgU2FtIENhbw0KPj5D YzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPg0KPj5TdWJqZWN0OiBSRTog VGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4N Cj4+SSB0aGluayB0aGUgZmlyc3Qgb3B0aW9uIGl0cyB0aGUgbmF0dXJhbCB3YXkgdG8gZ28uIEhv dyBpcyB0aGUgcHJvY2Vzc2luZw0KPj5pbiB0aGlzIGNhc2UgbW9yZSBjb21wbGV4Pw0KPj4NCj4+ VGh1bWIgdHlwZWQgLSBwbGVhc2UgYmUgdG9sZXJhbnQNCj4+DQo+Pkx1Y3kgeW9uZyA8bHVjeS55 b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+Pg0K Pj4NCj4+DQo+PlNuaXBwZWQuLg0KPj4NCj4+TXVsdGktUFcgLSBPbiBpbmdyZXNzIFBFLCBmcmFt ZSBpcyBwbGFjZWQgb250byBlaXRoZXIgYSBMZWFmLW9ubHkgUDJNUCBQVw0KPj4oZm9yIHRyYWZm aWMgY29taW5nIGZyb20gYSBsZWFmIEFDKSwgb3Igb250byBhIFJvb3QvTGVhZiBQMk1QIFBXIChm b3INCj4+dHJhZmZpYyBjb21pbmcgZnJvbSBhIHJvb3QgQUMpDQo+PltbTFldXSBOb3QgdGhhdCBz aW1wbGUuIFlvdSBjb25zdHJ1Y3QgZWl0aGVyIHR3byBQMk1QIFBXcyB0byBhbGwgb3RoZXINCj4+ UEVzIGFuZCBsZXQgZWdyZXNzIFBFIHBlcmZvcm1pbmcgZmlsdGVyaW5nLCBvciBjb25zdHJ1Y3Qg b25lIFAyTVAgUFcgdG8NCj4+bGVhZi1vbmx5IFBFcyBhbmQgdHdvIFAyTVAgUFdzIHRvIHJvb3Qg YW5kIGxlYWYgUEVzIGFuZCBsZXQgaW5ncmVzcyBQRQ0KPj5wZXJmb3JtIGZvcndhcmRpbmcgYW5k IGZpbHRlcmluZy4gQm90aCBtYWtlIG5vZGUgcHJvY2VzcyBjb21wbGV4Lg0KPj4NCj4+W1tMWV1d IFZQTFMgaXMgYnVpbHQgd2l0aCB0aGUgbWVjaGFuaXNtIHV0aWxpemluZyBQMlAgYW5kIFAyTVAg UFcgZm9yDQo+PmRlbGl2ZXJpbmcgdGhlIGZyYW1lcyB0byByZW1vdGUgUEVzLiBXZSBzaG91bGQg dXRpbGl6ZSB0aGVtIHdpdGggdGhlDQo+Pm1pbmltaXplZCBjaGFuZ2VzLiBEdWFsIFZMQU4gc29s dXRpb24gaXMgc2ltcGxlciB0aGFuIER1YWwgUFcuDQo+Pg0KPj5SZWdhcmRzLA0KPj5MdWN5DQo+ Pg0KPj4NCj4+SSBzZWUgaG93IDJWTEFOIGlzIHNpbXBsZXIgd2hlbiBQMk1QIFBXJ3MgYXJlIGlu dm9sdmVkLCBJIHRoaW5rLiAgSQ0KPj5oYXZlbid0IGhhZCBhbnkgZmlyc3QgaGFuZCBleHBlcmll bmNlIHdpdGggUDJNUCBQVydzLCBob3dldmVyLCBzbyBkb24ndA0KPj5mZWVsIHRlcnJpYmx5IHN0 cm9uZyBhYm91dCB0aGlzIG9iamVjdGlvbi4gIElzIHRoaXMgYSByZWFsIHByb2JsZW0gZm9yDQo+ Pm90aGVycyAobm93IG9yIGluIHRoZSBmdXR1cmUpLCBvciBpcyB0aGlzIG9iamVjdGlvbiBpbiB0 aGUgd2VlZHM/DQo+Pg0KPj5JJ20gbm90IHN1cmUgdGhlICdhZGRpdGlvbmFsIGNvbXBsZXhpdHkn IGlzIG5vdGFibGUsIG9yIGV2ZW4gcmVsZXZhbnQuICBJDQo+PmVuY291cmFnZSBvdGhlcnMgdG8g c3BlYWsgdXAgaWYgdGhleSBkaXNhZ3JlZSwgYXMgUDJNUCBQVyBpcyBvbmx5DQo+PmNvbmNlcHR1 YWwgdG8gbWUsIGFuZCBJIGFtIHVuZmFtaWxpYXIgd2l0aCByZWFsLWxpZmUgdXNlIGNhc2VzIGZv ciBpdC4NCj4+DQo+PlRoYW5rcywNCj4+Sm9zaA0KPj4NCj4+DQo+Pg0KPj5PbiA0LzE4LzEyIDEw OjMwIEFNLCAiTHVjeSB5b25nIiA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9u Z0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+Pg0KPj4+UGxlYXNlIHNlZSBpbmxpbmUuDQo+Pj4NCj4+ Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBTYW0gQ2FvIFttYWlsdG86eXVx dW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbT5dDQo+Pj5TZW50OiBU dWVzZGF5LCBBcHJpbCAxNywgMjAxMiA3OjE0IEFNDQo+Pj5UbzogJ0RhbmllbCBDb2huJzsgTHVj eSB5b25nOyAnUm9nZXJzLCBKb3NoJzsgJ0hlbmRlcmlja3gsIFdpbSAoV2ltKSc7DQo+Pj5naWxl cy5oZXJvbkBnbWFpbC5jb208bWFpbHRvOmdpbGVzLmhlcm9uQGdtYWlsLmNvbT47IHNpbW9uLmRl bG9yZEBnbWFpbC5jb208bWFpbHRvOnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+Ow0KPj4+QWxleGFu ZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tPg0KPj4+Q2M6IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz47 IFZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJAZWNp dGVsZS5jb20+Ow0KPj4+QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb208bWFpbHRvOkFuZHJldy5T ZXJnZWV2QGVjaXRlbGUuY29tPjsgSWRhbi5LYXNwaXRAZWNpdGVsZS5jb208bWFpbHRvOklkYW4u S2FzcGl0QGVjaXRlbGUuY29tPjsNCj4+Pk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPG1haWx0 bzpNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT47IFJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPG1h aWx0bzpSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbT4NCj4+PlN1YmplY3Q6IFJFOiBUaGUgc3RhdHVz IG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4NCj4+Plllcywg MiBwd3MgYXJlIG9ubHkgbmVlZGVkIGJldHdlZW4gcGVzIHdpdGggYm90aCByb290IGFuZCBsZWFm IGFjcyBhZnRlcg0KPj4+aW1wcm92aW5nIER1YWwtUFcgYXBwcm9hY2guIElmIGNvbnNpZGVyIFAy TVAsIER1YWwtUFcgYXBwcm9hY2ggc2V0dXAgMg0KPj4+UDJNUA0KPj4+UFdzIGlmIG5lZWQuIFRo ZXJlIGlzIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBQMk1QIG9yIG5vcm1hbCBQVyBzZXR1cC4gQnV0 LA0KPj4+Y2FuIExlYWYtQUNzIGJlIGJvdW5kIHRvIFJvb3QgUEUgb2YgUDJNUCBQVz8NCj4+Pg0K Pj4+W1tMWV1dIE5vLCBpdCBtYWtlcyBjb21wbGV4IGluIHNldHRpbmcgdXAgUDJNUCBQVy4gU2hv dWxkIGEgUEUgd2l0aCBib3RoDQo+Pj5yb290IGFuZCBsZWFmIEFDcyBzZXQgdXAgdHdvIG9yIG9u ZSBQMk1QIFBXIHRvIG90aGVyIFBFcyAoc29tZSBQRSBoYXZlDQo+Pj5ib3RoIHJvb3QgYW5kIGxl YWYgQUMgYW5kIHNvbWUgb25seSBoYXZlIGxlYWYgQUNzKT8NCj4+PlJlZ2FyZHMsDQo+Pj5MdWN5 DQo+Pj4NCj4+PlJlZ2FyZHMsDQo+Pj4NCj4+Pll1cXVuIChTYW0pIENhbw0KPj4+RS1tYWlsOiBZ dXF1bi5jYW9AZ21haWwuY29tPG1haWx0bzpZdXF1bi5jYW9AZ21haWwuY29tPg0KPj4+DQo+Pj4N Cj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBEYW5pZWwgQ29obiBbbWFp bHRvOkRhbmllbENAb3Jja2l0LmNvbTxtYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tPl0NCj4+PlNl bnQ6IFR1ZXNkYXksIEFwcmlsIDE3LCAyMDEyIDQ6NTYgUE0NCj4+PlRvOiBMdWN5IHlvbmc7IFJv Z2VycywgSm9zaDsgSGVuZGVyaWNreCwgV2ltIChXaW0pOw0KPj4+Z2lsZXMuaGVyb25AZ21haWwu Y29tPG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+Ow0KPj4+c2ltb24uZGVsb3JkQGdtYWls LmNvbTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT47IEFsZXhhbmRlci5WYWluc2h0ZWlu QGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT47IFNh bSBDYW8NCj4+PkNjOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBWbGFk aW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPG1haWx0bzpWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUu Y29tPjsNCj4+PkFuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPG1haWx0bzpBbmRyZXcuU2VyZ2Vl dkBlY2l0ZWxlLmNvbT47IElkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0bzpJZGFuLkthc3Bp dEBlY2l0ZWxlLmNvbT47DQo+Pj5NaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbTxtYWlsdG86TWlz aGFlbC5XZXhsZXJAZWNpdGVsZS5jb20+OyBSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbTxtYWlsdG86 Um90ZW0uQ29oZW5AZWNpdGVsZS5jb20+DQo+Pj5TdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0 aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+DQo+Pj5BZGRpbmcgU2Ft IChhcyBsMnZwbkAgaXMgaG9sZGluZyBtZXNzYWdlcykNCj4+Pg0KPj4+REMNCj4+Pg0KPj4+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IEx1Y3kgeW9uZyBbbWFpbHRvOmx1Y3ku eW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT5dDQo+Pj5TZW50OiBU dWVzZGF5LCBBcHJpbCAxNywgMjAxMiAxMjozOSBBTQ0KPj4+VG86IERhbmllbCBDb2huOyBSb2dl cnMsIEpvc2g7IEhlbmRlcmlja3gsIFdpbSAoV2ltKTsNCj4+PmdpbGVzLmhlcm9uQGdtYWlsLmNv bTxtYWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tPjsgc2ltb24uZGVsb3JkQGdtYWlsLmNvbTxt YWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT47DQo+Pj5BbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQo+Pj5D YzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPjsgVmxhZGltaXIuS2xlaW5l ckBlY2l0ZWxlLmNvbTxtYWlsdG86VmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbT47DQo+Pj5B bmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5j b20+OyBJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbTxtYWlsdG86SWRhbi5LYXNwaXRAZWNpdGVsZS5j b20+Ow0KPj4+TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb208bWFpbHRvOk1pc2hhZWwuV2V4bGVy QGVjaXRlbGUuY29tPjsgUm90ZW0uQ29oZW5AZWNpdGVsZS5jb208bWFpbHRvOlJvdGVtLkNvaGVu QGVjaXRlbGUuY29tPg0KPj4+U3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNo ZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4+Pg0KPj4+DQo+Pj5TbmlwcGVkLA0KPj4+DQo+ Pj5BcyB3ZSBkaXNjdXNzZWQgZXh0ZW5zaXZlbHkgaW4gdGhlIGxpc3QsIGFuZCBhcyByZWZsZWN0 ZWQgaW4gZ2lsZXMNCj4+PnNsaWRlLCAyIHB3cyBhcmUgb25seSBuZWVkZWQgYmV0d2VlbiBwZXMg d2l0aCBib3RoIHJvb3QgYW5kIGxlYWYgYWNzLA0KPj4+d2hpY2ggd2lsbCB0eXBpY2FsbHkgYmUg YSBzbWFsbCBtaW5vcml0eS4NCj4+PltbTFldXSBEb24ndCBrbm93IGlmIHRoZSBhc3N1bXB0aW9u IGlzIHRydWUuIEV2ZW4gaXQgaXMgdGhlIGNhc2UsIGJvdGgNCj4+PmFwcHJvYWNoZXMgY2FuIGJl bmVmaXQgZnJvbSBpdC4gSSB3YXMgb2ZmIGZvciBhIHdoaWxlIGFuZCBjYXB0dXJlcyBzb21lDQo+ Pj5kaXNjdXNzaW9ucyBub3cuDQo+Pj4NCj4+PkFsc28gYXMgcGVyIGdpbGVzIHNsaWRlLCBkdWFs IHZsYW4gY2FuIGhhdmUgc2NhbGFiaWxpdHkgaXNzdWVzIGR1ZSB0bw0KPj4+YWRkaXRpb25hbCBs b29rdXAgYW5kIGRvdWJsZSB1c2Ugb2YgdmxhbnMgaW4gaW50ZXJuYWwgZW11bGF0ZWQgbGFuDQo+ Pj5pbnRlcmZhY2UuIEFsc28gdGhlcmUgYXJlIHBvdGVudGlhbCBiYWNrd2FyZCBjb21wYXRpYmls aXR5IGlzc3VlcyB3aXRoDQo+Pj5zaWxpY29uIHRoYXQgZG9lc24ndCBzdXBwb3J0IHZsYW4gbWFw cGluZy4NCj4+PltbTFldXSBJIHdhcyBub3QgaW4gSUVURjgzIG1lZXRpbmcgYW5kIHdhaXQgb24g dGhlIG1lZXRpbmcgbWludXRlcy4gSSBhbQ0KPj4+bm90IGNsZWFyIG9uIGFsbCB0aGUgaXNzdWVz LiBDb3VsZCB5b3UgYmUgbW9yZSBzcGVjaWZpYz8gQXMgSSBtZW50aW9uZWQNCj4+PmluIGJlbG93 LCB0d28gUFcgYXBwcm9hY2ggbWFrZXMgVlBMUyB0cmFuc3BvcnQgY29uc3RydWN0aW9uIGFuZCBw YWNrZXQNCj4+PmZvcndhcmRpbmcgbW9yZSBjb21wbGV4LCBJIGNhbiBzZWUgcG90ZW50aWFsIGJh Y2t3YXJkIGNvbXBhdGliaWxpdHkNCj4+Pmlzc3VlcyB3aXRoIDIgUFcgc29sdXRpb24uDQo+Pj4N Cj4+PlJlZ2FyZHMsDQo+Pj5MdWN5DQo+Pj4NCj4+PlJlZ2FyZHMsDQo+Pj4NCj4+PkRhbmllbA0K Pj4+DQo+Pj5UaHVtYiB0eXBlZCAtIHBsZWFzZSBiZSB0b2xlcmFudA0KPj4+DQo+Pj5MdWN5IHlv bmcgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+IHdy b3RlOg0KPj4+DQo+Pj5JbiBteSBtaW5kLCB0aGUgVkxBTiBhcHByb2FjaCBtZWFucyBkdWFsIHZs YW4gbWV0aG9kLg0KPj4+DQo+Pj5UaGUgbWFpbiBjb25jZXJuIGZvciBDVyBhcHByb2FjaCBpcyBo YXJkd2FyZSBzdXBwb3J0Lg0KPj4+DQo+Pj5Ud28gUFcgYXBwcm9hY2ggY2FuIGJlIGNvbXBsZXgg dG9vIGlmIHRoZSBWUExTIGluc3RhbmNlIGZvciBFLVRyZWUgdXNlcw0KPj4+UDJQIFBXIGZvciB1 bmljYXN0IHRyYWZmaWMgYW5kIFAyTVAgUFcgZm9yIGJyb2FkY2FzdCBhbmQgdW5rbm93biB1bmlj YXN0DQo+Pj50cmFmZmljLCBhbmQgc29tZSBQMk1QIFBXcyBmb3IgbXVsdGljYXN0IHRyYWZmaWMu IEl0IG1heSBkb3VibGUgYWxsIG9mDQo+Pj50aGVtLg0KPj4+DQo+Pj5FLXRyZWUgaXMgYW4gRXRo ZXJuZXQgc2VydmljZSBhbmQgdGhlcmUgaXMgYWxyZWFkeSBWTEFOIGJhc2VkIHNvbHV0aW9uDQo+ Pj5pbiBJRUVFLCBjYW4gd2UganVzdCB1dGlsaXplIGl0IHdpdGhvdXQgY29tcGxpY2F0aW5nIFZQ TFMgdHJhbnNwb3J0DQo+Pj5jb25zdHJ1Y3Rpb24/IFRoaXMgYWxzbyBtYWtlcyBpbnRlcndvcmtp bmcgd2l0aCBFdGggb25seSBuZXR3b3JrIGVhc2llci4NCj4+Pg0KPj4+Q2hlZXJzLA0KPj4+THVj eQ0KPj4+DQo+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+RnJvbTogUm9nZXJzLCBK b3NoIFttYWlsdG86am9zaC5yb2dlcnNAdHdjYWJsZS5jb208bWFpbHRvOmpvc2gucm9nZXJzQHR3 Y2FibGUuY29tPl0NCj4+PlNlbnQ6IE1vbmRheSwgQXByaWwgMTYsIDIwMTIgODozNSBBTQ0KPj4+ VG86IEx1Y3kgeW9uZzsgSGVuZGVyaWNreCwgV2ltIChXaW0pOyAnZ2lsZXMuaGVyb25AZ21haWwu Y29tPG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+JzsNCj4+PidzaW1vbi5kZWxvcmRAZ21h aWwuY29tPG1haWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPic7ICdBbGV4YW5kZXIuVmFpbnNo dGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+ Jw0KPj4+Q2M6ICdsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+JzsgJ1ZsYWRp bWlyLktsZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5j b20+JzsNCj4+PidBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3LlNlcmdl ZXZAZWNpdGVsZS5jb20+JzsgJ0lkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0bzpJZGFuLkth c3BpdEBlY2l0ZWxlLmNvbT4nOw0KPj4+J01pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPG1haWx0 bzpNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT4nOyAnUm90ZW0uQ29oZW5AZWNpdGVsZS5jb208 bWFpbHRvOlJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPicNCj4+PlN1YmplY3Q6IFJFOiBUaGUgc3Rh dHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4NCj4+Pkkg YmVsaWV2ZSB0aGUgaW5pdGlhbCBxdWVzdGlvbiB3YXMgaW4gcmVnYXJkIHRvIHRoZSBDVyBtZXRo b2QuICBBcmUgeW91DQo+Pj5zYXlpbmcgdGhhdCB5b3Ugbm8gbG9uZ2VyIGFyZSBpbnRlcmVzdGVk IGluIHRoYXQgbWV0aG9kIGluIHByZWZlcmVuY2Ugb2YNCj4+PnRoZSBkdWFsIHZsYW4gbWV0aG9k Pw0KPj4+DQo+Pj4NCj4+Pg0KPj4+THVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWls dG86bHVjeS55b25nQGh1YXdlaS5jb20+PiB3cm90ZToNCj4+Pg0KPj4+DQo+Pj5BZ3JlZSB3aXRo IFdpbS4gVkxBTiBhcHByb2FjaCBpcyB0aGUgYmVzdCBzb2x1dGlvbiBmb3IgRS1UcmVlLg0KPj4+ DQo+Pj5MdWN5DQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBs MnZwbi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnPiBbbWFp bHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc+ XSBPbiBCZWhhbGYNCj4+Pk9mIEhlbmRlcmlja3gsIFdpbSAoV2ltKQ0KPj4+U2VudDogVGh1cnNk YXksIEFwcmlsIDEyLCAyMDEyIDI6MDMgQU0NCj4+PlRvOiAnZ2lsZXMuaGVyb25AZ21haWwuY29t PG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+JzsgJ3NpbW9uLmRlbG9yZEBnbWFpbC5jb208 bWFpbHRvOnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+JzsNCj4+PidBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+Jw0K Pj4+Q2M6ICdsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+JzsgJ1ZsYWRpbWly LktsZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb20+ JzsNCj4+PidBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3LlNlcmdlZXZA ZWNpdGVsZS5jb20+JzsgJ0lkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0bzpJZGFuLkthc3Bp dEBlY2l0ZWxlLmNvbT4nOw0KPj4+J01pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPG1haWx0bzpN aXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT4nOyAnUm90ZW0uQ29oZW5AZWNpdGVsZS5jb208bWFp bHRvOlJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPicNCj4+PlN1YmplY3Q6IFJlOiBUaGUgc3RhdHVz IG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4NCj4+PlRoZSB2 bGFuIGFwcHJvYWNoIGlzIHN1cGVyaW9yIGFzIGl0IGFsc28gd29ya3MgZm9yIGV0aCBvbmx5IG5l dHdvcmtzLA0KPj4+ZXRjLiBPbiB0b3Agc29tZSB2ZW5kb3JzIGluZGljYXRlIGh3IGlzc3VlcyB3 aXRoIHRoZSBjdyBhcHByb2FjaC4gQXMNCj4+PnN1Y2ggd2UgaGF2ZSBkcm9wcGVkIG1vcmUgb3Ig bGVzcyB0aGUgY3cgYXBwcm9hY2guDQo+Pj4NCj4+PkNoZWVycywNCj4+PldpbQ0KPj4+X19fX19f X19fX19fX19fX18NCj4+PnNlbnQgZnJvbSBibGFja2JlcnJ5DQo+Pj4NCj4+Pi0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgLS0tLS0NCj4+PkZyb206IEdpbGVzIEhlcm9uIFttYWlsdG86Z2lsZXMuaGVy b25AZ21haWwuY29tPG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+XQ0KPj4+U2VudDogVGh1 cnNkYXksIEFwcmlsIDEyLCAyMDEyIDA4OjIyIEFNDQo+Pj5UbzogU2ltb24gRGVsb3JkIDxzaW1v bi5kZWxvcmRAZ21haWwuY29tPG1haWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPj47IEFsZXhh bmRlciBWYWluc2h0ZWluDQo+Pj48QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFp bHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPj4NCj4+PkNjOiBsMnZwbkBpZXRm Lm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+IDxsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5A aWV0Zi5vcmc+PjsgVmxhZGltaXIgS2xlaW5lcg0KPj4+PFZsYWRpbWlyLktsZWluZXJAZWNpdGVs ZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb20+PjsgQW5kcmV3IFNlcmdl ZXYNCj4+PjxBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3LlNlcmdlZXZA ZWNpdGVsZS5jb20+PjsgSWRhbiBLYXNwaXQgPElkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0 bzpJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbT4+Ow0KPj4+TWlzaGFlbCBXZXhsZXIgPE1pc2hhZWwu V2V4bGVyQGVjaXRlbGUuY29tPG1haWx0bzpNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT4+OyBS b3RlbSBDb2hlbg0KPj4+PFJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPG1haWx0bzpSb3RlbS5Db2hl bkBlY2l0ZWxlLmNvbT4+DQo+Pj5TdWJqZWN0OiBSZTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9h Y2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+DQo+Pj5Tb3JyeSAtIHRoZSAiYW5vbnlt b3VzIHByZXNlbnRhdGlvbiIgd2FzIG1pbmUuICBJIHNob3VsZCBwb3NzaWJseSBoYXZlDQo+Pj5w dXQgaW4gYSB0aGlyZCBjb2x1bW4gb24gdGhlIENXIGFwcHJvYWNoLiAgQW5kIGhvcGVmdWxseSB0 aGUgbWludXRlcw0KPj4+d2lsbCBiZSBwb3N0ZWQgc29vbi4NCj4+Pg0KPj4+V2UgaGFkIHZhcmlv dXMgZGlzY3Vzc2lvbnMsIGFzIFNpbW9uIHN0YXRlZCwgYW5kIGNvbnNlbnN1cyBzZWVtZWQgdG8g YmUNCj4+PmZvcm1pbmcgYXJvdW5kIHRoZSB0d28gYWx0ZXJuYXRpdmVzIG9mIHR3byBQV0VzIG9y IHR3byBWTEFOcy4gIEkgYmVsaWV2ZQ0KPj4+dGhyZWUgb2YgdGhlIGF1dGhvcnMgb2YgdGhlIENX IGFwcHJvYWNoIGFyZSBhbHNvIGF1dGhvcnMgb2YgdGhlIHR3byBWTEFODQo+Pj5hcHByb2FjaCBh bmQgb25lIGlzIGFsc28gYW4gYXV0aG9yIG9mIHRoZSB0d28gUFdFIGFwcHJvYWNoLiBTbyBwZXJo YXBzDQo+Pj5pdCdzIGJlc3QgdG8gbGV0IHRob3NlIGZvdXIgaW5kaXZpZHVhbHMgc2F5IHdoaWNo IGFwcHJvYWNoIHRoZXkgcHJlZmVyDQo+Pj5hbmQgd2h5Pw0KPj4+DQo+Pj5HaWxlcw0KPj4+DQo+ Pj5PbiAxMC8wNC8yMDEyIDAwOjQ1LCAiU2ltb24gRGVsb3JkIiA8c2ltb24uZGVsb3JkQGdtYWls LmNvbTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4+DQo+Pj4+IEhp IEFsZXhhbmRlciwNCj4+Pj4NCj4+Pj4gWW91IGFyZSByaWdodCwgbm8gZGlzY3Vzc2lvbiBvbiB0 aGUgV0cgbWFpbGluZyBsaXN0IHJlY2VudGx5LCBidXQNCj4+Pj4gdGhlcmUgaGF2ZSBiZWVuIHN1 YnN0YW50aWFsIGRpc2N1c3Npb25zIGFtb25nIHRoZSBhdXRob3JzIG9mIHZhcmlvdXMNCj4+Pj4g c29sdXRpb24gZHJhZnRzIG9mZiB0aGUgbWFpbGluZyBsaXN0LiBBcyBmYXIgYXMgSSBrbm93LCBu byBjb25zZW5zdXMNCj4+Pj4geWV0IGJlZm9yZSBpZXRmODMsIG5vdCBzdXJlIHRoZSBwcm9ncmVz cyBpbiB0aGUgUGFyaXMgV0cgbWVldGluZy4gSQ0KPj4+PiB0aGluayB0aGUgQ1cgYXBwcm9hY2gg aGFzIG5vdCBiZWVuIHJlamVjdGVkIGJ5IHRoZSBXRyB5ZXQsIG9yIHRoZSBXRw0KPj4+PiBoYXMg bm90IHlldCBkZWNpZGVkIG9uIHdoaWNoIG9uZSB0byBhZG9wdC4NCj4+Pj4NCj4+Pj4gU2ltb24N Cj4+Pj4NCj4+Pj4gMjAxMi80LzggQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWlu c2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bT4+DQo+Pj4+DQo+Pj4+PiAgSGkgYWxsLA0KPj4+Pj4NCj4+Pj4+IFVuZm9ydHVuYXRlbHkgSSBo YXZlIG5vdCBiZWVuIGFibGUgdG8gYXR0ZW5kIHRoZSBQYXJpcyBJRVRGLg0KPj4+Pj4NCj4+Pj4+ IEhvd2V2ZXIsIGxvb2tpbmcgdXAgdGhlIEwyVlBOIHByb2NlZWRpbmdzLCBJJ3ZlIGZvdW5kIGEg c2hvcnQNCj4+Pj4+IGFub255bW91cyBwcmVzZW50YXRpb24gY2FsbGVkICJFLVRyZWUgVXBkYXRl IiAgKA0KPj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84My9zbGlkZXMvc2xp ZGVzLTgzLWwydnBuLTEucHB0eCkuDQo+Pj4+PiBUaGlzIHByZXNlbnRhdGlvbiBkaXNjdXNzZXMg dGhlIGRpZmZlcmVuY2VzIG9mIHRoZSBFLVRyZWUgYXBwcm9hY2hlcw0KPj4+Pj4gYmFzZWQgb24g ZGVkaWNhdGVkIFZMQU5zIChhcyBpbg0KPj4+Pj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1jYW8tbDJ2cG4tdnBscy1ldHJlZS8/aW5jbHVkZV90DQo+Pj4+PiBleHQ9MSkg YW5kIG11bHRpcGxlIFBXcyBiZXR3ZWVuIHRoZSBQRXMgKGFzIGluDQo+Pj4+PiBodHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJhbS1sMnZwbi1ldHJlZS1tdWx0aXBsZS1wdy8/ aW4NCj4+Pj4+IGNsdWRlX3RlDQo+Pj4+PiB4dD0xKQ0KPj4+Pj4gYW5kIGNvbXBsZXRlbHkgaWdu b3JlcyB0aGUgc29sdXRpb24gYmFzZWQgb24gdXNhZ2Ugb2YgdGhlIENXIGluIHRoZQ0KPj4+Pj4g UFdzIGNvbm5lY3RpbmcgdGhlIFBFcyAoYXMgaW4NCj4+Pj4+IGh0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQta2V5LWwydnBuLXZwbHMtZXRyZWUvP2luY2x1ZGVfdA0KPj4+Pj4g ZXh0PTENCj4+Pj4+ICkuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBUaGUgTWludXRlcyBv ZiB0aGUgUGFyaXMgTDJWUE4gc2Vzc2lvbiBhcmUgbm90IHlldCBhdmFpbGFibGUsIGJ1dCBJDQo+ Pj4+PiB3b25kZXIgd2hldGhlciB0aGUgV0cgaGFzIHRha2VuIGEgZGVjaXNpb24gdG8gcmVqZWN0 IHRoZSBhcHByb2FjaA0KPj4+Pj4gYmFzZWQgb24gdGhlIENXIHVzYWdlPyBJIGRvIG5vdCByZW1l bWJlciBhbnkgcmVjZW50IGRpc2N1c3Npb24gb2YNCj4+Pj4+IHRoaXMgdG9waWMgb24gdGhlIFdH IG1haWxpbmcgbGlzdC4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFJlZ2FyZHMsIGFuZCBs b3RzIG9mIHRoYW5rcyBpbiBhZHZhbmNlLA0KPj4+Pj4NCj4+Pj4+IFNhc2hhDQo+Pj4+Pg0KPj4+ Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50 ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMNCj4+Pj4+IGluZm9ybWF0 aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRv IEVDSQ0KPj4+DQo+Pj4+PiBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5z bWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlDQo+Pj4+PiBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9u ZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kDQo+Pj4+PiBhbGwgY29w aWVzIHRoZXJlb2YuDQo+Pj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+PlRoaXMgRS1t YWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENh YmxlDQo+Pj5wcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29u ZmlkZW50aWFsLCBvciBzdWJqZWN0DQo+Pj50byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUg V2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZA0KPj4+c29sZWx5IGZvciB0aGUg dXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQu DQo+Pj5JZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWls LCB5b3UgYXJlIGhlcmVieQ0KPj4+bm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlz dHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4NCj4+PmluIHJlbGF0aW9uIHRvIHRo ZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMNCj4+PnN0cmlj dGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcw0KPj4+RS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIHBlcm1hbmVudGx5DQo+Pj5kZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29w eSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0KPj4+DQo+Pg0KPj4NCj4+VGhpcyBF LW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIg Q2FibGUNCj4+cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNv bmZpZGVudGlhbCwgb3Igc3ViamVjdCB0bw0KPj5jb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUg V2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkNCj4+Zm9yIHRoZSB1 c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4g SWYgeW91DQo+PmFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwg eW91IGFyZSBoZXJlYnkgbm90aWZpZWQNCj4+dGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJp YnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4NCj4+cmVsYXRpb24gdG8gdGhlIGNv bnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseQ0KPj5w cm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg RS1tYWlsIGluDQo+PmVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUNCj4+b3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRo aXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo+DQo+DQo+IFRoaXMgRS1tYWlsIGFuZCBhbnkg b2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0 YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1 YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBF LW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9y IGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRo YXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRh a2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhp cyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFu ZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0KPiBUaGlzIGUtbWFp bCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5z IGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3By aWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlz c2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwg YW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYWxsIGNvcGllcyB0aGVyZW9mLg0KPg0K Pg0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTDJ2cG4gbWFpbGluZyBsaXN0 DQo+IEwydnBuQGlldGYub3JnPG1haWx0bzpMMnZwbkBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sMnZwbg0KPg0KPg0KPiBFbmQgb2YgTDJ2cG4gRGln ZXN0LCBWb2wgOTUsIElzc3VlIDI1DQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqDQo= From david.i.allan@ericsson.com Tue Apr 24 13:49:05 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED6711E8079 for ; Tue, 24 Apr 2012 13:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 cCuBh6hMpIUD for ; Tue, 24 Apr 2012 13:49:04 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id C3AD811E8074 for ; Tue, 24 Apr 2012 13:49:03 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q3OKmgmD022665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Apr 2012 15:49:03 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.69]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 24 Apr 2012 16:48:49 -0400 From: David Allan I To: Daniel Cohn , "l2vpn@ietf.org" Date: Tue, 24 Apr 2012 16:48:48 -0400 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IAAHuPxAAACKFwAACIeb8AADgRjpAAAAlvAABrkMXAAAGzCAAAD3VNAAAAbE0A== Message-ID: <60C093A41B5E45409A19D42CF7786DFD5232235948@EUSAACMS0703.eamcs.ericsson.se> References: <169e01cd2256$b31c5660$05280101@corrigent.com> <60C093A41B5E45409A19D42CF7786DFD52322358EB@EUSAACMS0703.eamcs.ericsson.se> <44F4E579A764584EA9BDFD07D0CA08130777C63F@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130777C63F@tlvmail1> 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-BeenThere: l2vpn@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, 24 Apr 2012 20:49:06 -0000 Then, and I do not wish to sound rude, but I do not know what you are talki= ng about. The leaf to root S-tag is preserved. The root to root/leaf S-tag is preserv= ed. An individual frame can only be one or the other so only carries one S-= tag. The only exception being the option to symmetrically translate tags at admi= nistrative boundaries as is documented in 802.1ad. But that does not change= the semantics, simply the VIDs used. Cheers Dave -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Tuesday, April 24, 2012 4:44 PM To: David Allan I; l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? No, the thread is about S-VLAN ID preservation. -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Tuesday, April 24, 2012 11:17 PM To: Daniel Cohn; l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Are you referring then to the C-tag.... It is preserved, NP Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Tuesday, April 24, 2012 4:11 PM To: Fedyk, Donald (Don); Hernandez-Valencia, Enrique (Enrique); l2vpn@ietf.= org Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Preservation requires egress =3D ingress vid - how does the egress pe know = what the ingress vid was, if the ingress vid was swapped at ingress? Thumb typed - please be tolerant "Fedyk, Donald (Don)" wrote: Dan In an E-Tree Model you have logically one VLAN on ingress and one on Egress= . In the E-Tree you can use a Root or Leaf VID. (one or the other.) So you have: ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. Ingress VID does not have to equal Egress VID but regardless there is only = ever one VID on a frame at a time. Don -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Tuesday, April 24, 2012 12:58 PM To: Hernandez-Valencia, Enrique (Enrique); Sprecher, Nurit (NSN - IL/Hod Ha= Sharon); Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.o= rg; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? I don't know what kind of translation you propose but I don't see how you c= an preserve the original s-vlan id plus root/leaf in the same number of bit= s Thumb typed - please be tolerant "Hernandez-Valencia, Enrique (Enrique)" wrote: VLAN-ID preservation does not necessarily require a third VLAN-ID. VLAN-ID translation is sufficient. Enrique -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Tuesday, April 24, 2012 7:17 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Lucy yong; Rogers, Josh; Shahr= am Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? No, the other way round. In the 2-VLAN solution, S-VLAN ID preservation req= uires adding a third VLAN ID. In the multi-PW solution, this is not require= d. DC -----Original Message----- From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.co= m] Sent: Tuesday, April 24, 2012 2:02 PM To: Daniel Cohn; Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vp= n@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Daniel, Is it so that you consider S-VAL stacking? If this is the case, are you aware that this is not in-line with the IEEE s= pecifications? Best regard, Nurit -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of e= xt Daniel Cohn Sent: Tuesday, April 24, 2012 10:12 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, even if the current MEF framework doesn't require s-vlan preservation, I be= lieve it's to the industry's benefit to adopt a solution that is not constr= ained to a specific enni model that, like all things networking, is likely = to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service provider= s' inputs. It had a fair reason to assume S-VLAN over ENNI by then. It may = open B-VLAN for the future. It is better for us not to discuss a future fr= amework here, because it will lead us to nowhere. Here, we want to extend VPLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Va= inshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume tha= t the VLAN tags at the E-NNI will always be according to the current MEF mo= del? Or should we try to be as transparent as possible to user VLAN encapsu= lation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case VLAN t= ag) to signal VPLS information (in this case root/leaf origin) is necessari= ly tied to specific assumptions on user payload encapsulation (in this case= , that S-VLAN tag is "available" to encode root/leaf). I don't think this i= s a future-proof assumption, it's very likely that other network models wil= l come up that require S-VLAN preservation, which in the 2-VLAN approach wo= uld necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, "l2vpn@ietf.org" >, "Alexander.Vainshtein@ecitele.com" > Cc: "yuqun.cao@gmail.com" > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic alrea= dy has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L i= nformation, customer payload or PW? The customer payload will be always mod= ified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is access= ed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informati= on? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > com>> > To: "Rogers, Josh" >, Lucy yong > >, Daniel Cohn >, Sam Cao > > > Cc: "l2vpn@ietf.org" > > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, but: > > IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BU= N traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes in the PE co= nfiguration. > > In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root = AC from a PE that previously has been supporting a mix etc. affect only the= PE where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on sp= ecific implementations. And some changes in the forwarding process are requ= ired in any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org > [l2vpn-bounces@ietf.org] on behalf of > Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a > more complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become > more complex. > > Gile's comparison slide still concisely captures the differences > between these methods, in my opinion. I haven't seen any new ideas or > thoughts brought to the group in the past week or two on the subject. > I would hate for both proposed methods to die on the vine because we > couldn't decide between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree >>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may >>double all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn >>[mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the >>processing in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >>PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW >>(for traffic coming from a root AC) [[LY]] Not that simple. You >>construct either two P2MP PWs to all other PEs and let egress PE >>performing filtering, or construct one P2MP PW to leaf-only PEs and >>two P2MP PWs to root and leaf PEs and let ingress PE perform >>forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so >>don't feel terribly strong about this objection. Is this a real >>problem for others (now or in the future), or is this objection in the weeds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. >>I encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao >>>[mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>(Wim)'; giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>PE have both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn >>>[mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com>; Sam Cao >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong >>>[mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>both approaches can benefit from it. I was off for a while and >>>captures some discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues >>>with silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >>>am not clear on all the issues. Could you be more specific? As I >>>mentioned in below, two PW approach makes VPLS transport construction >>>and packet forwarding more complex, I can see potential backward >>>compatibility issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>double all of them. >>> >>>E-tree is an Ethernet service and there is already VLAN based >>>solution in IEEE, can we just utilize it without complicating VPLS >>>transport construction? This also makes interworking with Eth only network easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh >>>[mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); >>>'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are >>>you saying that you no longer are interested in that method in >>>preference of the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org >>>[mailto:l2vpn-bounces@ietf.org] On >>>Behalf Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron >>>[mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord >>>>; Alexander >>>Vainshtein >>>>>.com>> >>>Cc: l2vpn@ietf.org >>>>; Vladimir Kleiner >>>>; >>>Andrew Sergeev >>>>; Idan >>>Kaspit >; >>>Mishael Wexler >>>>; >>>Rotem Cohen > >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly >>>have put in a third column on the CW approach. And hopefully the >>>minutes will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to >>>be forming around the two alternatives of two PWEs or two VLANs. I >>>believe three of the authors of the CW approach are also authors of >>>the two VLAN approach and one is also an author of the two PWE >>>approach. So perhaps it's best to let those four individuals say >>>which approach they prefer and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of >>>> various solution drafts off the mailing list. As far as I know, no >>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>> meeting. I think the CW approach has not been rejected by the WG >>>> yet, or the WG has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein >>>> >>> le.com>> >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree >>>>> approaches based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/ >>>>> ?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in >>>>> the PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>> I wonder whether the WG has taken a decision to reject the >>>>> approach based on the CW usage? I do not remember any recent >>>>> discussion of this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and >>>>> contains information which is CONFIDENTIAL and which may be >>>>> proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original >>>>> and all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or >>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>intended solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail >>>is strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is >>addressed. If you are not the intended recipient of this E-mail, you >>are hereby notified that any dissemination, distribution, copying, or >>action taken in relation to the contents of and attachments to this >>E-mail is strictly prohibited and may be unlawful. If you have >>received this E-mail in error, please notify the sender immediately >>and permanently delete the original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to c= opyright belonging to Time Warner Cable. This E-mail is intended solely for= the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notifi= ed that any dissemination, distribution, copying, or action taken in relati= on to the contents of and attachments to this E-mail is strictly prohibited= and may be unlawful. If you have received this E-mail in error, please not= ify the sender immediately and permanently delete the original and any copy= of this E-mail and any printout. > This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telec= om. If you have received this transmission in error, please inform us by e-= mail, phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** From DanielC@orckit.com Tue Apr 24 13:50:36 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454D511E8079 for ; Tue, 24 Apr 2012 13:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HS_INDEX_PARAM=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 9yYUANsYWTNh for ; Tue, 24 Apr 2012 13:50:34 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1956911E8074 for ; Tue, 24 Apr 2012 13:50:32 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Date: Tue, 24 Apr 2012 23:52:38 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130777C641@tlvmail1> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD5232235948@EUSAACMS0703.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IAAHuPxAAACKFwAACIeb8AADgRjpAAAAlvAABrkMXAAAGzCAAAD3VNAAAAbE0AAAP0Ig References: <169e01cd2256$b31c5660$05280101@corrigent.com> <60C093A41B5E45409A19D42CF7786DFD52322358EB@EUSAACMS0703.eamcs.ericsson.se> <44F4E579A764584EA9BDFD07D0CA08130777C63F@tlvmail1> <60C093A41B5E45409A19D42CF7786DFD5232235948@EUSAACMS0703.eamcs.ericsson.se> From: "Daniel Cohn" To: "David Allan I" , X-BeenThere: l2vpn@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, 24 Apr 2012 20:50:36 -0000 None taken ;-) I think the e-mail I just sent will help clarify the point. DC -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com]=20 Sent: Tuesday, April 24, 2012 11:49 PM To: Daniel Cohn; l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Then, and I do not wish to sound rude, but I do not know what you are talking about. The leaf to root S-tag is preserved. The root to root/leaf S-tag is preserved. An individual frame can only be one or the other so only carries one S-tag. The only exception being the option to symmetrically translate tags at administrative boundaries as is documented in 802.1ad. But that does not change the semantics, simply the VIDs used. Cheers Dave -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Tuesday, April 24, 2012 4:44 PM To: David Allan I; l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? No, the thread is about S-VLAN ID preservation. -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Tuesday, April 24, 2012 11:17 PM To: Daniel Cohn; l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Are you referring then to the C-tag.... It is preserved, NP Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: Tuesday, April 24, 2012 4:11 PM To: Fedyk, Donald (Don); Hernandez-Valencia, Enrique (Enrique); l2vpn@ietf.org Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Preservation requires egress =3D ingress vid - how does the egress pe = know what the ingress vid was, if the ingress vid was swapped at ingress? Thumb typed - please be tolerant "Fedyk, Donald (Don)" wrote: Dan In an E-Tree Model you have logically one VLAN on ingress and one on Egress. In the E-Tree you can use a Root or Leaf VID. (one or the other.) So you have: ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. Ingress VID does not have to equal Egress VID but regardless there is only ever one VID on a frame at a time. Don -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: Tuesday, April 24, 2012 12:58 PM To: Hernandez-Valencia, Enrique (Enrique); Sprecher, Nurit (NSN - IL/Hod HaSharon); Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? I don't know what kind of translation you propose but I don't see how you can preserve the original s-vlan id plus root/leaf in the same number of bits Thumb typed - please be tolerant "Hernandez-Valencia, Enrique (Enrique)" wrote: VLAN-ID preservation does not necessarily require a third VLAN-ID. VLAN-ID translation is sufficient. Enrique -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: Tuesday, April 24, 2012 7:17 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? No, the other way round. In the 2-VLAN solution, S-VLAN ID preservation requires adding a third VLAN ID. In the multi-PW solution, this is not required. DC -----Original Message----- From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.com] Sent: Tuesday, April 24, 2012 2:02 PM To: Daniel Cohn; Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Daniel, Is it so that you consider S-VAL stacking? If this is the case, are you aware that this is not in-line with the IEEE specifications? Best regard, Nurit -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of ext Daniel Cohn Sent: Tuesday, April 24, 2012 10:12 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, even if the current MEF framework doesn't require s-vlan preservation, I believe it's to the industry's benefit to adopt a solution that is not constrained to a specific enni model that, like all things networking, is likely to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service providers' inputs. It had a fair reason to assume S-VLAN over ENNI by then. It may open B-VLAN for the future. It is better for us not to discuss a future framework here, because it will lead us to nowhere. Here, we want to extend VPLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume that the VLAN tags at the E-NNI will always be according to the current MEF model? Or should we try to be as transparent as possible to user VLAN encapsulation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case VLAN tag) to signal VPLS information (in this case root/leaf origin) is necessarily tied to specific assumptions on user payload encapsulation (in this case, that S-VLAN tag is "available" to encode root/leaf). I don't think this is a future-proof assumption, it's very likely that other network models will come up that require S-VLAN preservation, which in the 2-VLAN approach would necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, "l2vpn@ietf.org" >, "Alexander.Vainshtein@ecitele.com" > Cc: "yuqun.cao@gmail.com" > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW will carry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > com>> > To: "Rogers, Josh" >, Lucy yong > >, Daniel Cohn >, Sam Cao > > > Cc: "l2vpn@ietf.org" > > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, but: > > IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes in the PE configuration. > > In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root AC from a PE that previously has been supporting a mix etc. affect only the PE where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org > [l2vpn-bounces@ietf.org] on behalf of > Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a > more complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become > more complex. > > Gile's comparison slide still concisely captures the differences > between these methods, in my opinion. I haven't seen any new ideas or > thoughts brought to the group in the past week or two on the subject. > I would hate for both proposed methods to die on the vine because we > couldn't decide between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree >>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may >>double all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn >>[mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the >>processing in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >>PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW >>(for traffic coming from a root AC) [[LY]] Not that simple. You >>construct either two P2MP PWs to all other PEs and let egress PE >>performing filtering, or construct one P2MP PW to leaf-only PEs and >>two P2MP PWs to root and leaf PEs and let ingress PE perform >>forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so >>don't feel terribly strong about this objection. Is this a real >>problem for others (now or in the future), or is this objection in the weeds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. >>I encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao >>>[mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>(Wim)'; giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>PE have both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn >>>[mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com>; Sam Cao >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong >>>[mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>both approaches can benefit from it. I was off for a while and >>>captures some discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues >>>with silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >>>am not clear on all the issues. Could you be more specific? As I >>>mentioned in below, two PW approach makes VPLS transport construction >>>and packet forwarding more complex, I can see potential backward >>>compatibility issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>double all of them. >>> >>>E-tree is an Ethernet service and there is already VLAN based >>>solution in IEEE, can we just utilize it without complicating VPLS >>>transport construction? This also makes interworking with Eth only network easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh >>>[mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); >>>'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are >>>you saying that you no longer are interested in that method in >>>preference of the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org >>>[mailto:l2vpn-bounces@ietf.org] On >>>Behalf Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron >>>[mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord >>>>; Alexander >>>Vainshtein >>>>>.com>> >>>Cc: l2vpn@ietf.org >>>>; Vladimir Kleiner >>>>; >>>Andrew Sergeev >>>>; Idan >>>Kaspit >; >>>Mishael Wexler >>>>; >>>Rotem Cohen > >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly >>>have put in a third column on the CW approach. And hopefully the >>>minutes will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to >>>be forming around the two alternatives of two PWEs or two VLANs. I >>>believe three of the authors of the CW approach are also authors of >>>the two VLAN approach and one is also an author of the two PWE >>>approach. So perhaps it's best to let those four individuals say >>>which approach they prefer and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of >>>> various solution drafts off the mailing list. As far as I know, no >>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>> meeting. I think the CW approach has not been rejected by the WG >>>> yet, or the WG has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein >>>> >>> le.com>> >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree >>>>> approaches based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/ >>>>> ?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in >>>>> the PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>> I wonder whether the WG has taken a decision to reject the >>>>> approach based on the CW usage? I do not remember any recent >>>>> discussion of this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and >>>>> contains information which is CONFIDENTIAL and which may be >>>>> proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original >>>>> and all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or >>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>intended solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail >>>is strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is >>addressed. If you are not the intended recipient of this E-mail, you >>are hereby notified that any dissemination, distribution, copying, or >>action taken in relation to the contents of and attachments to this >>E-mail is strictly prohibited and may be unlawful. If you have >>received this E-mail in error, please notify the sender immediately >>and permanently delete the original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** From david.i.allan@ericsson.com Tue Apr 24 13:56:12 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6829E21F8628 for ; Tue, 24 Apr 2012 13:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 FIgu2T3wJETV for ; Tue, 24 Apr 2012 13:56:10 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3899F21F85F8 for ; Tue, 24 Apr 2012 13:56:10 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3OKu8Fj012233; Tue, 24 Apr 2012 15:56:09 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.69]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 24 Apr 2012 16:56:03 -0400 From: David Allan I To: Daniel Cohn , "l2vpn@ietf.org" Date: Tue, 24 Apr 2012 16:56:02 -0400 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IAAHuPxAAACKFwAACIeb8AADgRjpAAAAlvAABrkMXAAAGzCAAAD3VNAAAAbE0AAAP0IgAAAFiLA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD523223596F@EUSAACMS0703.eamcs.ericsson.se> References: <169e01cd2256$b31c5660$05280101@corrigent.com> <60C093A41B5E45409A19D42CF7786DFD52322358EB@EUSAACMS0703.eamcs.ericsson.se> <44F4E579A764584EA9BDFD07D0CA08130777C63F@tlvmail1> <60C093A41B5E45409A19D42CF7786DFD5232235948@EUSAACMS0703.eamcs.ericsson.se> <44F4E579A764584EA9BDFD07D0CA08130777C641@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130777C641@tlvmail1> 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-BeenThere: l2vpn@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, 24 Apr 2012 20:56:12 -0000 Yes it did, Shahram's example is half pregnant, it is partially ETREE and partially ELA= N, and we are discussing changing administrative boundaries so VID translat= ion would be required (although I'm not sure this scenario, mapping symmetr= ic to asymmetric, actually is supported by the standard, I'll leave that to= others). Given the change of administration, IMO preserving a specific S-VID value t= o me is a non-requirement...that would be the key thought. Glad we could bottom this out Cheers Dave -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Tuesday, April 24, 2012 4:53 PM To: David Allan I; l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? None taken ;-) I think the e-mail I just sent will help clarify the point. DC -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Tuesday, April 24, 2012 11:49 PM To: Daniel Cohn; l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Then, and I do not wish to sound rude, but I do not know what you are talki= ng about. The leaf to root S-tag is preserved. The root to root/leaf S-tag is preserv= ed. An individual frame can only be one or the other so only carries one S-= tag. The only exception being the option to symmetrically translate tags at admi= nistrative boundaries as is documented in 802.1ad. But that does not change= the semantics, simply the VIDs used. Cheers Dave -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Tuesday, April 24, 2012 4:44 PM To: David Allan I; l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? No, the thread is about S-VLAN ID preservation. -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Tuesday, April 24, 2012 11:17 PM To: Daniel Cohn; l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Are you referring then to the C-tag.... It is preserved, NP Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Tuesday, April 24, 2012 4:11 PM To: Fedyk, Donald (Don); Hernandez-Valencia, Enrique (Enrique); l2vpn@ietf.= org Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Preservation requires egress =3D ingress vid - how does the egress pe know = what the ingress vid was, if the ingress vid was swapped at ingress? Thumb typed - please be tolerant "Fedyk, Donald (Don)" wrote: Dan In an E-Tree Model you have logically one VLAN on ingress and one on Egress= . In the E-Tree you can use a Root or Leaf VID. (one or the other.) So you have: ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. Ingress VID does not have to equal Egress VID but regardless there is only = ever one VID on a frame at a time. Don -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Tuesday, April 24, 2012 12:58 PM To: Hernandez-Valencia, Enrique (Enrique); Sprecher, Nurit (NSN - IL/Hod Ha= Sharon); Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.o= rg; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? I don't know what kind of translation you propose but I don't see how you c= an preserve the original s-vlan id plus root/leaf in the same number of bit= s Thumb typed - please be tolerant "Hernandez-Valencia, Enrique (Enrique)" wrote: VLAN-ID preservation does not necessarily require a third VLAN-ID. VLAN-ID translation is sufficient. Enrique -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Tuesday, April 24, 2012 7:17 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Lucy yong; Rogers, Josh; Shahr= am Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? No, the other way round. In the 2-VLAN solution, S-VLAN ID preservation req= uires adding a third VLAN ID. In the multi-PW solution, this is not require= d. DC -----Original Message----- From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.co= m] Sent: Tuesday, April 24, 2012 2:02 PM To: Daniel Cohn; Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vp= n@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Daniel, Is it so that you consider S-VAL stacking? If this is the case, are you aware that this is not in-line with the IEEE s= pecifications? Best regard, Nurit -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of e= xt Daniel Cohn Sent: Tuesday, April 24, 2012 10:12 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, even if the current MEF framework doesn't require s-vlan preservation, I be= lieve it's to the industry's benefit to adopt a solution that is not constr= ained to a specific enni model that, like all things networking, is likely = to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service provider= s' inputs. It had a fair reason to assume S-VLAN over ENNI by then. It may = open B-VLAN for the future. It is better for us not to discuss a future fr= amework here, because it will lead us to nowhere. Here, we want to extend VPLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Va= inshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume tha= t the VLAN tags at the E-NNI will always be according to the current MEF mo= del? Or should we try to be as transparent as possible to user VLAN encapsu= lation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case VLAN t= ag) to signal VPLS information (in this case root/leaf origin) is necessari= ly tied to specific assumptions on user payload encapsulation (in this case= , that S-VLAN tag is "available" to encode root/leaf). I don't think this i= s a future-proof assumption, it's very likely that other network models wil= l come up that require S-VLAN preservation, which in the 2-VLAN approach wo= uld necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, "l2vpn@ietf.org" >, "Alexander.Vainshtein@ecitele.com" > Cc: "yuqun.cao@gmail.com" > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic alrea= dy has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L i= nformation, customer payload or PW? The customer payload will be always mod= ified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is access= ed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informati= on? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > com>> > To: "Rogers, Josh" >, Lucy yong > >, Daniel Cohn >, Sam Cao > > > Cc: "l2vpn@ietf.org" > > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, but: > > IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BU= N traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes in the PE co= nfiguration. > > In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root = AC from a PE that previously has been supporting a mix etc. affect only the= PE where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on sp= ecific implementations. And some changes in the forwarding process are requ= ired in any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org > [l2vpn-bounces@ietf.org] on behalf of > Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a > more complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become > more complex. > > Gile's comparison slide still concisely captures the differences > between these methods, in my opinion. I haven't seen any new ideas or > thoughts brought to the group in the past week or two on the subject. > I would hate for both proposed methods to die on the vine because we > couldn't decide between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree >>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may >>double all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn >>[mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the >>processing in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >>PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW >>(for traffic coming from a root AC) [[LY]] Not that simple. You >>construct either two P2MP PWs to all other PEs and let egress PE >>performing filtering, or construct one P2MP PW to leaf-only PEs and >>two P2MP PWs to root and leaf PEs and let ingress PE perform >>forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so >>don't feel terribly strong about this objection. Is this a real >>problem for others (now or in the future), or is this objection in the weeds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. >>I encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao >>>[mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>(Wim)'; giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>PE have both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn >>>[mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com>; Sam Cao >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong >>>[mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>both approaches can benefit from it. I was off for a while and >>>captures some discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues >>>with silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >>>am not clear on all the issues. Could you be more specific? As I >>>mentioned in below, two PW approach makes VPLS transport construction >>>and packet forwarding more complex, I can see potential backward >>>compatibility issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>double all of them. >>> >>>E-tree is an Ethernet service and there is already VLAN based >>>solution in IEEE, can we just utilize it without complicating VPLS >>>transport construction? This also makes interworking with Eth only network easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh >>>[mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); >>>'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are >>>you saying that you no longer are interested in that method in >>>preference of the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org >>>[mailto:l2vpn-bounces@ietf.org] On >>>Behalf Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron >>>[mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord >>>>; Alexander >>>Vainshtein >>>>>.com>> >>>Cc: l2vpn@ietf.org >>>>; Vladimir Kleiner >>>>; >>>Andrew Sergeev >>>>; Idan >>>Kaspit >; >>>Mishael Wexler >>>>; >>>Rotem Cohen > >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly >>>have put in a third column on the CW approach. And hopefully the >>>minutes will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to >>>be forming around the two alternatives of two PWEs or two VLANs. I >>>believe three of the authors of the CW approach are also authors of >>>the two VLAN approach and one is also an author of the two PWE >>>approach. So perhaps it's best to let those four individuals say >>>which approach they prefer and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of >>>> various solution drafts off the mailing list. As far as I know, no >>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>> meeting. I think the CW approach has not been rejected by the WG >>>> yet, or the WG has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein >>>> >>> le.com>> >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree >>>>> approaches based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/ >>>>> ?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in >>>>> the PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>> I wonder whether the WG has taken a decision to reject the >>>>> approach based on the CW usage? I do not remember any recent >>>>> discussion of this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and >>>>> contains information which is CONFIDENTIAL and which may be >>>>> proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original >>>>> and all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or >>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>intended solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail >>>is strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is >>addressed. If you are not the intended recipient of this E-mail, you >>are hereby notified that any dissemination, distribution, copying, or >>action taken in relation to the contents of and attachments to this >>E-mail is strictly prohibited and may be unlawful. If you have >>received this E-mail in error, please notify the sender immediately >>and permanently delete the original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to c= opyright belonging to Time Warner Cable. This E-mail is intended solely for= the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notifi= ed that any dissemination, distribution, copying, or action taken in relati= on to the contents of and attachments to this E-mail is strictly prohibited= and may be unlawful. If you have received this E-mail in error, please not= ify the sender immediately and permanently delete the original and any copy= of this E-mail and any printout. > This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telec= om. If you have received this transmission in error, please inform us by e-= mail, phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** From lucy.yong@huawei.com Wed Apr 25 07:55:27 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1768321F8716 for ; Wed, 25 Apr 2012 07:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HS_INDEX_PARAM=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 IE0VkKo0J2Ls for ; Wed, 25 Apr 2012 07:55:25 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A833A21F8713 for ; Wed, 25 Apr 2012 07:55:25 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFF19554; Wed, 25 Apr 2012 10:55:25 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 07:53:10 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Wed, 25 Apr 2012 07:53:05 -0700 From: Lucy yong To: Giles Heron , Lizhong Jin Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNHf0He/4Txq0Y50G6N17p5Mncd5aqFgOAgAGPoPA= Date: Wed, 25 Apr 2012 14:53:05 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264BF51@dfweml505-mbx> 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.142.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , "yuqun.cao@gmail.com" X-BeenThere: l2vpn@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, 25 Apr 2012 14:55:27 -0000 [Snipped..] As I said in my last email I'm not sure there's a great need for P2MP from leaves. And P2MP from roots needs to go to all roots and leaves of course. But there would be a slight inefficiency if a node with roots and leaves sent leaf traffic over a P2MP PW to all other nodes - as leaf-only nodes wouldn't need to see those packets. [[LY]] what you suggest is to set up a P2MP PW on the PEs that have an root= AC while leaf-only PEs only use P2P PWs for multicast traffic. (no P2P PWs= between leaf-only PEs) This applies to Dual-VLAN solution well although th= ere is a slight inefficiency.=20 Thanks, Lucy > Thanks > Lizhong >=20 >=20 >>=20 >> Regards, >>=20 >> Yuqun (Sam) Cao >> E-mail: Yuqun.cao@gmail.com >>=20 >>=20 >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: Tuesday, April 17, 2012 4:56 PM >> To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); > giles.heron@gmail.com; >> simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >> Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >> Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >> Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >> Subject: RE: The status of the approaches to the E-Tree solution? >>=20 >> Adding Sam (as l2vpn@ is holding messages) >>=20 >> DC=20 >>=20 >> -----Original Message----- >> From: Lucy yong [mailto:lucy.yong@huawei.com] >> Sent: Tuesday, April 17, 2012 12:39 AM >> To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >> giles.heron@gmail.com; simon.delord@gmail.com; >> Alexander.Vainshtein@ecitele.com >> Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >> Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >> Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >> Subject: RE: The status of the approaches to the E-Tree solution? >>=20 >>=20 >> Snipped, >>=20 >> As we discussed extensively in the list, and as reflected in giles >> slide, 2 pws are only needed between pes with both root and leaf acs, >> which will typically be a small minority. >> [[LY]] Don't know if the assumption is true. Even it is the case, both >> approaches can benefit from it. I was off for a while and captures some >> discussions now. >>=20 >> Also as per giles slide, dual vlan can have scalability issues due to >> additional lookup and double use of vlans in internal emulated lan >> interface. Also there are potential backward compatibility issues with >> silicon that doesn't support vlan mapping. >> [[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >> not clear on all the issues. Could you be more specific? As I mentioned >> in below, two PW approach makes VPLS transport construction and packet >> forwarding more complex, I can see potential backward compatibility >> issues with 2 PW solution. >>=20 >> Regards, >> Lucy >>=20 >> Regards, >>=20 >> Daniel >>=20 >> Thumb typed - please be tolerant >>=20 >> Lucy yong wrote: >>=20 >> In my mind, the VLAN approach means dual vlan method. >>=20 >> The main concern for CW approach is hardware support. >>=20 >> Two PW approach can be complex too if the VPLS instance for E-Tree uses >> P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >> traffic, and some P2MP PWs for multicast traffic. It may double all of >> them. >>=20 >> E-tree is an Ethernet service and there is already VLAN based solution >> in IEEE, can we just utilize it without complicating VPLS transport >> construction? This also makes interworking with Eth only network easier. >>=20 >> Cheers, >> Lucy >>=20 >> -----Original Message----- >> From: Rogers, Josh [mailto:josh.rogers@twcable.com] >> Sent: Monday, April 16, 2012 8:35 AM >> To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >> 'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >> Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >> 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >> 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >> Subject: RE: The status of the approaches to the E-Tree solution? >>=20 >> I believe the initial question was in regard to the CW method. Are you >> saying that you no longer are interested in that method in preference of >> the dual vlan method? >>=20 >>=20 >>=20 >> Lucy yong wrote: >>=20 >>=20 >> Agree with Wim. VLAN approach is the best solution for E-Tree. >>=20 >> Lucy >>=20 >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Henderickx, Wim (Wim) >> Sent: Thursday, April 12, 2012 2:03 AM >> To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >> 'Alexander.Vainshtein@ecitele.com' >> Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >> 'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >> 'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >> Subject: Re: The status of the approaches to the E-Tree solution? >>=20 >> The vlan approach is superior as it also works for eth only networks, >> etc. On top some vendors indicate hw issues with the cw approach. As >> such we have dropped more or less the cw approach. >>=20 >> Cheers, >> Wim >> _________________ >> sent from blackberry >>=20 >> ----- Original Message ----- >> From: Giles Heron [mailto:giles.heron@gmail.com] >> Sent: Thursday, April 12, 2012 08:22 AM >> To: Simon Delord ; Alexander Vainshtein >> >> Cc: l2vpn@ietf.org ; Vladimir Kleiner >> ; Andrew Sergeev >> ; Idan Kaspit ; >> Mishael Wexler ; Rotem Cohen >> >> Subject: Re: The status of the approaches to the E-Tree solution? >>=20 >> Sorry - the "anonymous presentation" was mine. I should possibly have >> put in a third column on the CW approach. And hopefully the minutes >> will be posted soon. >>=20 >> We had various discussions, as Simon stated, and consensus seemed to be >> forming around the two alternatives of two PWEs or two VLANs. I believe >> three of the authors of the CW approach are also authors of the two VLAN >> approach and one is also an author of the two PWE approach. So perhaps >> it's best to let those four individuals say which approach they prefer >> and why? >>=20 >> Giles >>=20 >> On 10/04/2012 00:45, "Simon Delord" wrote: >>=20 >>> Hi Alexander, >>>=20 >>> You are right, no discussion on the WG mailing list recently, but >>> there have been substantial discussions among the authors of various >>> solution drafts off the mailing list. As far as I know, no consensus >>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>> think the CW approach has not been rejected by the WG yet, or the WG >>> has not yet decided on which one to adopt. >>>=20 >>> Simon >>>=20 >>> 2012/4/8 Alexander Vainshtein >>>=20 >>>> Hi all, >>>>=20 >>>> Unfortunately I have not been able to attend the Paris IETF. >>>>=20 >>>> However, looking up the L2VPN proceedings, I've found a short >>>> anonymous presentation called "E-Tree Update" ( >>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>> This presentation discusses the differences of the E-Tree approaches >>>> based on dedicated VLANs (as in >>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>> ext=3D1) and multiple PWs between the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>> clude_te >>>> xt=3D1) >>>> and completely ignores the solution based on usage of the CW in the >>>> PWs connecting the PEs (as in >>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>> ext=3D1 >>>> ). >>>>=20 >>>>=20 >>>>=20 >>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>> wonder whether the WG has taken a decision to reject the approach >>>> based on the CW usage? I do not remember any recent discussion of >>>> this topic on the WG mailing list. >>>>=20 >>>>=20 >>>>=20 >>>> Regards, and lots of thanks in advance, >>>>=20 >>>> Sasha >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> This e-mail message is intended for the recipient only and contains >>>> information which is CONFIDENTIAL and which may be proprietary to ECI >>=20 >>>> Telecom. If you have received this transmission in error, please >>>> inform us by e-mail, phone or fax, and then delete the original and >>>> all copies thereof. >>>>=20 >>=20 >>=20 >>=20 >>=20 From lucy.yong@huawei.com Wed Apr 25 09:06:53 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F214421F87A4 for ; Wed, 25 Apr 2012 09:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HS_INDEX_PARAM=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 8h8HOcN1pk0M for ; Wed, 25 Apr 2012 09:06:51 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0257821F87A0 for ; Wed, 25 Apr 2012 09:06:50 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFN27324; Wed, 25 Apr 2012 12:06:50 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 09:04:50 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Wed, 25 Apr 2012 09:04:53 -0700 From: Lucy yong To: Daniel Cohn , "Rogers, Josh" , Shahram Davari , Lizhong Jin , "l2vpn@ietf.org" , "Alexander.Vainshtein@ecitele.com" Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IABEiWPQ Date: Wed, 25 Apr 2012 16:04:52 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264BFAF@dfweml505-mbx> References: <161901cd21ea$9d7d8486$05280101@corrigent.com> In-Reply-To: <161901cd21ea$9d7d8486$05280101@corrigent.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.119] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "yuqun.cao@gmail.com" X-BeenThere: l2vpn@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, 25 Apr 2012 16:06:53 -0000 RGFuaWVsLA0KDQpNRUYgaGFzIFMtVkxBTiBwcmVzZXJ2YXRpb24gYXR0cmlidXRlIGZvciBFTk5J IG9ubHkgYmVjYXVzZSB0aGVyZSBpcyBubyBzLXZsYW4gYXQgVU5JLiBXaGVuIGFuIE1FTiBjb25u ZWN0cyB0byBtdWx0aXBsZSBFTk5JIGludGVyZmFjZXMsIFMtVkFMTiBwcmVzZXJ2YXRpb24gYXR0 cmlidXRlIGlzIHVzZWQuIEl0IGFwcGxpZXMgdG8gRS1UcmVlIGFzIHdlbGwuDQoNClJlZ2FyZHMs DQpMdWN5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsMnZwbi1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERh bmllbCBDb2huDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAyNCwgMjAxMiAyOjEyIEFNDQpUbzogTHVj eSB5b25nOyBSb2dlcnMsIEpvc2g7IFNoYWhyYW0gRGF2YXJpOyBMaXpob25nIEppbjsgbDJ2cG5A aWV0Zi5vcmc7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQpDYzogeXVxdW4uY2Fv QGdtYWlsLmNvbQ0KU3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8g dGhlIEUtVHJlZSBzb2x1dGlvbj8NCg0KTHVjeSwNCg0KZXZlbiBpZiB0aGUgY3VycmVudCBNRUYg ZnJhbWV3b3JrIGRvZXNuJ3QgcmVxdWlyZSBzLXZsYW4gcHJlc2VydmF0aW9uLCBJIGJlbGlldmUg aXQncyB0byB0aGUgaW5kdXN0cnkncyBiZW5lZml0IHRvIGFkb3B0IGEgc29sdXRpb24gdGhhdCBp cyBub3QgY29uc3RyYWluZWQgdG8gYSBzcGVjaWZpYyBlbm5pIG1vZGVsIHRoYXQsIGxpa2UgYWxs IHRoaW5ncyBuZXR3b3JraW5nLCBpcyBsaWtlbHkgdG8gZXZvbHZlLiBFc3BlY2lhbGx5IHdoZW4g c3VjaCBhIHNvbHV0aW9uIGlzIGF2YWlsYWJsZS4NCg0KRGFuaWVsDQoNClRodW1iIHR5cGVkIC0g cGxlYXNlIGJlIHRvbGVyYW50DQoNCkx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb20+IHdy b3RlOg0KDQpEYW5pZWwsDQoNCk1FRiBoYXMgd29ya2VkIGluIEVOTkkgaW50ZXJmYWNlIGZvciBh IGxvbmcgdGltZSB3aXRoIG1hbnkgc2VydmljZSBwcm92aWRlcnMnIGlucHV0cy4gSXQgaGFkIGEg ZmFpciByZWFzb24gdG8gYXNzdW1lIFMtVkxBTiBvdmVyIEVOTkkgYnkgdGhlbi4gSXQgbWF5IG9w ZW4gQi1WTEFOIGZvciB0aGUgZnV0dXJlLiBJdCBpcyBiZXR0ZXIgZm9yIHVzIG5vdCB0byBkaXNj dXNzICBhIGZ1dHVyZSBmcmFtZXdvcmsgaGVyZSwgYmVjYXVzZSBpdCB3aWxsIGxlYWQgdXMgdG8g bm93aGVyZS4gSGVyZSwgd2Ugd2FudCB0byBleHRlbmQgVlBMUyBpbiBzdXBwb3J0aW5nIEUtVHJl ZS4NCg0KQmVzdCBSZWdhcmRzLA0KTHVjeQ0KDQpGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhbmllbCBDb2hu DQpTZW50OiBTdW5kYXksIEFwcmlsIDIyLCAyMDEyIDc6MzQgQU0NClRvOiBSb2dlcnMsIEpvc2g7 IFNoYWhyYW0gRGF2YXJpOyBMaXpob25nIEppbjsgbDJ2cG5AaWV0Zi5vcmc7IEFsZXhhbmRlci5W YWluc2h0ZWluQGVjaXRlbGUuY29tDQpDYzogeXVxdW4uY2FvQGdtYWlsLmNvbQ0KU3ViamVjdDog UkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8N Cg0KU2hhaHJhbSBhbmQgYWxsLA0KDQpUaGlzIHF1ZXN0aW9uIGFscmVhZHkgY2FtZSB1cCBpbiBv dXIgZGlzY3Vzc2lvbnMgLSBpcyBpdCBzYWZlIHRvIGFzc3VtZSB0aGF0IHRoZSBWTEFOIHRhZ3Mg YXQgdGhlIEUtTk5JIHdpbGwgYWx3YXlzIGJlIGFjY29yZGluZyB0byB0aGUgY3VycmVudCBNRUYg bW9kZWw/IE9yIHNob3VsZCB3ZSB0cnkgdG8gYmUgYXMgdHJhbnNwYXJlbnQgYXMgcG9zc2libGUg dG8gdXNlciBWTEFOIGVuY2Fwc3VsYXRpb24gYXQgdGhlIEUtTk5JLCB0byBhY2NvbW1vZGF0ZSBm dXR1cmUgZnJhbWV3b3Jrcz8NCkkgYmVsaWV2ZSB0aGF0IGFueSBhcHByb2FjaCB0aGF0IGxvb2tz IGF0IHVzZXIgcGF5bG9hZCAoaW4gdGhpcyBjYXNlIFZMQU4gdGFnKSB0byBzaWduYWwgVlBMUyBp bmZvcm1hdGlvbiAoaW4gdGhpcyBjYXNlIHJvb3QvbGVhZiBvcmlnaW4pIGlzIG5lY2Vzc2FyaWx5 IHRpZWQgdG8gc3BlY2lmaWMgYXNzdW1wdGlvbnMgb24gdXNlciBwYXlsb2FkIGVuY2Fwc3VsYXRp b24gKGluIHRoaXMgY2FzZSwgdGhhdCBTLVZMQU4gdGFnIGlzICJhdmFpbGFibGUiIHRvIGVuY29k ZSByb290L2xlYWYpLiBJIGRvbid0IHRoaW5rIHRoaXMgaXMgYSBmdXR1cmUtcHJvb2YgYXNzdW1w dGlvbiwgaXQncyB2ZXJ5IGxpa2VseSB0aGF0IG90aGVyIG5ldHdvcmsgbW9kZWxzIHdpbGwgY29t ZSB1cCB0aGF0IHJlcXVpcmUgUy1WTEFOIHByZXNlcnZhdGlvbiwgd2hpY2ggaW4gdGhlIDItVkxB TiBhcHByb2FjaCB3b3VsZCBuZWNlc3NpdGF0ZSBhZGRpbmcgYSB0aGlyZCBWTEFOLUlELg0KDQpE YW5pZWwNCg0KRnJvbTogU2hhaHJhbSBEYXZhcmkgPGRhdmFyaUBicm9hZGNvbS5jb208bWFpbHRv OmRhdmFyaUBicm9hZGNvbS5jb20+Pg0KVG86IExpemhvbmcgSmluIDxsaXpoby5qaW5AZ21haWwu Y29tPG1haWx0bzpsaXpoby5qaW5AZ21haWwuY29tPj4sICJsMnZwbkBpZXRmLm9yZzxtYWlsdG86 bDJ2cG5AaWV0Zi5vcmc+IiA8bDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPj4s ICJBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5z aHRlaW5AZWNpdGVsZS5jb20+IiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFp bHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPj4NCkNjOiAieXVxdW4uY2FvQGdt YWlsLmNvbTxtYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbT4iIDx5dXF1bi5jYW9AZ21haWwuY29t PG1haWx0bzp5dXF1bi5jYW9AZ21haWwuY29tPj4NClN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9m IHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQoNCkhpLA0KDQpJIGFsc28g aGF2ZSBhIHF1ZXN0aW9uIHJlZ2FyZGluZyAyLVZMQU4uIFdoYXQgaWYgdGhlIGN1c3RvbWVyIHRy YWZmaWMgYWxyZWFkeSBoYXMgYW4gUy1WTEFOPyBEbyB3ZSBuZWVkIGEgM3JkIFZMQU4gdG8gaWRl bnRpZnkgdGhlIEwvUj8NCg0KVGh4DQpTaGFocmFtDQoNCkZyb206IGwydnBuLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bDJ2cG4tYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExpemhvbmcgSmluDQpTZW50OiBGcmlkYXksIEFwcmls IDIwLCAyMDEyIDk6MzggQU0NClRvOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5v cmc+OyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZh aW5zaHRlaW5AZWNpdGVsZS5jb20+DQpDYzogeXVxdW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86eXVx dW4uY2FvQGdtYWlsLmNvbT4NClN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2Fj aGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQoNCkhpLCBhbGwsDQpUaGUgZGlmZmVyZW5jZSBi ZXR3ZWVuIDItVkxBTiBhbmQgQ1cgYXBwcm9hY2ggaXMgd2hvIHdpbGwgcHJvdmlkZSB0aGUgUi9M IGluZm9ybWF0aW9uLCBjdXN0b21lciBwYXlsb2FkIG9yIFBXPyBUaGUgY3VzdG9tZXIgcGF5bG9h ZCB3aWxsIGJlIGFsd2F5cyBtb2RpZmllZCB0byBjYXJyeSBSL0wgaW5mb3JtYXRpb24gaW4gMi1W TEFOIGFwcHJvYWNoLCB3aGlsZSBQVyB3aXRoIENXIHdpbGwgY2FycnkgUi9MIGluZm9ybWF0aW9u IGZvciBDVyBhcHByb2FjaC4NCkkgaGF2ZSBhIHF1ZXN0aW9uIHdpdGggdGhlIDItVkxBTiBhcHBy b2FjaCBpbiBILVZQTFMgd2hlcmUgSC1WUExTIGlzIGFjY2Vzc2VkIGJ5IFZQV1MgYXMgZGVzY3Jp YmVkIGluIFJGQzQ2NzIgc2VjdGlvbiAxMC4xLjMuIElmIFZQV1MgaXMgdXNlZCB0byBhY2Nlc3Mg SC1WUExTLCBob3cgY291bGQgdGhlIFBFIG9uIFZQV1Mgc2lkZSBhZGRzIFZMQU4gdG8gaW5kaWNh dGUgUi9MIGluZm9ybWF0aW9uPw0KDQpUaGFua3MNCkxpemhvbmcNCg0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4gTWVzc2FnZTogMg0KPiBEYXRlOiBUaHUsIDE5IEFwciAy MDEyIDA0OjM4OjM2ICswMDAwDQo+IEZyb206IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5k ZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNp dGVsZS5jb20+Pg0KPiBUbzogIlJvZ2VycywgSm9zaCIgPGpvc2gucm9nZXJzQHR3Y2FibGUuY29t PG1haWx0bzpqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbT4+LCBMdWN5IHlvbmcNCj4gICAgICAgIDxs dWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiwgRGFuaWVs IENvaG4gPERhbmllbENAb3Jja2l0LmNvbTxtYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tPj4sIFNh bSBDYW8NCj4gICAgICAgIDx5dXF1bi5jYW9AZ21haWwuY29tPG1haWx0bzp5dXF1bi5jYW9AZ21h aWwuY29tPj4NCj4gQ2M6ICJsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+IiA8 bDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPj4NCj4gU3ViamVjdDogUkU6IFRo ZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4gTWVz c2FnZS1JRDoNCj4gICAgICAgIDxGOTMzNjU3MTczMUFERTQyQTUzOTdGQzgzMUNFQUEwMjAzNDE5 MkBGUklEV1BQTUIwMDIuZWNpdGVsZS5jb208bWFpbHRvOkY5MzM2NTcxNzMxQURFNDJBNTM5N0ZD ODMxQ0VBQTAyMDM0MTkyQEZSSURXUFBNQjAwMi5lY2l0ZWxlLmNvbT4+DQo+IENvbnRlbnQtVHlw ZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXMtYXNjaWkiDQo+DQo+IEhpIGFsbCwNCj4gSSBmdWxs eSB1bmRlcnN0YW5kIHRoYXQgdGhhdCB3aGF0IEkgYW0gZ29pbmcgdG8gc2F5IGlzIG5vdCB2ZXJ5 IHBvcHVsYXIsIGJ1dDoNCj4NCj4gSU1PIG9uZSBvZiB0aGUgYWR2YW50YWdlcyBvZiB0aGUgQ1ct YmFzZWQgc29sdXRpb24gaXMgdGhhdCBpdCBpcyBvcnRob2dvbmFsIHRvIHVzYWdlIChvciBub24t dXNhZ2UpIG9mIFAyTVAgUFdzIGZvciBlZmZlY3RpdmUgZGVsaXZlcnkgb2YgQlVOIHRyYWZmaWMu DQo+DQo+IEFub3RoZXIgYWR2YW50YWdlIGlzIHByZXNlcnZhdGlvbiBvZiBmdWxsIG1lc2ggb2Yg UDJQIFBXcyBpbiBhIFZQTFMsIGFuZCwgaW4gYSBtb3JlIGdlbmVyaWMgd2F5LCBsb2NhbGl6YXRp b24gb2YgZWZmZWN0cyBvZiBjaGFuZ2VzIGluIHRoZSBQRSBjb25maWd1cmF0aW9uLg0KPg0KPiBJ biBwYXJ0aWN1bGFyLCBhZGRpbmcgYSBMZWFmIEFDIHRvIGEgUEUgdGhhdCBwcmV2aW91c2x5IGhh cyBiZWVuIG9ubHkgc3VwcG9ydGluZyBSb290IEFDcyAob3IgdmljZSB2ZXJzYSksIHJlbW92YWwg b2YgdGhlIGxhc3QgTGVhZiBvciBsYXN0IFJvb3QgQUMgZnJvbSBhIFBFIHRoYXQgcHJldmlvdXNs eSBoYXMgYmVlbiBzdXBwb3J0aW5nIGEgbWl4IGV0Yy4gYWZmZWN0IG9ubHkgdGhlIFBFIHdoZXJl IHRoaXMgb3BlcmF0aW9uIGhhcHBlbnMgYW5kIG5vdCB0aGUgcmVzdCBvZiB0aGUgUEVzLg0KPg0K PiBBcyBmb3IgdGhlIG5lZWQgZm9yIEhXIGNoYW5nZXMgdGhhdCBoYXZlIGJlZW4gbWVudGlvbmVk IGFzIGEgbWFpbiBkaXNhZHZhbnRhZ2Ugb2YgdGhlIENXLWJhc2VkIGFwcHJvYWNoIC0gSSBiZWxp ZXZlIGl0IHN0cm9uZ2x5IGRlcGVuZHMgb24gc3BlY2lmaWMgaW1wbGVtZW50YXRpb25zLiBBbmQg c29tZSBjaGFuZ2VzIGluIHRoZSBmb3J3YXJkaW5nIHByb2Nlc3MgYXJlIHJlcXVpcmVkIGluIGFu eSBzb2x1dGlvbi4NCj4NCj4gTXkgMmMsDQo+ICAgICBTYXNoYQ0KPg0KPg0KPg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZyb206IGwydnBuLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc+IFtsMnZwbi1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnPl0gb24gYmVoYWxmIG9mIFJvZ2Vy cywgSm9zaCBbam9zaC5yb2dlcnNAdHdjYWJsZS5jb208bWFpbHRvOmpvc2gucm9nZXJzQHR3Y2Fi bGUuY29tPl0NCj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxOCwgMjAxMiA5OjU3IFBNDQo+IFRv OiBMdWN5IHlvbmc7IERhbmllbCBDb2huOyBTYW0gQ2FvDQo+IENjOiBsMnZwbkBpZXRmLm9yZzxt YWlsdG86bDJ2cG5AaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBUaGUgc3RhdHVzIG9mIHRoZSBh cHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+DQo+IEFnYWluLCB0aGUgUDJNUCBz aXR1YXRpb24gdGhyb3dzIG1lLiAgSXMgdGhpcyBzb21ldGhpbmcgdGhhdCBpcyB1c2VkDQo+IGNv bW1vbmx5Pw0KPg0KPiBJJ20gdW5kZXIgdGhlIGltcHJlc3Npb24gdGhhdCBhZGRpbmcgUDJNUCB0 byBhbnkgbW9kZWwgcmVzdWx0cyBpbiBhIG1vcmUNCj4gY29tcGxleCBtb2RlbC4gIFdldGhlciBv dXRzaWRlIHMtdGFnIGlzIHVzZWQgdG8gZGlmZmVyZW50aWF0ZSwgb3INCj4gZGVkaWNhdGVkIHB3 J3MgYXJlIHVzZWQgZm9yIHRoZSBzYW1lIHB1cnBvc2UsIGl0IHNlZW1zIGJvdGggYmVjb21lIG1v cmUNCj4gY29tcGxleC4NCj4NCj4gR2lsZSdzIGNvbXBhcmlzb24gc2xpZGUgc3RpbGwgY29uY2lz ZWx5IGNhcHR1cmVzIHRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVuDQo+IHRoZXNlIG1ldGhvZHMsIGlu IG15IG9waW5pb24uICBJIGhhdmVuJ3Qgc2VlbiBhbnkgbmV3IGlkZWFzIG9yIHRob3VnaHRzDQo+ IGJyb3VnaHQgdG8gdGhlIGdyb3VwIGluIHRoZSBwYXN0IHdlZWsgb3IgdHdvIG9uIHRoZSBzdWJq ZWN0LiAgSSB3b3VsZCBoYXRlDQo+IGZvciBib3RoIHByb3Bvc2VkIG1ldGhvZHMgdG8gZGllIG9u IHRoZSB2aW5lIGJlY2F1c2Ugd2UgY291bGRuJ3QgZGVjaWRlDQo+IGJldHdlZW4gdHdvIG1ldGhv ZHMgdGhhdCBoYXZlIG5vdGhpbmcgaW5oZXJlbnRseSB3cm9uZyB3aXRoIGVpdGhlci4NCj4NCj4g LUpvc2gNCj4NCj4NCj4gT24gNC8xOC8xMiAxOjUzIFBNLCAiTHVjeSB5b25nIiA8bHVjeS55b25n QGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+DQo+PlNl bmQgdGhpcyBhZ2Fpbi4NCj4+DQo+PlR3byBQVyBhcHByb2FjaCBjYW4gYmUgY29tcGxleCB0b28g aWYgdGhlIFZQTFMgaW5zdGFuY2UgZm9yIEUtVHJlZSB1c2VzDQo+PlAyUCBQVyBmb3IgdW5pY2Fz dCB0cmFmZmljIGFuZCBQMk1QIFBXIGZvciBicm9hZGNhc3QgYW5kIHVua25vd24NCj4+dW5pY2Fz dCB0cmFmZmljLCBhbmQgc29tZSBQMk1QIFBXcyBmb3IgbXVsdGljYXN0IHRyYWZmaWMuIEl0IG1h eSBkb3VibGUNCj4+YWxsIG9mIHRoZW0uDQo+Pg0KPj5MdWN5DQo+Pg0KPj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiBEYW5pZWwgQ29obiBbbWFpbHRvOkRhbmllbENAb3Jja2l0 LmNvbTxtYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tPl0NCj4+U2VudDogV2VkbmVzZGF5LCBBcHJp bCAxOCwgMjAxMiAxOjQyIFBNDQo+PlRvOiBMdWN5IHlvbmc7IFJvZ2VycywgSm9zaDsgU2FtIENh bw0KPj5DYzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPg0KPj5TdWJqZWN0 OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9u Pw0KPj4NCj4+SSB0aGluayB0aGUgZmlyc3Qgb3B0aW9uIGl0cyB0aGUgbmF0dXJhbCB3YXkgdG8g Z28uIEhvdyBpcyB0aGUgcHJvY2Vzc2luZw0KPj5pbiB0aGlzIGNhc2UgbW9yZSBjb21wbGV4Pw0K Pj4NCj4+VGh1bWIgdHlwZWQgLSBwbGVhc2UgYmUgdG9sZXJhbnQNCj4+DQo+Pkx1Y3kgeW9uZyA8 bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6 DQo+Pg0KPj4NCj4+DQo+PlNuaXBwZWQuLg0KPj4NCj4+TXVsdGktUFcgLSBPbiBpbmdyZXNzIFBF LCBmcmFtZSBpcyBwbGFjZWQgb250byBlaXRoZXIgYSBMZWFmLW9ubHkgUDJNUCBQVw0KPj4oZm9y IHRyYWZmaWMgY29taW5nIGZyb20gYSBsZWFmIEFDKSwgb3Igb250byBhIFJvb3QvTGVhZiBQMk1Q IFBXIChmb3INCj4+dHJhZmZpYyBjb21pbmcgZnJvbSBhIHJvb3QgQUMpDQo+PltbTFldXSBOb3Qg dGhhdCBzaW1wbGUuIFlvdSBjb25zdHJ1Y3QgZWl0aGVyIHR3byBQMk1QIFBXcyB0byBhbGwgb3Ro ZXINCj4+UEVzIGFuZCBsZXQgZWdyZXNzIFBFIHBlcmZvcm1pbmcgZmlsdGVyaW5nLCBvciBjb25z dHJ1Y3Qgb25lIFAyTVAgUFcgdG8NCj4+bGVhZi1vbmx5IFBFcyBhbmQgdHdvIFAyTVAgUFdzIHRv IHJvb3QgYW5kIGxlYWYgUEVzIGFuZCBsZXQgaW5ncmVzcyBQRQ0KPj5wZXJmb3JtIGZvcndhcmRp bmcgYW5kIGZpbHRlcmluZy4gQm90aCBtYWtlIG5vZGUgcHJvY2VzcyBjb21wbGV4Lg0KPj4NCj4+ W1tMWV1dIFZQTFMgaXMgYnVpbHQgd2l0aCB0aGUgbWVjaGFuaXNtIHV0aWxpemluZyBQMlAgYW5k IFAyTVAgUFcgZm9yDQo+PmRlbGl2ZXJpbmcgdGhlIGZyYW1lcyB0byByZW1vdGUgUEVzLiBXZSBz aG91bGQgdXRpbGl6ZSB0aGVtIHdpdGggdGhlDQo+Pm1pbmltaXplZCBjaGFuZ2VzLiBEdWFsIFZM QU4gc29sdXRpb24gaXMgc2ltcGxlciB0aGFuIER1YWwgUFcuDQo+Pg0KPj5SZWdhcmRzLA0KPj5M dWN5DQo+Pg0KPj4NCj4+SSBzZWUgaG93IDJWTEFOIGlzIHNpbXBsZXIgd2hlbiBQMk1QIFBXJ3Mg YXJlIGludm9sdmVkLCBJIHRoaW5rLiAgSQ0KPj5oYXZlbid0IGhhZCBhbnkgZmlyc3QgaGFuZCBl eHBlcmllbmNlIHdpdGggUDJNUCBQVydzLCBob3dldmVyLCBzbyBkb24ndA0KPj5mZWVsIHRlcnJp Ymx5IHN0cm9uZyBhYm91dCB0aGlzIG9iamVjdGlvbi4gIElzIHRoaXMgYSByZWFsIHByb2JsZW0g Zm9yDQo+Pm90aGVycyAobm93IG9yIGluIHRoZSBmdXR1cmUpLCBvciBpcyB0aGlzIG9iamVjdGlv biBpbiB0aGUgd2VlZHM/DQo+Pg0KPj5JJ20gbm90IHN1cmUgdGhlICdhZGRpdGlvbmFsIGNvbXBs ZXhpdHknIGlzIG5vdGFibGUsIG9yIGV2ZW4gcmVsZXZhbnQuICBJDQo+PmVuY291cmFnZSBvdGhl cnMgdG8gc3BlYWsgdXAgaWYgdGhleSBkaXNhZ3JlZSwgYXMgUDJNUCBQVyBpcyBvbmx5DQo+PmNv bmNlcHR1YWwgdG8gbWUsIGFuZCBJIGFtIHVuZmFtaWxpYXIgd2l0aCByZWFsLWxpZmUgdXNlIGNh c2VzIGZvciBpdC4NCj4+DQo+PlRoYW5rcywNCj4+Sm9zaA0KPj4NCj4+DQo+Pg0KPj5PbiA0LzE4 LzEyIDEwOjMwIEFNLCAiTHVjeSB5b25nIiA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1 Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+Pg0KPj4+UGxlYXNlIHNlZSBpbmxpbmUuDQo+ Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBTYW0gQ2FvIFttYWls dG86eXVxdW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbT5dDQo+Pj5T ZW50OiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiA3OjE0IEFNDQo+Pj5UbzogJ0RhbmllbCBDb2hu JzsgTHVjeSB5b25nOyAnUm9nZXJzLCBKb3NoJzsgJ0hlbmRlcmlja3gsIFdpbSAoV2ltKSc7DQo+ Pj5naWxlcy5oZXJvbkBnbWFpbC5jb208bWFpbHRvOmdpbGVzLmhlcm9uQGdtYWlsLmNvbT47IHNp bW9uLmRlbG9yZEBnbWFpbC5jb208bWFpbHRvOnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+Ow0KPj4+ QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0 ZWluQGVjaXRlbGUuY29tPg0KPj4+Q2M6IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRm Lm9yZz47IFZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWlu ZXJAZWNpdGVsZS5jb20+Ow0KPj4+QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb208bWFpbHRvOkFu ZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPjsgSWRhbi5LYXNwaXRAZWNpdGVsZS5jb208bWFpbHRv OklkYW4uS2FzcGl0QGVjaXRlbGUuY29tPjsNCj4+Pk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29t PG1haWx0bzpNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT47IFJvdGVtLkNvaGVuQGVjaXRlbGUu Y29tPG1haWx0bzpSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbT4NCj4+PlN1YmplY3Q6IFJFOiBUaGUg c3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4NCj4+ PlllcywgMiBwd3MgYXJlIG9ubHkgbmVlZGVkIGJldHdlZW4gcGVzIHdpdGggYm90aCByb290IGFu ZCBsZWFmIGFjcyBhZnRlcg0KPj4+aW1wcm92aW5nIER1YWwtUFcgYXBwcm9hY2guIElmIGNvbnNp ZGVyIFAyTVAsIER1YWwtUFcgYXBwcm9hY2ggc2V0dXAgMg0KPj4+UDJNUA0KPj4+UFdzIGlmIG5l ZWQuIFRoZXJlIGlzIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBQMk1QIG9yIG5vcm1hbCBQVyBzZXR1 cC4gQnV0LA0KPj4+Y2FuIExlYWYtQUNzIGJlIGJvdW5kIHRvIFJvb3QgUEUgb2YgUDJNUCBQVz8N Cj4+Pg0KPj4+W1tMWV1dIE5vLCBpdCBtYWtlcyBjb21wbGV4IGluIHNldHRpbmcgdXAgUDJNUCBQ Vy4gU2hvdWxkIGEgUEUgd2l0aCBib3RoDQo+Pj5yb290IGFuZCBsZWFmIEFDcyBzZXQgdXAgdHdv IG9yIG9uZSBQMk1QIFBXIHRvIG90aGVyIFBFcyAoc29tZSBQRSBoYXZlDQo+Pj5ib3RoIHJvb3Qg YW5kIGxlYWYgQUMgYW5kIHNvbWUgb25seSBoYXZlIGxlYWYgQUNzKT8NCj4+PlJlZ2FyZHMsDQo+ Pj5MdWN5DQo+Pj4NCj4+PlJlZ2FyZHMsDQo+Pj4NCj4+Pll1cXVuIChTYW0pIENhbw0KPj4+RS1t YWlsOiBZdXF1bi5jYW9AZ21haWwuY29tPG1haWx0bzpZdXF1bi5jYW9AZ21haWwuY29tPg0KPj4+ DQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBEYW5pZWwgQ29o biBbbWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbTxtYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tPl0N Cj4+PlNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE3LCAyMDEyIDQ6NTYgUE0NCj4+PlRvOiBMdWN5IHlv bmc7IFJvZ2VycywgSm9zaDsgSGVuZGVyaWNreCwgV2ltIChXaW0pOw0KPj4+Z2lsZXMuaGVyb25A Z21haWwuY29tPG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+Ow0KPj4+c2ltb24uZGVsb3Jk QGdtYWlsLmNvbTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT47IEFsZXhhbmRlci5WYWlu c2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bT47IFNhbSBDYW8NCj4+PkNjOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+ OyBWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPG1haWx0bzpWbGFkaW1pci5LbGVpbmVyQGVj aXRlbGUuY29tPjsNCj4+PkFuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPG1haWx0bzpBbmRyZXcu U2VyZ2VldkBlY2l0ZWxlLmNvbT47IElkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0bzpJZGFu Lkthc3BpdEBlY2l0ZWxlLmNvbT47DQo+Pj5NaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbTxtYWls dG86TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb20+OyBSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbTxt YWlsdG86Um90ZW0uQ29oZW5AZWNpdGVsZS5jb20+DQo+Pj5TdWJqZWN0OiBSRTogVGhlIHN0YXR1 cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+DQo+Pj5BZGRp bmcgU2FtIChhcyBsMnZwbkAgaXMgaG9sZGluZyBtZXNzYWdlcykNCj4+Pg0KPj4+REMNCj4+Pg0K Pj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IEx1Y3kgeW9uZyBbbWFpbHRv Omx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT5dDQo+Pj5T ZW50OiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiAxMjozOSBBTQ0KPj4+VG86IERhbmllbCBDb2hu OyBSb2dlcnMsIEpvc2g7IEhlbmRlcmlja3gsIFdpbSAoV2ltKTsNCj4+PmdpbGVzLmhlcm9uQGdt YWlsLmNvbTxtYWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tPjsgc2ltb24uZGVsb3JkQGdtYWls LmNvbTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT47DQo+Pj5BbGV4YW5kZXIuVmFpbnNo dGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+ DQo+Pj5DYzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPjsgVmxhZGltaXIu S2xlaW5lckBlY2l0ZWxlLmNvbTxtYWlsdG86VmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbT47 DQo+Pj5BbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3LlNlcmdlZXZAZWNp dGVsZS5jb20+OyBJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbTxtYWlsdG86SWRhbi5LYXNwaXRAZWNp dGVsZS5jb20+Ow0KPj4+TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb208bWFpbHRvOk1pc2hhZWwu V2V4bGVyQGVjaXRlbGUuY29tPjsgUm90ZW0uQ29oZW5AZWNpdGVsZS5jb208bWFpbHRvOlJvdGVt LkNvaGVuQGVjaXRlbGUuY29tPg0KPj4+U3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFw cHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4+Pg0KPj4+DQo+Pj5TbmlwcGVkLA0K Pj4+DQo+Pj5BcyB3ZSBkaXNjdXNzZWQgZXh0ZW5zaXZlbHkgaW4gdGhlIGxpc3QsIGFuZCBhcyBy ZWZsZWN0ZWQgaW4gZ2lsZXMNCj4+PnNsaWRlLCAyIHB3cyBhcmUgb25seSBuZWVkZWQgYmV0d2Vl biBwZXMgd2l0aCBib3RoIHJvb3QgYW5kIGxlYWYgYWNzLA0KPj4+d2hpY2ggd2lsbCB0eXBpY2Fs bHkgYmUgYSBzbWFsbCBtaW5vcml0eS4NCj4+PltbTFldXSBEb24ndCBrbm93IGlmIHRoZSBhc3N1 bXB0aW9uIGlzIHRydWUuIEV2ZW4gaXQgaXMgdGhlIGNhc2UsIGJvdGgNCj4+PmFwcHJvYWNoZXMg Y2FuIGJlbmVmaXQgZnJvbSBpdC4gSSB3YXMgb2ZmIGZvciBhIHdoaWxlIGFuZCBjYXB0dXJlcyBz b21lDQo+Pj5kaXNjdXNzaW9ucyBub3cuDQo+Pj4NCj4+PkFsc28gYXMgcGVyIGdpbGVzIHNsaWRl LCBkdWFsIHZsYW4gY2FuIGhhdmUgc2NhbGFiaWxpdHkgaXNzdWVzIGR1ZSB0bw0KPj4+YWRkaXRp b25hbCBsb29rdXAgYW5kIGRvdWJsZSB1c2Ugb2YgdmxhbnMgaW4gaW50ZXJuYWwgZW11bGF0ZWQg bGFuDQo+Pj5pbnRlcmZhY2UuIEFsc28gdGhlcmUgYXJlIHBvdGVudGlhbCBiYWNrd2FyZCBjb21w YXRpYmlsaXR5IGlzc3VlcyB3aXRoDQo+Pj5zaWxpY29uIHRoYXQgZG9lc24ndCBzdXBwb3J0IHZs YW4gbWFwcGluZy4NCj4+PltbTFldXSBJIHdhcyBub3QgaW4gSUVURjgzIG1lZXRpbmcgYW5kIHdh aXQgb24gdGhlIG1lZXRpbmcgbWludXRlcy4gSSBhbQ0KPj4+bm90IGNsZWFyIG9uIGFsbCB0aGUg aXNzdWVzLiBDb3VsZCB5b3UgYmUgbW9yZSBzcGVjaWZpYz8gQXMgSSBtZW50aW9uZWQNCj4+Pmlu IGJlbG93LCB0d28gUFcgYXBwcm9hY2ggbWFrZXMgVlBMUyB0cmFuc3BvcnQgY29uc3RydWN0aW9u IGFuZCBwYWNrZXQNCj4+PmZvcndhcmRpbmcgbW9yZSBjb21wbGV4LCBJIGNhbiBzZWUgcG90ZW50 aWFsIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkNCj4+Pmlzc3VlcyB3aXRoIDIgUFcgc29sdXRpb24u DQo+Pj4NCj4+PlJlZ2FyZHMsDQo+Pj5MdWN5DQo+Pj4NCj4+PlJlZ2FyZHMsDQo+Pj4NCj4+PkRh bmllbA0KPj4+DQo+Pj5UaHVtYiB0eXBlZCAtIHBsZWFzZSBiZSB0b2xlcmFudA0KPj4+DQo+Pj5M dWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNv bT4+IHdyb3RlOg0KPj4+DQo+Pj5JbiBteSBtaW5kLCB0aGUgVkxBTiBhcHByb2FjaCBtZWFucyBk dWFsIHZsYW4gbWV0aG9kLg0KPj4+DQo+Pj5UaGUgbWFpbiBjb25jZXJuIGZvciBDVyBhcHByb2Fj aCBpcyBoYXJkd2FyZSBzdXBwb3J0Lg0KPj4+DQo+Pj5Ud28gUFcgYXBwcm9hY2ggY2FuIGJlIGNv bXBsZXggdG9vIGlmIHRoZSBWUExTIGluc3RhbmNlIGZvciBFLVRyZWUgdXNlcw0KPj4+UDJQIFBX IGZvciB1bmljYXN0IHRyYWZmaWMgYW5kIFAyTVAgUFcgZm9yIGJyb2FkY2FzdCBhbmQgdW5rbm93 biB1bmljYXN0DQo+Pj50cmFmZmljLCBhbmQgc29tZSBQMk1QIFBXcyBmb3IgbXVsdGljYXN0IHRy YWZmaWMuIEl0IG1heSBkb3VibGUgYWxsIG9mDQo+Pj50aGVtLg0KPj4+DQo+Pj5FLXRyZWUgaXMg YW4gRXRoZXJuZXQgc2VydmljZSBhbmQgdGhlcmUgaXMgYWxyZWFkeSBWTEFOIGJhc2VkIHNvbHV0 aW9uDQo+Pj5pbiBJRUVFLCBjYW4gd2UganVzdCB1dGlsaXplIGl0IHdpdGhvdXQgY29tcGxpY2F0 aW5nIFZQTFMgdHJhbnNwb3J0DQo+Pj5jb25zdHJ1Y3Rpb24/IFRoaXMgYWxzbyBtYWtlcyBpbnRl cndvcmtpbmcgd2l0aCBFdGggb25seSBuZXR3b3JrIGVhc2llci4NCj4+Pg0KPj4+Q2hlZXJzLA0K Pj4+THVjeQ0KPj4+DQo+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+RnJvbTogUm9n ZXJzLCBKb3NoIFttYWlsdG86am9zaC5yb2dlcnNAdHdjYWJsZS5jb208bWFpbHRvOmpvc2gucm9n ZXJzQHR3Y2FibGUuY29tPl0NCj4+PlNlbnQ6IE1vbmRheSwgQXByaWwgMTYsIDIwMTIgODozNSBB TQ0KPj4+VG86IEx1Y3kgeW9uZzsgSGVuZGVyaWNreCwgV2ltIChXaW0pOyAnZ2lsZXMuaGVyb25A Z21haWwuY29tPG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+JzsNCj4+PidzaW1vbi5kZWxv cmRAZ21haWwuY29tPG1haWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPic7ICdBbGV4YW5kZXIu VmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVs ZS5jb20+Jw0KPj4+Q2M6ICdsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+Jzsg J1ZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJAZWNp dGVsZS5jb20+JzsNCj4+PidBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3 LlNlcmdlZXZAZWNpdGVsZS5jb20+JzsgJ0lkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0bzpJ ZGFuLkthc3BpdEBlY2l0ZWxlLmNvbT4nOw0KPj4+J01pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29t PG1haWx0bzpNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT4nOyAnUm90ZW0uQ29oZW5AZWNpdGVs ZS5jb208bWFpbHRvOlJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPicNCj4+PlN1YmplY3Q6IFJFOiBU aGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4N Cj4+PkkgYmVsaWV2ZSB0aGUgaW5pdGlhbCBxdWVzdGlvbiB3YXMgaW4gcmVnYXJkIHRvIHRoZSBD VyBtZXRob2QuICBBcmUgeW91DQo+Pj5zYXlpbmcgdGhhdCB5b3Ugbm8gbG9uZ2VyIGFyZSBpbnRl cmVzdGVkIGluIHRoYXQgbWV0aG9kIGluIHByZWZlcmVuY2Ugb2YNCj4+PnRoZSBkdWFsIHZsYW4g bWV0aG9kPw0KPj4+DQo+Pj4NCj4+Pg0KPj4+THVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNv bTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiB3cm90ZToNCj4+Pg0KPj4+DQo+Pj5BZ3Jl ZSB3aXRoIFdpbS4gVkxBTiBhcHByb2FjaCBpcyB0aGUgYmVzdCBzb2x1dGlvbiBmb3IgRS1UcmVl Lg0KPj4+DQo+Pj5MdWN5DQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5G cm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3Jn PiBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0 Zi5vcmc+XSBPbiBCZWhhbGYNCj4+Pk9mIEhlbmRlcmlja3gsIFdpbSAoV2ltKQ0KPj4+U2VudDog VGh1cnNkYXksIEFwcmlsIDEyLCAyMDEyIDI6MDMgQU0NCj4+PlRvOiAnZ2lsZXMuaGVyb25AZ21h aWwuY29tPG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+JzsgJ3NpbW9uLmRlbG9yZEBnbWFp bC5jb208bWFpbHRvOnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+JzsNCj4+PidBbGV4YW5kZXIuVmFp bnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b20+Jw0KPj4+Q2M6ICdsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+JzsgJ1Zs YWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJAZWNpdGVs ZS5jb20+JzsNCj4+PidBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3LlNl cmdlZXZAZWNpdGVsZS5jb20+JzsgJ0lkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0bzpJZGFu Lkthc3BpdEBlY2l0ZWxlLmNvbT4nOw0KPj4+J01pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPG1h aWx0bzpNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT4nOyAnUm90ZW0uQ29oZW5AZWNpdGVsZS5j b208bWFpbHRvOlJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPicNCj4+PlN1YmplY3Q6IFJlOiBUaGUg c3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4NCj4+ PlRoZSB2bGFuIGFwcHJvYWNoIGlzIHN1cGVyaW9yIGFzIGl0IGFsc28gd29ya3MgZm9yIGV0aCBv bmx5IG5ldHdvcmtzLA0KPj4+ZXRjLiBPbiB0b3Agc29tZSB2ZW5kb3JzIGluZGljYXRlIGh3IGlz c3VlcyB3aXRoIHRoZSBjdyBhcHByb2FjaC4gQXMNCj4+PnN1Y2ggd2UgaGF2ZSBkcm9wcGVkIG1v cmUgb3IgbGVzcyB0aGUgY3cgYXBwcm9hY2guDQo+Pj4NCj4+PkNoZWVycywNCj4+PldpbQ0KPj4+ X19fX19fX19fX19fX19fX18NCj4+PnNlbnQgZnJvbSBibGFja2JlcnJ5DQo+Pj4NCj4+Pi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4+PkZyb206IEdpbGVzIEhlcm9uIFttYWlsdG86Z2ls ZXMuaGVyb25AZ21haWwuY29tPG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+XQ0KPj4+U2Vu dDogVGh1cnNkYXksIEFwcmlsIDEyLCAyMDEyIDA4OjIyIEFNDQo+Pj5UbzogU2ltb24gRGVsb3Jk IDxzaW1vbi5kZWxvcmRAZ21haWwuY29tPG1haWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPj47 IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+Pj48QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPj4NCj4+PkNjOiBsMnZw bkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+IDxsMnZwbkBpZXRmLm9yZzxtYWlsdG86 bDJ2cG5AaWV0Zi5vcmc+PjsgVmxhZGltaXIgS2xlaW5lcg0KPj4+PFZsYWRpbWlyLktsZWluZXJA ZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb20+PjsgQW5kcmV3 IFNlcmdlZXYNCj4+PjxBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3LlNl cmdlZXZAZWNpdGVsZS5jb20+PjsgSWRhbiBLYXNwaXQgPElkYW4uS2FzcGl0QGVjaXRlbGUuY29t PG1haWx0bzpJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbT4+Ow0KPj4+TWlzaGFlbCBXZXhsZXIgPE1p c2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPG1haWx0bzpNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNv bT4+OyBSb3RlbSBDb2hlbg0KPj4+PFJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPG1haWx0bzpSb3Rl bS5Db2hlbkBlY2l0ZWxlLmNvbT4+DQo+Pj5TdWJqZWN0OiBSZTogVGhlIHN0YXR1cyBvZiB0aGUg YXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+DQo+Pj5Tb3JyeSAtIHRoZSAi YW5vbnltb3VzIHByZXNlbnRhdGlvbiIgd2FzIG1pbmUuICBJIHNob3VsZCBwb3NzaWJseSBoYXZl DQo+Pj5wdXQgaW4gYSB0aGlyZCBjb2x1bW4gb24gdGhlIENXIGFwcHJvYWNoLiAgQW5kIGhvcGVm dWxseSB0aGUgbWludXRlcw0KPj4+d2lsbCBiZSBwb3N0ZWQgc29vbi4NCj4+Pg0KPj4+V2UgaGFk IHZhcmlvdXMgZGlzY3Vzc2lvbnMsIGFzIFNpbW9uIHN0YXRlZCwgYW5kIGNvbnNlbnN1cyBzZWVt ZWQgdG8gYmUNCj4+PmZvcm1pbmcgYXJvdW5kIHRoZSB0d28gYWx0ZXJuYXRpdmVzIG9mIHR3byBQ V0VzIG9yIHR3byBWTEFOcy4gIEkgYmVsaWV2ZQ0KPj4+dGhyZWUgb2YgdGhlIGF1dGhvcnMgb2Yg dGhlIENXIGFwcHJvYWNoIGFyZSBhbHNvIGF1dGhvcnMgb2YgdGhlIHR3byBWTEFODQo+Pj5hcHBy b2FjaCBhbmQgb25lIGlzIGFsc28gYW4gYXV0aG9yIG9mIHRoZSB0d28gUFdFIGFwcHJvYWNoLiBT byBwZXJoYXBzDQo+Pj5pdCdzIGJlc3QgdG8gbGV0IHRob3NlIGZvdXIgaW5kaXZpZHVhbHMgc2F5 IHdoaWNoIGFwcHJvYWNoIHRoZXkgcHJlZmVyDQo+Pj5hbmQgd2h5Pw0KPj4+DQo+Pj5HaWxlcw0K Pj4+DQo+Pj5PbiAxMC8wNC8yMDEyIDAwOjQ1LCAiU2ltb24gRGVsb3JkIiA8c2ltb24uZGVsb3Jk QGdtYWlsLmNvbTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4+DQo+ Pj4+IEhpIEFsZXhhbmRlciwNCj4+Pj4NCj4+Pj4gWW91IGFyZSByaWdodCwgbm8gZGlzY3Vzc2lv biBvbiB0aGUgV0cgbWFpbGluZyBsaXN0IHJlY2VudGx5LCBidXQNCj4+Pj4gdGhlcmUgaGF2ZSBi ZWVuIHN1YnN0YW50aWFsIGRpc2N1c3Npb25zIGFtb25nIHRoZSBhdXRob3JzIG9mIHZhcmlvdXMN Cj4+Pj4gc29sdXRpb24gZHJhZnRzIG9mZiB0aGUgbWFpbGluZyBsaXN0LiBBcyBmYXIgYXMgSSBr bm93LCBubyBjb25zZW5zdXMNCj4+Pj4geWV0IGJlZm9yZSBpZXRmODMsIG5vdCBzdXJlIHRoZSBw cm9ncmVzcyBpbiB0aGUgUGFyaXMgV0cgbWVldGluZy4gSQ0KPj4+PiB0aGluayB0aGUgQ1cgYXBw cm9hY2ggaGFzIG5vdCBiZWVuIHJlamVjdGVkIGJ5IHRoZSBXRyB5ZXQsIG9yIHRoZSBXRw0KPj4+ PiBoYXMgbm90IHlldCBkZWNpZGVkIG9uIHdoaWNoIG9uZSB0byBhZG9wdC4NCj4+Pj4NCj4+Pj4g U2ltb24NCj4+Pj4NCj4+Pj4gMjAxMi80LzggQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRl ci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0 ZWxlLmNvbT4+DQo+Pj4+DQo+Pj4+PiAgSGkgYWxsLA0KPj4+Pj4NCj4+Pj4+IFVuZm9ydHVuYXRl bHkgSSBoYXZlIG5vdCBiZWVuIGFibGUgdG8gYXR0ZW5kIHRoZSBQYXJpcyBJRVRGLg0KPj4+Pj4N Cj4+Pj4+IEhvd2V2ZXIsIGxvb2tpbmcgdXAgdGhlIEwyVlBOIHByb2NlZWRpbmdzLCBJJ3ZlIGZv dW5kIGEgc2hvcnQNCj4+Pj4+IGFub255bW91cyBwcmVzZW50YXRpb24gY2FsbGVkICJFLVRyZWUg VXBkYXRlIiAgKA0KPj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84My9zbGlk ZXMvc2xpZGVzLTgzLWwydnBuLTEucHB0eCkuDQo+Pj4+PiBUaGlzIHByZXNlbnRhdGlvbiBkaXNj dXNzZXMgdGhlIGRpZmZlcmVuY2VzIG9mIHRoZSBFLVRyZWUgYXBwcm9hY2hlcw0KPj4+Pj4gYmFz ZWQgb24gZGVkaWNhdGVkIFZMQU5zIChhcyBpbg0KPj4+Pj4gaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1jYW8tbDJ2cG4tdnBscy1ldHJlZS8/aW5jbHVkZV90DQo+Pj4+PiBl eHQ9MSkgYW5kIG11bHRpcGxlIFBXcyBiZXR3ZWVuIHRoZSBQRXMgKGFzIGluDQo+Pj4+PiBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJhbS1sMnZwbi1ldHJlZS1tdWx0aXBs ZS1wdy8/aW4NCj4+Pj4+IGNsdWRlX3RlDQo+Pj4+PiB4dD0xKQ0KPj4+Pj4gYW5kIGNvbXBsZXRl bHkgaWdub3JlcyB0aGUgc29sdXRpb24gYmFzZWQgb24gdXNhZ2Ugb2YgdGhlIENXIGluIHRoZQ0K Pj4+Pj4gUFdzIGNvbm5lY3RpbmcgdGhlIFBFcyAoYXMgaW4NCj4+Pj4+IGh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta2V5LWwydnBuLXZwbHMtZXRyZWUvP2luY2x1ZGVfdA0K Pj4+Pj4gZXh0PTENCj4+Pj4+ICkuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBUaGUgTWlu dXRlcyBvZiB0aGUgUGFyaXMgTDJWUE4gc2Vzc2lvbiBhcmUgbm90IHlldCBhdmFpbGFibGUsIGJ1 dCBJDQo+Pj4+PiB3b25kZXIgd2hldGhlciB0aGUgV0cgaGFzIHRha2VuIGEgZGVjaXNpb24gdG8g cmVqZWN0IHRoZSBhcHByb2FjaA0KPj4+Pj4gYmFzZWQgb24gdGhlIENXIHVzYWdlPyBJIGRvIG5v dCByZW1lbWJlciBhbnkgcmVjZW50IGRpc2N1c3Npb24gb2YNCj4+Pj4+IHRoaXMgdG9waWMgb24g dGhlIFdHIG1haWxpbmcgbGlzdC4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFJlZ2FyZHMs IGFuZCBsb3RzIG9mIHRoYW5rcyBpbiBhZHZhbmNlLA0KPj4+Pj4NCj4+Pj4+IFNhc2hhDQo+Pj4+ Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFRoaXMgZS1tYWlsIG1lc3NhZ2Ug aXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMNCj4+Pj4+IGlu Zm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0 YXJ5IHRvIEVDSQ0KPj4+DQo+Pj4+PiBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlDQo+Pj4+PiBpbmZvcm0gdXMgYnkgZS1tYWls LCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kDQo+Pj4+PiBh bGwgY29waWVzIHRoZXJlb2YuDQo+Pj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+PlRo aXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2Fy bmVyIENhYmxlDQo+Pj5wcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdl ZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0DQo+Pj50byBjb3B5cmlnaHQgYmVsb25naW5nIHRv IFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZA0KPj4+c29sZWx5IGZv ciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRy ZXNzZWQuDQo+Pj5JZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMg RS1tYWlsLCB5b3UgYXJlIGhlcmVieQ0KPj4+bm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlv biwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4NCj4+PmluIHJlbGF0aW9u IHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMNCj4+ PnN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcw0KPj4+RS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg aW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5DQo+Pj5kZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBh bnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0KPj4+DQo+Pg0KPj4NCj4+ VGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBX YXJuZXIgQ2FibGUNCj4+cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVn ZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0bw0KPj5jb3B5cmlnaHQgYmVsb25naW5nIHRv IFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkNCj4+Zm9y IHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJl c3NlZC4gSWYgeW91DQo+PmFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUt bWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQNCj4+dGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwg ZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4NCj4+cmVsYXRpb24gdG8g dGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3Rs eQ0KPj5wcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgRS1tYWlsIGluDQo+PmVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUNCj4+b3JpZ2luYWwgYW5kIGFueSBjb3B5 IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo+DQo+DQo+IFRoaXMgRS1tYWlsIGFu ZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHBy b3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWws IG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4g VGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlm aWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0 aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMg dG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVs LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdp bmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0KPiBUaGlz IGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNv bnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJl IHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRy YW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9y IGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYWxsIGNvcGllcyB0aGVyZW9m Lg0KPg0KPg0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTDJ2cG4gbWFpbGlu ZyBsaXN0DQo+IEwydnBuQGlldGYub3JnPG1haWx0bzpMMnZwbkBpZXRmLm9yZz4NCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sMnZwbg0KPg0KPg0KPiBFbmQgb2YgTDJ2 cG4gRGlnZXN0LCBWb2wgOTUsIElzc3VlIDI1DQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqDQo= From DanielC@orckit.com Wed Apr 25 09:39:29 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1968821F87BF for ; Wed, 25 Apr 2012 09:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.66 X-Spam-Level: * X-Spam-Status: No, score=1.66 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_ILLEGAL_IP=1.908, RCVD_NUMERIC_HELO=2.067] 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 i74um-YWM-1N for ; Wed, 25 Apr 2012 09:39:27 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id BC45C21F87BA for ; Wed, 25 Apr 2012 09:39:26 -0700 (PDT) Received: from 1.1.40.5 ([1.1.40.5]) by tlvmail1.corrigent.com ([1.1.40.5]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Apr 2012 16:41:32 +0000 Date: Wed, 25 Apr 2012 19:39:19 +0300 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <171f01cd2302$45aa461f$05280101@corrigent.com> Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IABEiWPQAAFgqVo= X-MimeOLE: Produced By Microsoft Exchange V6.5 Importance: normal From: "Daniel Cohn" To: "Lucy yong" , "Rogers, Josh" , "Shahram Davari" , "Lizhong Jin" , , MIME-Version: 1.0 Cc: yuqun.cao@gmail.com X-BeenThere: l2vpn@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, 25 Apr 2012 16:39:29 -0000 Hi Lucy,=0A= =0A= The scenario we are discussing is not the E-Tree E-NNI, but a general = scenario where frames arriving at the root or leaf AC are already = double tagged. In this case, the dual vlan solution cannot preserve the = vlans without adding a third one, can it?=0A= =0A= Maybe Shahram can add details on the scenario he had in mind=0A= =0A= Thumb typed - please be tolerant=0A= =0A= Lucy yong wrote:=0A= =0A= Daniel, MEF has S-VLAN preservation attribute for ENNI only because there is no = s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN = preservation attribute is used. It applies to E-Tree as well. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Daniel Cohn Sent: Tuesday, April 24, 2012 2:12 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; = l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, even if the current MEF framework doesn't require s-vlan preservation, I = believe it's to the industry's benefit to adopt a solution that is not = constrained to a specific enni model that, like all things networking, = is likely to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service = providers' inputs. It had a fair reason to assume S-VLAN over ENNI by = then. It may open B-VLAN for the future. It is better for us not to = discuss a future framework here, because it will lead us to nowhere. = Here, we want to extend VPLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Daniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; = Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume = that the VLAN tags at the E-NNI will always be according to the current = MEF model? Or should we try to be as transparent as possible to user = VLAN encapsulation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case = VLAN tag) to signal VPLS information (in this case root/leaf origin) is = necessarily tied to specific assumptions on user payload encapsulation = (in this case, that S-VLAN tag is "available" to encode root/leaf). I = don't think this is a future-proof assumption, it's very likely that = other network models will come up that require S-VLAN preservation, = which in the 2-VLAN approach would necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, = "l2vpn@ietf.org" = >, = "Alexander.Vainshtein@ecitele.com" = > Cc: "yuqun.cao@gmail.com" = > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic = already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; = Alexander.Vainshtein@ecitele.com= Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the = R/L information, customer payload or PW? The customer payload will be = always modified to carry R/L information in 2-VLAN approach, while PW = with CW will carry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is = accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used = to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate = R/L information? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein = > > To: "Rogers, Josh" = >, Lucy yong > >, Daniel = Cohn >, Sam Cao > > > Cc: "l2vpn@ietf.org" = > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > = > > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very = popular, but: > > IMO one of the advantages of the CW-based solution is that it is = orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, = and, in a more generic way, localization of effects of changes in the PE = configuration. > > In particular, adding a Leaf AC to a PE that previously has been only = supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect = only the PE where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main = disadvantage of the CW-based approach - I believe it strongly depends on = specific implementations. And some changes in the forwarding process are = required in any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org = [l2vpn-bounces@ietf.org] on behalf of = Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a = more > complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become = more > complex. > > Gile's comparison slide still concisely captures the differences = between > these methods, in my opinion. I haven't seen any new ideas or = thoughts > brought to the group in the past week or two on the subject. I would = hate > for both proposed methods to die on the vine because we couldn't = decide > between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" = > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree = uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may = double >>all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn = [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the = processing >>in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP = PW >>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >>traffic coming from a root AC) >>[[LY]] Not that simple. You construct either two P2MP PWs to all other >>PEs and let egress PE performing filtering, or construct one P2MP PW = to >>leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >>perform forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so = don't >>feel terribly strong about this objection. Is this a real problem for >>others (now or in the future), or is this objection in the weeds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. = I >>encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" = > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao = [mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim = (Wim)'; >>>giles.heron@gmail.com; = simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; = Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; = Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; = Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs = after >>>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup = 2 >>>P2MP >>>PWs if need. There is no difference between P2MP or normal PW setup. = But, >>>can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with = both >>>root and leaf ACs set up two or one P2MP PW to other PEs (some PE = have >>>both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn = [mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; = Alexander.Vainshtein@ecitele.com= ; Sam Cao >>>Cc: l2vpn@ietf.org; = Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; = Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; = Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong = [mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; = simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; = Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; = Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; = Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, = both >>>approaches can benefit from it. I was off for a while and captures = some >>>discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues = with >>>silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I = am >>>not clear on all the issues. Could you be more specific? As I = mentioned >>>in below, two PW approach makes VPLS transport construction and = packet >>>forwarding more complex, I can see potential backward compatibility >>>issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree = uses >>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown = unicast >>>traffic, and some P2MP PWs for multicast traffic. It may double all = of >>>them. >>> >>>E-tree is an Ethernet service and there is already VLAN based = solution >>>in IEEE, can we just utilize it without complicating VPLS transport >>>construction? This also makes interworking with Eth only network = easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh = [mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); = 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; = 'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; = 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; = 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; = 'Rotem.Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are = you >>>saying that you no longer are interested in that method in preference = of >>>the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org] On Behalf >>>Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; = 'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; = 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; = 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; = 'Rotem.Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron = [mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord = >; Alexander = Vainshtein >>>> >>>Cc: l2vpn@ietf.org = >; Vladimir Kleiner >>>>; = Andrew Sergeev >>>>; Idan = Kaspit >; >>>Mishael Wexler = >; Rotem = Cohen >>>> >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly = have >>>put in a third column on the CW approach. And hopefully the minutes >>>will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to = be >>>forming around the two alternatives of two PWEs or two VLANs. I = believe >>>three of the authors of the CW approach are also authors of the two = VLAN >>>approach and one is also an author of the two PWE approach. So = perhaps >>>it's best to let those four individuals say which approach they = prefer >>>and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" = > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of = various >>>> solution drafts off the mailing list. As far as I know, no = consensus >>>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>>> think the CW approach has not been rejected by the WG yet, or the = WG >>>> has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein = > >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree = approaches >>>>> based on dedicated VLANs (as in >>>>> = http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> = http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in = the >>>>> PWs connecting the PEs (as in >>>>> = http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but = I >>>>> wonder whether the WG has taken a decision to reject the approach >>>>> based on the CW usage? I do not remember any recent discussion of >>>>> this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and = contains >>>>> information which is CONFIDENTIAL and which may be proprietary to = ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original = and >>>>> all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or = subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is = addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action = taken >>>in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject = to >>copyright belonging to Time Warner Cable. This E-mail is intended = solely >>for the use of the individual or entity to which it is addressed. If = you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies = thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** From lucy.yong@huawei.com Wed Apr 25 12:07:26 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAF621F8888 for ; Wed, 25 Apr 2012 12:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HS_INDEX_PARAM=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 WKB6-2G62WYm for ; Wed, 25 Apr 2012 12:07:24 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B2A1A21F887A for ; Wed, 25 Apr 2012 12:07:19 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFF35464; Wed, 25 Apr 2012 15:07:19 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 12:06:03 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Wed, 25 Apr 2012 12:06:01 -0700 From: Lucy yong To: Daniel Cohn , "Rogers, Josh" , Shahram Davari , Lizhong Jin , "l2vpn@ietf.org" , "Alexander.Vainshtein@ecitele.com" Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IABEiWPQAAFgqVoABMXRAA== Date: Wed, 25 Apr 2012 19:06:01 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264C0C9@dfweml505-mbx> References: <171f01cd2302$45aa461f$05280101@corrigent.com> In-Reply-To: <171f01cd2302$45aa461f$05280101@corrigent.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.119] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "yuqun.cao@gmail.com" X-BeenThere: l2vpn@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, 25 Apr 2012 19:07:26 -0000 RGFuaWVsLA0KDQpEYXZpZCBBbGxlbiBhbHJlYWR5IGV4cGxhaW5lZCB0aGUgc29sdXRpb24uIA0K DQpGcm9tIERhdmlkOg0KaW5ncmVzcyBWTEFOIElEIDwtPiBFdHJlZSBSb290L0xlYWYgVklEIDwt PiBFZ3Jlc3MgVklELg0KDQpJbmdyZXNzIFZJRCBkb2VzIG5vdCBoYXZlIHRvIGVxdWFsIEVncmVz cyBWSUQgYnV0IHJlZ2FyZGxlc3MgdGhlcmUgaXMgb25seSBldmVyIG9uZSBWSUQgb24gYSBmcmFt ZSBhdCBhIHRpbWUuDQoNCi1lbmQNCg0KVGhpcyB3b3JrcyB3aGVuIGN1c3RvbWVyIG1ha2VzIGlu Z3Jlc3MgVkxBTiBJRCBub3QgZXF1YWwgdG8gb3IgZXF1YWwgdG8gZWdyZXNzIFZMQU4gSUQuDQoN ClJlZ2FyZHMsDQpMdWN5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsMnZw bi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIERhbmllbCBDb2huDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDI1LCAyMDEyIDExOjM5 IEFNDQpUbzogTHVjeSB5b25nOyBSb2dlcnMsIEpvc2g7IFNoYWhyYW0gRGF2YXJpOyBMaXpob25n IEppbjsgbDJ2cG5AaWV0Zi5vcmc7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQpD YzogeXVxdW4uY2FvQGdtYWlsLmNvbQ0KU3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFw cHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCg0KSGkgTHVjeSwNCg0KVGhlIHNjZW5h cmlvIHdlIGFyZSBkaXNjdXNzaW5nIGlzIG5vdCB0aGUgRS1UcmVlIEUtTk5JLCBidXQgYSBnZW5l cmFsIHNjZW5hcmlvIHdoZXJlIGZyYW1lcyBhcnJpdmluZyBhdCB0aGUgcm9vdCBvciBsZWFmIEFD ICBhcmUgYWxyZWFkeSBkb3VibGUgdGFnZ2VkLiBJbiB0aGlzIGNhc2UsIHRoZSBkdWFsIHZsYW4g c29sdXRpb24gY2Fubm90IHByZXNlcnZlIHRoZSB2bGFucyB3aXRob3V0IGFkZGluZyBhIHRoaXJk IG9uZSwgY2FuIGl0Pw0KDQpNYXliZSBTaGFocmFtIGNhbiBhZGQgZGV0YWlscyBvbiB0aGUgc2Nl bmFyaW8gaGUgaGFkIGluIG1pbmQNCg0KVGh1bWIgdHlwZWQgLSBwbGVhc2UgYmUgdG9sZXJhbnQN Cg0KTHVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQoNCkRhbmllbCwNCg0K TUVGIGhhcyBTLVZMQU4gcHJlc2VydmF0aW9uIGF0dHJpYnV0ZSBmb3IgRU5OSSBvbmx5IGJlY2F1 c2UgdGhlcmUgaXMgbm8gcy12bGFuIGF0IFVOSS4gV2hlbiBhbiBNRU4gY29ubmVjdHMgdG8gbXVs dGlwbGUgRU5OSSBpbnRlcmZhY2VzLCBTLVZBTE4gcHJlc2VydmF0aW9uIGF0dHJpYnV0ZSBpcyB1 c2VkLiBJdCBhcHBsaWVzIHRvIEUtVHJlZSBhcyB3ZWxsLg0KDQpSZWdhcmRzLA0KTHVjeQ0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYW5pZWwgQ29obg0K U2VudDogVHVlc2RheSwgQXByaWwgMjQsIDIwMTIgMjoxMiBBTQ0KVG86IEx1Y3kgeW9uZzsgUm9n ZXJzLCBKb3NoOyBTaGFocmFtIERhdmFyaTsgTGl6aG9uZyBKaW47IGwydnBuQGlldGYub3JnOyBB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KQ2M6IHl1cXVuLmNhb0BnbWFpbC5jb20N ClN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUg c29sdXRpb24/DQoNCkx1Y3ksDQoNCmV2ZW4gaWYgdGhlIGN1cnJlbnQgTUVGIGZyYW1ld29yayBk b2Vzbid0IHJlcXVpcmUgcy12bGFuIHByZXNlcnZhdGlvbiwgSSBiZWxpZXZlIGl0J3MgdG8gdGhl IGluZHVzdHJ5J3MgYmVuZWZpdCB0byBhZG9wdCBhIHNvbHV0aW9uIHRoYXQgaXMgbm90IGNvbnN0 cmFpbmVkIHRvIGEgc3BlY2lmaWMgZW5uaSBtb2RlbCB0aGF0LCBsaWtlIGFsbCB0aGluZ3MgbmV0 d29ya2luZywgaXMgbGlrZWx5IHRvIGV2b2x2ZS4gRXNwZWNpYWxseSB3aGVuIHN1Y2ggYSBzb2x1 dGlvbiBpcyBhdmFpbGFibGUuDQoNCkRhbmllbA0KDQpUaHVtYiB0eXBlZCAtIHBsZWFzZSBiZSB0 b2xlcmFudA0KDQpMdWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPiB3cm90ZToNCg0KRGFu aWVsLA0KDQpNRUYgaGFzIHdvcmtlZCBpbiBFTk5JIGludGVyZmFjZSBmb3IgYSBsb25nIHRpbWUg d2l0aCBtYW55IHNlcnZpY2UgcHJvdmlkZXJzJyBpbnB1dHMuIEl0IGhhZCBhIGZhaXIgcmVhc29u IHRvIGFzc3VtZSBTLVZMQU4gb3ZlciBFTk5JIGJ5IHRoZW4uIEl0IG1heSBvcGVuIEItVkxBTiBm b3IgdGhlIGZ1dHVyZS4gSXQgaXMgYmV0dGVyIGZvciB1cyBub3QgdG8gZGlzY3VzcyAgYSBmdXR1 cmUgZnJhbWV3b3JrIGhlcmUsIGJlY2F1c2UgaXQgd2lsbCBsZWFkIHVzIHRvIG5vd2hlcmUuIEhl cmUsIHdlIHdhbnQgdG8gZXh0ZW5kIFZQTFMgaW4gc3VwcG9ydGluZyBFLVRyZWUuDQoNCkJlc3Qg UmVnYXJkcywNCkx1Y3kNCg0KRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwy dnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYW5pZWwgQ29obg0KU2VudDogU3Vu ZGF5LCBBcHJpbCAyMiwgMjAxMiA3OjM0IEFNDQpUbzogUm9nZXJzLCBKb3NoOyBTaGFocmFtIERh dmFyaTsgTGl6aG9uZyBKaW47IGwydnBuQGlldGYub3JnOyBBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbQ0KQ2M6IHl1cXVuLmNhb0BnbWFpbC5jb20NClN1YmplY3Q6IFJFOiBUaGUgc3Rh dHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQoNClNoYWhyYW0g YW5kIGFsbCwNCg0KVGhpcyBxdWVzdGlvbiBhbHJlYWR5IGNhbWUgdXAgaW4gb3VyIGRpc2N1c3Np b25zIC0gaXMgaXQgc2FmZSB0byBhc3N1bWUgdGhhdCB0aGUgVkxBTiB0YWdzIGF0IHRoZSBFLU5O SSB3aWxsIGFsd2F5cyBiZSBhY2NvcmRpbmcgdG8gdGhlIGN1cnJlbnQgTUVGIG1vZGVsPyBPciBz aG91bGQgd2UgdHJ5IHRvIGJlIGFzIHRyYW5zcGFyZW50IGFzIHBvc3NpYmxlIHRvIHVzZXIgVkxB TiBlbmNhcHN1bGF0aW9uIGF0IHRoZSBFLU5OSSwgdG8gYWNjb21tb2RhdGUgZnV0dXJlIGZyYW1l d29ya3M/DQpJIGJlbGlldmUgdGhhdCBhbnkgYXBwcm9hY2ggdGhhdCBsb29rcyBhdCB1c2VyIHBh eWxvYWQgKGluIHRoaXMgY2FzZSBWTEFOIHRhZykgdG8gc2lnbmFsIFZQTFMgaW5mb3JtYXRpb24g KGluIHRoaXMgY2FzZSByb290L2xlYWYgb3JpZ2luKSBpcyBuZWNlc3NhcmlseSB0aWVkIHRvIHNw ZWNpZmljIGFzc3VtcHRpb25zIG9uIHVzZXIgcGF5bG9hZCBlbmNhcHN1bGF0aW9uIChpbiB0aGlz IGNhc2UsIHRoYXQgUy1WTEFOIHRhZyBpcyAiYXZhaWxhYmxlIiB0byBlbmNvZGUgcm9vdC9sZWFm KS4gSSBkb24ndCB0aGluayB0aGlzIGlzIGEgZnV0dXJlLXByb29mIGFzc3VtcHRpb24sIGl0J3Mg dmVyeSBsaWtlbHkgdGhhdCBvdGhlciBuZXR3b3JrIG1vZGVscyB3aWxsIGNvbWUgdXAgdGhhdCBy ZXF1aXJlIFMtVkxBTiBwcmVzZXJ2YXRpb24sIHdoaWNoIGluIHRoZSAyLVZMQU4gYXBwcm9hY2gg d291bGQgbmVjZXNzaXRhdGUgYWRkaW5nIGEgdGhpcmQgVkxBTi1JRC4NCg0KRGFuaWVsDQoNCkZy b206IFNoYWhyYW0gRGF2YXJpIDxkYXZhcmlAYnJvYWRjb20uY29tPG1haWx0bzpkYXZhcmlAYnJv YWRjb20uY29tPj4NClRvOiBMaXpob25nIEppbiA8bGl6aG8uamluQGdtYWlsLmNvbTxtYWlsdG86 bGl6aG8uamluQGdtYWlsLmNvbT4+LCAibDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYu b3JnPiIgPGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4+LCAiQWxleGFuZGVy LlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRl bGUuY29tPiIgPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5k ZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4+DQpDYzogInl1cXVuLmNhb0BnbWFpbC5jb208bWFp bHRvOnl1cXVuLmNhb0BnbWFpbC5jb20+IiA8eXVxdW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86eXVx dW4uY2FvQGdtYWlsLmNvbT4+DQpTdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9h Y2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KDQpIaSwNCg0KSSBhbHNvIGhhdmUgYSBxdWVz dGlvbiByZWdhcmRpbmcgMi1WTEFOLiBXaGF0IGlmIHRoZSBjdXN0b21lciB0cmFmZmljIGFscmVh ZHkgaGFzIGFuIFMtVkxBTj8gRG8gd2UgbmVlZCBhIDNyZCBWTEFOIHRvIGlkZW50aWZ5IHRoZSBM L1I/DQoNClRoeA0KU2hhaHJhbQ0KDQpGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBMaXpob25nIEppbg0KU2VudDogRnJpZGF5LCBBcHJpbCAyMCwgMjAxMiA5 OjM4IEFNDQpUbzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPjsgQWxleGFu ZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tPg0KQ2M6IHl1cXVuLmNhb0BnbWFpbC5jb208bWFpbHRvOnl1cXVuLmNhb0BnbWFp bC5jb20+DQpTdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUg RS1UcmVlIHNvbHV0aW9uPw0KDQpIaSwgYWxsLA0KVGhlIGRpZmZlcmVuY2UgYmV0d2VlbiAyLVZM QU4gYW5kIENXIGFwcHJvYWNoIGlzIHdobyB3aWxsIHByb3ZpZGUgdGhlIFIvTCBpbmZvcm1hdGlv biwgY3VzdG9tZXIgcGF5bG9hZCBvciBQVz8gVGhlIGN1c3RvbWVyIHBheWxvYWQgd2lsbCBiZSBh bHdheXMgbW9kaWZpZWQgdG8gY2FycnkgUi9MIGluZm9ybWF0aW9uIGluIDItVkxBTiBhcHByb2Fj aCwgd2hpbGUgUFcgd2l0aCBDVyB3aWxsIGNhcnJ5IFIvTCBpbmZvcm1hdGlvbiBmb3IgQ1cgYXBw cm9hY2guDQpJIGhhdmUgYSBxdWVzdGlvbiB3aXRoIHRoZSAyLVZMQU4gYXBwcm9hY2ggaW4gSC1W UExTIHdoZXJlIEgtVlBMUyBpcyBhY2Nlc3NlZCBieSBWUFdTIGFzIGRlc2NyaWJlZCBpbiBSRkM0 NjcyIHNlY3Rpb24gMTAuMS4zLiBJZiBWUFdTIGlzIHVzZWQgdG8gYWNjZXNzIEgtVlBMUywgaG93 IGNvdWxkIHRoZSBQRSBvbiBWUFdTIHNpZGUgYWRkcyBWTEFOIHRvIGluZGljYXRlIFIvTCBpbmZv cm1hdGlvbj8NCg0KVGhhbmtzDQpMaXpob25nDQoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+DQo+IE1lc3NhZ2U6IDINCj4gRGF0ZTogVGh1LCAxOSBBcHIgMjAxMiAwNDozODoz NiArMDAwMA0KPiBGcm9tOiBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRl aW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPj4N Cj4gVG86ICJSb2dlcnMsIEpvc2giIDxqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbTxtYWlsdG86am9z aC5yb2dlcnNAdHdjYWJsZS5jb20+PiwgTHVjeSB5b25nDQo+ICAgICAgICA8bHVjeS55b25nQGh1 YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4sIERhbmllbCBDb2huIDxEYW5p ZWxDQG9yY2tpdC5jb208bWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbT4+LCBTYW0gQ2FvDQo+ICAg ICAgICA8eXVxdW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbT4+DQo+ IENjOiAibDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPiIgPGwydnBuQGlldGYu b3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4+DQo+IFN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9m IHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+IE1lc3NhZ2UtSUQ6DQo+ ICAgICAgICA8RjkzMzY1NzE3MzFBREU0MkE1Mzk3RkM4MzFDRUFBMDIwMzQxOTJARlJJRFdQUE1C MDAyLmVjaXRlbGUuY29tPG1haWx0bzpGOTMzNjU3MTczMUFERTQyQTUzOTdGQzgzMUNFQUEwMjAz NDE5MkBGUklEV1BQTUIwMDIuZWNpdGVsZS5jb20+Pg0KPiBDb250ZW50LVR5cGU6IHRleHQvcGxh aW47IGNoYXJzZXQ9InVzLWFzY2lpIg0KPg0KPiBIaSBhbGwsDQo+IEkgZnVsbHkgdW5kZXJzdGFu ZCB0aGF0IHRoYXQgd2hhdCBJIGFtIGdvaW5nIHRvIHNheSBpcyBub3QgdmVyeSBwb3B1bGFyLCBi dXQ6DQo+DQo+IElNTyBvbmUgb2YgdGhlIGFkdmFudGFnZXMgb2YgdGhlIENXLWJhc2VkIHNvbHV0 aW9uIGlzIHRoYXQgaXQgaXMgb3J0aG9nb25hbCB0byB1c2FnZSAob3Igbm9uLXVzYWdlKSBvZiBQ Mk1QIFBXcyBmb3IgZWZmZWN0aXZlIGRlbGl2ZXJ5IG9mIEJVTiB0cmFmZmljLg0KPg0KPiBBbm90 aGVyIGFkdmFudGFnZSBpcyBwcmVzZXJ2YXRpb24gb2YgZnVsbCBtZXNoIG9mIFAyUCBQV3MgaW4g YSBWUExTLCBhbmQsIGluIGEgbW9yZSBnZW5lcmljIHdheSwgbG9jYWxpemF0aW9uIG9mIGVmZmVj dHMgb2YgY2hhbmdlcyBpbiB0aGUgUEUgY29uZmlndXJhdGlvbi4NCj4NCj4gSW4gcGFydGljdWxh ciwgYWRkaW5nIGEgTGVhZiBBQyB0byBhIFBFIHRoYXQgcHJldmlvdXNseSBoYXMgYmVlbiBvbmx5 IHN1cHBvcnRpbmcgUm9vdCBBQ3MgKG9yIHZpY2UgdmVyc2EpLCByZW1vdmFsIG9mIHRoZSBsYXN0 IExlYWYgb3IgbGFzdCBSb290IEFDIGZyb20gYSBQRSB0aGF0IHByZXZpb3VzbHkgaGFzIGJlZW4g c3VwcG9ydGluZyBhIG1peCBldGMuIGFmZmVjdCBvbmx5IHRoZSBQRSB3aGVyZSB0aGlzIG9wZXJh dGlvbiBoYXBwZW5zIGFuZCBub3QgdGhlIHJlc3Qgb2YgdGhlIFBFcy4NCj4NCj4gQXMgZm9yIHRo ZSBuZWVkIGZvciBIVyBjaGFuZ2VzIHRoYXQgaGF2ZSBiZWVuIG1lbnRpb25lZCBhcyBhIG1haW4g ZGlzYWR2YW50YWdlIG9mIHRoZSBDVy1iYXNlZCBhcHByb2FjaCAtIEkgYmVsaWV2ZSBpdCBzdHJv bmdseSBkZXBlbmRzIG9uIHNwZWNpZmljIGltcGxlbWVudGF0aW9ucy4gQW5kIHNvbWUgY2hhbmdl cyBpbiB0aGUgZm9yd2FyZGluZyBwcm9jZXNzIGFyZSByZXF1aXJlZCBpbiBhbnkgc29sdXRpb24u DQo+DQo+IE15IDJjLA0KPiAgICAgU2FzaGENCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnPiBbbDJ2cG4tYm91bmNlc0BpZXRmLm9yZzxtYWls dG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZz5dIG9uIGJlaGFsZiBvZiBSb2dlcnMsIEpvc2ggW2pv c2gucm9nZXJzQHR3Y2FibGUuY29tPG1haWx0bzpqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbT5dDQo+ IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTgsIDIwMTIgOTo1NyBQTQ0KPiBUbzogTHVjeSB5b25n OyBEYW5pZWwgQ29objsgU2FtIENhbw0KPiBDYzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBu QGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0 byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPg0KPiBBZ2FpbiwgdGhlIFAyTVAgc2l0dWF0aW9uIHRo cm93cyBtZS4gIElzIHRoaXMgc29tZXRoaW5nIHRoYXQgaXMgdXNlZA0KPiBjb21tb25seT8NCj4N Cj4gSSdtIHVuZGVyIHRoZSBpbXByZXNzaW9uIHRoYXQgYWRkaW5nIFAyTVAgdG8gYW55IG1vZGVs IHJlc3VsdHMgaW4gYSBtb3JlDQo+IGNvbXBsZXggbW9kZWwuICBXZXRoZXIgb3V0c2lkZSBzLXRh ZyBpcyB1c2VkIHRvIGRpZmZlcmVudGlhdGUsIG9yDQo+IGRlZGljYXRlZCBwdydzIGFyZSB1c2Vk IGZvciB0aGUgc2FtZSBwdXJwb3NlLCBpdCBzZWVtcyBib3RoIGJlY29tZSBtb3JlDQo+IGNvbXBs ZXguDQo+DQo+IEdpbGUncyBjb21wYXJpc29uIHNsaWRlIHN0aWxsIGNvbmNpc2VseSBjYXB0dXJl cyB0aGUgZGlmZmVyZW5jZXMgYmV0d2Vlbg0KPiB0aGVzZSBtZXRob2RzLCBpbiBteSBvcGluaW9u LiAgSSBoYXZlbid0IHNlZW4gYW55IG5ldyBpZGVhcyBvciB0aG91Z2h0cw0KPiBicm91Z2h0IHRv IHRoZSBncm91cCBpbiB0aGUgcGFzdCB3ZWVrIG9yIHR3byBvbiB0aGUgc3ViamVjdC4gIEkgd291 bGQgaGF0ZQ0KPiBmb3IgYm90aCBwcm9wb3NlZCBtZXRob2RzIHRvIGRpZSBvbiB0aGUgdmluZSBi ZWNhdXNlIHdlIGNvdWxkbid0IGRlY2lkZQ0KPiBiZXR3ZWVuIHR3byBtZXRob2RzIHRoYXQgaGF2 ZSBub3RoaW5nIGluaGVyZW50bHkgd3Jvbmcgd2l0aCBlaXRoZXIuDQo+DQo+IC1Kb3NoDQo+DQo+ DQo+IE9uIDQvMTgvMTIgMTo1MyBQTSwgIkx1Y3kgeW9uZyIgPGx1Y3kueW9uZ0BodWF3ZWkuY29t PG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KPg0KPj5TZW5kIHRoaXMgYWdh aW4uDQo+Pg0KPj5Ud28gUFcgYXBwcm9hY2ggY2FuIGJlIGNvbXBsZXggdG9vIGlmIHRoZSBWUExT IGluc3RhbmNlIGZvciBFLVRyZWUgdXNlcw0KPj5QMlAgUFcgZm9yIHVuaWNhc3QgdHJhZmZpYyBh bmQgUDJNUCBQVyBmb3IgYnJvYWRjYXN0IGFuZCB1bmtub3duDQo+PnVuaWNhc3QgdHJhZmZpYywg YW5kIHNvbWUgUDJNUCBQV3MgZm9yIG11bHRpY2FzdCB0cmFmZmljLiBJdCBtYXkgZG91YmxlDQo+ PmFsbCBvZiB0aGVtLg0KPj4NCj4+THVjeQ0KPj4NCj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+RnJvbTogRGFuaWVsIENvaG4gW21haWx0bzpEYW5pZWxDQG9yY2tpdC5jb208bWFpbHRv OkRhbmllbENAb3Jja2l0LmNvbT5dDQo+PlNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTgsIDIwMTIg MTo0MiBQTQ0KPj5UbzogTHVjeSB5b25nOyBSb2dlcnMsIEpvc2g7IFNhbSBDYW8NCj4+Q2M6IGwy dnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4NCj4+U3ViamVjdDogUkU6IFRoZSBz dGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4+DQo+Pkkg dGhpbmsgdGhlIGZpcnN0IG9wdGlvbiBpdHMgdGhlIG5hdHVyYWwgd2F5IHRvIGdvLiBIb3cgaXMg dGhlIHByb2Nlc3NpbmcNCj4+aW4gdGhpcyBjYXNlIG1vcmUgY29tcGxleD8NCj4+DQo+PlRodW1i IHR5cGVkIC0gcGxlYXNlIGJlIHRvbGVyYW50DQo+Pg0KPj5MdWN5IHlvbmcgPGx1Y3kueW9uZ0Bo dWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KPj4NCj4+DQo+ Pg0KPj5TbmlwcGVkLi4NCj4+DQo+Pk11bHRpLVBXIC0gT24gaW5ncmVzcyBQRSwgZnJhbWUgaXMg cGxhY2VkIG9udG8gZWl0aGVyIGEgTGVhZi1vbmx5IFAyTVAgUFcNCj4+KGZvciB0cmFmZmljIGNv bWluZyBmcm9tIGEgbGVhZiBBQyksIG9yIG9udG8gYSBSb290L0xlYWYgUDJNUCBQVyAoZm9yDQo+ PnRyYWZmaWMgY29taW5nIGZyb20gYSByb290IEFDKQ0KPj5bW0xZXV0gTm90IHRoYXQgc2ltcGxl LiBZb3UgY29uc3RydWN0IGVpdGhlciB0d28gUDJNUCBQV3MgdG8gYWxsIG90aGVyDQo+PlBFcyBh bmQgbGV0IGVncmVzcyBQRSBwZXJmb3JtaW5nIGZpbHRlcmluZywgb3IgY29uc3RydWN0IG9uZSBQ Mk1QIFBXIHRvDQo+PmxlYWYtb25seSBQRXMgYW5kIHR3byBQMk1QIFBXcyB0byByb290IGFuZCBs ZWFmIFBFcyBhbmQgbGV0IGluZ3Jlc3MgUEUNCj4+cGVyZm9ybSBmb3J3YXJkaW5nIGFuZCBmaWx0 ZXJpbmcuIEJvdGggbWFrZSBub2RlIHByb2Nlc3MgY29tcGxleC4NCj4+DQo+PltbTFldXSBWUExT IGlzIGJ1aWx0IHdpdGggdGhlIG1lY2hhbmlzbSB1dGlsaXppbmcgUDJQIGFuZCBQMk1QIFBXIGZv cg0KPj5kZWxpdmVyaW5nIHRoZSBmcmFtZXMgdG8gcmVtb3RlIFBFcy4gV2Ugc2hvdWxkIHV0aWxp emUgdGhlbSB3aXRoIHRoZQ0KPj5taW5pbWl6ZWQgY2hhbmdlcy4gRHVhbCBWTEFOIHNvbHV0aW9u IGlzIHNpbXBsZXIgdGhhbiBEdWFsIFBXLg0KPj4NCj4+UmVnYXJkcywNCj4+THVjeQ0KPj4NCj4+ DQo+Pkkgc2VlIGhvdyAyVkxBTiBpcyBzaW1wbGVyIHdoZW4gUDJNUCBQVydzIGFyZSBpbnZvbHZl ZCwgSSB0aGluay4gIEkNCj4+aGF2ZW4ndCBoYWQgYW55IGZpcnN0IGhhbmQgZXhwZXJpZW5jZSB3 aXRoIFAyTVAgUFcncywgaG93ZXZlciwgc28gZG9uJ3QNCj4+ZmVlbCB0ZXJyaWJseSBzdHJvbmcg YWJvdXQgdGhpcyBvYmplY3Rpb24uICBJcyB0aGlzIGEgcmVhbCBwcm9ibGVtIGZvcg0KPj5vdGhl cnMgKG5vdyBvciBpbiB0aGUgZnV0dXJlKSwgb3IgaXMgdGhpcyBvYmplY3Rpb24gaW4gdGhlIHdl ZWRzPw0KPj4NCj4+SSdtIG5vdCBzdXJlIHRoZSAnYWRkaXRpb25hbCBjb21wbGV4aXR5JyBpcyBu b3RhYmxlLCBvciBldmVuIHJlbGV2YW50LiAgSQ0KPj5lbmNvdXJhZ2Ugb3RoZXJzIHRvIHNwZWFr IHVwIGlmIHRoZXkgZGlzYWdyZWUsIGFzIFAyTVAgUFcgaXMgb25seQ0KPj5jb25jZXB0dWFsIHRv IG1lLCBhbmQgSSBhbSB1bmZhbWlsaWFyIHdpdGggcmVhbC1saWZlIHVzZSBjYXNlcyBmb3IgaXQu DQo+Pg0KPj5UaGFua3MsDQo+Pkpvc2gNCj4+DQo+Pg0KPj4NCj4+T24gNC8xOC8xMiAxMDozMCBB TSwgIkx1Y3kgeW9uZyIgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVh d2VpLmNvbT4+IHdyb3RlOg0KPj4NCj4+PlBsZWFzZSBzZWUgaW5saW5lLg0KPj4+DQo+Pj4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+RnJvbTogU2FtIENhbyBbbWFpbHRvOnl1cXVuLmNh b0BnbWFpbC5jb208bWFpbHRvOnl1cXVuLmNhb0BnbWFpbC5jb20+XQ0KPj4+U2VudDogVHVlc2Rh eSwgQXByaWwgMTcsIDIwMTIgNzoxNCBBTQ0KPj4+VG86ICdEYW5pZWwgQ29obic7IEx1Y3kgeW9u ZzsgJ1JvZ2VycywgSm9zaCc7ICdIZW5kZXJpY2t4LCBXaW0gKFdpbSknOw0KPj4+Z2lsZXMuaGVy b25AZ21haWwuY29tPG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+OyBzaW1vbi5kZWxvcmRA Z21haWwuY29tPG1haWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPjsNCj4+PkFsZXhhbmRlci5W YWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbT4NCj4+PkNjOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBWbGFk aW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPG1haWx0bzpWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUu Y29tPjsNCj4+PkFuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPG1haWx0bzpBbmRyZXcuU2VyZ2Vl dkBlY2l0ZWxlLmNvbT47IElkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0bzpJZGFuLkthc3Bp dEBlY2l0ZWxlLmNvbT47DQo+Pj5NaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbTxtYWlsdG86TWlz aGFlbC5XZXhsZXJAZWNpdGVsZS5jb20+OyBSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbTxtYWlsdG86 Um90ZW0uQ29oZW5AZWNpdGVsZS5jb20+DQo+Pj5TdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0 aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+DQo+Pj5ZZXMsIDIgcHdz IGFyZSBvbmx5IG5lZWRlZCBiZXR3ZWVuIHBlcyB3aXRoIGJvdGggcm9vdCBhbmQgbGVhZiBhY3Mg YWZ0ZXINCj4+PmltcHJvdmluZyBEdWFsLVBXIGFwcHJvYWNoLiBJZiBjb25zaWRlciBQMk1QLCBE dWFsLVBXIGFwcHJvYWNoIHNldHVwIDINCj4+PlAyTVANCj4+PlBXcyBpZiBuZWVkLiBUaGVyZSBp cyBubyBkaWZmZXJlbmNlIGJldHdlZW4gUDJNUCBvciBub3JtYWwgUFcgc2V0dXAuIEJ1dCwNCj4+ PmNhbiBMZWFmLUFDcyBiZSBib3VuZCB0byBSb290IFBFIG9mIFAyTVAgUFc/DQo+Pj4NCj4+Pltb TFldXSBObywgaXQgbWFrZXMgY29tcGxleCBpbiBzZXR0aW5nIHVwIFAyTVAgUFcuIFNob3VsZCBh IFBFIHdpdGggYm90aA0KPj4+cm9vdCBhbmQgbGVhZiBBQ3Mgc2V0IHVwIHR3byBvciBvbmUgUDJN UCBQVyB0byBvdGhlciBQRXMgKHNvbWUgUEUgaGF2ZQ0KPj4+Ym90aCByb290IGFuZCBsZWFmIEFD IGFuZCBzb21lIG9ubHkgaGF2ZSBsZWFmIEFDcyk/DQo+Pj5SZWdhcmRzLA0KPj4+THVjeQ0KPj4+ DQo+Pj5SZWdhcmRzLA0KPj4+DQo+Pj5ZdXF1biAoU2FtKSBDYW8NCj4+PkUtbWFpbDogWXVxdW4u Y2FvQGdtYWlsLmNvbTxtYWlsdG86WXVxdW4uY2FvQGdtYWlsLmNvbT4NCj4+Pg0KPj4+DQo+Pj4t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+RnJvbTogRGFuaWVsIENvaG4gW21haWx0bzpE YW5pZWxDQG9yY2tpdC5jb208bWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbT5dDQo+Pj5TZW50OiBU dWVzZGF5LCBBcHJpbCAxNywgMjAxMiA0OjU2IFBNDQo+Pj5UbzogTHVjeSB5b25nOyBSb2dlcnMs IEpvc2g7IEhlbmRlcmlja3gsIFdpbSAoV2ltKTsNCj4+PmdpbGVzLmhlcm9uQGdtYWlsLmNvbTxt YWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tPjsNCj4+PnNpbW9uLmRlbG9yZEBnbWFpbC5jb208 bWFpbHRvOnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+OyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0 ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+OyBTYW0gQ2Fv DQo+Pj5DYzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPjsgVmxhZGltaXIu S2xlaW5lckBlY2l0ZWxlLmNvbTxtYWlsdG86VmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbT47 DQo+Pj5BbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3LlNlcmdlZXZAZWNp dGVsZS5jb20+OyBJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbTxtYWlsdG86SWRhbi5LYXNwaXRAZWNp dGVsZS5jb20+Ow0KPj4+TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb208bWFpbHRvOk1pc2hhZWwu V2V4bGVyQGVjaXRlbGUuY29tPjsgUm90ZW0uQ29oZW5AZWNpdGVsZS5jb208bWFpbHRvOlJvdGVt LkNvaGVuQGVjaXRlbGUuY29tPg0KPj4+U3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFw cHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4+Pg0KPj4+QWRkaW5nIFNhbSAoYXMg bDJ2cG5AIGlzIGhvbGRpbmcgbWVzc2FnZXMpDQo+Pj4NCj4+PkRDDQo+Pj4NCj4+Pi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBMdWN5IHlvbmcgW21haWx0bzpsdWN5LnlvbmdA aHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+XQ0KPj4+U2VudDogVHVlc2Rh eSwgQXByaWwgMTcsIDIwMTIgMTI6MzkgQU0NCj4+PlRvOiBEYW5pZWwgQ29objsgUm9nZXJzLCBK b3NoOyBIZW5kZXJpY2t4LCBXaW0gKFdpbSk7DQo+Pj5naWxlcy5oZXJvbkBnbWFpbC5jb208bWFp bHRvOmdpbGVzLmhlcm9uQGdtYWlsLmNvbT47IHNpbW9uLmRlbG9yZEBnbWFpbC5jb208bWFpbHRv OnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+Ow0KPj4+QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVs ZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPg0KPj4+Q2M6IGwy dnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz47IFZsYWRpbWlyLktsZWluZXJAZWNp dGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb20+Ow0KPj4+QW5kcmV3 LlNlcmdlZXZAZWNpdGVsZS5jb208bWFpbHRvOkFuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPjsg SWRhbi5LYXNwaXRAZWNpdGVsZS5jb208bWFpbHRvOklkYW4uS2FzcGl0QGVjaXRlbGUuY29tPjsN Cj4+Pk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPG1haWx0bzpNaXNoYWVsLldleGxlckBlY2l0 ZWxlLmNvbT47IFJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPG1haWx0bzpSb3RlbS5Db2hlbkBlY2l0 ZWxlLmNvbT4NCj4+PlN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRv IHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4NCj4+Pg0KPj4+U25pcHBlZCwNCj4+Pg0KPj4+QXMg d2UgZGlzY3Vzc2VkIGV4dGVuc2l2ZWx5IGluIHRoZSBsaXN0LCBhbmQgYXMgcmVmbGVjdGVkIGlu IGdpbGVzDQo+Pj5zbGlkZSwgMiBwd3MgYXJlIG9ubHkgbmVlZGVkIGJldHdlZW4gcGVzIHdpdGgg Ym90aCByb290IGFuZCBsZWFmIGFjcywNCj4+PndoaWNoIHdpbGwgdHlwaWNhbGx5IGJlIGEgc21h bGwgbWlub3JpdHkuDQo+Pj5bW0xZXV0gRG9uJ3Qga25vdyBpZiB0aGUgYXNzdW1wdGlvbiBpcyB0 cnVlLiBFdmVuIGl0IGlzIHRoZSBjYXNlLCBib3RoDQo+Pj5hcHByb2FjaGVzIGNhbiBiZW5lZml0 IGZyb20gaXQuIEkgd2FzIG9mZiBmb3IgYSB3aGlsZSBhbmQgY2FwdHVyZXMgc29tZQ0KPj4+ZGlz Y3Vzc2lvbnMgbm93Lg0KPj4+DQo+Pj5BbHNvIGFzIHBlciBnaWxlcyBzbGlkZSwgZHVhbCB2bGFu IGNhbiBoYXZlIHNjYWxhYmlsaXR5IGlzc3VlcyBkdWUgdG8NCj4+PmFkZGl0aW9uYWwgbG9va3Vw IGFuZCBkb3VibGUgdXNlIG9mIHZsYW5zIGluIGludGVybmFsIGVtdWxhdGVkIGxhbg0KPj4+aW50 ZXJmYWNlLiBBbHNvIHRoZXJlIGFyZSBwb3RlbnRpYWwgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBp c3N1ZXMgd2l0aA0KPj4+c2lsaWNvbiB0aGF0IGRvZXNuJ3Qgc3VwcG9ydCB2bGFuIG1hcHBpbmcu DQo+Pj5bW0xZXV0gSSB3YXMgbm90IGluIElFVEY4MyBtZWV0aW5nIGFuZCB3YWl0IG9uIHRoZSBt ZWV0aW5nIG1pbnV0ZXMuIEkgYW0NCj4+Pm5vdCBjbGVhciBvbiBhbGwgdGhlIGlzc3Vlcy4gQ291 bGQgeW91IGJlIG1vcmUgc3BlY2lmaWM/IEFzIEkgbWVudGlvbmVkDQo+Pj5pbiBiZWxvdywgdHdv IFBXIGFwcHJvYWNoIG1ha2VzIFZQTFMgdHJhbnNwb3J0IGNvbnN0cnVjdGlvbiBhbmQgcGFja2V0 DQo+Pj5mb3J3YXJkaW5nIG1vcmUgY29tcGxleCwgSSBjYW4gc2VlIHBvdGVudGlhbCBiYWNrd2Fy ZCBjb21wYXRpYmlsaXR5DQo+Pj5pc3N1ZXMgd2l0aCAyIFBXIHNvbHV0aW9uLg0KPj4+DQo+Pj5S ZWdhcmRzLA0KPj4+THVjeQ0KPj4+DQo+Pj5SZWdhcmRzLA0KPj4+DQo+Pj5EYW5pZWwNCj4+Pg0K Pj4+VGh1bWIgdHlwZWQgLSBwbGVhc2UgYmUgdG9sZXJhbnQNCj4+Pg0KPj4+THVjeSB5b25nIDxs dWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiB3cm90ZToN Cj4+Pg0KPj4+SW4gbXkgbWluZCwgdGhlIFZMQU4gYXBwcm9hY2ggbWVhbnMgZHVhbCB2bGFuIG1l dGhvZC4NCj4+Pg0KPj4+VGhlIG1haW4gY29uY2VybiBmb3IgQ1cgYXBwcm9hY2ggaXMgaGFyZHdh cmUgc3VwcG9ydC4NCj4+Pg0KPj4+VHdvIFBXIGFwcHJvYWNoIGNhbiBiZSBjb21wbGV4IHRvbyBp ZiB0aGUgVlBMUyBpbnN0YW5jZSBmb3IgRS1UcmVlIHVzZXMNCj4+PlAyUCBQVyBmb3IgdW5pY2Fz dCB0cmFmZmljIGFuZCBQMk1QIFBXIGZvciBicm9hZGNhc3QgYW5kIHVua25vd24gdW5pY2FzdA0K Pj4+dHJhZmZpYywgYW5kIHNvbWUgUDJNUCBQV3MgZm9yIG11bHRpY2FzdCB0cmFmZmljLiBJdCBt YXkgZG91YmxlIGFsbCBvZg0KPj4+dGhlbS4NCj4+Pg0KPj4+RS10cmVlIGlzIGFuIEV0aGVybmV0 IHNlcnZpY2UgYW5kIHRoZXJlIGlzIGFscmVhZHkgVkxBTiBiYXNlZCBzb2x1dGlvbg0KPj4+aW4g SUVFRSwgY2FuIHdlIGp1c3QgdXRpbGl6ZSBpdCB3aXRob3V0IGNvbXBsaWNhdGluZyBWUExTIHRy YW5zcG9ydA0KPj4+Y29uc3RydWN0aW9uPyBUaGlzIGFsc28gbWFrZXMgaW50ZXJ3b3JraW5nIHdp dGggRXRoIG9ubHkgbmV0d29yayBlYXNpZXIuDQo+Pj4NCj4+PkNoZWVycywNCj4+Pkx1Y3kNCj4+ Pg0KPj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IFJvZ2VycywgSm9zaCBb bWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29tPG1haWx0bzpqb3NoLnJvZ2Vyc0B0d2NhYmxl LmNvbT5dDQo+Pj5TZW50OiBNb25kYXksIEFwcmlsIDE2LCAyMDEyIDg6MzUgQU0NCj4+PlRvOiBM dWN5IHlvbmc7IEhlbmRlcmlja3gsIFdpbSAoV2ltKTsgJ2dpbGVzLmhlcm9uQGdtYWlsLmNvbTxt YWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tPic7DQo+Pj4nc2ltb24uZGVsb3JkQGdtYWlsLmNv bTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT4nOyAnQWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPicNCj4+ PkNjOiAnbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPic7ICdWbGFkaW1pci5L bGVpbmVyQGVjaXRlbGUuY29tPG1haWx0bzpWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPic7 DQo+Pj4nQW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb208bWFpbHRvOkFuZHJldy5TZXJnZWV2QGVj aXRlbGUuY29tPic7ICdJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbTxtYWlsdG86SWRhbi5LYXNwaXRA ZWNpdGVsZS5jb20+JzsNCj4+PidNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbTxtYWlsdG86TWlz aGFlbC5XZXhsZXJAZWNpdGVsZS5jb20+JzsgJ1JvdGVtLkNvaGVuQGVjaXRlbGUuY29tPG1haWx0 bzpSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbT4nDQo+Pj5TdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBv ZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+DQo+Pj5JIGJlbGll dmUgdGhlIGluaXRpYWwgcXVlc3Rpb24gd2FzIGluIHJlZ2FyZCB0byB0aGUgQ1cgbWV0aG9kLiAg QXJlIHlvdQ0KPj4+c2F5aW5nIHRoYXQgeW91IG5vIGxvbmdlciBhcmUgaW50ZXJlc3RlZCBpbiB0 aGF0IG1ldGhvZCBpbiBwcmVmZXJlbmNlIG9mDQo+Pj50aGUgZHVhbCB2bGFuIG1ldGhvZD8NCj4+ Pg0KPj4+DQo+Pj4NCj4+Pkx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1 Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+Pj4NCj4+Pg0KPj4+QWdyZWUgd2l0aCBXaW0u IFZMQU4gYXBwcm9hY2ggaXMgdGhlIGJlc3Qgc29sdXRpb24gZm9yIEUtVHJlZS4NCj4+Pg0KPj4+ THVjeQ0KPj4+DQo+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+RnJvbTogbDJ2cG4t Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzps MnZwbi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnPl0gT24g QmVoYWxmDQo+Pj5PZiBIZW5kZXJpY2t4LCBXaW0gKFdpbSkNCj4+PlNlbnQ6IFRodXJzZGF5LCBB cHJpbCAxMiwgMjAxMiAyOjAzIEFNDQo+Pj5UbzogJ2dpbGVzLmhlcm9uQGdtYWlsLmNvbTxtYWls dG86Z2lsZXMuaGVyb25AZ21haWwuY29tPic7ICdzaW1vbi5kZWxvcmRAZ21haWwuY29tPG1haWx0 bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPic7DQo+Pj4nQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNp dGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPicNCj4+PkNj OiAnbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPic7ICdWbGFkaW1pci5LbGVp bmVyQGVjaXRlbGUuY29tPG1haWx0bzpWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPic7DQo+ Pj4nQW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb208bWFpbHRvOkFuZHJldy5TZXJnZWV2QGVjaXRl bGUuY29tPic7ICdJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbTxtYWlsdG86SWRhbi5LYXNwaXRAZWNp dGVsZS5jb20+JzsNCj4+PidNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbTxtYWlsdG86TWlzaGFl bC5XZXhsZXJAZWNpdGVsZS5jb20+JzsgJ1JvdGVtLkNvaGVuQGVjaXRlbGUuY29tPG1haWx0bzpS b3RlbS5Db2hlbkBlY2l0ZWxlLmNvbT4nDQo+Pj5TdWJqZWN0OiBSZTogVGhlIHN0YXR1cyBvZiB0 aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+DQo+Pj5UaGUgdmxhbiBh cHByb2FjaCBpcyBzdXBlcmlvciBhcyBpdCBhbHNvIHdvcmtzIGZvciBldGggb25seSBuZXR3b3Jr cywNCj4+PmV0Yy4gT24gdG9wIHNvbWUgdmVuZG9ycyBpbmRpY2F0ZSBodyBpc3N1ZXMgd2l0aCB0 aGUgY3cgYXBwcm9hY2guIEFzDQo+Pj5zdWNoIHdlIGhhdmUgZHJvcHBlZCBtb3JlIG9yIGxlc3Mg dGhlIGN3IGFwcHJvYWNoLg0KPj4+DQo+Pj5DaGVlcnMsDQo+Pj5XaW0NCj4+Pl9fX19fX19fX19f X19fX19fDQo+Pj5zZW50IGZyb20gYmxhY2tiZXJyeQ0KPj4+DQo+Pj4tLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tDQo+Pj5Gcm9tOiBHaWxlcyBIZXJvbiBbbWFpbHRvOmdpbGVzLmhlcm9uQGdt YWlsLmNvbTxtYWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tPl0NCj4+PlNlbnQ6IFRodXJzZGF5 LCBBcHJpbCAxMiwgMjAxMiAwODoyMiBBTQ0KPj4+VG86IFNpbW9uIERlbG9yZCA8c2ltb24uZGVs b3JkQGdtYWlsLmNvbTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT4+OyBBbGV4YW5kZXIg VmFpbnNodGVpbg0KPj4+PEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4+DQo+Pj5DYzogbDJ2cG5AaWV0Zi5vcmc8 bWFpbHRvOmwydnBuQGlldGYub3JnPiA8bDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYu b3JnPj47IFZsYWRpbWlyIEtsZWluZXINCj4+PjxWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29t PG1haWx0bzpWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPj47IEFuZHJldyBTZXJnZWV2DQo+ Pj48QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb208bWFpbHRvOkFuZHJldy5TZXJnZWV2QGVjaXRl bGUuY29tPj47IElkYW4gS2FzcGl0IDxJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbTxtYWlsdG86SWRh bi5LYXNwaXRAZWNpdGVsZS5jb20+PjsNCj4+Pk1pc2hhZWwgV2V4bGVyIDxNaXNoYWVsLldleGxl ckBlY2l0ZWxlLmNvbTxtYWlsdG86TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb20+PjsgUm90ZW0g Q29oZW4NCj4+PjxSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbTxtYWlsdG86Um90ZW0uQ29oZW5AZWNp dGVsZS5jb20+Pg0KPj4+U3ViamVjdDogUmU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMg dG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4+Pg0KPj4+U29ycnkgLSB0aGUgImFub255bW91cyBw cmVzZW50YXRpb24iIHdhcyBtaW5lLiAgSSBzaG91bGQgcG9zc2libHkgaGF2ZQ0KPj4+cHV0IGlu IGEgdGhpcmQgY29sdW1uIG9uIHRoZSBDVyBhcHByb2FjaC4gIEFuZCBob3BlZnVsbHkgdGhlIG1p bnV0ZXMNCj4+PndpbGwgYmUgcG9zdGVkIHNvb24uDQo+Pj4NCj4+PldlIGhhZCB2YXJpb3VzIGRp c2N1c3Npb25zLCBhcyBTaW1vbiBzdGF0ZWQsIGFuZCBjb25zZW5zdXMgc2VlbWVkIHRvIGJlDQo+ Pj5mb3JtaW5nIGFyb3VuZCB0aGUgdHdvIGFsdGVybmF0aXZlcyBvZiB0d28gUFdFcyBvciB0d28g VkxBTnMuICBJIGJlbGlldmUNCj4+PnRocmVlIG9mIHRoZSBhdXRob3JzIG9mIHRoZSBDVyBhcHBy b2FjaCBhcmUgYWxzbyBhdXRob3JzIG9mIHRoZSB0d28gVkxBTg0KPj4+YXBwcm9hY2ggYW5kIG9u ZSBpcyBhbHNvIGFuIGF1dGhvciBvZiB0aGUgdHdvIFBXRSBhcHByb2FjaC4gU28gcGVyaGFwcw0K Pj4+aXQncyBiZXN0IHRvIGxldCB0aG9zZSBmb3VyIGluZGl2aWR1YWxzIHNheSB3aGljaCBhcHBy b2FjaCB0aGV5IHByZWZlcg0KPj4+YW5kIHdoeT8NCj4+Pg0KPj4+R2lsZXMNCj4+Pg0KPj4+T24g MTAvMDQvMjAxMiAwMDo0NSwgIlNpbW9uIERlbG9yZCIgPHNpbW9uLmRlbG9yZEBnbWFpbC5jb208 bWFpbHRvOnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+PiB3cm90ZToNCj4+Pg0KPj4+PiBIaSBBbGV4 YW5kZXIsDQo+Pj4+DQo+Pj4+IFlvdSBhcmUgcmlnaHQsIG5vIGRpc2N1c3Npb24gb24gdGhlIFdH IG1haWxpbmcgbGlzdCByZWNlbnRseSwgYnV0DQo+Pj4+IHRoZXJlIGhhdmUgYmVlbiBzdWJzdGFu dGlhbCBkaXNjdXNzaW9ucyBhbW9uZyB0aGUgYXV0aG9ycyBvZiB2YXJpb3VzDQo+Pj4+IHNvbHV0 aW9uIGRyYWZ0cyBvZmYgdGhlIG1haWxpbmcgbGlzdC4gQXMgZmFyIGFzIEkga25vdywgbm8gY29u c2Vuc3VzDQo+Pj4+IHlldCBiZWZvcmUgaWV0ZjgzLCBub3Qgc3VyZSB0aGUgcHJvZ3Jlc3MgaW4g dGhlIFBhcmlzIFdHIG1lZXRpbmcuIEkNCj4+Pj4gdGhpbmsgdGhlIENXIGFwcHJvYWNoIGhhcyBu b3QgYmVlbiByZWplY3RlZCBieSB0aGUgV0cgeWV0LCBvciB0aGUgV0cNCj4+Pj4gaGFzIG5vdCB5 ZXQgZGVjaWRlZCBvbiB3aGljaCBvbmUgdG8gYWRvcHQuDQo+Pj4+DQo+Pj4+IFNpbW9uDQo+Pj4+ DQo+Pj4+IDIwMTIvNC84IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+Pg0K Pj4+Pg0KPj4+Pj4gIEhpIGFsbCwNCj4+Pj4+DQo+Pj4+PiBVbmZvcnR1bmF0ZWx5IEkgaGF2ZSBu b3QgYmVlbiBhYmxlIHRvIGF0dGVuZCB0aGUgUGFyaXMgSUVURi4NCj4+Pj4+DQo+Pj4+PiBIb3dl dmVyLCBsb29raW5nIHVwIHRoZSBMMlZQTiBwcm9jZWVkaW5ncywgSSd2ZSBmb3VuZCBhIHNob3J0 DQo+Pj4+PiBhbm9ueW1vdXMgcHJlc2VudGF0aW9uIGNhbGxlZCAiRS1UcmVlIFVwZGF0ZSIgICgN Cj4+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODMvc2xpZGVzL3NsaWRlcy04 My1sMnZwbi0xLnBwdHgpLg0KPj4+Pj4gVGhpcyBwcmVzZW50YXRpb24gZGlzY3Vzc2VzIHRoZSBk aWZmZXJlbmNlcyBvZiB0aGUgRS1UcmVlIGFwcHJvYWNoZXMNCj4+Pj4+IGJhc2VkIG9uIGRlZGlj YXRlZCBWTEFOcyAoYXMgaW4NCj4+Pj4+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtY2FvLWwydnBuLXZwbHMtZXRyZWUvP2luY2x1ZGVfdA0KPj4+Pj4gZXh0PTEpIGFuZCBt dWx0aXBsZSBQV3MgYmV0d2VlbiB0aGUgUEVzIChhcyBpbg0KPj4+Pj4gaHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1yYW0tbDJ2cG4tZXRyZWUtbXVsdGlwbGUtcHcvP2luDQo+ Pj4+PiBjbHVkZV90ZQ0KPj4+Pj4geHQ9MSkNCj4+Pj4+IGFuZCBjb21wbGV0ZWx5IGlnbm9yZXMg dGhlIHNvbHV0aW9uIGJhc2VkIG9uIHVzYWdlIG9mIHRoZSBDVyBpbiB0aGUNCj4+Pj4+IFBXcyBj b25uZWN0aW5nIHRoZSBQRXMgKGFzIGluDQo+Pj4+PiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWtleS1sMnZwbi12cGxzLWV0cmVlLz9pbmNsdWRlX3QNCj4+Pj4+IGV4dD0x DQo+Pj4+PiApLg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gVGhlIE1pbnV0ZXMgb2YgdGhl IFBhcmlzIEwyVlBOIHNlc3Npb24gYXJlIG5vdCB5ZXQgYXZhaWxhYmxlLCBidXQgSQ0KPj4+Pj4g d29uZGVyIHdoZXRoZXIgdGhlIFdHIGhhcyB0YWtlbiBhIGRlY2lzaW9uIHRvIHJlamVjdCB0aGUg YXBwcm9hY2gNCj4+Pj4+IGJhc2VkIG9uIHRoZSBDVyB1c2FnZT8gSSBkbyBub3QgcmVtZW1iZXIg YW55IHJlY2VudCBkaXNjdXNzaW9uIG9mDQo+Pj4+PiB0aGlzIHRvcGljIG9uIHRoZSBXRyBtYWls aW5nIGxpc3QuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBSZWdhcmRzLCBhbmQgbG90cyBv ZiB0aGFua3MgaW4gYWR2YW5jZSwNCj4+Pj4+DQo+Pj4+PiBTYXNoYQ0KPj4+Pj4NCj4+Pj4+DQo+ Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVk IGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zDQo+Pj4+PiBpbmZvcm1hdGlvbiB3 aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kN Cj4+Pg0KPj4+Pj4gVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Np b24gaW4gZXJyb3IsIHBsZWFzZQ0KPj4+Pj4gaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3Ig ZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZA0KPj4+Pj4gYWxsIGNvcGllcyB0 aGVyZW9mLg0KPj4+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj5UaGlzIEUtbWFpbCBh bmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZQ0K Pj4+cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVu dGlhbCwgb3Igc3ViamVjdA0KPj4+dG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5l ciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQNCj4+PnNvbGVseSBmb3IgdGhlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLg0KPj4+ SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91 IGFyZSBoZXJlYnkNCj4+Pm5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1 dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuDQo+Pj5pbiByZWxhdGlvbiB0byB0aGUgY29u dGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzDQo+Pj5zdHJpY3RseSBw cm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMN Cj4+PkUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGFuZCBwZXJtYW5lbnRseQ0KPj4+ZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2Yg dGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCj4+Pg0KPj4NCj4+DQo+PlRoaXMgRS1tYWls IGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxl DQo+PnByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRl bnRpYWwsIG9yIHN1YmplY3QgdG8NCj4+Y29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5l ciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5DQo+PmZvciB0aGUgdXNlIG9m IHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlv dQ0KPj5hcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBh cmUgaGVyZWJ5IG5vdGlmaWVkDQo+PnRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlv biwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluDQo+PnJlbGF0aW9uIHRvIHRoZSBjb250ZW50 cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkNCj4+cHJvaGli aXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFp bCBpbg0KPj5lcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBw ZXJtYW5lbnRseSBkZWxldGUgdGhlDQo+Pm9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUt bWFpbCBhbmQgYW55IHByaW50b3V0Lg0KPg0KPg0KPiBUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBp bmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0 IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWls IGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRp dHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFu eSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBp biByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1t YWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55 IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCj4gVGhpcyBlLW1haWwgbWVz c2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucyBpbmZv cm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFy eSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24g aW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0 aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFsbCBjb3BpZXMgdGhlcmVvZi4NCj4NCj4NCj4N Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEwydnBuIG1haWxpbmcgbGlzdA0KPiBM MnZwbkBpZXRmLm9yZzxtYWlsdG86TDJ2cG5AaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbDJ2cG4NCj4NCj4NCj4gRW5kIG9mIEwydnBuIERpZ2VzdCwg Vm9sIDk1LCBJc3N1ZSAyNQ0KPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K From david.i.allan@ericsson.com Wed Apr 25 12:19:39 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5E221F88F4 for ; Wed, 25 Apr 2012 12:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 YCUi1mIX8ku2 for ; Wed, 25 Apr 2012 12:19:37 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C162821F88E7 for ; Wed, 25 Apr 2012 12:19:37 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3PJIqMR001711; Wed, 25 Apr 2012 14:19:03 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.69]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 25 Apr 2012 15:18:55 -0400 From: David Allan I To: Lucy yong , Daniel Cohn , "Rogers, Josh" , Shahram Davari , Lizhong Jin , "l2vpn@ietf.org" , "Alexander.Vainshtein@ecitele.com" Date: Wed, 25 Apr 2012 15:18:54 -0400 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IABEiWPQAAFgqVoABMXRAAAApgww Message-ID: <60C093A41B5E45409A19D42CF7786DFD52324EEE6F@EUSAACMS0703.eamcs.ericsson.se> References: <171f01cd2302$45aa461f$05280101@corrigent.com> <2691CE0099834E4A9C5044EEC662BB9D3264C0C9@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D3264C0C9@dfweml505-mbx> 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 Cc: "yuqun.cao@gmail.com" X-BeenThere: l2vpn@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, 25 Apr 2012 19:19:39 -0000 Actually that was Don Fedyk's example and it was correct. I'd clarify this to say there can be a tag stack, but maximum 2 deep (C tag= and S tag). You never have two tags of the same type in a frame in a PB ne= twork. D -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of L= ucy yong Sent: Wednesday, April 25, 2012 3:06 PM To: Daniel Cohn; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org;= Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Daniel, David Allen already explained the solution. >From David: ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. Ingress VID does not have to equal Egress VID but regardless there is only = ever one VID on a frame at a time. -end This works when customer makes ingress VLAN ID not equal to or equal to egr= ess VLAN ID. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Wednesday, April 25, 2012 11:39 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi Lucy, The scenario we are discussing is not the E-Tree E-NNI, but a general scena= rio where frames arriving at the root or leaf AC are already double tagged= . In this case, the dual vlan solution cannot preserve the vlans without ad= ding a third one, can it? Maybe Shahram can add details on the scenario he had in mind Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has S-VLAN preservation attribute for ENNI only because there is no s-v= lan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN preser= vation attribute is used. It applies to E-Tree as well. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Tuesday, April 24, 2012 2:12 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, even if the current MEF framework doesn't require s-vlan preservation, I be= lieve it's to the industry's benefit to adopt a solution that is not constr= ained to a specific enni model that, like all things networking, is likely = to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service provider= s' inputs. It had a fair reason to assume S-VLAN over ENNI by then. It may = open B-VLAN for the future. It is better for us not to discuss a future fr= amework here, because it will lead us to nowhere. Here, we want to extend V= PLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Va= inshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume tha= t the VLAN tags at the E-NNI will always be according to the current MEF mo= del? Or should we try to be as transparent as possible to user VLAN encapsu= lation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case VLAN t= ag) to signal VPLS information (in this case root/leaf origin) is necessari= ly tied to specific assumptions on user payload encapsulation (in this case= , that S-VLAN tag is "available" to encode root/leaf). I don't think this i= s a future-proof assumption, it's very likely that other network models wil= l come up that require S-VLAN preservation, which in the 2-VLAN approach wo= uld necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, "l2vpn@i= etf.org" >, "A= lexander.Vainshtein@ecitele.com" <= Alexander.Vainshtein@ecitele.com> Cc: "yuqun.cao@gmail.com" > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic alrea= dy has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com= Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L i= nformation, customer payload or PW? The customer payload will be always mod= ified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is access= ed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informati= on? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > com>> > To: "Rogers, Josh" >, Lucy yong > >, Daniel Cohn <= DanielC@orckit.com>, Sam Cao > > > Cc: "l2vpn@ietf.org" > > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, = but: > > IMO one of the advantages of the CW-based solution is that it is orthogon= al to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffi= c. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and,= in a more generic way, localization of effects of changes in the PE config= uration. > > In particular, adding a Leaf AC to a PE that previously has been only sup= porting Root ACs (or vice versa), removal of the last Leaf or last Root AC = from a PE that previously has been supporting a mix etc. affect only the PE= where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadva= ntage of the CW-based approach - I believe it strongly depends on specific = implementations. And some changes in the forwarding process are required in= any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org > [l2vpn-bounces@ietf.org] on behalf of > Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a > more complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become > more complex. > > Gile's comparison slide still concisely captures the differences > between these methods, in my opinion. I haven't seen any new ideas or > thoughts brought to the group in the past week or two on the subject. > I would hate for both proposed methods to die on the vine because we > couldn't decide between two methods that have nothing inherently wrong wi= th either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree >>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may >>double all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn >>[mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the >>processing in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >>PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW >>(for traffic coming from a root AC) [[LY]] Not that simple. You >>construct either two P2MP PWs to all other PEs and let egress PE >>performing filtering, or construct one P2MP PW to leaf-only PEs and >>two P2MP PWs to root and leaf PEs and let ingress PE perform >>forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so >>don't feel terribly strong about this objection. Is this a real >>problem for others (now or in the future), or is this objection in the we= eds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. >>I encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao >>>[mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>(Wim)'; giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>PE have both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn >>>[mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com>; Sam Cao >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong >>>[mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>both approaches can benefit from it. I was off for a while and >>>captures some discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues >>>with silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >>>am not clear on all the issues. Could you be more specific? As I >>>mentioned in below, two PW approach makes VPLS transport construction >>>and packet forwarding more complex, I can see potential backward >>>compatibility issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>double all of them. >>> >>>E-tree is an Ethernet service and there is already VLAN based >>>solution in IEEE, can we just utilize it without complicating VPLS >>>transport construction? This also makes interworking with Eth only netwo= rk easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh >>>[mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); >>>'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vain= shtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are >>>you saying that you no longer are interested in that method in >>>preference of the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org >>>[mailto:l2vpn-bounces@ietf.org] On >>>Behalf Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron >>>[mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord >>>>; Alexander >>>Vainshtein >>>>>.com>> >>>Cc: l2vpn@ietf.org >>>>; Vladimir Kleiner >>>>; >>>Andrew Sergeev >>>>; Idan >>>Kaspit >; >>>Mishael Wexler >>>>; >>>Rotem Cohen > >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly >>>have put in a third column on the CW approach. And hopefully the >>>minutes will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to >>>be forming around the two alternatives of two PWEs or two VLANs. I >>>believe three of the authors of the CW approach are also authors of >>>the two VLAN approach and one is also an author of the two PWE >>>approach. So perhaps it's best to let those four individuals say >>>which approach they prefer and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of >>>> various solution drafts off the mailing list. As far as I know, no >>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>> meeting. I think the CW approach has not been rejected by the WG >>>> yet, or the WG has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein >>>> >>> le.com>> >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree >>>>> approaches based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/ >>>>> ?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in >>>>> the PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>> I wonder whether the WG has taken a decision to reject the >>>>> approach based on the CW usage? I do not remember any recent >>>>> discussion of this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and >>>>> contains information which is CONFIDENTIAL and which may be >>>>> proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original >>>>> and all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or >>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>intended solely for the use of the individual or entity to which it is a= ddressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail >>>is strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is >>addressed. If you are not the intended recipient of this E-mail, you >>are hereby notified that any dissemination, distribution, copying, or >>action taken in relation to the contents of and attachments to this >>E-mail is strictly prohibited and may be unlawful. If you have >>received this E-mail in error, please notify the sender immediately >>and permanently delete the original and any copy of this E-mail and any p= rintout. > > > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** From DanielC@orckit.com Wed Apr 25 12:46:15 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F51A21F8816 for ; Wed, 25 Apr 2012 12:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.62 X-Spam-Level: * X-Spam-Status: No, score=1.62 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_ILLEGAL_IP=1.908, RCVD_NUMERIC_HELO=2.067] 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 rl02Q9IayT3M for ; Wed, 25 Apr 2012 12:46:13 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id EB5C621F889F for ; Wed, 25 Apr 2012 12:46:12 -0700 (PDT) Received: from 1.1.40.5 ([1.1.40.5]) by tlvmail1.corrigent.com ([1.1.40.5]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Apr 2012 19:48:18 +0000 Date: Wed, 25 Apr 2012 22:46:07 +0300 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <172d01cd231c$5cce3952$05280101@corrigent.com> Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IABEiWPQAAFgqVoABMXRAAABv/gY X-MimeOLE: Produced By Microsoft Exchange V6.5 Importance: normal From: "Daniel Cohn" To: "Lucy yong" , "Rogers, Josh" , "Shahram Davari" , "Lizhong Jin" , , MIME-Version: 1.0 Cc: yuqun.cao@gmail.com X-BeenThere: l2vpn@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, 25 Apr 2012 19:46:15 -0000 And to this I asked how this mapping works - how does the egress pe = recover the ingress vid when it gets the frame tagged with only the = root/leaf vid? How can you convey the ingress vid plus the root/leaf = attribute in the same number of bits?=0A= What am I missing?=0A= =0A= Daniel=0A= =0A= Thumb typed - please be tolerant=0A= =0A= Lucy yong wrote:=0A= =0A= Daniel, David Allen already explained the solution.=20 >From David: ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. Ingress VID does not have to equal Egress VID but regardless there is = only ever one VID on a frame at a time. -end This works when customer makes ingress VLAN ID not equal to or equal to = egress VLAN ID. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Daniel Cohn Sent: Wednesday, April 25, 2012 11:39 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; = l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi Lucy, The scenario we are discussing is not the E-Tree E-NNI, but a general = scenario where frames arriving at the root or leaf AC are already = double tagged. In this case, the dual vlan solution cannot preserve the = vlans without adding a third one, can it? Maybe Shahram can add details on the scenario he had in mind Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has S-VLAN preservation attribute for ENNI only because there is no = s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN = preservation attribute is used. It applies to E-Tree as well. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Daniel Cohn Sent: Tuesday, April 24, 2012 2:12 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; = l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, even if the current MEF framework doesn't require s-vlan preservation, I = believe it's to the industry's benefit to adopt a solution that is not = constrained to a specific enni model that, like all things networking, = is likely to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service = providers' inputs. It had a fair reason to assume S-VLAN over ENNI by = then. It may open B-VLAN for the future. It is better for us not to = discuss a future framework here, because it will lead us to nowhere. = Here, we want to extend VPLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Daniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; = Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume = that the VLAN tags at the E-NNI will always be according to the current = MEF model? Or should we try to be as transparent as possible to user = VLAN encapsulation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case = VLAN tag) to signal VPLS information (in this case root/leaf origin) is = necessarily tied to specific assumptions on user payload encapsulation = (in this case, that S-VLAN tag is "available" to encode root/leaf). I = don't think this is a future-proof assumption, it's very likely that = other network models will come up that require S-VLAN preservation, = which in the 2-VLAN approach would necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, = "l2vpn@ietf.org" = >, = "Alexander.Vainshtein@ecitele.com" = > Cc: "yuqun.cao@gmail.com" = > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic = already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; = Alexander.Vainshtein@ecitele.com= Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the = R/L information, customer payload or PW? The customer payload will be = always modified to carry R/L information in 2-VLAN approach, while PW = with CW will carry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is = accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used = to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate = R/L information? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein = > > To: "Rogers, Josh" = >, Lucy yong > >, Daniel = Cohn >, Sam Cao > > > Cc: "l2vpn@ietf.org" = > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > = > > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very = popular, but: > > IMO one of the advantages of the CW-based solution is that it is = orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, = and, in a more generic way, localization of effects of changes in the PE = configuration. > > In particular, adding a Leaf AC to a PE that previously has been only = supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect = only the PE where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main = disadvantage of the CW-based approach - I believe it strongly depends on = specific implementations. And some changes in the forwarding process are = required in any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org = [l2vpn-bounces@ietf.org] on behalf of = Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a = more > complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become = more > complex. > > Gile's comparison slide still concisely captures the differences = between > these methods, in my opinion. I haven't seen any new ideas or = thoughts > brought to the group in the past week or two on the subject. I would = hate > for both proposed methods to die on the vine because we couldn't = decide > between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" = > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree = uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may = double >>all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn = [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the = processing >>in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP = PW >>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >>traffic coming from a root AC) >>[[LY]] Not that simple. You construct either two P2MP PWs to all other >>PEs and let egress PE performing filtering, or construct one P2MP PW = to >>leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >>perform forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so = don't >>feel terribly strong about this objection. Is this a real problem for >>others (now or in the future), or is this objection in the weeds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. = I >>encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" = > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao = [mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim = (Wim)'; >>>giles.heron@gmail.com; = simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; = Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; = Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; = Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs = after >>>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup = 2 >>>P2MP >>>PWs if need. There is no difference between P2MP or normal PW setup. = But, >>>can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with = both >>>root and leaf ACs set up two or one P2MP PW to other PEs (some PE = have >>>both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn = [mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; = Alexander.Vainshtein@ecitele.com= ; Sam Cao >>>Cc: l2vpn@ietf.org; = Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; = Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; = Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong = [mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; = simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; = Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; = Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; = Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, = both >>>approaches can benefit from it. I was off for a while and captures = some >>>discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues = with >>>silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I = am >>>not clear on all the issues. Could you be more specific? As I = mentioned >>>in below, two PW approach makes VPLS transport construction and = packet >>>forwarding more complex, I can see potential backward compatibility >>>issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree = uses >>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown = unicast >>>traffic, and some P2MP PWs for multicast traffic. It may double all = of >>>them. >>> >>>E-tree is an Ethernet service and there is already VLAN based = solution >>>in IEEE, can we just utilize it without complicating VPLS transport >>>construction? This also makes interworking with Eth only network = easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh = [mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); = 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; = 'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; = 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; = 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; = 'Rotem.Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are = you >>>saying that you no longer are interested in that method in preference = of >>>the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org] On Behalf >>>Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; = 'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; = 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; = 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; = 'Rotem.Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron = [mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord = >; Alexander = Vainshtein >>>> >>>Cc: l2vpn@ietf.org = >; Vladimir Kleiner >>>>; = Andrew Sergeev >>>>; Idan = Kaspit >; >>>Mishael Wexler = >; Rotem = Cohen >>>> >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly = have >>>put in a third column on the CW approach. And hopefully the minutes >>>will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to = be >>>forming around the two alternatives of two PWEs or two VLANs. I = believe >>>three of the authors of the CW approach are also authors of the two = VLAN >>>approach and one is also an author of the two PWE approach. So = perhaps >>>it's best to let those four individuals say which approach they = prefer >>>and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" = > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of = various >>>> solution drafts off the mailing list. As far as I know, no = consensus >>>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>>> think the CW approach has not been rejected by the WG yet, or the = WG >>>> has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein = > >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree = approaches >>>>> based on dedicated VLANs (as in >>>>> = http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> = http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in = the >>>>> PWs connecting the PEs (as in >>>>> = http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but = I >>>>> wonder whether the WG has taken a decision to reject the approach >>>>> based on the CW usage? I do not remember any recent discussion of >>>>> this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and = contains >>>>> information which is CONFIDENTIAL and which may be proprietary to = ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original = and >>>>> all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or = subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is = addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action = taken >>>in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject = to >>copyright belonging to Time Warner Cable. This E-mail is intended = solely >>for the use of the individual or entity to which it is addressed. If = you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies = thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** From david.i.allan@ericsson.com Wed Apr 25 12:55:37 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662BD21F896A for ; Wed, 25 Apr 2012 12:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 egUE7M-4I7Lp for ; Wed, 25 Apr 2012 12:55:35 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFEF21F8967 for ; Wed, 25 Apr 2012 12:55:35 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3PJtUXb010655; Wed, 25 Apr 2012 14:55:34 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.69]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 25 Apr 2012 15:55:28 -0400 From: David Allan I To: Daniel Cohn , "l2vpn@ietf.org" Date: Wed, 25 Apr 2012 15:55:29 -0400 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IABEiWPQAAFgqVoABMXRAAABv/gYAAAFTgA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD52324EEEE3@EUSAACMS0703.eamcs.ericsson.se> References: <172d01cd231c$5cce3952$05280101@corrigent.com> In-Reply-To: <172d01cd231c$5cce3952$05280101@corrigent.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: l2vpn@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, 25 Apr 2012 19:55:37 -0000 HI Daniel: In the example provided, "ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" A B the service is not ETREE in the domains of the ingress and egress VID. It i= s ELAN. SO there is no root/leaf attribute to shovel around. It would requi= re two VIDs in each domain if the ETREE semantics were to be telescoped E2E= . Otherwise it is a provisioning of the VID translation tables at the interme= diate nodes (A&B that I've added to the picture) that would determine the V= ID values used in each domain. Or in the example above, what the ingress, E= tree and egress VID values were. Cheers Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Wednesday, April 25, 2012 3:46 PM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? And to this I asked how this mapping works - how does the egress pe recover= the ingress vid when it gets the frame tagged with only the root/leaf vid?= How can you convey the ingress vid plus the root/leaf attribute in the sam= e number of bits? What am I missing? Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, David Allen already explained the solution. >From David: ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. Ingress VID does not have to equal Egress VID but regardless there is only = ever one VID on a frame at a time. -end This works when customer makes ingress VLAN ID not equal to or equal to egr= ess VLAN ID. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Wednesday, April 25, 2012 11:39 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi Lucy, The scenario we are discussing is not the E-Tree E-NNI, but a general scena= rio where frames arriving at the root or leaf AC are already double tagged= . In this case, the dual vlan solution cannot preserve the vlans without ad= ding a third one, can it? Maybe Shahram can add details on the scenario he had in mind Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has S-VLAN preservation attribute for ENNI only because there is no s-v= lan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN preser= vation attribute is used. It applies to E-Tree as well. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Tuesday, April 24, 2012 2:12 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, even if the current MEF framework doesn't require s-vlan preservation, I be= lieve it's to the industry's benefit to adopt a solution that is not constr= ained to a specific enni model that, like all things networking, is likely = to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service provider= s' inputs. It had a fair reason to assume S-VLAN over ENNI by then. It may = open B-VLAN for the future. It is better for us not to discuss a future fr= amework here, because it will lead us to nowhere. Here, we want to extend V= PLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Va= inshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume tha= t the VLAN tags at the E-NNI will always be according to the current MEF mo= del? Or should we try to be as transparent as possible to user VLAN encapsu= lation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case VLAN t= ag) to signal VPLS information (in this case root/leaf origin) is necessari= ly tied to specific assumptions on user payload encapsulation (in this case= , that S-VLAN tag is "available" to encode root/leaf). I don't think this i= s a future-proof assumption, it's very likely that other network models wil= l come up that require S-VLAN preservation, which in the 2-VLAN approach wo= uld necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, "l2vpn@i= etf.org" >, "A= lexander.Vainshtein@ecitele.com" <= Alexander.Vainshtein@ecitele.com> Cc: "yuqun.cao@gmail.com" > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic alrea= dy has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com= Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L i= nformation, customer payload or PW? The customer payload will be always mod= ified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is access= ed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informati= on? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > com>> > To: "Rogers, Josh" >, Lucy yong > >, Daniel Cohn <= DanielC@orckit.com>, Sam Cao > > > Cc: "l2vpn@ietf.org" > > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, = but: > > IMO one of the advantages of the CW-based solution is that it is orthogon= al to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffi= c. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and,= in a more generic way, localization of effects of changes in the PE config= uration. > > In particular, adding a Leaf AC to a PE that previously has been only sup= porting Root ACs (or vice versa), removal of the last Leaf or last Root AC = from a PE that previously has been supporting a mix etc. affect only the PE= where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadva= ntage of the CW-based approach - I believe it strongly depends on specific = implementations. And some changes in the forwarding process are required in= any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org > [l2vpn-bounces@ietf.org] on behalf of > Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a > more complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become > more complex. > > Gile's comparison slide still concisely captures the differences > between these methods, in my opinion. I haven't seen any new ideas or > thoughts brought to the group in the past week or two on the subject. > I would hate for both proposed methods to die on the vine because we > couldn't decide between two methods that have nothing inherently wrong wi= th either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree >>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may >>double all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn >>[mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the >>processing in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >>PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW >>(for traffic coming from a root AC) [[LY]] Not that simple. You >>construct either two P2MP PWs to all other PEs and let egress PE >>performing filtering, or construct one P2MP PW to leaf-only PEs and >>two P2MP PWs to root and leaf PEs and let ingress PE perform >>forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so >>don't feel terribly strong about this objection. Is this a real >>problem for others (now or in the future), or is this objection in the we= eds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. >>I encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao >>>[mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>(Wim)'; giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>PE have both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn >>>[mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com>; Sam Cao >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong >>>[mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>both approaches can benefit from it. I was off for a while and >>>captures some discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues >>>with silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >>>am not clear on all the issues. Could you be more specific? As I >>>mentioned in below, two PW approach makes VPLS transport construction >>>and packet forwarding more complex, I can see potential backward >>>compatibility issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>double all of them. >>> >>>E-tree is an Ethernet service and there is already VLAN based >>>solution in IEEE, can we just utilize it without complicating VPLS >>>transport construction? This also makes interworking with Eth only netwo= rk easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh >>>[mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); >>>'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vain= shtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are >>>you saying that you no longer are interested in that method in >>>preference of the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org >>>[mailto:l2vpn-bounces@ietf.org] On >>>Behalf Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron >>>[mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord >>>>; Alexander >>>Vainshtein >>>>>.com>> >>>Cc: l2vpn@ietf.org >>>>; Vladimir Kleiner >>>>; >>>Andrew Sergeev >>>>; Idan >>>Kaspit >; >>>Mishael Wexler >>>>; >>>Rotem Cohen > >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly >>>have put in a third column on the CW approach. And hopefully the >>>minutes will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to >>>be forming around the two alternatives of two PWEs or two VLANs. I >>>believe three of the authors of the CW approach are also authors of >>>the two VLAN approach and one is also an author of the two PWE >>>approach. So perhaps it's best to let those four individuals say >>>which approach they prefer and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of >>>> various solution drafts off the mailing list. As far as I know, no >>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>> meeting. I think the CW approach has not been rejected by the WG >>>> yet, or the WG has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein >>>> >>> le.com>> >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree >>>>> approaches based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/ >>>>> ?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in >>>>> the PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>> I wonder whether the WG has taken a decision to reject the >>>>> approach based on the CW usage? I do not remember any recent >>>>> discussion of this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and >>>>> contains information which is CONFIDENTIAL and which may be >>>>> proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original >>>>> and all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or >>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>intended solely for the use of the individual or entity to which it is a= ddressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail >>>is strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is >>addressed. If you are not the intended recipient of this E-mail, you >>are hereby notified that any dissemination, distribution, copying, or >>action taken in relation to the contents of and attachments to this >>E-mail is strictly prohibited and may be unlawful. If you have >>received this E-mail in error, please notify the sender immediately >>and permanently delete the original and any copy of this E-mail and any p= rintout. > > > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** From lucy.yong@huawei.com Wed Apr 25 12:58:30 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E954B21F88E5 for ; Wed, 25 Apr 2012 12:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HS_INDEX_PARAM=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 IAUSebGobzNT for ; Wed, 25 Apr 2012 12:58:29 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C8ED021F87D6 for ; Wed, 25 Apr 2012 12:58:28 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFN40883; Wed, 25 Apr 2012 15:58:28 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 12:56:16 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Wed, 25 Apr 2012 12:56:12 -0700 From: Lucy yong To: Daniel Cohn , "Rogers, Josh" , Shahram Davari , Lizhong Jin , "l2vpn@ietf.org" , "Alexander.Vainshtein@ecitele.com" Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IABEiWPQAAFgqVoABMXRAAABv/gYAAArZUA= Date: Wed, 25 Apr 2012 19:56:11 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264C130@dfweml505-mbx> References: <172d01cd231c$5cce3952$05280101@corrigent.com> In-Reply-To: <172d01cd231c$5cce3952$05280101@corrigent.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.119] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "yuqun.cao@gmail.com" X-BeenThere: l2vpn@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, 25 Apr 2012 19:58:31 -0000 TG9jYWwgbWFwcGluZyBpcyBzdWZmaWNpZW50IGZvciB0aGlzLiBJZiBhIGN1c3RvbWVyIHdpc2gg Ym90aCBpbmdyZXNzIFZMQU4gSUQgYW5kIGVncmVzcyBWTEFOIElEIGFyZSB0aGUgc2FtZSwgaXQg b2JleXMgdGhlIHJ1bGUgZmlyc3QsIHRoZW4gbG9jYWwgdHJhbnNsYXRlIGluIE1QTFMgd2lsbCB3 b3JrIHBlcmZlY3RseS4NCkx1Y3kNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IERhbmllbCBDb2huIFttYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tXSANClNlbnQ6IFdlZG5lc2Rh eSwgQXByaWwgMjUsIDIwMTIgMjo0NiBQTQ0KVG86IEx1Y3kgeW9uZzsgUm9nZXJzLCBKb3NoOyBT aGFocmFtIERhdmFyaTsgTGl6aG9uZyBKaW47IGwydnBuQGlldGYub3JnOyBBbGV4YW5kZXIuVmFp bnNodGVpbkBlY2l0ZWxlLmNvbQ0KQ2M6IHl1cXVuLmNhb0BnbWFpbC5jb20NClN1YmplY3Q6IFJF OiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQoN CkFuZCB0byB0aGlzIEkgYXNrZWQgaG93IHRoaXMgbWFwcGluZyB3b3JrcyAtIGhvdyBkb2VzIHRo ZSBlZ3Jlc3MgcGUgcmVjb3ZlciB0aGUgaW5ncmVzcyB2aWQgd2hlbiBpdCBnZXRzIHRoZSBmcmFt ZSB0YWdnZWQgd2l0aCBvbmx5IHRoZSByb290L2xlYWYgdmlkPyBIb3cgY2FuIHlvdSBjb252ZXkg dGhlIGluZ3Jlc3MgdmlkIHBsdXMgdGhlIHJvb3QvbGVhZiBhdHRyaWJ1dGUgaW4gdGhlIHNhbWUg bnVtYmVyIG9mIGJpdHM/DQpXaGF0IGFtIEkgbWlzc2luZz8NCg0KRGFuaWVsDQoNClRodW1iIHR5 cGVkIC0gcGxlYXNlIGJlIHRvbGVyYW50DQoNCkx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5j b20+IHdyb3RlOg0KDQpEYW5pZWwsDQoNCkRhdmlkIEFsbGVuIGFscmVhZHkgZXhwbGFpbmVkIHRo ZSBzb2x1dGlvbi4gDQoNCkZyb20gRGF2aWQ6DQppbmdyZXNzIFZMQU4gSUQgPC0+IEV0cmVlIFJv b3QvTGVhZiBWSUQgPC0+IEVncmVzcyBWSUQuDQoNCkluZ3Jlc3MgVklEIGRvZXMgbm90IGhhdmUg dG8gZXF1YWwgRWdyZXNzIFZJRCBidXQgcmVnYXJkbGVzcyB0aGVyZSBpcyBvbmx5IGV2ZXIgb25l IFZJRCBvbiBhIGZyYW1lIGF0IGEgdGltZS4NCg0KLWVuZA0KDQpUaGlzIHdvcmtzIHdoZW4gY3Vz dG9tZXIgbWFrZXMgaW5ncmVzcyBWTEFOIElEIG5vdCBlcXVhbCB0byBvciBlcXVhbCB0byBlZ3Jl c3MgVkxBTiBJRC4NCg0KUmVnYXJkcywNCkx1Y3kNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgRGFuaWVsIENvaG4NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwg MjUsIDIwMTIgMTE6MzkgQU0NClRvOiBMdWN5IHlvbmc7IFJvZ2VycywgSm9zaDsgU2hhaHJhbSBE YXZhcmk7IExpemhvbmcgSmluOyBsMnZwbkBpZXRmLm9yZzsgQWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb20NCkNjOiB5dXF1bi5jYW9AZ21haWwuY29tDQpTdWJqZWN0OiBSRTogVGhlIHN0 YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KDQpIaSBMdWN5 LA0KDQpUaGUgc2NlbmFyaW8gd2UgYXJlIGRpc2N1c3NpbmcgaXMgbm90IHRoZSBFLVRyZWUgRS1O TkksIGJ1dCBhIGdlbmVyYWwgc2NlbmFyaW8gd2hlcmUgZnJhbWVzIGFycml2aW5nIGF0IHRoZSBy b290IG9yIGxlYWYgQUMgIGFyZSBhbHJlYWR5IGRvdWJsZSB0YWdnZWQuIEluIHRoaXMgY2FzZSwg dGhlIGR1YWwgdmxhbiBzb2x1dGlvbiBjYW5ub3QgcHJlc2VydmUgdGhlIHZsYW5zIHdpdGhvdXQg YWRkaW5nIGEgdGhpcmQgb25lLCBjYW4gaXQ/DQoNCk1heWJlIFNoYWhyYW0gY2FuIGFkZCBkZXRh aWxzIG9uIHRoZSBzY2VuYXJpbyBoZSBoYWQgaW4gbWluZA0KDQpUaHVtYiB0eXBlZCAtIHBsZWFz ZSBiZSB0b2xlcmFudA0KDQpMdWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPiB3cm90ZToN Cg0KRGFuaWVsLA0KDQpNRUYgaGFzIFMtVkxBTiBwcmVzZXJ2YXRpb24gYXR0cmlidXRlIGZvciBF Tk5JIG9ubHkgYmVjYXVzZSB0aGVyZSBpcyBubyBzLXZsYW4gYXQgVU5JLiBXaGVuIGFuIE1FTiBj b25uZWN0cyB0byBtdWx0aXBsZSBFTk5JIGludGVyZmFjZXMsIFMtVkFMTiBwcmVzZXJ2YXRpb24g YXR0cmlidXRlIGlzIHVzZWQuIEl0IGFwcGxpZXMgdG8gRS1UcmVlIGFzIHdlbGwuDQoNClJlZ2Fy ZHMsDQpMdWN5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsMnZwbi1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IERhbmllbCBDb2huDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAyNCwgMjAxMiAyOjEyIEFNDQpUbzog THVjeSB5b25nOyBSb2dlcnMsIEpvc2g7IFNoYWhyYW0gRGF2YXJpOyBMaXpob25nIEppbjsgbDJ2 cG5AaWV0Zi5vcmc7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQpDYzogeXVxdW4u Y2FvQGdtYWlsLmNvbQ0KU3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMg dG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCg0KTHVjeSwNCg0KZXZlbiBpZiB0aGUgY3VycmVudCBN RUYgZnJhbWV3b3JrIGRvZXNuJ3QgcmVxdWlyZSBzLXZsYW4gcHJlc2VydmF0aW9uLCBJIGJlbGll dmUgaXQncyB0byB0aGUgaW5kdXN0cnkncyBiZW5lZml0IHRvIGFkb3B0IGEgc29sdXRpb24gdGhh dCBpcyBub3QgY29uc3RyYWluZWQgdG8gYSBzcGVjaWZpYyBlbm5pIG1vZGVsIHRoYXQsIGxpa2Ug YWxsIHRoaW5ncyBuZXR3b3JraW5nLCBpcyBsaWtlbHkgdG8gZXZvbHZlLiBFc3BlY2lhbGx5IHdo ZW4gc3VjaCBhIHNvbHV0aW9uIGlzIGF2YWlsYWJsZS4NCg0KRGFuaWVsDQoNClRodW1iIHR5cGVk IC0gcGxlYXNlIGJlIHRvbGVyYW50DQoNCkx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb20+ IHdyb3RlOg0KDQpEYW5pZWwsDQoNCk1FRiBoYXMgd29ya2VkIGluIEVOTkkgaW50ZXJmYWNlIGZv ciBhIGxvbmcgdGltZSB3aXRoIG1hbnkgc2VydmljZSBwcm92aWRlcnMnIGlucHV0cy4gSXQgaGFk IGEgZmFpciByZWFzb24gdG8gYXNzdW1lIFMtVkxBTiBvdmVyIEVOTkkgYnkgdGhlbi4gSXQgbWF5 IG9wZW4gQi1WTEFOIGZvciB0aGUgZnV0dXJlLiBJdCBpcyBiZXR0ZXIgZm9yIHVzIG5vdCB0byBk aXNjdXNzICBhIGZ1dHVyZSBmcmFtZXdvcmsgaGVyZSwgYmVjYXVzZSBpdCB3aWxsIGxlYWQgdXMg dG8gbm93aGVyZS4gSGVyZSwgd2Ugd2FudCB0byBleHRlbmQgVlBMUyBpbiBzdXBwb3J0aW5nIEUt VHJlZS4NCg0KQmVzdCBSZWdhcmRzLA0KTHVjeQ0KDQpGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhbmllbCBD b2huDQpTZW50OiBTdW5kYXksIEFwcmlsIDIyLCAyMDEyIDc6MzQgQU0NClRvOiBSb2dlcnMsIEpv c2g7IFNoYWhyYW0gRGF2YXJpOyBMaXpob25nIEppbjsgbDJ2cG5AaWV0Zi5vcmc7IEFsZXhhbmRl ci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQpDYzogeXVxdW4uY2FvQGdtYWlsLmNvbQ0KU3ViamVj dDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlv bj8NCg0KU2hhaHJhbSBhbmQgYWxsLA0KDQpUaGlzIHF1ZXN0aW9uIGFscmVhZHkgY2FtZSB1cCBp biBvdXIgZGlzY3Vzc2lvbnMgLSBpcyBpdCBzYWZlIHRvIGFzc3VtZSB0aGF0IHRoZSBWTEFOIHRh Z3MgYXQgdGhlIEUtTk5JIHdpbGwgYWx3YXlzIGJlIGFjY29yZGluZyB0byB0aGUgY3VycmVudCBN RUYgbW9kZWw/IE9yIHNob3VsZCB3ZSB0cnkgdG8gYmUgYXMgdHJhbnNwYXJlbnQgYXMgcG9zc2li bGUgdG8gdXNlciBWTEFOIGVuY2Fwc3VsYXRpb24gYXQgdGhlIEUtTk5JLCB0byBhY2NvbW1vZGF0 ZSBmdXR1cmUgZnJhbWV3b3Jrcz8NCkkgYmVsaWV2ZSB0aGF0IGFueSBhcHByb2FjaCB0aGF0IGxv b2tzIGF0IHVzZXIgcGF5bG9hZCAoaW4gdGhpcyBjYXNlIFZMQU4gdGFnKSB0byBzaWduYWwgVlBM UyBpbmZvcm1hdGlvbiAoaW4gdGhpcyBjYXNlIHJvb3QvbGVhZiBvcmlnaW4pIGlzIG5lY2Vzc2Fy aWx5IHRpZWQgdG8gc3BlY2lmaWMgYXNzdW1wdGlvbnMgb24gdXNlciBwYXlsb2FkIGVuY2Fwc3Vs YXRpb24gKGluIHRoaXMgY2FzZSwgdGhhdCBTLVZMQU4gdGFnIGlzICJhdmFpbGFibGUiIHRvIGVu Y29kZSByb290L2xlYWYpLiBJIGRvbid0IHRoaW5rIHRoaXMgaXMgYSBmdXR1cmUtcHJvb2YgYXNz dW1wdGlvbiwgaXQncyB2ZXJ5IGxpa2VseSB0aGF0IG90aGVyIG5ldHdvcmsgbW9kZWxzIHdpbGwg Y29tZSB1cCB0aGF0IHJlcXVpcmUgUy1WTEFOIHByZXNlcnZhdGlvbiwgd2hpY2ggaW4gdGhlIDIt VkxBTiBhcHByb2FjaCB3b3VsZCBuZWNlc3NpdGF0ZSBhZGRpbmcgYSB0aGlyZCBWTEFOLUlELg0K DQpEYW5pZWwNCg0KRnJvbTogU2hhaHJhbSBEYXZhcmkgPGRhdmFyaUBicm9hZGNvbS5jb208bWFp bHRvOmRhdmFyaUBicm9hZGNvbS5jb20+Pg0KVG86IExpemhvbmcgSmluIDxsaXpoby5qaW5AZ21h aWwuY29tPG1haWx0bzpsaXpoby5qaW5AZ21haWwuY29tPj4sICJsMnZwbkBpZXRmLm9yZzxtYWls dG86bDJ2cG5AaWV0Zi5vcmc+IiA8bDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3Jn Pj4sICJBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZh aW5zaHRlaW5AZWNpdGVsZS5jb20+IiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208 bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPj4NCkNjOiAieXVxdW4uY2Fv QGdtYWlsLmNvbTxtYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbT4iIDx5dXF1bi5jYW9AZ21haWwu Y29tPG1haWx0bzp5dXF1bi5jYW9AZ21haWwuY29tPj4NClN1YmplY3Q6IFJFOiBUaGUgc3RhdHVz IG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQoNCkhpLA0KDQpJIGFs c28gaGF2ZSBhIHF1ZXN0aW9uIHJlZ2FyZGluZyAyLVZMQU4uIFdoYXQgaWYgdGhlIGN1c3RvbWVy IHRyYWZmaWMgYWxyZWFkeSBoYXMgYW4gUy1WTEFOPyBEbyB3ZSBuZWVkIGEgM3JkIFZMQU4gdG8g aWRlbnRpZnkgdGhlIEwvUj8NCg0KVGh4DQpTaGFocmFtDQoNCkZyb206IGwydnBuLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bDJ2cG4tYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExpemhvbmcgSmluDQpTZW50OiBGcmlkYXksIEFw cmlsIDIwLCAyMDEyIDk6MzggQU0NClRvOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0 Zi5vcmc+OyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVy LlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQpDYzogeXVxdW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86 eXVxdW4uY2FvQGdtYWlsLmNvbT4NClN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHBy b2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQoNCkhpLCBhbGwsDQpUaGUgZGlmZmVyZW5j ZSBiZXR3ZWVuIDItVkxBTiBhbmQgQ1cgYXBwcm9hY2ggaXMgd2hvIHdpbGwgcHJvdmlkZSB0aGUg Ui9MIGluZm9ybWF0aW9uLCBjdXN0b21lciBwYXlsb2FkIG9yIFBXPyBUaGUgY3VzdG9tZXIgcGF5 bG9hZCB3aWxsIGJlIGFsd2F5cyBtb2RpZmllZCB0byBjYXJyeSBSL0wgaW5mb3JtYXRpb24gaW4g Mi1WTEFOIGFwcHJvYWNoLCB3aGlsZSBQVyB3aXRoIENXIHdpbGwgY2FycnkgUi9MIGluZm9ybWF0 aW9uIGZvciBDVyBhcHByb2FjaC4NCkkgaGF2ZSBhIHF1ZXN0aW9uIHdpdGggdGhlIDItVkxBTiBh cHByb2FjaCBpbiBILVZQTFMgd2hlcmUgSC1WUExTIGlzIGFjY2Vzc2VkIGJ5IFZQV1MgYXMgZGVz Y3JpYmVkIGluIFJGQzQ2NzIgc2VjdGlvbiAxMC4xLjMuIElmIFZQV1MgaXMgdXNlZCB0byBhY2Nl c3MgSC1WUExTLCBob3cgY291bGQgdGhlIFBFIG9uIFZQV1Mgc2lkZSBhZGRzIFZMQU4gdG8gaW5k aWNhdGUgUi9MIGluZm9ybWF0aW9uPw0KDQpUaGFua3MNCkxpemhvbmcNCg0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4gTWVzc2FnZTogMg0KPiBEYXRlOiBUaHUsIDE5IEFw ciAyMDEyIDA0OjM4OjM2ICswMDAwDQo+IEZyb206IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb20+Pg0KPiBUbzogIlJvZ2VycywgSm9zaCIgPGpvc2gucm9nZXJzQHR3Y2FibGUu Y29tPG1haWx0bzpqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbT4+LCBMdWN5IHlvbmcNCj4gICAgICAg IDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiwgRGFu aWVsIENvaG4gPERhbmllbENAb3Jja2l0LmNvbTxtYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tPj4s IFNhbSBDYW8NCj4gICAgICAgIDx5dXF1bi5jYW9AZ21haWwuY29tPG1haWx0bzp5dXF1bi5jYW9A Z21haWwuY29tPj4NCj4gQ2M6ICJsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+ IiA8bDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPj4NCj4gU3ViamVjdDogUkU6 IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4g TWVzc2FnZS1JRDoNCj4gICAgICAgIDxGOTMzNjU3MTczMUFERTQyQTUzOTdGQzgzMUNFQUEwMjAz NDE5MkBGUklEV1BQTUIwMDIuZWNpdGVsZS5jb208bWFpbHRvOkY5MzM2NTcxNzMxQURFNDJBNTM5 N0ZDODMxQ0VBQTAyMDM0MTkyQEZSSURXUFBNQjAwMi5lY2l0ZWxlLmNvbT4+DQo+IENvbnRlbnQt VHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXMtYXNjaWkiDQo+DQo+IEhpIGFsbCwNCj4gSSBm dWxseSB1bmRlcnN0YW5kIHRoYXQgdGhhdCB3aGF0IEkgYW0gZ29pbmcgdG8gc2F5IGlzIG5vdCB2 ZXJ5IHBvcHVsYXIsIGJ1dDoNCj4NCj4gSU1PIG9uZSBvZiB0aGUgYWR2YW50YWdlcyBvZiB0aGUg Q1ctYmFzZWQgc29sdXRpb24gaXMgdGhhdCBpdCBpcyBvcnRob2dvbmFsIHRvIHVzYWdlIChvciBu b24tdXNhZ2UpIG9mIFAyTVAgUFdzIGZvciBlZmZlY3RpdmUgZGVsaXZlcnkgb2YgQlVOIHRyYWZm aWMuDQo+DQo+IEFub3RoZXIgYWR2YW50YWdlIGlzIHByZXNlcnZhdGlvbiBvZiBmdWxsIG1lc2gg b2YgUDJQIFBXcyBpbiBhIFZQTFMsIGFuZCwgaW4gYSBtb3JlIGdlbmVyaWMgd2F5LCBsb2NhbGl6 YXRpb24gb2YgZWZmZWN0cyBvZiBjaGFuZ2VzIGluIHRoZSBQRSBjb25maWd1cmF0aW9uLg0KPg0K PiBJbiBwYXJ0aWN1bGFyLCBhZGRpbmcgYSBMZWFmIEFDIHRvIGEgUEUgdGhhdCBwcmV2aW91c2x5 IGhhcyBiZWVuIG9ubHkgc3VwcG9ydGluZyBSb290IEFDcyAob3IgdmljZSB2ZXJzYSksIHJlbW92 YWwgb2YgdGhlIGxhc3QgTGVhZiBvciBsYXN0IFJvb3QgQUMgZnJvbSBhIFBFIHRoYXQgcHJldmlv dXNseSBoYXMgYmVlbiBzdXBwb3J0aW5nIGEgbWl4IGV0Yy4gYWZmZWN0IG9ubHkgdGhlIFBFIHdo ZXJlIHRoaXMgb3BlcmF0aW9uIGhhcHBlbnMgYW5kIG5vdCB0aGUgcmVzdCBvZiB0aGUgUEVzLg0K Pg0KPiBBcyBmb3IgdGhlIG5lZWQgZm9yIEhXIGNoYW5nZXMgdGhhdCBoYXZlIGJlZW4gbWVudGlv bmVkIGFzIGEgbWFpbiBkaXNhZHZhbnRhZ2Ugb2YgdGhlIENXLWJhc2VkIGFwcHJvYWNoIC0gSSBi ZWxpZXZlIGl0IHN0cm9uZ2x5IGRlcGVuZHMgb24gc3BlY2lmaWMgaW1wbGVtZW50YXRpb25zLiBB bmQgc29tZSBjaGFuZ2VzIGluIHRoZSBmb3J3YXJkaW5nIHByb2Nlc3MgYXJlIHJlcXVpcmVkIGlu IGFueSBzb2x1dGlvbi4NCj4NCj4gTXkgMmMsDQo+ICAgICBTYXNoYQ0KPg0KPg0KPg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZyb206IGwydnBuLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc+IFtsMnZwbi1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnPl0gb24gYmVoYWxmIG9mIFJv Z2VycywgSm9zaCBbam9zaC5yb2dlcnNAdHdjYWJsZS5jb208bWFpbHRvOmpvc2gucm9nZXJzQHR3 Y2FibGUuY29tPl0NCj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxOCwgMjAxMiA5OjU3IFBNDQo+ IFRvOiBMdWN5IHlvbmc7IERhbmllbCBDb2huOyBTYW0gQ2FvDQo+IENjOiBsMnZwbkBpZXRmLm9y ZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBUaGUgc3RhdHVzIG9mIHRo ZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+DQo+IEFnYWluLCB0aGUgUDJN UCBzaXR1YXRpb24gdGhyb3dzIG1lLiAgSXMgdGhpcyBzb21ldGhpbmcgdGhhdCBpcyB1c2VkDQo+ IGNvbW1vbmx5Pw0KPg0KPiBJJ20gdW5kZXIgdGhlIGltcHJlc3Npb24gdGhhdCBhZGRpbmcgUDJN UCB0byBhbnkgbW9kZWwgcmVzdWx0cyBpbiBhIG1vcmUNCj4gY29tcGxleCBtb2RlbC4gIFdldGhl ciBvdXRzaWRlIHMtdGFnIGlzIHVzZWQgdG8gZGlmZmVyZW50aWF0ZSwgb3INCj4gZGVkaWNhdGVk IHB3J3MgYXJlIHVzZWQgZm9yIHRoZSBzYW1lIHB1cnBvc2UsIGl0IHNlZW1zIGJvdGggYmVjb21l IG1vcmUNCj4gY29tcGxleC4NCj4NCj4gR2lsZSdzIGNvbXBhcmlzb24gc2xpZGUgc3RpbGwgY29u Y2lzZWx5IGNhcHR1cmVzIHRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVuDQo+IHRoZXNlIG1ldGhvZHMs IGluIG15IG9waW5pb24uICBJIGhhdmVuJ3Qgc2VlbiBhbnkgbmV3IGlkZWFzIG9yIHRob3VnaHRz DQo+IGJyb3VnaHQgdG8gdGhlIGdyb3VwIGluIHRoZSBwYXN0IHdlZWsgb3IgdHdvIG9uIHRoZSBz dWJqZWN0LiAgSSB3b3VsZCBoYXRlDQo+IGZvciBib3RoIHByb3Bvc2VkIG1ldGhvZHMgdG8gZGll IG9uIHRoZSB2aW5lIGJlY2F1c2Ugd2UgY291bGRuJ3QgZGVjaWRlDQo+IGJldHdlZW4gdHdvIG1l dGhvZHMgdGhhdCBoYXZlIG5vdGhpbmcgaW5oZXJlbnRseSB3cm9uZyB3aXRoIGVpdGhlci4NCj4N Cj4gLUpvc2gNCj4NCj4NCj4gT24gNC8xOC8xMiAxOjUzIFBNLCAiTHVjeSB5b25nIiA8bHVjeS55 b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+DQo+ PlNlbmQgdGhpcyBhZ2Fpbi4NCj4+DQo+PlR3byBQVyBhcHByb2FjaCBjYW4gYmUgY29tcGxleCB0 b28gaWYgdGhlIFZQTFMgaW5zdGFuY2UgZm9yIEUtVHJlZSB1c2VzDQo+PlAyUCBQVyBmb3IgdW5p Y2FzdCB0cmFmZmljIGFuZCBQMk1QIFBXIGZvciBicm9hZGNhc3QgYW5kIHVua25vd24NCj4+dW5p Y2FzdCB0cmFmZmljLCBhbmQgc29tZSBQMk1QIFBXcyBmb3IgbXVsdGljYXN0IHRyYWZmaWMuIEl0 IG1heSBkb3VibGUNCj4+YWxsIG9mIHRoZW0uDQo+Pg0KPj5MdWN5DQo+Pg0KPj4tLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiBEYW5pZWwgQ29obiBbbWFpbHRvOkRhbmllbENAb3Jj a2l0LmNvbTxtYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tPl0NCj4+U2VudDogV2VkbmVzZGF5LCBB cHJpbCAxOCwgMjAxMiAxOjQyIFBNDQo+PlRvOiBMdWN5IHlvbmc7IFJvZ2VycywgSm9zaDsgU2Ft IENhbw0KPj5DYzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPg0KPj5TdWJq ZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0 aW9uPw0KPj4NCj4+SSB0aGluayB0aGUgZmlyc3Qgb3B0aW9uIGl0cyB0aGUgbmF0dXJhbCB3YXkg dG8gZ28uIEhvdyBpcyB0aGUgcHJvY2Vzc2luZw0KPj5pbiB0aGlzIGNhc2UgbW9yZSBjb21wbGV4 Pw0KPj4NCj4+VGh1bWIgdHlwZWQgLSBwbGVhc2UgYmUgdG9sZXJhbnQNCj4+DQo+Pkx1Y3kgeW9u ZyA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3Jv dGU6DQo+Pg0KPj4NCj4+DQo+PlNuaXBwZWQuLg0KPj4NCj4+TXVsdGktUFcgLSBPbiBpbmdyZXNz IFBFLCBmcmFtZSBpcyBwbGFjZWQgb250byBlaXRoZXIgYSBMZWFmLW9ubHkgUDJNUCBQVw0KPj4o Zm9yIHRyYWZmaWMgY29taW5nIGZyb20gYSBsZWFmIEFDKSwgb3Igb250byBhIFJvb3QvTGVhZiBQ Mk1QIFBXIChmb3INCj4+dHJhZmZpYyBjb21pbmcgZnJvbSBhIHJvb3QgQUMpDQo+PltbTFldXSBO b3QgdGhhdCBzaW1wbGUuIFlvdSBjb25zdHJ1Y3QgZWl0aGVyIHR3byBQMk1QIFBXcyB0byBhbGwg b3RoZXINCj4+UEVzIGFuZCBsZXQgZWdyZXNzIFBFIHBlcmZvcm1pbmcgZmlsdGVyaW5nLCBvciBj b25zdHJ1Y3Qgb25lIFAyTVAgUFcgdG8NCj4+bGVhZi1vbmx5IFBFcyBhbmQgdHdvIFAyTVAgUFdz IHRvIHJvb3QgYW5kIGxlYWYgUEVzIGFuZCBsZXQgaW5ncmVzcyBQRQ0KPj5wZXJmb3JtIGZvcndh cmRpbmcgYW5kIGZpbHRlcmluZy4gQm90aCBtYWtlIG5vZGUgcHJvY2VzcyBjb21wbGV4Lg0KPj4N Cj4+W1tMWV1dIFZQTFMgaXMgYnVpbHQgd2l0aCB0aGUgbWVjaGFuaXNtIHV0aWxpemluZyBQMlAg YW5kIFAyTVAgUFcgZm9yDQo+PmRlbGl2ZXJpbmcgdGhlIGZyYW1lcyB0byByZW1vdGUgUEVzLiBX ZSBzaG91bGQgdXRpbGl6ZSB0aGVtIHdpdGggdGhlDQo+Pm1pbmltaXplZCBjaGFuZ2VzLiBEdWFs IFZMQU4gc29sdXRpb24gaXMgc2ltcGxlciB0aGFuIER1YWwgUFcuDQo+Pg0KPj5SZWdhcmRzLA0K Pj5MdWN5DQo+Pg0KPj4NCj4+SSBzZWUgaG93IDJWTEFOIGlzIHNpbXBsZXIgd2hlbiBQMk1QIFBX J3MgYXJlIGludm9sdmVkLCBJIHRoaW5rLiAgSQ0KPj5oYXZlbid0IGhhZCBhbnkgZmlyc3QgaGFu ZCBleHBlcmllbmNlIHdpdGggUDJNUCBQVydzLCBob3dldmVyLCBzbyBkb24ndA0KPj5mZWVsIHRl cnJpYmx5IHN0cm9uZyBhYm91dCB0aGlzIG9iamVjdGlvbi4gIElzIHRoaXMgYSByZWFsIHByb2Js ZW0gZm9yDQo+Pm90aGVycyAobm93IG9yIGluIHRoZSBmdXR1cmUpLCBvciBpcyB0aGlzIG9iamVj dGlvbiBpbiB0aGUgd2VlZHM/DQo+Pg0KPj5JJ20gbm90IHN1cmUgdGhlICdhZGRpdGlvbmFsIGNv bXBsZXhpdHknIGlzIG5vdGFibGUsIG9yIGV2ZW4gcmVsZXZhbnQuICBJDQo+PmVuY291cmFnZSBv dGhlcnMgdG8gc3BlYWsgdXAgaWYgdGhleSBkaXNhZ3JlZSwgYXMgUDJNUCBQVyBpcyBvbmx5DQo+ PmNvbmNlcHR1YWwgdG8gbWUsIGFuZCBJIGFtIHVuZmFtaWxpYXIgd2l0aCByZWFsLWxpZmUgdXNl IGNhc2VzIGZvciBpdC4NCj4+DQo+PlRoYW5rcywNCj4+Sm9zaA0KPj4NCj4+DQo+Pg0KPj5PbiA0 LzE4LzEyIDEwOjMwIEFNLCAiTHVjeSB5b25nIiA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRv Omx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+Pg0KPj4+UGxlYXNlIHNlZSBpbmxpbmUu DQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBTYW0gQ2FvIFtt YWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbT5dDQo+ Pj5TZW50OiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiA3OjE0IEFNDQo+Pj5UbzogJ0RhbmllbCBD b2huJzsgTHVjeSB5b25nOyAnUm9nZXJzLCBKb3NoJzsgJ0hlbmRlcmlja3gsIFdpbSAoV2ltKSc7 DQo+Pj5naWxlcy5oZXJvbkBnbWFpbC5jb208bWFpbHRvOmdpbGVzLmhlcm9uQGdtYWlsLmNvbT47 IHNpbW9uLmRlbG9yZEBnbWFpbC5jb208bWFpbHRvOnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+Ow0K Pj4+QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWlu c2h0ZWluQGVjaXRlbGUuY29tPg0KPj4+Q2M6IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBp ZXRmLm9yZz47IFZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLkts ZWluZXJAZWNpdGVsZS5jb20+Ow0KPj4+QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb208bWFpbHRv OkFuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPjsgSWRhbi5LYXNwaXRAZWNpdGVsZS5jb208bWFp bHRvOklkYW4uS2FzcGl0QGVjaXRlbGUuY29tPjsNCj4+Pk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUu Y29tPG1haWx0bzpNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT47IFJvdGVtLkNvaGVuQGVjaXRl bGUuY29tPG1haWx0bzpSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbT4NCj4+PlN1YmplY3Q6IFJFOiBU aGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4N Cj4+PlllcywgMiBwd3MgYXJlIG9ubHkgbmVlZGVkIGJldHdlZW4gcGVzIHdpdGggYm90aCByb290 IGFuZCBsZWFmIGFjcyBhZnRlcg0KPj4+aW1wcm92aW5nIER1YWwtUFcgYXBwcm9hY2guIElmIGNv bnNpZGVyIFAyTVAsIER1YWwtUFcgYXBwcm9hY2ggc2V0dXAgMg0KPj4+UDJNUA0KPj4+UFdzIGlm IG5lZWQuIFRoZXJlIGlzIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBQMk1QIG9yIG5vcm1hbCBQVyBz ZXR1cC4gQnV0LA0KPj4+Y2FuIExlYWYtQUNzIGJlIGJvdW5kIHRvIFJvb3QgUEUgb2YgUDJNUCBQ Vz8NCj4+Pg0KPj4+W1tMWV1dIE5vLCBpdCBtYWtlcyBjb21wbGV4IGluIHNldHRpbmcgdXAgUDJN UCBQVy4gU2hvdWxkIGEgUEUgd2l0aCBib3RoDQo+Pj5yb290IGFuZCBsZWFmIEFDcyBzZXQgdXAg dHdvIG9yIG9uZSBQMk1QIFBXIHRvIG90aGVyIFBFcyAoc29tZSBQRSBoYXZlDQo+Pj5ib3RoIHJv b3QgYW5kIGxlYWYgQUMgYW5kIHNvbWUgb25seSBoYXZlIGxlYWYgQUNzKT8NCj4+PlJlZ2FyZHMs DQo+Pj5MdWN5DQo+Pj4NCj4+PlJlZ2FyZHMsDQo+Pj4NCj4+Pll1cXVuIChTYW0pIENhbw0KPj4+ RS1tYWlsOiBZdXF1bi5jYW9AZ21haWwuY29tPG1haWx0bzpZdXF1bi5jYW9AZ21haWwuY29tPg0K Pj4+DQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBEYW5pZWwg Q29obiBbbWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbTxtYWlsdG86RGFuaWVsQ0BvcmNraXQuY29t Pl0NCj4+PlNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE3LCAyMDEyIDQ6NTYgUE0NCj4+PlRvOiBMdWN5 IHlvbmc7IFJvZ2VycywgSm9zaDsgSGVuZGVyaWNreCwgV2ltIChXaW0pOw0KPj4+Z2lsZXMuaGVy b25AZ21haWwuY29tPG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+Ow0KPj4+c2ltb24uZGVs b3JkQGdtYWlsLmNvbTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT47IEFsZXhhbmRlci5W YWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbT47IFNhbSBDYW8NCj4+PkNjOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5v cmc+OyBWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPG1haWx0bzpWbGFkaW1pci5LbGVpbmVy QGVjaXRlbGUuY29tPjsNCj4+PkFuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPG1haWx0bzpBbmRy ZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbT47IElkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0bzpJ ZGFuLkthc3BpdEBlY2l0ZWxlLmNvbT47DQo+Pj5NaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbTxt YWlsdG86TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb20+OyBSb3RlbS5Db2hlbkBlY2l0ZWxlLmNv bTxtYWlsdG86Um90ZW0uQ29oZW5AZWNpdGVsZS5jb20+DQo+Pj5TdWJqZWN0OiBSRTogVGhlIHN0 YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+DQo+Pj5B ZGRpbmcgU2FtIChhcyBsMnZwbkAgaXMgaG9sZGluZyBtZXNzYWdlcykNCj4+Pg0KPj4+REMNCj4+ Pg0KPj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IEx1Y3kgeW9uZyBbbWFp bHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT5dDQo+ Pj5TZW50OiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiAxMjozOSBBTQ0KPj4+VG86IERhbmllbCBD b2huOyBSb2dlcnMsIEpvc2g7IEhlbmRlcmlja3gsIFdpbSAoV2ltKTsNCj4+PmdpbGVzLmhlcm9u QGdtYWlsLmNvbTxtYWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tPjsgc2ltb24uZGVsb3JkQGdt YWlsLmNvbTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT47DQo+Pj5BbGV4YW5kZXIuVmFp bnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b20+DQo+Pj5DYzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPjsgVmxhZGlt aXIuS2xlaW5lckBlY2l0ZWxlLmNvbTxtYWlsdG86VmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNv bT47DQo+Pj5BbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3LlNlcmdlZXZA ZWNpdGVsZS5jb20+OyBJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbTxtYWlsdG86SWRhbi5LYXNwaXRA ZWNpdGVsZS5jb20+Ow0KPj4+TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb208bWFpbHRvOk1pc2hh ZWwuV2V4bGVyQGVjaXRlbGUuY29tPjsgUm90ZW0uQ29oZW5AZWNpdGVsZS5jb208bWFpbHRvOlJv dGVtLkNvaGVuQGVjaXRlbGUuY29tPg0KPj4+U3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhl IGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4+Pg0KPj4+DQo+Pj5TbmlwcGVk LA0KPj4+DQo+Pj5BcyB3ZSBkaXNjdXNzZWQgZXh0ZW5zaXZlbHkgaW4gdGhlIGxpc3QsIGFuZCBh cyByZWZsZWN0ZWQgaW4gZ2lsZXMNCj4+PnNsaWRlLCAyIHB3cyBhcmUgb25seSBuZWVkZWQgYmV0 d2VlbiBwZXMgd2l0aCBib3RoIHJvb3QgYW5kIGxlYWYgYWNzLA0KPj4+d2hpY2ggd2lsbCB0eXBp Y2FsbHkgYmUgYSBzbWFsbCBtaW5vcml0eS4NCj4+PltbTFldXSBEb24ndCBrbm93IGlmIHRoZSBh c3N1bXB0aW9uIGlzIHRydWUuIEV2ZW4gaXQgaXMgdGhlIGNhc2UsIGJvdGgNCj4+PmFwcHJvYWNo ZXMgY2FuIGJlbmVmaXQgZnJvbSBpdC4gSSB3YXMgb2ZmIGZvciBhIHdoaWxlIGFuZCBjYXB0dXJl cyBzb21lDQo+Pj5kaXNjdXNzaW9ucyBub3cuDQo+Pj4NCj4+PkFsc28gYXMgcGVyIGdpbGVzIHNs aWRlLCBkdWFsIHZsYW4gY2FuIGhhdmUgc2NhbGFiaWxpdHkgaXNzdWVzIGR1ZSB0bw0KPj4+YWRk aXRpb25hbCBsb29rdXAgYW5kIGRvdWJsZSB1c2Ugb2YgdmxhbnMgaW4gaW50ZXJuYWwgZW11bGF0 ZWQgbGFuDQo+Pj5pbnRlcmZhY2UuIEFsc28gdGhlcmUgYXJlIHBvdGVudGlhbCBiYWNrd2FyZCBj b21wYXRpYmlsaXR5IGlzc3VlcyB3aXRoDQo+Pj5zaWxpY29uIHRoYXQgZG9lc24ndCBzdXBwb3J0 IHZsYW4gbWFwcGluZy4NCj4+PltbTFldXSBJIHdhcyBub3QgaW4gSUVURjgzIG1lZXRpbmcgYW5k IHdhaXQgb24gdGhlIG1lZXRpbmcgbWludXRlcy4gSSBhbQ0KPj4+bm90IGNsZWFyIG9uIGFsbCB0 aGUgaXNzdWVzLiBDb3VsZCB5b3UgYmUgbW9yZSBzcGVjaWZpYz8gQXMgSSBtZW50aW9uZWQNCj4+ PmluIGJlbG93LCB0d28gUFcgYXBwcm9hY2ggbWFrZXMgVlBMUyB0cmFuc3BvcnQgY29uc3RydWN0 aW9uIGFuZCBwYWNrZXQNCj4+PmZvcndhcmRpbmcgbW9yZSBjb21wbGV4LCBJIGNhbiBzZWUgcG90 ZW50aWFsIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkNCj4+Pmlzc3VlcyB3aXRoIDIgUFcgc29sdXRp b24uDQo+Pj4NCj4+PlJlZ2FyZHMsDQo+Pj5MdWN5DQo+Pj4NCj4+PlJlZ2FyZHMsDQo+Pj4NCj4+ PkRhbmllbA0KPj4+DQo+Pj5UaHVtYiB0eXBlZCAtIHBsZWFzZSBiZSB0b2xlcmFudA0KPj4+DQo+ Pj5MdWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2Vp LmNvbT4+IHdyb3RlOg0KPj4+DQo+Pj5JbiBteSBtaW5kLCB0aGUgVkxBTiBhcHByb2FjaCBtZWFu cyBkdWFsIHZsYW4gbWV0aG9kLg0KPj4+DQo+Pj5UaGUgbWFpbiBjb25jZXJuIGZvciBDVyBhcHBy b2FjaCBpcyBoYXJkd2FyZSBzdXBwb3J0Lg0KPj4+DQo+Pj5Ud28gUFcgYXBwcm9hY2ggY2FuIGJl IGNvbXBsZXggdG9vIGlmIHRoZSBWUExTIGluc3RhbmNlIGZvciBFLVRyZWUgdXNlcw0KPj4+UDJQ IFBXIGZvciB1bmljYXN0IHRyYWZmaWMgYW5kIFAyTVAgUFcgZm9yIGJyb2FkY2FzdCBhbmQgdW5r bm93biB1bmljYXN0DQo+Pj50cmFmZmljLCBhbmQgc29tZSBQMk1QIFBXcyBmb3IgbXVsdGljYXN0 IHRyYWZmaWMuIEl0IG1heSBkb3VibGUgYWxsIG9mDQo+Pj50aGVtLg0KPj4+DQo+Pj5FLXRyZWUg aXMgYW4gRXRoZXJuZXQgc2VydmljZSBhbmQgdGhlcmUgaXMgYWxyZWFkeSBWTEFOIGJhc2VkIHNv bHV0aW9uDQo+Pj5pbiBJRUVFLCBjYW4gd2UganVzdCB1dGlsaXplIGl0IHdpdGhvdXQgY29tcGxp Y2F0aW5nIFZQTFMgdHJhbnNwb3J0DQo+Pj5jb25zdHJ1Y3Rpb24/IFRoaXMgYWxzbyBtYWtlcyBp bnRlcndvcmtpbmcgd2l0aCBFdGggb25seSBuZXR3b3JrIGVhc2llci4NCj4+Pg0KPj4+Q2hlZXJz LA0KPj4+THVjeQ0KPj4+DQo+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+RnJvbTog Um9nZXJzLCBKb3NoIFttYWlsdG86am9zaC5yb2dlcnNAdHdjYWJsZS5jb208bWFpbHRvOmpvc2gu cm9nZXJzQHR3Y2FibGUuY29tPl0NCj4+PlNlbnQ6IE1vbmRheSwgQXByaWwgMTYsIDIwMTIgODoz NSBBTQ0KPj4+VG86IEx1Y3kgeW9uZzsgSGVuZGVyaWNreCwgV2ltIChXaW0pOyAnZ2lsZXMuaGVy b25AZ21haWwuY29tPG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+JzsNCj4+PidzaW1vbi5k ZWxvcmRAZ21haWwuY29tPG1haWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPic7ICdBbGV4YW5k ZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNp dGVsZS5jb20+Jw0KPj4+Q2M6ICdsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+ JzsgJ1ZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJA ZWNpdGVsZS5jb20+JzsNCj4+PidBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5k cmV3LlNlcmdlZXZAZWNpdGVsZS5jb20+JzsgJ0lkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0 bzpJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbT4nOw0KPj4+J01pc2hhZWwuV2V4bGVyQGVjaXRlbGUu Y29tPG1haWx0bzpNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT4nOyAnUm90ZW0uQ29oZW5AZWNp dGVsZS5jb208bWFpbHRvOlJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPicNCj4+PlN1YmplY3Q6IFJF OiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+ Pj4NCj4+PkkgYmVsaWV2ZSB0aGUgaW5pdGlhbCBxdWVzdGlvbiB3YXMgaW4gcmVnYXJkIHRvIHRo ZSBDVyBtZXRob2QuICBBcmUgeW91DQo+Pj5zYXlpbmcgdGhhdCB5b3Ugbm8gbG9uZ2VyIGFyZSBp bnRlcmVzdGVkIGluIHRoYXQgbWV0aG9kIGluIHByZWZlcmVuY2Ugb2YNCj4+PnRoZSBkdWFsIHZs YW4gbWV0aG9kPw0KPj4+DQo+Pj4NCj4+Pg0KPj4+THVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2Vp LmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiB3cm90ZToNCj4+Pg0KPj4+DQo+Pj5B Z3JlZSB3aXRoIFdpbS4gVkxBTiBhcHByb2FjaCBpcyB0aGUgYmVzdCBzb2x1dGlvbiBmb3IgRS1U cmVlLg0KPj4+DQo+Pj5MdWN5DQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ Pj5Gcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYu b3JnPiBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJvdW5jZXNA aWV0Zi5vcmc+XSBPbiBCZWhhbGYNCj4+Pk9mIEhlbmRlcmlja3gsIFdpbSAoV2ltKQ0KPj4+U2Vu dDogVGh1cnNkYXksIEFwcmlsIDEyLCAyMDEyIDI6MDMgQU0NCj4+PlRvOiAnZ2lsZXMuaGVyb25A Z21haWwuY29tPG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+JzsgJ3NpbW9uLmRlbG9yZEBn bWFpbC5jb208bWFpbHRvOnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+JzsNCj4+PidBbGV4YW5kZXIu VmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVs ZS5jb20+Jw0KPj4+Q2M6ICdsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+Jzsg J1ZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJAZWNp dGVsZS5jb20+JzsNCj4+PidBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3 LlNlcmdlZXZAZWNpdGVsZS5jb20+JzsgJ0lkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0bzpJ ZGFuLkthc3BpdEBlY2l0ZWxlLmNvbT4nOw0KPj4+J01pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29t PG1haWx0bzpNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT4nOyAnUm90ZW0uQ29oZW5AZWNpdGVs ZS5jb208bWFpbHRvOlJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPicNCj4+PlN1YmplY3Q6IFJlOiBU aGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4N Cj4+PlRoZSB2bGFuIGFwcHJvYWNoIGlzIHN1cGVyaW9yIGFzIGl0IGFsc28gd29ya3MgZm9yIGV0 aCBvbmx5IG5ldHdvcmtzLA0KPj4+ZXRjLiBPbiB0b3Agc29tZSB2ZW5kb3JzIGluZGljYXRlIGh3 IGlzc3VlcyB3aXRoIHRoZSBjdyBhcHByb2FjaC4gQXMNCj4+PnN1Y2ggd2UgaGF2ZSBkcm9wcGVk IG1vcmUgb3IgbGVzcyB0aGUgY3cgYXBwcm9hY2guDQo+Pj4NCj4+PkNoZWVycywNCj4+PldpbQ0K Pj4+X19fX19fX19fX19fX19fX18NCj4+PnNlbnQgZnJvbSBibGFja2JlcnJ5DQo+Pj4NCj4+Pi0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4+PkZyb206IEdpbGVzIEhlcm9uIFttYWlsdG86 Z2lsZXMuaGVyb25AZ21haWwuY29tPG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+XQ0KPj4+ U2VudDogVGh1cnNkYXksIEFwcmlsIDEyLCAyMDEyIDA4OjIyIEFNDQo+Pj5UbzogU2ltb24gRGVs b3JkIDxzaW1vbi5kZWxvcmRAZ21haWwuY29tPG1haWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29t Pj47IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+Pj48QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVs ZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPj4NCj4+PkNjOiBs MnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+IDxsMnZwbkBpZXRmLm9yZzxtYWls dG86bDJ2cG5AaWV0Zi5vcmc+PjsgVmxhZGltaXIgS2xlaW5lcg0KPj4+PFZsYWRpbWlyLktsZWlu ZXJAZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb20+PjsgQW5k cmV3IFNlcmdlZXYNCj4+PjxBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3 LlNlcmdlZXZAZWNpdGVsZS5jb20+PjsgSWRhbiBLYXNwaXQgPElkYW4uS2FzcGl0QGVjaXRlbGUu Y29tPG1haWx0bzpJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbT4+Ow0KPj4+TWlzaGFlbCBXZXhsZXIg PE1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPG1haWx0bzpNaXNoYWVsLldleGxlckBlY2l0ZWxl LmNvbT4+OyBSb3RlbSBDb2hlbg0KPj4+PFJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPG1haWx0bzpS b3RlbS5Db2hlbkBlY2l0ZWxlLmNvbT4+DQo+Pj5TdWJqZWN0OiBSZTogVGhlIHN0YXR1cyBvZiB0 aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+DQo+Pj5Tb3JyeSAtIHRo ZSAiYW5vbnltb3VzIHByZXNlbnRhdGlvbiIgd2FzIG1pbmUuICBJIHNob3VsZCBwb3NzaWJseSBo YXZlDQo+Pj5wdXQgaW4gYSB0aGlyZCBjb2x1bW4gb24gdGhlIENXIGFwcHJvYWNoLiAgQW5kIGhv cGVmdWxseSB0aGUgbWludXRlcw0KPj4+d2lsbCBiZSBwb3N0ZWQgc29vbi4NCj4+Pg0KPj4+V2Ug aGFkIHZhcmlvdXMgZGlzY3Vzc2lvbnMsIGFzIFNpbW9uIHN0YXRlZCwgYW5kIGNvbnNlbnN1cyBz ZWVtZWQgdG8gYmUNCj4+PmZvcm1pbmcgYXJvdW5kIHRoZSB0d28gYWx0ZXJuYXRpdmVzIG9mIHR3 byBQV0VzIG9yIHR3byBWTEFOcy4gIEkgYmVsaWV2ZQ0KPj4+dGhyZWUgb2YgdGhlIGF1dGhvcnMg b2YgdGhlIENXIGFwcHJvYWNoIGFyZSBhbHNvIGF1dGhvcnMgb2YgdGhlIHR3byBWTEFODQo+Pj5h cHByb2FjaCBhbmQgb25lIGlzIGFsc28gYW4gYXV0aG9yIG9mIHRoZSB0d28gUFdFIGFwcHJvYWNo LiBTbyBwZXJoYXBzDQo+Pj5pdCdzIGJlc3QgdG8gbGV0IHRob3NlIGZvdXIgaW5kaXZpZHVhbHMg c2F5IHdoaWNoIGFwcHJvYWNoIHRoZXkgcHJlZmVyDQo+Pj5hbmQgd2h5Pw0KPj4+DQo+Pj5HaWxl cw0KPj4+DQo+Pj5PbiAxMC8wNC8yMDEyIDAwOjQ1LCAiU2ltb24gRGVsb3JkIiA8c2ltb24uZGVs b3JkQGdtYWlsLmNvbTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4+ DQo+Pj4+IEhpIEFsZXhhbmRlciwNCj4+Pj4NCj4+Pj4gWW91IGFyZSByaWdodCwgbm8gZGlzY3Vz c2lvbiBvbiB0aGUgV0cgbWFpbGluZyBsaXN0IHJlY2VudGx5LCBidXQNCj4+Pj4gdGhlcmUgaGF2 ZSBiZWVuIHN1YnN0YW50aWFsIGRpc2N1c3Npb25zIGFtb25nIHRoZSBhdXRob3JzIG9mIHZhcmlv dXMNCj4+Pj4gc29sdXRpb24gZHJhZnRzIG9mZiB0aGUgbWFpbGluZyBsaXN0LiBBcyBmYXIgYXMg SSBrbm93LCBubyBjb25zZW5zdXMNCj4+Pj4geWV0IGJlZm9yZSBpZXRmODMsIG5vdCBzdXJlIHRo ZSBwcm9ncmVzcyBpbiB0aGUgUGFyaXMgV0cgbWVldGluZy4gSQ0KPj4+PiB0aGluayB0aGUgQ1cg YXBwcm9hY2ggaGFzIG5vdCBiZWVuIHJlamVjdGVkIGJ5IHRoZSBXRyB5ZXQsIG9yIHRoZSBXRw0K Pj4+PiBoYXMgbm90IHlldCBkZWNpZGVkIG9uIHdoaWNoIG9uZSB0byBhZG9wdC4NCj4+Pj4NCj4+ Pj4gU2ltb24NCj4+Pj4NCj4+Pj4gMjAxMi80LzggQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbT4+DQo+Pj4+DQo+Pj4+PiAgSGkgYWxsLA0KPj4+Pj4NCj4+Pj4+IFVuZm9ydHVu YXRlbHkgSSBoYXZlIG5vdCBiZWVuIGFibGUgdG8gYXR0ZW5kIHRoZSBQYXJpcyBJRVRGLg0KPj4+ Pj4NCj4+Pj4+IEhvd2V2ZXIsIGxvb2tpbmcgdXAgdGhlIEwyVlBOIHByb2NlZWRpbmdzLCBJJ3Zl IGZvdW5kIGEgc2hvcnQNCj4+Pj4+IGFub255bW91cyBwcmVzZW50YXRpb24gY2FsbGVkICJFLVRy ZWUgVXBkYXRlIiAgKA0KPj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84My9z bGlkZXMvc2xpZGVzLTgzLWwydnBuLTEucHB0eCkuDQo+Pj4+PiBUaGlzIHByZXNlbnRhdGlvbiBk aXNjdXNzZXMgdGhlIGRpZmZlcmVuY2VzIG9mIHRoZSBFLVRyZWUgYXBwcm9hY2hlcw0KPj4+Pj4g YmFzZWQgb24gZGVkaWNhdGVkIFZMQU5zIChhcyBpbg0KPj4+Pj4gaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1jYW8tbDJ2cG4tdnBscy1ldHJlZS8/aW5jbHVkZV90DQo+Pj4+ PiBleHQ9MSkgYW5kIG11bHRpcGxlIFBXcyBiZXR3ZWVuIHRoZSBQRXMgKGFzIGluDQo+Pj4+PiBo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJhbS1sMnZwbi1ldHJlZS1tdWx0 aXBsZS1wdy8/aW4NCj4+Pj4+IGNsdWRlX3RlDQo+Pj4+PiB4dD0xKQ0KPj4+Pj4gYW5kIGNvbXBs ZXRlbHkgaWdub3JlcyB0aGUgc29sdXRpb24gYmFzZWQgb24gdXNhZ2Ugb2YgdGhlIENXIGluIHRo ZQ0KPj4+Pj4gUFdzIGNvbm5lY3RpbmcgdGhlIFBFcyAoYXMgaW4NCj4+Pj4+IGh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta2V5LWwydnBuLXZwbHMtZXRyZWUvP2luY2x1ZGVf dA0KPj4+Pj4gZXh0PTENCj4+Pj4+ICkuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBUaGUg TWludXRlcyBvZiB0aGUgUGFyaXMgTDJWUE4gc2Vzc2lvbiBhcmUgbm90IHlldCBhdmFpbGFibGUs IGJ1dCBJDQo+Pj4+PiB3b25kZXIgd2hldGhlciB0aGUgV0cgaGFzIHRha2VuIGEgZGVjaXNpb24g dG8gcmVqZWN0IHRoZSBhcHByb2FjaA0KPj4+Pj4gYmFzZWQgb24gdGhlIENXIHVzYWdlPyBJIGRv IG5vdCByZW1lbWJlciBhbnkgcmVjZW50IGRpc2N1c3Npb24gb2YNCj4+Pj4+IHRoaXMgdG9waWMg b24gdGhlIFdHIG1haWxpbmcgbGlzdC4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFJlZ2Fy ZHMsIGFuZCBsb3RzIG9mIHRoYW5rcyBpbiBhZHZhbmNlLA0KPj4+Pj4NCj4+Pj4+IFNhc2hhDQo+ Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFRoaXMgZS1tYWlsIG1lc3Nh Z2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMNCj4+Pj4+ IGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3By aWV0YXJ5IHRvIEVDSQ0KPj4+DQo+Pj4+PiBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlDQo+Pj4+PiBpbmZvcm0gdXMgYnkgZS1t YWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kDQo+Pj4+ PiBhbGwgY29waWVzIHRoZXJlb2YuDQo+Pj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+ PlRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUg V2FybmVyIENhYmxlDQo+Pj5wcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmls ZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0DQo+Pj50byBjb3B5cmlnaHQgYmVsb25naW5n IHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZA0KPj4+c29sZWx5 IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBh ZGRyZXNzZWQuDQo+Pj5JZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRo aXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieQ0KPj4+bm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5h dGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4NCj4+PmluIHJlbGF0 aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMN Cj4+PnN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcw0KPj4+RS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5DQo+Pj5kZWxldGUgdGhlIG9yaWdpbmFsIGFu ZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0KPj4+DQo+Pg0KPj4N Cj4+VGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGlt ZSBXYXJuZXIgQ2FibGUNCj4+cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZp bGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0bw0KPj5jb3B5cmlnaHQgYmVsb25naW5n IHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkNCj4+ Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFk ZHJlc3NlZC4gSWYgeW91DQo+PmFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlz IEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQNCj4+dGhhdCBhbnkgZGlzc2VtaW5hdGlv biwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4NCj4+cmVsYXRpb24g dG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJp Y3RseQ0KPj5wcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgRS1tYWlsIGluDQo+PmVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUNCj4+b3JpZ2luYWwgYW5kIGFueSBj b3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo+DQo+DQo+IFRoaXMgRS1tYWls IGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxl IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRp YWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJs ZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRp dmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5v dGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3Ig YWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVu dHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3 ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9y aWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0KPiBU aGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5k IGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5 IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25l IG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYWxsIGNvcGllcyB0aGVy ZW9mLg0KPg0KPg0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTDJ2cG4gbWFp bGluZyBsaXN0DQo+IEwydnBuQGlldGYub3JnPG1haWx0bzpMMnZwbkBpZXRmLm9yZz4NCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sMnZwbg0KPg0KPg0KPiBFbmQgb2Yg TDJ2cG4gRGlnZXN0LCBWb2wgOTUsIElzc3VlIDI1DQo+ICoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqDQo= From DanielC@orckit.com Wed Apr 25 13:31:36 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB2011E8083 for ; Wed, 25 Apr 2012 13:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.589 X-Spam-Level: * X-Spam-Status: No, score=1.589 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_ILLEGAL_IP=1.908, RCVD_NUMERIC_HELO=2.067] 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 98Q5ZPI8hwSV for ; Wed, 25 Apr 2012 13:31:35 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 703E111E8072 for ; Wed, 25 Apr 2012 13:31:34 -0700 (PDT) Received: from 1.1.40.5 ([1.1.40.5]) by tlvmail1.corrigent.com ([1.1.40.5]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Apr 2012 20:33:38 +0000 Date: Wed, 25 Apr 2012 23:31:28 +0300 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <172e01cd2322$b1efdc43$05280101@corrigent.com> Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IABEiWPQAAFgqVoABMXRAAABv/gYAAArZUAAAWnjjA== X-MimeOLE: Produced By Microsoft Exchange V6.5 Importance: normal From: "Daniel Cohn" To: "Lucy yong" , "Rogers, Josh" , "Shahram Davari" , "Lizhong Jin" , , MIME-Version: 1.0 Cc: yuqun.cao@gmail.com X-BeenThere: l2vpn@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, 25 Apr 2012 20:31:37 -0000 Lucy, don't understand what you mean by "obey the rule first".=0A= Say you get a frame with double tag at a leaf ac. According to the 2 = vlan draft, you must add the leaf vlan before forwarding the frame to = the mpls, otherwise the egress pe won't know it can only forward the = frame over root acs. If you remove the outer tag on ingress, how can you = recover it on egress? If you don't remove it, you get a 3-deep stack.=0A= =0A= Daniel=0A= =0A= Thumb typed - please be tolerant=0A= =0A= Lucy yong wrote:=0A= =0A= Local mapping is sufficient for this. If a customer wish both ingress = VLAN ID and egress VLAN ID are the same, it obeys the rule first, then = local translate in MPLS will work perfectly. Lucy -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Wednesday, April 25, 2012 2:46 PM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; = l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? And to this I asked how this mapping works - how does the egress pe = recover the ingress vid when it gets the frame tagged with only the = root/leaf vid? How can you convey the ingress vid plus the root/leaf = attribute in the same number of bits? What am I missing? Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, David Allen already explained the solution.=20 >From David: ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. Ingress VID does not have to equal Egress VID but regardless there is = only ever one VID on a frame at a time. -end This works when customer makes ingress VLAN ID not equal to or equal to = egress VLAN ID. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Daniel Cohn Sent: Wednesday, April 25, 2012 11:39 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; = l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi Lucy, The scenario we are discussing is not the E-Tree E-NNI, but a general = scenario where frames arriving at the root or leaf AC are already = double tagged. In this case, the dual vlan solution cannot preserve the = vlans without adding a third one, can it? Maybe Shahram can add details on the scenario he had in mind Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has S-VLAN preservation attribute for ENNI only because there is no = s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN = preservation attribute is used. It applies to E-Tree as well. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Daniel Cohn Sent: Tuesday, April 24, 2012 2:12 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; = l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, even if the current MEF framework doesn't require s-vlan preservation, I = believe it's to the industry's benefit to adopt a solution that is not = constrained to a specific enni model that, like all things networking, = is likely to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service = providers' inputs. It had a fair reason to assume S-VLAN over ENNI by = then. It may open B-VLAN for the future. It is better for us not to = discuss a future framework here, because it will lead us to nowhere. = Here, we want to extend VPLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Daniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; = Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume = that the VLAN tags at the E-NNI will always be according to the current = MEF model? Or should we try to be as transparent as possible to user = VLAN encapsulation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case = VLAN tag) to signal VPLS information (in this case root/leaf origin) is = necessarily tied to specific assumptions on user payload encapsulation = (in this case, that S-VLAN tag is "available" to encode root/leaf). I = don't think this is a future-proof assumption, it's very likely that = other network models will come up that require S-VLAN preservation, = which in the 2-VLAN approach would necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, = "l2vpn@ietf.org" = >, = "Alexander.Vainshtein@ecitele.com" = > Cc: "yuqun.cao@gmail.com" = > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic = already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; = Alexander.Vainshtein@ecitele.com= Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the = R/L information, customer payload or PW? The customer payload will be = always modified to carry R/L information in 2-VLAN approach, while PW = with CW will carry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is = accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used = to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate = R/L information? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein = > > To: "Rogers, Josh" = >, Lucy yong > >, Daniel = Cohn >, Sam Cao > > > Cc: "l2vpn@ietf.org" = > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > = > > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very = popular, but: > > IMO one of the advantages of the CW-based solution is that it is = orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, = and, in a more generic way, localization of effects of changes in the PE = configuration. > > In particular, adding a Leaf AC to a PE that previously has been only = supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect = only the PE where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main = disadvantage of the CW-based approach - I believe it strongly depends on = specific implementations. And some changes in the forwarding process are = required in any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org = [l2vpn-bounces@ietf.org] on behalf of = Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a = more > complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become = more > complex. > > Gile's comparison slide still concisely captures the differences = between > these methods, in my opinion. I haven't seen any new ideas or = thoughts > brought to the group in the past week or two on the subject. I would = hate > for both proposed methods to die on the vine because we couldn't = decide > between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" = > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree = uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may = double >>all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn = [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the = processing >>in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP = PW >>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >>traffic coming from a root AC) >>[[LY]] Not that simple. You construct either two P2MP PWs to all other >>PEs and let egress PE performing filtering, or construct one P2MP PW = to >>leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >>perform forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so = don't >>feel terribly strong about this objection. Is this a real problem for >>others (now or in the future), or is this objection in the weeds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. = I >>encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" = > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao = [mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim = (Wim)'; >>>giles.heron@gmail.com; = simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; = Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; = Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; = Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs = after >>>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup = 2 >>>P2MP >>>PWs if need. There is no difference between P2MP or normal PW setup. = But, >>>can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with = both >>>root and leaf ACs set up two or one P2MP PW to other PEs (some PE = have >>>both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn = [mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; = Alexander.Vainshtein@ecitele.com= ; Sam Cao >>>Cc: l2vpn@ietf.org; = Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; = Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; = Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong = [mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; = simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; = Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; = Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; = Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, = both >>>approaches can benefit from it. I was off for a while and captures = some >>>discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues = with >>>silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I = am >>>not clear on all the issues. Could you be more specific? As I = mentioned >>>in below, two PW approach makes VPLS transport construction and = packet >>>forwarding more complex, I can see potential backward compatibility >>>issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree = uses >>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown = unicast >>>traffic, and some P2MP PWs for multicast traffic. It may double all = of >>>them. >>> >>>E-tree is an Ethernet service and there is already VLAN based = solution >>>in IEEE, can we just utilize it without complicating VPLS transport >>>construction? This also makes interworking with Eth only network = easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh = [mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); = 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; = 'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; = 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; = 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; = 'Rotem.Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are = you >>>saying that you no longer are interested in that method in preference = of >>>the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org] On Behalf >>>Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; = 'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; = 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; = 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; = 'Rotem.Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron = [mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord = >; Alexander = Vainshtein >>>> >>>Cc: l2vpn@ietf.org = >; Vladimir Kleiner >>>>; = Andrew Sergeev >>>>; Idan = Kaspit >; >>>Mishael Wexler = >; Rotem = Cohen >>>> >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly = have >>>put in a third column on the CW approach. And hopefully the minutes >>>will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to = be >>>forming around the two alternatives of two PWEs or two VLANs. I = believe >>>three of the authors of the CW approach are also authors of the two = VLAN >>>approach and one is also an author of the two PWE approach. So = perhaps >>>it's best to let those four individuals say which approach they = prefer >>>and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" = > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of = various >>>> solution drafts off the mailing list. As far as I know, no = consensus >>>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>>> think the CW approach has not been rejected by the WG yet, or the = WG >>>> has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein = > >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree = approaches >>>>> based on dedicated VLANs (as in >>>>> = http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> = http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in = the >>>>> PWs connecting the PEs (as in >>>>> = http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but = I >>>>> wonder whether the WG has taken a decision to reject the approach >>>>> based on the CW usage? I do not remember any recent discussion of >>>>> this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and = contains >>>>> information which is CONFIDENTIAL and which may be proprietary to = ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original = and >>>>> all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or = subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is = addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action = taken >>>in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject = to >>copyright belonging to Time Warner Cable. This E-mail is intended = solely >>for the use of the individual or entity to which it is addressed. If = you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies = thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** From DanielC@orckit.com Wed Apr 25 13:39:05 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F3E21F87C9 for ; Wed, 25 Apr 2012 13:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.566 X-Spam-Level: * X-Spam-Status: No, score=1.566 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_ILLEGAL_IP=1.908, RCVD_NUMERIC_HELO=2.067] 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 bTRVXKeRRR68 for ; Wed, 25 Apr 2012 13:39:03 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id E706821F8777 for ; Wed, 25 Apr 2012 13:39:02 -0700 (PDT) Received: from 1.1.40.5 ([1.1.40.5]) by tlvmail1.corrigent.com ([1.1.40.5]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Apr 2012 20:41:07 +0000 Date: Wed, 25 Apr 2012 23:38:56 +0300 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IABEiWPQAAFgqVoABMXRAAABv/gYAAAFTgAAAdLw+g== X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <172f01cd2323$bdca1c82$05280101@corrigent.com> Importance: normal From: "Daniel Cohn" To: "David Allan I" , MIME-Version: 1.0 X-BeenThere: l2vpn@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, 25 Apr 2012 20:39:05 -0000 Dave, but the ACs are root/leaf (that's what the whole vpls etree is = about - see the reqt draft), so per the 2vlan draft the root/leaf vlan = must be added.=0A= =0A= Thumb typed - please be tolerant=0A= =0A= David Allan I wrote:=0A= =0A= HI Daniel: In the example provided, "ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" A B the service is not ETREE in the domains of the ingress and egress VID. = It is ELAN. SO there is no root/leaf attribute to shovel around. It = would require two VIDs in each domain if the ETREE semantics were to be = telescoped E2E. Otherwise it is a provisioning of the VID translation tables at the = intermediate nodes (A&B that I've added to the picture) that would = determine the VID values used in each domain. Or in the example above, = what the ingress, Etree and egress VID values were. Cheers Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Daniel Cohn Sent: Wednesday, April 25, 2012 3:46 PM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; = l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? And to this I asked how this mapping works - how does the egress pe = recover the ingress vid when it gets the frame tagged with only the = root/leaf vid? How can you convey the ingress vid plus the root/leaf = attribute in the same number of bits? What am I missing? Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, David Allen already explained the solution. >From David: ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. Ingress VID does not have to equal Egress VID but regardless there is = only ever one VID on a frame at a time. -end This works when customer makes ingress VLAN ID not equal to or equal to = egress VLAN ID. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Daniel Cohn Sent: Wednesday, April 25, 2012 11:39 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; = l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi Lucy, The scenario we are discussing is not the E-Tree E-NNI, but a general = scenario where frames arriving at the root or leaf AC are already = double tagged. In this case, the dual vlan solution cannot preserve the = vlans without adding a third one, can it? Maybe Shahram can add details on the scenario he had in mind Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has S-VLAN preservation attribute for ENNI only because there is no = s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN = preservation attribute is used. It applies to E-Tree as well. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Daniel Cohn Sent: Tuesday, April 24, 2012 2:12 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; = l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, even if the current MEF framework doesn't require s-vlan preservation, I = believe it's to the industry's benefit to adopt a solution that is not = constrained to a specific enni model that, like all things networking, = is likely to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service = providers' inputs. It had a fair reason to assume S-VLAN over ENNI by = then. It may open B-VLAN for the future. It is better for us not to = discuss a future framework here, because it will lead us to nowhere. = Here, we want to extend VPLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Daniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; = Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume = that the VLAN tags at the E-NNI will always be according to the current = MEF model? Or should we try to be as transparent as possible to user = VLAN encapsulation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case = VLAN tag) to signal VPLS information (in this case root/leaf origin) is = necessarily tied to specific assumptions on user payload encapsulation = (in this case, that S-VLAN tag is "available" to encode root/leaf). I = don't think this is a future-proof assumption, it's very likely that = other network models will come up that require S-VLAN preservation, = which in the 2-VLAN approach would necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, = "l2vpn@ietf.org" = >, = "Alexander.Vainshtein@ecitele.com" = > Cc: "yuqun.cao@gmail.com" = > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic = already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; = Alexander.Vainshtein@ecitele.com= Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the = R/L information, customer payload or PW? The customer payload will be = always modified to carry R/L information in 2-VLAN approach, while PW = with CW will carry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is = accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used = to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate = R/L information? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > com>> > To: "Rogers, Josh" = >, Lucy yong > >, Daniel = Cohn >, Sam Cao > > > Cc: "l2vpn@ietf.org" > > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very = popular, but: > > IMO one of the advantages of the CW-based solution is that it is = orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of = BUN traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, = and, in a more generic way, localization of effects of changes in the PE = configuration. > > In particular, adding a Leaf AC to a PE that previously has been only = supporting Root ACs (or vice versa), removal of the last Leaf or last = Root AC from a PE that previously has been supporting a mix etc. affect = only the PE where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main = disadvantage of the CW-based approach - I believe it strongly depends on = specific implementations. And some changes in the forwarding process are = required in any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org > [l2vpn-bounces@ietf.org] on behalf of > Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a > more complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become > more complex. > > Gile's comparison slide still concisely captures the differences > between these methods, in my opinion. I haven't seen any new ideas or > thoughts brought to the group in the past week or two on the subject. > I would hate for both proposed methods to die on the vine because we > couldn't decide between two methods that have nothing inherently wrong = with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" = > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree >>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may >>double all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn >>[mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the >>processing in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >>PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW >>(for traffic coming from a root AC) [[LY]] Not that simple. You >>construct either two P2MP PWs to all other PEs and let egress PE >>performing filtering, or construct one P2MP PW to leaf-only PEs and >>two P2MP PWs to root and leaf PEs and let ingress PE perform >>forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so >>don't feel terribly strong about this objection. Is this a real >>problem for others (now or in the future), or is this objection in the = weeds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. >>I encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" = > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao >>>[mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>(Wim)'; giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>PE have both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn >>>[mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com>; Sam Cao >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong >>>[mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>both approaches can benefit from it. I was off for a while and >>>captures some discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues >>>with silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >>>am not clear on all the issues. Could you be more specific? As I >>>mentioned in below, two PW approach makes VPLS transport construction >>>and packet forwarding more complex, I can see potential backward >>>compatibility issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>double all of them. >>> >>>E-tree is an Ethernet service and there is already VLAN based >>>solution in IEEE, can we just utilize it without complicating VPLS >>>transport construction? This also makes interworking with Eth only = network easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh >>>[mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); >>>'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; = 'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; = 'Rotem.Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are >>>you saying that you no longer are interested in that method in >>>preference of the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org >>>[mailto:l2vpn-bounces@ietf.org] On >>>Behalf Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; = 'Rotem.Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron >>>[mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord >>>>; Alexander >>>Vainshtein >>>>>.com>> >>>Cc: l2vpn@ietf.org >>>>; Vladimir Kleiner >>>>; >>>Andrew Sergeev >>>>; Idan >>>Kaspit >; >>>Mishael Wexler >>>>; >>>Rotem Cohen > >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly >>>have put in a third column on the CW approach. And hopefully the >>>minutes will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to >>>be forming around the two alternatives of two PWEs or two VLANs. I >>>believe three of the authors of the CW approach are also authors of >>>the two VLAN approach and one is also an author of the two PWE >>>approach. So perhaps it's best to let those four individuals say >>>which approach they prefer and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" = > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of >>>> various solution drafts off the mailing list. As far as I know, no >>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>> meeting. I think the CW approach has not been rejected by the WG >>>> yet, or the WG has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein >>>> >>> le.com>> >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree >>>>> approaches based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/ >>>>> ?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in >>>>> the PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>> I wonder whether the WG has taken a decision to reject the >>>>> approach based on the CW usage? I do not remember any recent >>>>> discussion of this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and >>>>> contains information which is CONFIDENTIAL and which may be >>>>> proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original >>>>> and all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or >>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>intended solely for the use of the individual or entity to which it = is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail >>>is strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is >>addressed. If you are not the intended recipient of this E-mail, you >>are hereby notified that any dissemination, distribution, copying, or >>action taken in relation to the contents of and attachments to this >>E-mail is strictly prohibited and may be unlawful. If you have >>received this E-mail in error, please notify the sender immediately >>and permanently delete the original and any copy of this E-mail and = any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies = thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** From lucy.yong@huawei.com Wed Apr 25 14:02:17 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8981D21E8011 for ; Wed, 25 Apr 2012 14:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HS_INDEX_PARAM=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 Ia4XQeOG8jOJ for ; Wed, 25 Apr 2012 14:02:15 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5B34411E8072 for ; Wed, 25 Apr 2012 14:02:15 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFN45016; Wed, 25 Apr 2012 17:02:15 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 13:59:55 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Wed, 25 Apr 2012 13:59:59 -0700 From: Lucy yong To: Daniel Cohn , "Rogers, Josh" , Shahram Davari , Lizhong Jin , "l2vpn@ietf.org" , "Alexander.Vainshtein@ecitele.com" Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IABEiWPQAAFgqVoABMXRAAABv/gYAAArZUAAAWnjjAAAAsVA Date: Wed, 25 Apr 2012 20:59:59 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264C1A2@dfweml505-mbx> References: <172e01cd2322$b1efdc43$05280101@corrigent.com> In-Reply-To: <172e01cd2322$b1efdc43$05280101@corrigent.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.119] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "yuqun.cao@gmail.com" X-BeenThere: l2vpn@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, 25 Apr 2012 21:02:17 -0000 VGhlIGN1cnJlbnQgVkxBTiBkcmFmdCBkb2VzIG5vdCBhc3N1bWUgZG91YmxlIHRhZyBmcmFtZSBh dCBBQy4gSWYgd2UgaGF2ZSB0byBjb25zaWRlciB0aGlzIGNhc2UsIHRoZSBzb2x1dGlvbiB3YXMg ZGlzY3Vzc2VkIGluIHRoZSBlLW1haWwuIEkgc2hvdWxkIHVzZSBsb2NhbCB0cmFuc2xhdGlvbiBp bnN0ZWFkIG9mIG1hcHBpbmcgaW4gcHJldmlvdXMgZS1tYWlsLCB3aGljaCBtYWtlcyBpdCBtb3Jl IGNsZWFyLiBJbiB0aGlzIGNhc2UsIFBFIGtub3dzIHdoaWNoIFMtVkxBTiBJRCBpcyB1c2VkIG9u IGFuIEFDLCBzbyBQRSBpbnNlcnRzIHRoZSBzYW1lIFMtVkxBTiBJRCBvbiB0aGUgZnJhbWVzIGdv aW5nIHRvd2FyZCB0byB0aGUgQUMuIFRoaXMgaXMgdGhlIHBhcnQgeW91IG1pc3NlZC4NCg0KTHVj eQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGFuaWVsIENvaG4gW21haWx0 bzpEYW5pZWxDQG9yY2tpdC5jb21dIA0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAyNSwgMjAxMiAz OjMxIFBNDQpUbzogTHVjeSB5b25nOyBSb2dlcnMsIEpvc2g7IFNoYWhyYW0gRGF2YXJpOyBMaXpo b25nIEppbjsgbDJ2cG5AaWV0Zi5vcmc7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29t DQpDYzogeXVxdW4uY2FvQGdtYWlsLmNvbQ0KU3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhl IGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCg0KTHVjeSwgZG9uJ3QgdW5kZXJz dGFuZCB3aGF0IHlvdSBtZWFuIGJ5ICJvYmV5IHRoZSBydWxlIGZpcnN0Ii4NClNheSB5b3UgZ2V0 IGEgZnJhbWUgd2l0aCBkb3VibGUgdGFnIGF0IGEgbGVhZiBhYy4gQWNjb3JkaW5nIHRvIHRoZSAy IHZsYW4gZHJhZnQsIHlvdSBtdXN0IGFkZCB0aGUgbGVhZiB2bGFuIGJlZm9yZSBmb3J3YXJkaW5n IHRoZSBmcmFtZSB0byB0aGUgbXBscywgb3RoZXJ3aXNlIHRoZSBlZ3Jlc3MgcGUgd29uJ3Qga25v dyBpdCBjYW4gb25seSBmb3J3YXJkIHRoZSBmcmFtZSBvdmVyIHJvb3QgYWNzLiBJZiB5b3UgcmVt b3ZlIHRoZSBvdXRlciB0YWcgb24gaW5ncmVzcywgaG93IGNhbiB5b3UgcmVjb3ZlciBpdCBvbiBl Z3Jlc3M/IElmIHlvdSBkb24ndCByZW1vdmUgaXQsIHlvdSBnZXQgYSAzLWRlZXAgc3RhY2suDQoN CkRhbmllbA0KDQpUaHVtYiB0eXBlZCAtIHBsZWFzZSBiZSB0b2xlcmFudA0KDQpMdWN5IHlvbmcg PGx1Y3kueW9uZ0BodWF3ZWkuY29tPiB3cm90ZToNCg0KTG9jYWwgbWFwcGluZyBpcyBzdWZmaWNp ZW50IGZvciB0aGlzLiBJZiBhIGN1c3RvbWVyIHdpc2ggYm90aCBpbmdyZXNzIFZMQU4gSUQgYW5k IGVncmVzcyBWTEFOIElEIGFyZSB0aGUgc2FtZSwgaXQgb2JleXMgdGhlIHJ1bGUgZmlyc3QsIHRo ZW4gbG9jYWwgdHJhbnNsYXRlIGluIE1QTFMgd2lsbCB3b3JrIHBlcmZlY3RseS4NCkx1Y3kNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERhbmllbCBDb2huIFttYWlsdG86RGFu aWVsQ0BvcmNraXQuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjUsIDIwMTIgMjo0NiBQ TQ0KVG86IEx1Y3kgeW9uZzsgUm9nZXJzLCBKb3NoOyBTaGFocmFtIERhdmFyaTsgTGl6aG9uZyBK aW47IGwydnBuQGlldGYub3JnOyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KQ2M6 IHl1cXVuLmNhb0BnbWFpbC5jb20NClN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHBy b2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQoNCkFuZCB0byB0aGlzIEkgYXNrZWQgaG93 IHRoaXMgbWFwcGluZyB3b3JrcyAtIGhvdyBkb2VzIHRoZSBlZ3Jlc3MgcGUgcmVjb3ZlciB0aGUg aW5ncmVzcyB2aWQgd2hlbiBpdCBnZXRzIHRoZSBmcmFtZSB0YWdnZWQgd2l0aCBvbmx5IHRoZSBy b290L2xlYWYgdmlkPyBIb3cgY2FuIHlvdSBjb252ZXkgdGhlIGluZ3Jlc3MgdmlkIHBsdXMgdGhl IHJvb3QvbGVhZiBhdHRyaWJ1dGUgaW4gdGhlIHNhbWUgbnVtYmVyIG9mIGJpdHM/DQpXaGF0IGFt IEkgbWlzc2luZz8NCg0KRGFuaWVsDQoNClRodW1iIHR5cGVkIC0gcGxlYXNlIGJlIHRvbGVyYW50 DQoNCkx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb20+IHdyb3RlOg0KDQpEYW5pZWwsDQoN CkRhdmlkIEFsbGVuIGFscmVhZHkgZXhwbGFpbmVkIHRoZSBzb2x1dGlvbi4gDQoNCkZyb20gRGF2 aWQ6DQppbmdyZXNzIFZMQU4gSUQgPC0+IEV0cmVlIFJvb3QvTGVhZiBWSUQgPC0+IEVncmVzcyBW SUQuDQoNCkluZ3Jlc3MgVklEIGRvZXMgbm90IGhhdmUgdG8gZXF1YWwgRWdyZXNzIFZJRCBidXQg cmVnYXJkbGVzcyB0aGVyZSBpcyBvbmx5IGV2ZXIgb25lIFZJRCBvbiBhIGZyYW1lIGF0IGEgdGlt ZS4NCg0KLWVuZA0KDQpUaGlzIHdvcmtzIHdoZW4gY3VzdG9tZXIgbWFrZXMgaW5ncmVzcyBWTEFO IElEIG5vdCBlcXVhbCB0byBvciBlcXVhbCB0byBlZ3Jlc3MgVkxBTiBJRC4NCg0KUmVnYXJkcywN Ckx1Y3kNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGwydnBuLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGFu aWVsIENvaG4NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjUsIDIwMTIgMTE6MzkgQU0NClRvOiBM dWN5IHlvbmc7IFJvZ2VycywgSm9zaDsgU2hhaHJhbSBEYXZhcmk7IExpemhvbmcgSmluOyBsMnZw bkBpZXRmLm9yZzsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20NCkNjOiB5dXF1bi5j YW9AZ21haWwuY29tDQpTdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0 byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KDQpIaSBMdWN5LA0KDQpUaGUgc2NlbmFyaW8gd2UgYXJl IGRpc2N1c3NpbmcgaXMgbm90IHRoZSBFLVRyZWUgRS1OTkksIGJ1dCBhIGdlbmVyYWwgc2NlbmFy aW8gd2hlcmUgZnJhbWVzIGFycml2aW5nIGF0IHRoZSByb290IG9yIGxlYWYgQUMgIGFyZSBhbHJl YWR5IGRvdWJsZSB0YWdnZWQuIEluIHRoaXMgY2FzZSwgdGhlIGR1YWwgdmxhbiBzb2x1dGlvbiBj YW5ub3QgcHJlc2VydmUgdGhlIHZsYW5zIHdpdGhvdXQgYWRkaW5nIGEgdGhpcmQgb25lLCBjYW4g aXQ/DQoNCk1heWJlIFNoYWhyYW0gY2FuIGFkZCBkZXRhaWxzIG9uIHRoZSBzY2VuYXJpbyBoZSBo YWQgaW4gbWluZA0KDQpUaHVtYiB0eXBlZCAtIHBsZWFzZSBiZSB0b2xlcmFudA0KDQpMdWN5IHlv bmcgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPiB3cm90ZToNCg0KRGFuaWVsLA0KDQpNRUYgaGFzIFMt VkxBTiBwcmVzZXJ2YXRpb24gYXR0cmlidXRlIGZvciBFTk5JIG9ubHkgYmVjYXVzZSB0aGVyZSBp cyBubyBzLXZsYW4gYXQgVU5JLiBXaGVuIGFuIE1FTiBjb25uZWN0cyB0byBtdWx0aXBsZSBFTk5J IGludGVyZmFjZXMsIFMtVkFMTiBwcmVzZXJ2YXRpb24gYXR0cmlidXRlIGlzIHVzZWQuIEl0IGFw cGxpZXMgdG8gRS1UcmVlIGFzIHdlbGwuDQoNClJlZ2FyZHMsDQpMdWN5DQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2 cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhbmllbCBDb2huDQpTZW50OiBUdWVz ZGF5LCBBcHJpbCAyNCwgMjAxMiAyOjEyIEFNDQpUbzogTHVjeSB5b25nOyBSb2dlcnMsIEpvc2g7 IFNoYWhyYW0gRGF2YXJpOyBMaXpob25nIEppbjsgbDJ2cG5AaWV0Zi5vcmc7IEFsZXhhbmRlci5W YWluc2h0ZWluQGVjaXRlbGUuY29tDQpDYzogeXVxdW4uY2FvQGdtYWlsLmNvbQ0KU3ViamVjdDog UkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8N Cg0KTHVjeSwNCg0KZXZlbiBpZiB0aGUgY3VycmVudCBNRUYgZnJhbWV3b3JrIGRvZXNuJ3QgcmVx dWlyZSBzLXZsYW4gcHJlc2VydmF0aW9uLCBJIGJlbGlldmUgaXQncyB0byB0aGUgaW5kdXN0cnkn cyBiZW5lZml0IHRvIGFkb3B0IGEgc29sdXRpb24gdGhhdCBpcyBub3QgY29uc3RyYWluZWQgdG8g YSBzcGVjaWZpYyBlbm5pIG1vZGVsIHRoYXQsIGxpa2UgYWxsIHRoaW5ncyBuZXR3b3JraW5nLCBp cyBsaWtlbHkgdG8gZXZvbHZlLiBFc3BlY2lhbGx5IHdoZW4gc3VjaCBhIHNvbHV0aW9uIGlzIGF2 YWlsYWJsZS4NCg0KRGFuaWVsDQoNClRodW1iIHR5cGVkIC0gcGxlYXNlIGJlIHRvbGVyYW50DQoN Ckx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb20+IHdyb3RlOg0KDQpEYW5pZWwsDQoNCk1F RiBoYXMgd29ya2VkIGluIEVOTkkgaW50ZXJmYWNlIGZvciBhIGxvbmcgdGltZSB3aXRoIG1hbnkg c2VydmljZSBwcm92aWRlcnMnIGlucHV0cy4gSXQgaGFkIGEgZmFpciByZWFzb24gdG8gYXNzdW1l IFMtVkxBTiBvdmVyIEVOTkkgYnkgdGhlbi4gSXQgbWF5IG9wZW4gQi1WTEFOIGZvciB0aGUgZnV0 dXJlLiBJdCBpcyBiZXR0ZXIgZm9yIHVzIG5vdCB0byBkaXNjdXNzICBhIGZ1dHVyZSBmcmFtZXdv cmsgaGVyZSwgYmVjYXVzZSBpdCB3aWxsIGxlYWQgdXMgdG8gbm93aGVyZS4gSGVyZSwgd2Ugd2Fu dCB0byBleHRlbmQgVlBMUyBpbiBzdXBwb3J0aW5nIEUtVHJlZS4NCg0KQmVzdCBSZWdhcmRzLA0K THVjeQ0KDQpGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhbmllbCBDb2huDQpTZW50OiBTdW5kYXksIEFwcmls IDIyLCAyMDEyIDc6MzQgQU0NClRvOiBSb2dlcnMsIEpvc2g7IFNoYWhyYW0gRGF2YXJpOyBMaXpo b25nIEppbjsgbDJ2cG5AaWV0Zi5vcmc7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29t DQpDYzogeXVxdW4uY2FvQGdtYWlsLmNvbQ0KU3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhl IGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCg0KU2hhaHJhbSBhbmQgYWxsLA0K DQpUaGlzIHF1ZXN0aW9uIGFscmVhZHkgY2FtZSB1cCBpbiBvdXIgZGlzY3Vzc2lvbnMgLSBpcyBp dCBzYWZlIHRvIGFzc3VtZSB0aGF0IHRoZSBWTEFOIHRhZ3MgYXQgdGhlIEUtTk5JIHdpbGwgYWx3 YXlzIGJlIGFjY29yZGluZyB0byB0aGUgY3VycmVudCBNRUYgbW9kZWw/IE9yIHNob3VsZCB3ZSB0 cnkgdG8gYmUgYXMgdHJhbnNwYXJlbnQgYXMgcG9zc2libGUgdG8gdXNlciBWTEFOIGVuY2Fwc3Vs YXRpb24gYXQgdGhlIEUtTk5JLCB0byBhY2NvbW1vZGF0ZSBmdXR1cmUgZnJhbWV3b3Jrcz8NCkkg YmVsaWV2ZSB0aGF0IGFueSBhcHByb2FjaCB0aGF0IGxvb2tzIGF0IHVzZXIgcGF5bG9hZCAoaW4g dGhpcyBjYXNlIFZMQU4gdGFnKSB0byBzaWduYWwgVlBMUyBpbmZvcm1hdGlvbiAoaW4gdGhpcyBj YXNlIHJvb3QvbGVhZiBvcmlnaW4pIGlzIG5lY2Vzc2FyaWx5IHRpZWQgdG8gc3BlY2lmaWMgYXNz dW1wdGlvbnMgb24gdXNlciBwYXlsb2FkIGVuY2Fwc3VsYXRpb24gKGluIHRoaXMgY2FzZSwgdGhh dCBTLVZMQU4gdGFnIGlzICJhdmFpbGFibGUiIHRvIGVuY29kZSByb290L2xlYWYpLiBJIGRvbid0 IHRoaW5rIHRoaXMgaXMgYSBmdXR1cmUtcHJvb2YgYXNzdW1wdGlvbiwgaXQncyB2ZXJ5IGxpa2Vs eSB0aGF0IG90aGVyIG5ldHdvcmsgbW9kZWxzIHdpbGwgY29tZSB1cCB0aGF0IHJlcXVpcmUgUy1W TEFOIHByZXNlcnZhdGlvbiwgd2hpY2ggaW4gdGhlIDItVkxBTiBhcHByb2FjaCB3b3VsZCBuZWNl c3NpdGF0ZSBhZGRpbmcgYSB0aGlyZCBWTEFOLUlELg0KDQpEYW5pZWwNCg0KRnJvbTogU2hhaHJh bSBEYXZhcmkgPGRhdmFyaUBicm9hZGNvbS5jb208bWFpbHRvOmRhdmFyaUBicm9hZGNvbS5jb20+ Pg0KVG86IExpemhvbmcgSmluIDxsaXpoby5qaW5AZ21haWwuY29tPG1haWx0bzpsaXpoby5qaW5A Z21haWwuY29tPj4sICJsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+IiA8bDJ2 cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPj4sICJBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+IiA8 QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0 ZWluQGVjaXRlbGUuY29tPj4NCkNjOiAieXVxdW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86eXVxdW4u Y2FvQGdtYWlsLmNvbT4iIDx5dXF1bi5jYW9AZ21haWwuY29tPG1haWx0bzp5dXF1bi5jYW9AZ21h aWwuY29tPj4NClN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRo ZSBFLVRyZWUgc29sdXRpb24/DQoNCkhpLA0KDQpJIGFsc28gaGF2ZSBhIHF1ZXN0aW9uIHJlZ2Fy ZGluZyAyLVZMQU4uIFdoYXQgaWYgdGhlIGN1c3RvbWVyIHRyYWZmaWMgYWxyZWFkeSBoYXMgYW4g Uy1WTEFOPyBEbyB3ZSBuZWVkIGEgM3JkIFZMQU4gdG8gaWRlbnRpZnkgdGhlIEwvUj8NCg0KVGh4 DQpTaGFocmFtDQoNCkZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJv dW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIExpemhvbmcgSmluDQpTZW50OiBGcmlkYXksIEFwcmlsIDIwLCAyMDEyIDk6MzggQU0NClRv OiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBBbGV4YW5kZXIuVmFpbnNo dGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+ DQpDYzogeXVxdW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbT4NClN1 YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29s dXRpb24/DQoNCkhpLCBhbGwsDQpUaGUgZGlmZmVyZW5jZSBiZXR3ZWVuIDItVkxBTiBhbmQgQ1cg YXBwcm9hY2ggaXMgd2hvIHdpbGwgcHJvdmlkZSB0aGUgUi9MIGluZm9ybWF0aW9uLCBjdXN0b21l ciBwYXlsb2FkIG9yIFBXPyBUaGUgY3VzdG9tZXIgcGF5bG9hZCB3aWxsIGJlIGFsd2F5cyBtb2Rp ZmllZCB0byBjYXJyeSBSL0wgaW5mb3JtYXRpb24gaW4gMi1WTEFOIGFwcHJvYWNoLCB3aGlsZSBQ VyB3aXRoIENXIHdpbGwgY2FycnkgUi9MIGluZm9ybWF0aW9uIGZvciBDVyBhcHByb2FjaC4NCkkg aGF2ZSBhIHF1ZXN0aW9uIHdpdGggdGhlIDItVkxBTiBhcHByb2FjaCBpbiBILVZQTFMgd2hlcmUg SC1WUExTIGlzIGFjY2Vzc2VkIGJ5IFZQV1MgYXMgZGVzY3JpYmVkIGluIFJGQzQ2NzIgc2VjdGlv biAxMC4xLjMuIElmIFZQV1MgaXMgdXNlZCB0byBhY2Nlc3MgSC1WUExTLCBob3cgY291bGQgdGhl IFBFIG9uIFZQV1Mgc2lkZSBhZGRzIFZMQU4gdG8gaW5kaWNhdGUgUi9MIGluZm9ybWF0aW9uPw0K DQpUaGFua3MNCkxpemhvbmcNCg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4N Cj4gTWVzc2FnZTogMg0KPiBEYXRlOiBUaHUsIDE5IEFwciAyMDEyIDA0OjM4OjM2ICswMDAwDQo+ IEZyb206IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+Pg0KPiBUbzogIlJv Z2VycywgSm9zaCIgPGpvc2gucm9nZXJzQHR3Y2FibGUuY29tPG1haWx0bzpqb3NoLnJvZ2Vyc0B0 d2NhYmxlLmNvbT4+LCBMdWN5IHlvbmcNCj4gICAgICAgIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxt YWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiwgRGFuaWVsIENvaG4gPERhbmllbENAb3Jja2l0 LmNvbTxtYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tPj4sIFNhbSBDYW8NCj4gICAgICAgIDx5dXF1 bi5jYW9AZ21haWwuY29tPG1haWx0bzp5dXF1bi5jYW9AZ21haWwuY29tPj4NCj4gQ2M6ICJsMnZw bkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+IiA8bDJ2cG5AaWV0Zi5vcmc8bWFpbHRv OmwydnBuQGlldGYub3JnPj4NCj4gU3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJv YWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4gTWVzc2FnZS1JRDoNCj4gICAgICAgIDxG OTMzNjU3MTczMUFERTQyQTUzOTdGQzgzMUNFQUEwMjAzNDE5MkBGUklEV1BQTUIwMDIuZWNpdGVs ZS5jb208bWFpbHRvOkY5MzM2NTcxNzMxQURFNDJBNTM5N0ZDODMxQ0VBQTAyMDM0MTkyQEZSSURX UFBNQjAwMi5lY2l0ZWxlLmNvbT4+DQo+IENvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNl dD0idXMtYXNjaWkiDQo+DQo+IEhpIGFsbCwNCj4gSSBmdWxseSB1bmRlcnN0YW5kIHRoYXQgdGhh dCB3aGF0IEkgYW0gZ29pbmcgdG8gc2F5IGlzIG5vdCB2ZXJ5IHBvcHVsYXIsIGJ1dDoNCj4NCj4g SU1PIG9uZSBvZiB0aGUgYWR2YW50YWdlcyBvZiB0aGUgQ1ctYmFzZWQgc29sdXRpb24gaXMgdGhh dCBpdCBpcyBvcnRob2dvbmFsIHRvIHVzYWdlIChvciBub24tdXNhZ2UpIG9mIFAyTVAgUFdzIGZv ciBlZmZlY3RpdmUgZGVsaXZlcnkgb2YgQlVOIHRyYWZmaWMuDQo+DQo+IEFub3RoZXIgYWR2YW50 YWdlIGlzIHByZXNlcnZhdGlvbiBvZiBmdWxsIG1lc2ggb2YgUDJQIFBXcyBpbiBhIFZQTFMsIGFu ZCwgaW4gYSBtb3JlIGdlbmVyaWMgd2F5LCBsb2NhbGl6YXRpb24gb2YgZWZmZWN0cyBvZiBjaGFu Z2VzIGluIHRoZSBQRSBjb25maWd1cmF0aW9uLg0KPg0KPiBJbiBwYXJ0aWN1bGFyLCBhZGRpbmcg YSBMZWFmIEFDIHRvIGEgUEUgdGhhdCBwcmV2aW91c2x5IGhhcyBiZWVuIG9ubHkgc3VwcG9ydGlu ZyBSb290IEFDcyAob3IgdmljZSB2ZXJzYSksIHJlbW92YWwgb2YgdGhlIGxhc3QgTGVhZiBvciBs YXN0IFJvb3QgQUMgZnJvbSBhIFBFIHRoYXQgcHJldmlvdXNseSBoYXMgYmVlbiBzdXBwb3J0aW5n IGEgbWl4IGV0Yy4gYWZmZWN0IG9ubHkgdGhlIFBFIHdoZXJlIHRoaXMgb3BlcmF0aW9uIGhhcHBl bnMgYW5kIG5vdCB0aGUgcmVzdCBvZiB0aGUgUEVzLg0KPg0KPiBBcyBmb3IgdGhlIG5lZWQgZm9y IEhXIGNoYW5nZXMgdGhhdCBoYXZlIGJlZW4gbWVudGlvbmVkIGFzIGEgbWFpbiBkaXNhZHZhbnRh Z2Ugb2YgdGhlIENXLWJhc2VkIGFwcHJvYWNoIC0gSSBiZWxpZXZlIGl0IHN0cm9uZ2x5IGRlcGVu ZHMgb24gc3BlY2lmaWMgaW1wbGVtZW50YXRpb25zLiBBbmQgc29tZSBjaGFuZ2VzIGluIHRoZSBm b3J3YXJkaW5nIHByb2Nlc3MgYXJlIHJlcXVpcmVkIGluIGFueSBzb2x1dGlvbi4NCj4NCj4gTXkg MmMsDQo+ICAgICBTYXNoYQ0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IEZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBu LWJvdW5jZXNAaWV0Zi5vcmc+IFtsMnZwbi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpsMnZwbi1i b3VuY2VzQGlldGYub3JnPl0gb24gYmVoYWxmIG9mIFJvZ2VycywgSm9zaCBbam9zaC5yb2dlcnNA dHdjYWJsZS5jb208bWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29tPl0NCj4gU2VudDogV2Vk bmVzZGF5LCBBcHJpbCAxOCwgMjAxMiA5OjU3IFBNDQo+IFRvOiBMdWN5IHlvbmc7IERhbmllbCBD b2huOyBTYW0gQ2FvDQo+IENjOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+ DQo+IFN1YmplY3Q6IFJlOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRy ZWUgc29sdXRpb24/DQo+DQo+IEFnYWluLCB0aGUgUDJNUCBzaXR1YXRpb24gdGhyb3dzIG1lLiAg SXMgdGhpcyBzb21ldGhpbmcgdGhhdCBpcyB1c2VkDQo+IGNvbW1vbmx5Pw0KPg0KPiBJJ20gdW5k ZXIgdGhlIGltcHJlc3Npb24gdGhhdCBhZGRpbmcgUDJNUCB0byBhbnkgbW9kZWwgcmVzdWx0cyBp biBhIG1vcmUNCj4gY29tcGxleCBtb2RlbC4gIFdldGhlciBvdXRzaWRlIHMtdGFnIGlzIHVzZWQg dG8gZGlmZmVyZW50aWF0ZSwgb3INCj4gZGVkaWNhdGVkIHB3J3MgYXJlIHVzZWQgZm9yIHRoZSBz YW1lIHB1cnBvc2UsIGl0IHNlZW1zIGJvdGggYmVjb21lIG1vcmUNCj4gY29tcGxleC4NCj4NCj4g R2lsZSdzIGNvbXBhcmlzb24gc2xpZGUgc3RpbGwgY29uY2lzZWx5IGNhcHR1cmVzIHRoZSBkaWZm ZXJlbmNlcyBiZXR3ZWVuDQo+IHRoZXNlIG1ldGhvZHMsIGluIG15IG9waW5pb24uICBJIGhhdmVu J3Qgc2VlbiBhbnkgbmV3IGlkZWFzIG9yIHRob3VnaHRzDQo+IGJyb3VnaHQgdG8gdGhlIGdyb3Vw IGluIHRoZSBwYXN0IHdlZWsgb3IgdHdvIG9uIHRoZSBzdWJqZWN0LiAgSSB3b3VsZCBoYXRlDQo+ IGZvciBib3RoIHByb3Bvc2VkIG1ldGhvZHMgdG8gZGllIG9uIHRoZSB2aW5lIGJlY2F1c2Ugd2Ug Y291bGRuJ3QgZGVjaWRlDQo+IGJldHdlZW4gdHdvIG1ldGhvZHMgdGhhdCBoYXZlIG5vdGhpbmcg aW5oZXJlbnRseSB3cm9uZyB3aXRoIGVpdGhlci4NCj4NCj4gLUpvc2gNCj4NCj4NCj4gT24gNC8x OC8xMiAxOjUzIFBNLCAiTHVjeSB5b25nIiA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1 Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+DQo+PlNlbmQgdGhpcyBhZ2Fpbi4NCj4+DQo+ PlR3byBQVyBhcHByb2FjaCBjYW4gYmUgY29tcGxleCB0b28gaWYgdGhlIFZQTFMgaW5zdGFuY2Ug Zm9yIEUtVHJlZSB1c2VzDQo+PlAyUCBQVyBmb3IgdW5pY2FzdCB0cmFmZmljIGFuZCBQMk1QIFBX IGZvciBicm9hZGNhc3QgYW5kIHVua25vd24NCj4+dW5pY2FzdCB0cmFmZmljLCBhbmQgc29tZSBQ Mk1QIFBXcyBmb3IgbXVsdGljYXN0IHRyYWZmaWMuIEl0IG1heSBkb3VibGUNCj4+YWxsIG9mIHRo ZW0uDQo+Pg0KPj5MdWN5DQo+Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9t OiBEYW5pZWwgQ29obiBbbWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbTxtYWlsdG86RGFuaWVsQ0Bv cmNraXQuY29tPl0NCj4+U2VudDogV2VkbmVzZGF5LCBBcHJpbCAxOCwgMjAxMiAxOjQyIFBNDQo+ PlRvOiBMdWN5IHlvbmc7IFJvZ2VycywgSm9zaDsgU2FtIENhbw0KPj5DYzogbDJ2cG5AaWV0Zi5v cmc8bWFpbHRvOmwydnBuQGlldGYub3JnPg0KPj5TdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0 aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4NCj4+SSB0aGluayB0aGUg Zmlyc3Qgb3B0aW9uIGl0cyB0aGUgbmF0dXJhbCB3YXkgdG8gZ28uIEhvdyBpcyB0aGUgcHJvY2Vz c2luZw0KPj5pbiB0aGlzIGNhc2UgbW9yZSBjb21wbGV4Pw0KPj4NCj4+VGh1bWIgdHlwZWQgLSBw bGVhc2UgYmUgdG9sZXJhbnQNCj4+DQo+Pkx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb208 bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+Pg0KPj4NCj4+DQo+PlNuaXBw ZWQuLg0KPj4NCj4+TXVsdGktUFcgLSBPbiBpbmdyZXNzIFBFLCBmcmFtZSBpcyBwbGFjZWQgb250 byBlaXRoZXIgYSBMZWFmLW9ubHkgUDJNUCBQVw0KPj4oZm9yIHRyYWZmaWMgY29taW5nIGZyb20g YSBsZWFmIEFDKSwgb3Igb250byBhIFJvb3QvTGVhZiBQMk1QIFBXIChmb3INCj4+dHJhZmZpYyBj b21pbmcgZnJvbSBhIHJvb3QgQUMpDQo+PltbTFldXSBOb3QgdGhhdCBzaW1wbGUuIFlvdSBjb25z dHJ1Y3QgZWl0aGVyIHR3byBQMk1QIFBXcyB0byBhbGwgb3RoZXINCj4+UEVzIGFuZCBsZXQgZWdy ZXNzIFBFIHBlcmZvcm1pbmcgZmlsdGVyaW5nLCBvciBjb25zdHJ1Y3Qgb25lIFAyTVAgUFcgdG8N Cj4+bGVhZi1vbmx5IFBFcyBhbmQgdHdvIFAyTVAgUFdzIHRvIHJvb3QgYW5kIGxlYWYgUEVzIGFu ZCBsZXQgaW5ncmVzcyBQRQ0KPj5wZXJmb3JtIGZvcndhcmRpbmcgYW5kIGZpbHRlcmluZy4gQm90 aCBtYWtlIG5vZGUgcHJvY2VzcyBjb21wbGV4Lg0KPj4NCj4+W1tMWV1dIFZQTFMgaXMgYnVpbHQg d2l0aCB0aGUgbWVjaGFuaXNtIHV0aWxpemluZyBQMlAgYW5kIFAyTVAgUFcgZm9yDQo+PmRlbGl2 ZXJpbmcgdGhlIGZyYW1lcyB0byByZW1vdGUgUEVzLiBXZSBzaG91bGQgdXRpbGl6ZSB0aGVtIHdp dGggdGhlDQo+Pm1pbmltaXplZCBjaGFuZ2VzLiBEdWFsIFZMQU4gc29sdXRpb24gaXMgc2ltcGxl ciB0aGFuIER1YWwgUFcuDQo+Pg0KPj5SZWdhcmRzLA0KPj5MdWN5DQo+Pg0KPj4NCj4+SSBzZWUg aG93IDJWTEFOIGlzIHNpbXBsZXIgd2hlbiBQMk1QIFBXJ3MgYXJlIGludm9sdmVkLCBJIHRoaW5r LiAgSQ0KPj5oYXZlbid0IGhhZCBhbnkgZmlyc3QgaGFuZCBleHBlcmllbmNlIHdpdGggUDJNUCBQ VydzLCBob3dldmVyLCBzbyBkb24ndA0KPj5mZWVsIHRlcnJpYmx5IHN0cm9uZyBhYm91dCB0aGlz IG9iamVjdGlvbi4gIElzIHRoaXMgYSByZWFsIHByb2JsZW0gZm9yDQo+Pm90aGVycyAobm93IG9y IGluIHRoZSBmdXR1cmUpLCBvciBpcyB0aGlzIG9iamVjdGlvbiBpbiB0aGUgd2VlZHM/DQo+Pg0K Pj5JJ20gbm90IHN1cmUgdGhlICdhZGRpdGlvbmFsIGNvbXBsZXhpdHknIGlzIG5vdGFibGUsIG9y IGV2ZW4gcmVsZXZhbnQuICBJDQo+PmVuY291cmFnZSBvdGhlcnMgdG8gc3BlYWsgdXAgaWYgdGhl eSBkaXNhZ3JlZSwgYXMgUDJNUCBQVyBpcyBvbmx5DQo+PmNvbmNlcHR1YWwgdG8gbWUsIGFuZCBJ IGFtIHVuZmFtaWxpYXIgd2l0aCByZWFsLWxpZmUgdXNlIGNhc2VzIGZvciBpdC4NCj4+DQo+PlRo YW5rcywNCj4+Sm9zaA0KPj4NCj4+DQo+Pg0KPj5PbiA0LzE4LzEyIDEwOjMwIEFNLCAiTHVjeSB5 b25nIiA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4g d3JvdGU6DQo+Pg0KPj4+UGxlYXNlIHNlZSBpbmxpbmUuDQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBTYW0gQ2FvIFttYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNv bTxtYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbT5dDQo+Pj5TZW50OiBUdWVzZGF5LCBBcHJpbCAx NywgMjAxMiA3OjE0IEFNDQo+Pj5UbzogJ0RhbmllbCBDb2huJzsgTHVjeSB5b25nOyAnUm9nZXJz LCBKb3NoJzsgJ0hlbmRlcmlja3gsIFdpbSAoV2ltKSc7DQo+Pj5naWxlcy5oZXJvbkBnbWFpbC5j b208bWFpbHRvOmdpbGVzLmhlcm9uQGdtYWlsLmNvbT47IHNpbW9uLmRlbG9yZEBnbWFpbC5jb208 bWFpbHRvOnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+Ow0KPj4+QWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPg0KPj4+ Q2M6IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz47IFZsYWRpbWlyLktsZWlu ZXJAZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb20+Ow0KPj4+ QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb208bWFpbHRvOkFuZHJldy5TZXJnZWV2QGVjaXRlbGUu Y29tPjsgSWRhbi5LYXNwaXRAZWNpdGVsZS5jb208bWFpbHRvOklkYW4uS2FzcGl0QGVjaXRlbGUu Y29tPjsNCj4+Pk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPG1haWx0bzpNaXNoYWVsLldleGxl ckBlY2l0ZWxlLmNvbT47IFJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPG1haWx0bzpSb3RlbS5Db2hl bkBlY2l0ZWxlLmNvbT4NCj4+PlN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2Fj aGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4NCj4+PlllcywgMiBwd3MgYXJlIG9ubHkg bmVlZGVkIGJldHdlZW4gcGVzIHdpdGggYm90aCByb290IGFuZCBsZWFmIGFjcyBhZnRlcg0KPj4+ aW1wcm92aW5nIER1YWwtUFcgYXBwcm9hY2guIElmIGNvbnNpZGVyIFAyTVAsIER1YWwtUFcgYXBw cm9hY2ggc2V0dXAgMg0KPj4+UDJNUA0KPj4+UFdzIGlmIG5lZWQuIFRoZXJlIGlzIG5vIGRpZmZl cmVuY2UgYmV0d2VlbiBQMk1QIG9yIG5vcm1hbCBQVyBzZXR1cC4gQnV0LA0KPj4+Y2FuIExlYWYt QUNzIGJlIGJvdW5kIHRvIFJvb3QgUEUgb2YgUDJNUCBQVz8NCj4+Pg0KPj4+W1tMWV1dIE5vLCBp dCBtYWtlcyBjb21wbGV4IGluIHNldHRpbmcgdXAgUDJNUCBQVy4gU2hvdWxkIGEgUEUgd2l0aCBi b3RoDQo+Pj5yb290IGFuZCBsZWFmIEFDcyBzZXQgdXAgdHdvIG9yIG9uZSBQMk1QIFBXIHRvIG90 aGVyIFBFcyAoc29tZSBQRSBoYXZlDQo+Pj5ib3RoIHJvb3QgYW5kIGxlYWYgQUMgYW5kIHNvbWUg b25seSBoYXZlIGxlYWYgQUNzKT8NCj4+PlJlZ2FyZHMsDQo+Pj5MdWN5DQo+Pj4NCj4+PlJlZ2Fy ZHMsDQo+Pj4NCj4+Pll1cXVuIChTYW0pIENhbw0KPj4+RS1tYWlsOiBZdXF1bi5jYW9AZ21haWwu Y29tPG1haWx0bzpZdXF1bi5jYW9AZ21haWwuY29tPg0KPj4+DQo+Pj4NCj4+Pi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBEYW5pZWwgQ29obiBbbWFpbHRvOkRhbmllbENAb3Jj a2l0LmNvbTxtYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tPl0NCj4+PlNlbnQ6IFR1ZXNkYXksIEFw cmlsIDE3LCAyMDEyIDQ6NTYgUE0NCj4+PlRvOiBMdWN5IHlvbmc7IFJvZ2VycywgSm9zaDsgSGVu ZGVyaWNreCwgV2ltIChXaW0pOw0KPj4+Z2lsZXMuaGVyb25AZ21haWwuY29tPG1haWx0bzpnaWxl cy5oZXJvbkBnbWFpbC5jb20+Ow0KPj4+c2ltb24uZGVsb3JkQGdtYWlsLmNvbTxtYWlsdG86c2lt b24uZGVsb3JkQGdtYWlsLmNvbT47IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1h aWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT47IFNhbSBDYW8NCj4+PkNjOiBs MnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBWbGFkaW1pci5LbGVpbmVyQGVj aXRlbGUuY29tPG1haWx0bzpWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPjsNCj4+PkFuZHJl dy5TZXJnZWV2QGVjaXRlbGUuY29tPG1haWx0bzpBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbT47 IElkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0bzpJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbT47 DQo+Pj5NaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbTxtYWlsdG86TWlzaGFlbC5XZXhsZXJAZWNp dGVsZS5jb20+OyBSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbTxtYWlsdG86Um90ZW0uQ29oZW5AZWNp dGVsZS5jb20+DQo+Pj5TdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0 byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+DQo+Pj5BZGRpbmcgU2FtIChhcyBsMnZwbkAgaXMg aG9sZGluZyBtZXNzYWdlcykNCj4+Pg0KPj4+REMNCj4+Pg0KPj4+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+PkZyb206IEx1Y3kgeW9uZyBbbWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29t PG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT5dDQo+Pj5TZW50OiBUdWVzZGF5LCBBcHJpbCAx NywgMjAxMiAxMjozOSBBTQ0KPj4+VG86IERhbmllbCBDb2huOyBSb2dlcnMsIEpvc2g7IEhlbmRl cmlja3gsIFdpbSAoV2ltKTsNCj4+PmdpbGVzLmhlcm9uQGdtYWlsLmNvbTxtYWlsdG86Z2lsZXMu aGVyb25AZ21haWwuY29tPjsgc2ltb24uZGVsb3JkQGdtYWlsLmNvbTxtYWlsdG86c2ltb24uZGVs b3JkQGdtYWlsLmNvbT47DQo+Pj5BbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWls dG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQo+Pj5DYzogbDJ2cG5AaWV0Zi5v cmc8bWFpbHRvOmwydnBuQGlldGYub3JnPjsgVmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbTxt YWlsdG86VmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbT47DQo+Pj5BbmRyZXcuU2VyZ2VldkBl Y2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb20+OyBJZGFuLkthc3Bp dEBlY2l0ZWxlLmNvbTxtYWlsdG86SWRhbi5LYXNwaXRAZWNpdGVsZS5jb20+Ow0KPj4+TWlzaGFl bC5XZXhsZXJAZWNpdGVsZS5jb208bWFpbHRvOk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPjsg Um90ZW0uQ29oZW5AZWNpdGVsZS5jb208bWFpbHRvOlJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPg0K Pj4+U3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJl ZSBzb2x1dGlvbj8NCj4+Pg0KPj4+DQo+Pj5TbmlwcGVkLA0KPj4+DQo+Pj5BcyB3ZSBkaXNjdXNz ZWQgZXh0ZW5zaXZlbHkgaW4gdGhlIGxpc3QsIGFuZCBhcyByZWZsZWN0ZWQgaW4gZ2lsZXMNCj4+ PnNsaWRlLCAyIHB3cyBhcmUgb25seSBuZWVkZWQgYmV0d2VlbiBwZXMgd2l0aCBib3RoIHJvb3Qg YW5kIGxlYWYgYWNzLA0KPj4+d2hpY2ggd2lsbCB0eXBpY2FsbHkgYmUgYSBzbWFsbCBtaW5vcml0 eS4NCj4+PltbTFldXSBEb24ndCBrbm93IGlmIHRoZSBhc3N1bXB0aW9uIGlzIHRydWUuIEV2ZW4g aXQgaXMgdGhlIGNhc2UsIGJvdGgNCj4+PmFwcHJvYWNoZXMgY2FuIGJlbmVmaXQgZnJvbSBpdC4g SSB3YXMgb2ZmIGZvciBhIHdoaWxlIGFuZCBjYXB0dXJlcyBzb21lDQo+Pj5kaXNjdXNzaW9ucyBu b3cuDQo+Pj4NCj4+PkFsc28gYXMgcGVyIGdpbGVzIHNsaWRlLCBkdWFsIHZsYW4gY2FuIGhhdmUg c2NhbGFiaWxpdHkgaXNzdWVzIGR1ZSB0bw0KPj4+YWRkaXRpb25hbCBsb29rdXAgYW5kIGRvdWJs ZSB1c2Ugb2YgdmxhbnMgaW4gaW50ZXJuYWwgZW11bGF0ZWQgbGFuDQo+Pj5pbnRlcmZhY2UuIEFs c28gdGhlcmUgYXJlIHBvdGVudGlhbCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGlzc3VlcyB3aXRo DQo+Pj5zaWxpY29uIHRoYXQgZG9lc24ndCBzdXBwb3J0IHZsYW4gbWFwcGluZy4NCj4+PltbTFld XSBJIHdhcyBub3QgaW4gSUVURjgzIG1lZXRpbmcgYW5kIHdhaXQgb24gdGhlIG1lZXRpbmcgbWlu dXRlcy4gSSBhbQ0KPj4+bm90IGNsZWFyIG9uIGFsbCB0aGUgaXNzdWVzLiBDb3VsZCB5b3UgYmUg bW9yZSBzcGVjaWZpYz8gQXMgSSBtZW50aW9uZWQNCj4+PmluIGJlbG93LCB0d28gUFcgYXBwcm9h Y2ggbWFrZXMgVlBMUyB0cmFuc3BvcnQgY29uc3RydWN0aW9uIGFuZCBwYWNrZXQNCj4+PmZvcndh cmRpbmcgbW9yZSBjb21wbGV4LCBJIGNhbiBzZWUgcG90ZW50aWFsIGJhY2t3YXJkIGNvbXBhdGli aWxpdHkNCj4+Pmlzc3VlcyB3aXRoIDIgUFcgc29sdXRpb24uDQo+Pj4NCj4+PlJlZ2FyZHMsDQo+ Pj5MdWN5DQo+Pj4NCj4+PlJlZ2FyZHMsDQo+Pj4NCj4+PkRhbmllbA0KPj4+DQo+Pj5UaHVtYiB0 eXBlZCAtIHBsZWFzZSBiZSB0b2xlcmFudA0KPj4+DQo+Pj5MdWN5IHlvbmcgPGx1Y3kueW9uZ0Bo dWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KPj4+DQo+Pj5J biBteSBtaW5kLCB0aGUgVkxBTiBhcHByb2FjaCBtZWFucyBkdWFsIHZsYW4gbWV0aG9kLg0KPj4+ DQo+Pj5UaGUgbWFpbiBjb25jZXJuIGZvciBDVyBhcHByb2FjaCBpcyBoYXJkd2FyZSBzdXBwb3J0 Lg0KPj4+DQo+Pj5Ud28gUFcgYXBwcm9hY2ggY2FuIGJlIGNvbXBsZXggdG9vIGlmIHRoZSBWUExT IGluc3RhbmNlIGZvciBFLVRyZWUgdXNlcw0KPj4+UDJQIFBXIGZvciB1bmljYXN0IHRyYWZmaWMg YW5kIFAyTVAgUFcgZm9yIGJyb2FkY2FzdCBhbmQgdW5rbm93biB1bmljYXN0DQo+Pj50cmFmZmlj LCBhbmQgc29tZSBQMk1QIFBXcyBmb3IgbXVsdGljYXN0IHRyYWZmaWMuIEl0IG1heSBkb3VibGUg YWxsIG9mDQo+Pj50aGVtLg0KPj4+DQo+Pj5FLXRyZWUgaXMgYW4gRXRoZXJuZXQgc2VydmljZSBh bmQgdGhlcmUgaXMgYWxyZWFkeSBWTEFOIGJhc2VkIHNvbHV0aW9uDQo+Pj5pbiBJRUVFLCBjYW4g d2UganVzdCB1dGlsaXplIGl0IHdpdGhvdXQgY29tcGxpY2F0aW5nIFZQTFMgdHJhbnNwb3J0DQo+ Pj5jb25zdHJ1Y3Rpb24/IFRoaXMgYWxzbyBtYWtlcyBpbnRlcndvcmtpbmcgd2l0aCBFdGggb25s eSBuZXR3b3JrIGVhc2llci4NCj4+Pg0KPj4+Q2hlZXJzLA0KPj4+THVjeQ0KPj4+DQo+Pj4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+RnJvbTogUm9nZXJzLCBKb3NoIFttYWlsdG86am9z aC5yb2dlcnNAdHdjYWJsZS5jb208bWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29tPl0NCj4+ PlNlbnQ6IE1vbmRheSwgQXByaWwgMTYsIDIwMTIgODozNSBBTQ0KPj4+VG86IEx1Y3kgeW9uZzsg SGVuZGVyaWNreCwgV2ltIChXaW0pOyAnZ2lsZXMuaGVyb25AZ21haWwuY29tPG1haWx0bzpnaWxl cy5oZXJvbkBnbWFpbC5jb20+JzsNCj4+PidzaW1vbi5kZWxvcmRAZ21haWwuY29tPG1haWx0bzpz aW1vbi5kZWxvcmRAZ21haWwuY29tPic7ICdBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+Jw0KPj4+Q2M6ICdsMnZw bkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+JzsgJ1ZsYWRpbWlyLktsZWluZXJAZWNp dGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb20+JzsNCj4+PidBbmRy ZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb20+ JzsgJ0lkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0bzpJZGFuLkthc3BpdEBlY2l0ZWxlLmNv bT4nOw0KPj4+J01pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPG1haWx0bzpNaXNoYWVsLldleGxl ckBlY2l0ZWxlLmNvbT4nOyAnUm90ZW0uQ29oZW5AZWNpdGVsZS5jb208bWFpbHRvOlJvdGVtLkNv aGVuQGVjaXRlbGUuY29tPicNCj4+PlN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHBy b2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4NCj4+PkkgYmVsaWV2ZSB0aGUgaW5p dGlhbCBxdWVzdGlvbiB3YXMgaW4gcmVnYXJkIHRvIHRoZSBDVyBtZXRob2QuICBBcmUgeW91DQo+ Pj5zYXlpbmcgdGhhdCB5b3Ugbm8gbG9uZ2VyIGFyZSBpbnRlcmVzdGVkIGluIHRoYXQgbWV0aG9k IGluIHByZWZlcmVuY2Ugb2YNCj4+PnRoZSBkdWFsIHZsYW4gbWV0aG9kPw0KPj4+DQo+Pj4NCj4+ Pg0KPj4+THVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1 YXdlaS5jb20+PiB3cm90ZToNCj4+Pg0KPj4+DQo+Pj5BZ3JlZSB3aXRoIFdpbS4gVkxBTiBhcHBy b2FjaCBpcyB0aGUgYmVzdCBzb2x1dGlvbiBmb3IgRS1UcmVlLg0KPj4+DQo+Pj5MdWN5DQo+Pj4N Cj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBsMnZwbi1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmwydnBuLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYNCj4+ Pk9mIEhlbmRlcmlja3gsIFdpbSAoV2ltKQ0KPj4+U2VudDogVGh1cnNkYXksIEFwcmlsIDEyLCAy MDEyIDI6MDMgQU0NCj4+PlRvOiAnZ2lsZXMuaGVyb25AZ21haWwuY29tPG1haWx0bzpnaWxlcy5o ZXJvbkBnbWFpbC5jb20+JzsgJ3NpbW9uLmRlbG9yZEBnbWFpbC5jb208bWFpbHRvOnNpbW9uLmRl bG9yZEBnbWFpbC5jb20+JzsNCj4+PidBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxt YWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+Jw0KPj4+Q2M6ICdsMnZwbkBp ZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+JzsgJ1ZsYWRpbWlyLktsZWluZXJAZWNpdGVs ZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb20+JzsNCj4+PidBbmRyZXcu U2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb20+Jzsg J0lkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0bzpJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbT4n Ow0KPj4+J01pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPG1haWx0bzpNaXNoYWVsLldleGxlckBl Y2l0ZWxlLmNvbT4nOyAnUm90ZW0uQ29oZW5AZWNpdGVsZS5jb208bWFpbHRvOlJvdGVtLkNvaGVu QGVjaXRlbGUuY29tPicNCj4+PlN1YmplY3Q6IFJlOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2Fj aGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4NCj4+PlRoZSB2bGFuIGFwcHJvYWNoIGlz IHN1cGVyaW9yIGFzIGl0IGFsc28gd29ya3MgZm9yIGV0aCBvbmx5IG5ldHdvcmtzLA0KPj4+ZXRj LiBPbiB0b3Agc29tZSB2ZW5kb3JzIGluZGljYXRlIGh3IGlzc3VlcyB3aXRoIHRoZSBjdyBhcHBy b2FjaC4gQXMNCj4+PnN1Y2ggd2UgaGF2ZSBkcm9wcGVkIG1vcmUgb3IgbGVzcyB0aGUgY3cgYXBw cm9hY2guDQo+Pj4NCj4+PkNoZWVycywNCj4+PldpbQ0KPj4+X19fX19fX19fX19fX19fX18NCj4+ PnNlbnQgZnJvbSBibGFja2JlcnJ5DQo+Pj4NCj4+Pi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0NCj4+PkZyb206IEdpbGVzIEhlcm9uIFttYWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tPG1h aWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+XQ0KPj4+U2VudDogVGh1cnNkYXksIEFwcmlsIDEy LCAyMDEyIDA4OjIyIEFNDQo+Pj5UbzogU2ltb24gRGVsb3JkIDxzaW1vbi5kZWxvcmRAZ21haWwu Y29tPG1haWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPj47IEFsZXhhbmRlciBWYWluc2h0ZWlu DQo+Pj48QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5W YWluc2h0ZWluQGVjaXRlbGUuY29tPj4NCj4+PkNjOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2 cG5AaWV0Zi5vcmc+IDxsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+PjsgVmxh ZGltaXIgS2xlaW5lcg0KPj4+PFZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZs YWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb20+PjsgQW5kcmV3IFNlcmdlZXYNCj4+PjxBbmRyZXcu U2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb20+Pjsg SWRhbiBLYXNwaXQgPElkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0bzpJZGFuLkthc3BpdEBl Y2l0ZWxlLmNvbT4+Ow0KPj4+TWlzaGFlbCBXZXhsZXIgPE1pc2hhZWwuV2V4bGVyQGVjaXRlbGUu Y29tPG1haWx0bzpNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT4+OyBSb3RlbSBDb2hlbg0KPj4+ PFJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPG1haWx0bzpSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbT4+ DQo+Pj5TdWJqZWN0OiBSZTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1U cmVlIHNvbHV0aW9uPw0KPj4+DQo+Pj5Tb3JyeSAtIHRoZSAiYW5vbnltb3VzIHByZXNlbnRhdGlv biIgd2FzIG1pbmUuICBJIHNob3VsZCBwb3NzaWJseSBoYXZlDQo+Pj5wdXQgaW4gYSB0aGlyZCBj b2x1bW4gb24gdGhlIENXIGFwcHJvYWNoLiAgQW5kIGhvcGVmdWxseSB0aGUgbWludXRlcw0KPj4+ d2lsbCBiZSBwb3N0ZWQgc29vbi4NCj4+Pg0KPj4+V2UgaGFkIHZhcmlvdXMgZGlzY3Vzc2lvbnMs IGFzIFNpbW9uIHN0YXRlZCwgYW5kIGNvbnNlbnN1cyBzZWVtZWQgdG8gYmUNCj4+PmZvcm1pbmcg YXJvdW5kIHRoZSB0d28gYWx0ZXJuYXRpdmVzIG9mIHR3byBQV0VzIG9yIHR3byBWTEFOcy4gIEkg YmVsaWV2ZQ0KPj4+dGhyZWUgb2YgdGhlIGF1dGhvcnMgb2YgdGhlIENXIGFwcHJvYWNoIGFyZSBh bHNvIGF1dGhvcnMgb2YgdGhlIHR3byBWTEFODQo+Pj5hcHByb2FjaCBhbmQgb25lIGlzIGFsc28g YW4gYXV0aG9yIG9mIHRoZSB0d28gUFdFIGFwcHJvYWNoLiBTbyBwZXJoYXBzDQo+Pj5pdCdzIGJl c3QgdG8gbGV0IHRob3NlIGZvdXIgaW5kaXZpZHVhbHMgc2F5IHdoaWNoIGFwcHJvYWNoIHRoZXkg cHJlZmVyDQo+Pj5hbmQgd2h5Pw0KPj4+DQo+Pj5HaWxlcw0KPj4+DQo+Pj5PbiAxMC8wNC8yMDEy IDAwOjQ1LCAiU2ltb24gRGVsb3JkIiA8c2ltb24uZGVsb3JkQGdtYWlsLmNvbTxtYWlsdG86c2lt b24uZGVsb3JkQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4+DQo+Pj4+IEhpIEFsZXhhbmRlciwNCj4+ Pj4NCj4+Pj4gWW91IGFyZSByaWdodCwgbm8gZGlzY3Vzc2lvbiBvbiB0aGUgV0cgbWFpbGluZyBs aXN0IHJlY2VudGx5LCBidXQNCj4+Pj4gdGhlcmUgaGF2ZSBiZWVuIHN1YnN0YW50aWFsIGRpc2N1 c3Npb25zIGFtb25nIHRoZSBhdXRob3JzIG9mIHZhcmlvdXMNCj4+Pj4gc29sdXRpb24gZHJhZnRz IG9mZiB0aGUgbWFpbGluZyBsaXN0LiBBcyBmYXIgYXMgSSBrbm93LCBubyBjb25zZW5zdXMNCj4+ Pj4geWV0IGJlZm9yZSBpZXRmODMsIG5vdCBzdXJlIHRoZSBwcm9ncmVzcyBpbiB0aGUgUGFyaXMg V0cgbWVldGluZy4gSQ0KPj4+PiB0aGluayB0aGUgQ1cgYXBwcm9hY2ggaGFzIG5vdCBiZWVuIHJl amVjdGVkIGJ5IHRoZSBXRyB5ZXQsIG9yIHRoZSBXRw0KPj4+PiBoYXMgbm90IHlldCBkZWNpZGVk IG9uIHdoaWNoIG9uZSB0byBhZG9wdC4NCj4+Pj4NCj4+Pj4gU2ltb24NCj4+Pj4NCj4+Pj4gMjAx Mi80LzggQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUu Y29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4+DQo+Pj4+DQo+Pj4+ PiAgSGkgYWxsLA0KPj4+Pj4NCj4+Pj4+IFVuZm9ydHVuYXRlbHkgSSBoYXZlIG5vdCBiZWVuIGFi bGUgdG8gYXR0ZW5kIHRoZSBQYXJpcyBJRVRGLg0KPj4+Pj4NCj4+Pj4+IEhvd2V2ZXIsIGxvb2tp bmcgdXAgdGhlIEwyVlBOIHByb2NlZWRpbmdzLCBJJ3ZlIGZvdW5kIGEgc2hvcnQNCj4+Pj4+IGFu b255bW91cyBwcmVzZW50YXRpb24gY2FsbGVkICJFLVRyZWUgVXBkYXRlIiAgKA0KPj4+Pj4gaHR0 cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84My9zbGlkZXMvc2xpZGVzLTgzLWwydnBuLTEu cHB0eCkuDQo+Pj4+PiBUaGlzIHByZXNlbnRhdGlvbiBkaXNjdXNzZXMgdGhlIGRpZmZlcmVuY2Vz IG9mIHRoZSBFLVRyZWUgYXBwcm9hY2hlcw0KPj4+Pj4gYmFzZWQgb24gZGVkaWNhdGVkIFZMQU5z IChhcyBpbg0KPj4+Pj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jYW8t bDJ2cG4tdnBscy1ldHJlZS8/aW5jbHVkZV90DQo+Pj4+PiBleHQ9MSkgYW5kIG11bHRpcGxlIFBX cyBiZXR3ZWVuIHRoZSBQRXMgKGFzIGluDQo+Pj4+PiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXJhbS1sMnZwbi1ldHJlZS1tdWx0aXBsZS1wdy8/aW4NCj4+Pj4+IGNsdWRl X3RlDQo+Pj4+PiB4dD0xKQ0KPj4+Pj4gYW5kIGNvbXBsZXRlbHkgaWdub3JlcyB0aGUgc29sdXRp b24gYmFzZWQgb24gdXNhZ2Ugb2YgdGhlIENXIGluIHRoZQ0KPj4+Pj4gUFdzIGNvbm5lY3Rpbmcg dGhlIFBFcyAoYXMgaW4NCj4+Pj4+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQta2V5LWwydnBuLXZwbHMtZXRyZWUvP2luY2x1ZGVfdA0KPj4+Pj4gZXh0PTENCj4+Pj4+ICku DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBUaGUgTWludXRlcyBvZiB0aGUgUGFyaXMgTDJW UE4gc2Vzc2lvbiBhcmUgbm90IHlldCBhdmFpbGFibGUsIGJ1dCBJDQo+Pj4+PiB3b25kZXIgd2hl dGhlciB0aGUgV0cgaGFzIHRha2VuIGEgZGVjaXNpb24gdG8gcmVqZWN0IHRoZSBhcHByb2FjaA0K Pj4+Pj4gYmFzZWQgb24gdGhlIENXIHVzYWdlPyBJIGRvIG5vdCByZW1lbWJlciBhbnkgcmVjZW50 IGRpc2N1c3Npb24gb2YNCj4+Pj4+IHRoaXMgdG9waWMgb24gdGhlIFdHIG1haWxpbmcgbGlzdC4N Cj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFJlZ2FyZHMsIGFuZCBsb3RzIG9mIHRoYW5rcyBp biBhZHZhbmNlLA0KPj4+Pj4NCj4+Pj4+IFNhc2hhDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+ Pg0KPj4+Pj4NCj4+Pj4+IFRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSBy ZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMNCj4+Pj4+IGluZm9ybWF0aW9uIHdoaWNoIGlzIENP TkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSQ0KPj4+DQo+Pj4+ PiBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJv ciwgcGxlYXNlDQo+Pj4+PiBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0 aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kDQo+Pj4+PiBhbGwgY29waWVzIHRoZXJlb2YuDQo+ Pj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+PlRoaXMgRS1tYWlsIGFuZCBhbnkgb2Yg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlDQo+Pj5wcm9wcmll dGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBz dWJqZWN0DQo+Pj50byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBU aGlzIEUtbWFpbCBpcyBpbnRlbmRlZA0KPj4+c29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRp dmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuDQo+Pj5JZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVi eQ0KPj4+bm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5 aW5nLCBvciBhY3Rpb24gdGFrZW4NCj4+PmluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBh bmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMNCj4+PnN0cmljdGx5IHByb2hpYml0ZWQg YW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcw0KPj4+RS1tYWls IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1h bmVudGx5DQo+Pj5kZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFp bCBhbmQgYW55IHByaW50b3V0Lg0KPj4+DQo+Pg0KPj4NCj4+VGhpcyBFLW1haWwgYW5kIGFueSBv ZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUNCj4+cHJvcHJp ZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Ig c3ViamVjdCB0bw0KPj5jb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBU aGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkNCj4+Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91DQo+PmFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkg bm90aWZpZWQNCj4+dGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5n LCBvciBhY3Rpb24gdGFrZW4gaW4NCj4+cmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBh dHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseQ0KPj5wcm9oaWJpdGVkIGFuZCBt YXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluDQo+PmVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5 IGRlbGV0ZSB0aGUNCj4+b3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBh bnkgcHJpbnRvdXQuDQo+DQo+DQo+IFRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9u LCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJp Z2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5k ZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGlj aCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQg b2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWlu YXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9u IHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0 aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0KPiBUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGlu dGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdo aWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBU ZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwg cGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRl IHRoZSBvcmlnaW5hbCBhbmQgYWxsIGNvcGllcyB0aGVyZW9mLg0KPg0KPg0KPg0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gTDJ2cG4gbWFpbGluZyBsaXN0DQo+IEwydnBuQGlldGYu b3JnPG1haWx0bzpMMnZwbkBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9sMnZwbg0KPg0KPg0KPiBFbmQgb2YgTDJ2cG4gRGlnZXN0LCBWb2wgOTUsIElz c3VlIDI1DQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo= From david.i.allan@ericsson.com Wed Apr 25 14:05:08 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E690D11E8072 for ; Wed, 25 Apr 2012 14:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 304xh7pvzuI4 for ; Wed, 25 Apr 2012 14:05:06 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8E58811E8089 for ; Wed, 25 Apr 2012 14:05:06 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3PL54Ee026419; Wed, 25 Apr 2012 16:05:05 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.69]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 25 Apr 2012 17:04:58 -0400 From: David Allan I To: Daniel Cohn , "l2vpn@ietf.org" Date: Wed, 25 Apr 2012 17:04:57 -0400 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IABEiWPQAAFgqVoABMXRAAABv/gYAAAFTgAAAdLw+gAAAf/w Message-ID: <60C093A41B5E45409A19D42CF7786DFD52324EEFF1@EUSAACMS0703.eamcs.ericsson.se> References: <172f01cd2323$bdca1c82$05280101@corrigent.com> In-Reply-To: <172f01cd2323$bdca1c82$05280101@corrigent.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: l2vpn@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, 25 Apr 2012 21:05:09 -0000 OK I feel like I am digressing a fair distance from the actual problem.... = But here goes: So the scenarios center around "how ETREE do you want to be?".... If the ACs are root/leaf, then if they are P2P (single ethernet end station= attached to each AC) this is moot. ETREE semantics are enforced by the 2VI= D domain in the center of the example. If you assumed nodes A&B in the exam= ple were L2VPN PEs, the tagging and the PW tag imposition all happened at t= he same point in the network. If they are not simple P2P all the way to end systems and the objective is = to avoid bridging between leaf "sites" but allowing intra-leaf-site connect= ivity then the leaves can be LANs but the root is not, such that I cannot b= ridge through the root. But all hosts at a given leaf site can see each oth= er. So root Ethernet end systems are directly attached or two VIDs are used= in the root site. If the objective is that there are multiple ethernet attached end stations = at both the leaf and root sites, and the objective is to enforce L2 isolati= on everywhere then I need two VIDs extended to the end system attachement p= oint in the local LANs by whatever means.... And I do not see adding VLANs in any particular spot, simply selection of t= he VID and associated semantics where VIDs are translated. The actual point= of S-tag imposition could be a PE, or cloud be a NID/CLE on the customer p= rem (more likely scenario here to extend OAM demarc to the prem), or some s= witch in a RAN downstream of the MPLS PE... blah blah blah. And if ETREE is= extended into a customer site LAN and outside of the provider domain, then= two C-tags would have to be used that mapped to S-tags at the PBN boundary= ... Make sense? Dave -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Wednesday, April 25, 2012 4:39 PM To: David Allan I; l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Dave, but the ACs are root/leaf (that's what the whole vpls etree is about = - see the reqt draft), so per the 2vlan draft the root/leaf vlan must be ad= ded. Thumb typed - please be tolerant David Allan I wrote: HI Daniel: In the example provided, "ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" A B the service is not ETREE in the domains of the ingress and egress VID. It i= s ELAN. SO there is no root/leaf attribute to shovel around. It would requi= re two VIDs in each domain if the ETREE semantics were to be telescoped E2E= . Otherwise it is a provisioning of the VID translation tables at the interme= diate nodes (A&B that I've added to the picture) that would determine the V= ID values used in each domain. Or in the example above, what the ingress, E= tree and egress VID values were. Cheers Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Wednesday, April 25, 2012 3:46 PM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? And to this I asked how this mapping works - how does the egress pe recover= the ingress vid when it gets the frame tagged with only the root/leaf vid?= How can you convey the ingress vid plus the root/leaf attribute in the sam= e number of bits? What am I missing? Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, David Allen already explained the solution. >From David: ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. Ingress VID does not have to equal Egress VID but regardless there is only = ever one VID on a frame at a time. -end This works when customer makes ingress VLAN ID not equal to or equal to egr= ess VLAN ID. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Wednesday, April 25, 2012 11:39 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi Lucy, The scenario we are discussing is not the E-Tree E-NNI, but a general scena= rio where frames arriving at the root or leaf AC are already double tagged= . In this case, the dual vlan solution cannot preserve the vlans without ad= ding a third one, can it? Maybe Shahram can add details on the scenario he had in mind Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has S-VLAN preservation attribute for ENNI only because there is no s-v= lan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN preser= vation attribute is used. It applies to E-Tree as well. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Tuesday, April 24, 2012 2:12 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, even if the current MEF framework doesn't require s-vlan preservation, I be= lieve it's to the industry's benefit to adopt a solution that is not constr= ained to a specific enni model that, like all things networking, is likely = to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service provider= s' inputs. It had a fair reason to assume S-VLAN over ENNI by then. It may = open B-VLAN for the future. It is better for us not to discuss a future fr= amework here, because it will lead us to nowhere. Here, we want to extend V= PLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Va= inshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume tha= t the VLAN tags at the E-NNI will always be according to the current MEF mo= del? Or should we try to be as transparent as possible to user VLAN encapsu= lation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case VLAN t= ag) to signal VPLS information (in this case root/leaf origin) is necessari= ly tied to specific assumptions on user payload encapsulation (in this case= , that S-VLAN tag is "available" to encode root/leaf). I don't think this i= s a future-proof assumption, it's very likely that other network models wil= l come up that require S-VLAN preservation, which in the 2-VLAN approach wo= uld necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, "l2vpn@i= etf.org" >, "A= lexander.Vainshtein@ecitele.com" <= Alexander.Vainshtein@ecitele.com> Cc: "yuqun.cao@gmail.com" > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic alrea= dy has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com= Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L i= nformation, customer payload or PW? The customer payload will be always mod= ified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is access= ed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informati= on? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > com>> > To: "Rogers, Josh" >, Lucy yong > >, Daniel Cohn <= DanielC@orckit.com>, Sam Cao > > > Cc: "l2vpn@ietf.org" > > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, = but: > > IMO one of the advantages of the CW-based solution is that it is orthogon= al to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffi= c. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and,= in a more generic way, localization of effects of changes in the PE config= uration. > > In particular, adding a Leaf AC to a PE that previously has been only sup= porting Root ACs (or vice versa), removal of the last Leaf or last Root AC = from a PE that previously has been supporting a mix etc. affect only the PE= where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadva= ntage of the CW-based approach - I believe it strongly depends on specific = implementations. And some changes in the forwarding process are required in= any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org > [l2vpn-bounces@ietf.org] on behalf of > Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a > more complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become > more complex. > > Gile's comparison slide still concisely captures the differences > between these methods, in my opinion. I haven't seen any new ideas or > thoughts brought to the group in the past week or two on the subject. > I would hate for both proposed methods to die on the vine because we > couldn't decide between two methods that have nothing inherently wrong wi= th either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree >>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may >>double all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn >>[mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the >>processing in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >>PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW >>(for traffic coming from a root AC) [[LY]] Not that simple. You >>construct either two P2MP PWs to all other PEs and let egress PE >>performing filtering, or construct one P2MP PW to leaf-only PEs and >>two P2MP PWs to root and leaf PEs and let ingress PE perform >>forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so >>don't feel terribly strong about this objection. Is this a real >>problem for others (now or in the future), or is this objection in the we= eds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. >>I encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao >>>[mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>(Wim)'; giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>PE have both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn >>>[mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com>; Sam Cao >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong >>>[mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>both approaches can benefit from it. I was off for a while and >>>captures some discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues >>>with silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >>>am not clear on all the issues. Could you be more specific? As I >>>mentioned in below, two PW approach makes VPLS transport construction >>>and packet forwarding more complex, I can see potential backward >>>compatibility issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>double all of them. >>> >>>E-tree is an Ethernet service and there is already VLAN based >>>solution in IEEE, can we just utilize it without complicating VPLS >>>transport construction? This also makes interworking with Eth only netwo= rk easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh >>>[mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); >>>'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vain= shtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are >>>you saying that you no longer are interested in that method in >>>preference of the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org >>>[mailto:l2vpn-bounces@ietf.org] On >>>Behalf Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron >>>[mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord >>>>; Alexander >>>Vainshtein >>>>>.com>> >>>Cc: l2vpn@ietf.org >>>>; Vladimir Kleiner >>>>; >>>Andrew Sergeev >>>>; Idan >>>Kaspit >; >>>Mishael Wexler >>>>; >>>Rotem Cohen > >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly >>>have put in a third column on the CW approach. And hopefully the >>>minutes will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to >>>be forming around the two alternatives of two PWEs or two VLANs. I >>>believe three of the authors of the CW approach are also authors of >>>the two VLAN approach and one is also an author of the two PWE >>>approach. So perhaps it's best to let those four individuals say >>>which approach they prefer and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of >>>> various solution drafts off the mailing list. As far as I know, no >>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>> meeting. I think the CW approach has not been rejected by the WG >>>> yet, or the WG has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein >>>> >>> le.com>> >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree >>>>> approaches based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/ >>>>> ?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in >>>>> the PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>> I wonder whether the WG has taken a decision to reject the >>>>> approach based on the CW usage? I do not remember any recent >>>>> discussion of this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and >>>>> contains information which is CONFIDENTIAL and which may be >>>>> proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original >>>>> and all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or >>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>intended solely for the use of the individual or entity to which it is a= ddressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail >>>is strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is >>addressed. If you are not the intended recipient of this E-mail, you >>are hereby notified that any dissemination, distribution, copying, or >>action taken in relation to the contents of and attachments to this >>E-mail is strictly prohibited and may be unlawful. If you have >>received this E-mail in error, please notify the sender immediately >>and permanently delete the original and any copy of this E-mail and any p= rintout. > > > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** From donald.fedyk@alcatel-lucent.com Wed Apr 25 14:22:54 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A62711E809F for ; Wed, 25 Apr 2012 14:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.598 X-Spam-Level: X-Spam-Status: No, score=-7.598 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 Z8SThKopYY9J for ; Wed, 25 Apr 2012 14:22:49 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 49BB011E809C for ; Wed, 25 Apr 2012 14:22:48 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q3PLMhqk008746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Apr 2012 16:22:43 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q3PLMhNB001524 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Apr 2012 16:22:43 -0500 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.145]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Wed, 25 Apr 2012 16:22:43 -0500 From: "Fedyk, Donald (Don)" To: David Allan I , Daniel Cohn , "l2vpn@ietf.org" Date: Wed, 25 Apr 2012 16:22:38 -0500 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IABEiWPQAAFgqVoABMXRAAABv/gYAAAFTgAAAdLw+gAAAf/wAADrR4A= Message-ID: References: <172f01cd2323$bdca1c82$05280101@corrigent.com> <60C093A41B5E45409A19D42CF7786DFD52324EEFF1@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD52324EEFF1@EUSAACMS0703.eamcs.ericsson.se> 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-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 X-BeenThere: l2vpn@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, 25 Apr 2012 21:22:54 -0000 Hi Dave Yes the only point I would add is Dual VLAN means One VID for Root and one = VID for Leaf. Not two TAGs at a time on the frame but two allocated for the= service. The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks abo= ut Encapsulation Overhead as a VLAN Tag. While that is true in a PWE sense = it is still a single VLAN Tag at a time in a Ethernet E-tree sense. The co= mpelling driver for Dual VLAN is having a Etree service that works in many = environments and the DUAL VLAN (really dual VLAN interface on a VSI) uses t= he same mechanism (one VID for root and one VID for Leaf at a time) as spec= ified in the IEEE. In a pure Ethernet bridging world the VLAN TAGs for Etre= e are not typically an overhead since translation is used. Don -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= avid Allan I Sent: Wednesday, April 25, 2012 5:05 PM To: Daniel Cohn; l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? OK I feel like I am digressing a fair distance from the actual problem.... = But here goes: So the scenarios center around "how ETREE do you want to be?".... If the ACs are root/leaf, then if they are P2P (single ethernet end station= attached to each AC) this is moot. ETREE semantics are enforced by the 2VI= D domain in the center of the example. If you assumed nodes A&B in the exam= ple were L2VPN PEs, the tagging and the PW tag imposition all happened at t= he same point in the network. If they are not simple P2P all the way to end systems and the objective is = to avoid bridging between leaf "sites" but allowing intra-leaf-site connect= ivity then the leaves can be LANs but the root is not, such that I cannot b= ridge through the root. But all hosts at a given leaf site can see each oth= er. So root Ethernet end systems are directly attached or two VIDs are used= in the root site. If the objective is that there are multiple ethernet attached end stations = at both the leaf and root sites, and the objective is to enforce L2 isolati= on everywhere then I need two VIDs extended to the end system attachement p= oint in the local LANs by whatever means.... And I do not see adding VLANs in any particular spot, simply selection of t= he VID and associated semantics where VIDs are translated. The actual point= of S-tag imposition could be a PE, or cloud be a NID/CLE on the customer p= rem (more likely scenario here to extend OAM demarc to the prem), or some s= witch in a RAN downstream of the MPLS PE... blah blah blah. And if ETREE is= extended into a customer site LAN and outside of the provider domain, then= two C-tags would have to be used that mapped to S-tags at the PBN boundary= ... Make sense? Dave -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Wednesday, April 25, 2012 4:39 PM To: David Allan I; l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Dave, but the ACs are root/leaf (that's what the whole vpls etree is about = - see the reqt draft), so per the 2vlan draft the root/leaf vlan must be ad= ded. Thumb typed - please be tolerant David Allan I wrote: HI Daniel: In the example provided, "ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" A B the service is not ETREE in the domains of the ingress and egress VID. It i= s ELAN. SO there is no root/leaf attribute to shovel around. It would requi= re two VIDs in each domain if the ETREE semantics were to be telescoped E2E= . Otherwise it is a provisioning of the VID translation tables at the interme= diate nodes (A&B that I've added to the picture) that would determine the V= ID values used in each domain. Or in the example above, what the ingress, E= tree and egress VID values were. Cheers Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Wednesday, April 25, 2012 3:46 PM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? And to this I asked how this mapping works - how does the egress pe recover= the ingress vid when it gets the frame tagged with only the root/leaf vid?= How can you convey the ingress vid plus the root/leaf attribute in the sam= e number of bits? What am I missing? Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, David Allen already explained the solution. >From David: ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. Ingress VID does not have to equal Egress VID but regardless there is only = ever one VID on a frame at a time. -end This works when customer makes ingress VLAN ID not equal to or equal to egr= ess VLAN ID. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Wednesday, April 25, 2012 11:39 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi Lucy, The scenario we are discussing is not the E-Tree E-NNI, but a general scena= rio where frames arriving at the root or leaf AC are already double tagged= . In this case, the dual vlan solution cannot preserve the vlans without ad= ding a third one, can it? Maybe Shahram can add details on the scenario he had in mind Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has S-VLAN preservation attribute for ENNI only because there is no s-v= lan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN preser= vation attribute is used. It applies to E-Tree as well. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Tuesday, April 24, 2012 2:12 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, even if the current MEF framework doesn't require s-vlan preservation, I be= lieve it's to the industry's benefit to adopt a solution that is not constr= ained to a specific enni model that, like all things networking, is likely = to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service provider= s' inputs. It had a fair reason to assume S-VLAN over ENNI by then. It may = open B-VLAN for the future. It is better for us not to discuss a future fr= amework here, because it will lead us to nowhere. Here, we want to extend V= PLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Va= inshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume tha= t the VLAN tags at the E-NNI will always be according to the current MEF mo= del? Or should we try to be as transparent as possible to user VLAN encapsu= lation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case VLAN t= ag) to signal VPLS information (in this case root/leaf origin) is necessari= ly tied to specific assumptions on user payload encapsulation (in this case= , that S-VLAN tag is "available" to encode root/leaf). I don't think this i= s a future-proof assumption, it's very likely that other network models wil= l come up that require S-VLAN preservation, which in the 2-VLAN approach wo= uld necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, "l2vpn@i= etf.org" >, "A= lexander.Vainshtein@ecitele.com" <= Alexander.Vainshtein@ecitele.com> Cc: "yuqun.cao@gmail.com" > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic alrea= dy has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com= Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L i= nformation, customer payload or PW? The customer payload will be always mod= ified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is access= ed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informati= on? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > com>> > To: "Rogers, Josh" >, Lucy yong > >, Daniel Cohn <= DanielC@orckit.com>, Sam Cao > > > Cc: "l2vpn@ietf.org" > > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, = but: > > IMO one of the advantages of the CW-based solution is that it is orthogon= al to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffi= c. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and,= in a more generic way, localization of effects of changes in the PE config= uration. > > In particular, adding a Leaf AC to a PE that previously has been only sup= porting Root ACs (or vice versa), removal of the last Leaf or last Root AC = from a PE that previously has been supporting a mix etc. affect only the PE= where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadva= ntage of the CW-based approach - I believe it strongly depends on specific = implementations. And some changes in the forwarding process are required in= any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org > [l2vpn-bounces@ietf.org] on behalf of > Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a > more complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become > more complex. > > Gile's comparison slide still concisely captures the differences > between these methods, in my opinion. I haven't seen any new ideas or > thoughts brought to the group in the past week or two on the subject. > I would hate for both proposed methods to die on the vine because we > couldn't decide between two methods that have nothing inherently wrong wi= th either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree >>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may >>double all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn >>[mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the >>processing in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >>PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW >>(for traffic coming from a root AC) [[LY]] Not that simple. You >>construct either two P2MP PWs to all other PEs and let egress PE >>performing filtering, or construct one P2MP PW to leaf-only PEs and >>two P2MP PWs to root and leaf PEs and let ingress PE perform >>forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so >>don't feel terribly strong about this objection. Is this a real >>problem for others (now or in the future), or is this objection in the we= eds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. >>I encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao >>>[mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>(Wim)'; giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>PE have both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn >>>[mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com>; Sam Cao >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong >>>[mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>both approaches can benefit from it. I was off for a while and >>>captures some discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues >>>with silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >>>am not clear on all the issues. Could you be more specific? As I >>>mentioned in below, two PW approach makes VPLS transport construction >>>and packet forwarding more complex, I can see potential backward >>>compatibility issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>double all of them. >>> >>>E-tree is an Ethernet service and there is already VLAN based >>>solution in IEEE, can we just utilize it without complicating VPLS >>>transport construction? This also makes interworking with Eth only netwo= rk easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh >>>[mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); >>>'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vain= shtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are >>>you saying that you no longer are interested in that method in >>>preference of the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org >>>[mailto:l2vpn-bounces@ietf.org] On >>>Behalf Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron >>>[mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord >>>>; Alexander >>>Vainshtein >>>>>.com>> >>>Cc: l2vpn@ietf.org >>>>; Vladimir Kleiner >>>>; >>>Andrew Sergeev >>>>; Idan >>>Kaspit >; >>>Mishael Wexler >>>>; >>>Rotem Cohen > >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly >>>have put in a third column on the CW approach. And hopefully the >>>minutes will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to >>>be forming around the two alternatives of two PWEs or two VLANs. I >>>believe three of the authors of the CW approach are also authors of >>>the two VLAN approach and one is also an author of the two PWE >>>approach. So perhaps it's best to let those four individuals say >>>which approach they prefer and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of >>>> various solution drafts off the mailing list. As far as I know, no >>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>> meeting. I think the CW approach has not been rejected by the WG >>>> yet, or the WG has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein >>>> >>> le.com>> >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree >>>>> approaches based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/ >>>>> ?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in >>>>> the PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>> I wonder whether the WG has taken a decision to reject the >>>>> approach based on the CW usage? I do not remember any recent >>>>> discussion of this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and >>>>> contains information which is CONFIDENTIAL and which may be >>>>> proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original >>>>> and all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or >>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>intended solely for the use of the individual or entity to which it is a= ddressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail >>>is strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is >>addressed. If you are not the intended recipient of this E-mail, you >>are hereby notified that any dissemination, distribution, copying, or >>action taken in relation to the contents of and attachments to this >>E-mail is strictly prohibited and may be unlawful. If you have >>received this E-mail in error, please notify the sender immediately >>and permanently delete the original and any copy of this E-mail and any p= rintout. > > > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** From david.i.allan@ericsson.com Wed Apr 25 14:34:16 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39EB421E8037 for ; Wed, 25 Apr 2012 14:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 OlyyiUCd8Owd for ; Wed, 25 Apr 2012 14:34:13 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 29F2421E803D for ; Wed, 25 Apr 2012 14:34:13 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3PLYADN032039; Wed, 25 Apr 2012 16:34:11 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.69]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 25 Apr 2012 17:34:05 -0400 From: David Allan I To: "Fedyk, Donald (Don)" , Daniel Cohn , "l2vpn@ietf.org" Date: Wed, 25 Apr 2012 17:34:03 -0400 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IABEiWPQAAFgqVoABMXRAAABv/gYAAAFTgAAAdLw+gAAAf/wAADrR4AAAMRokA== Message-ID: <60C093A41B5E45409A19D42CF7786DFD52324EF036@EUSAACMS0703.eamcs.ericsson.se> References: <172f01cd2323$bdca1c82$05280101@corrigent.com> <60C093A41B5E45409A19D42CF7786DFD52324EEFF1@EUSAACMS0703.eamcs.ericsson.se> 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-BeenThere: l2vpn@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, 25 Apr 2012 21:34:16 -0000 HI Don: As usual you're correct. It would be no different than including a single S= -tag for an ELAN in the PW when subtending PBNs needed to be supported as f= ar as overhead at any point is concerned. IMO NIDs is a good example (esp. for business services) of where this would= be highly desirable as an example of both the art of the possible and a pr= actical deployment scenario... Best Dave -----Original Message----- From: Fedyk, Donald (Don) [mailto:donald.fedyk@alcatel-lucent.com] Sent: Wednesday, April 25, 2012 5:23 PM To: David Allan I; Daniel Cohn; l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Dave Yes the only point I would add is Dual VLAN means One VID for Root and one = VID for Leaf. Not two TAGs at a time on the frame but two allocated for the= service. The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks abo= ut Encapsulation Overhead as a VLAN Tag. While that is true in a PWE sense = it is still a single VLAN Tag at a time in a Ethernet E-tree sense. The co= mpelling driver for Dual VLAN is having a Etree service that works in many = environments and the DUAL VLAN (really dual VLAN interface on a VSI) uses t= he same mechanism (one VID for root and one VID for Leaf at a time) as spec= ified in the IEEE. In a pure Ethernet bridging world the VLAN TAGs for Etre= e are not typically an overhead since translation is used. Don -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= avid Allan I Sent: Wednesday, April 25, 2012 5:05 PM To: Daniel Cohn; l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? OK I feel like I am digressing a fair distance from the actual problem.... = But here goes: So the scenarios center around "how ETREE do you want to be?".... If the ACs are root/leaf, then if they are P2P (single ethernet end station= attached to each AC) this is moot. ETREE semantics are enforced by the 2VI= D domain in the center of the example. If you assumed nodes A&B in the exam= ple were L2VPN PEs, the tagging and the PW tag imposition all happened at t= he same point in the network. If they are not simple P2P all the way to end systems and the objective is = to avoid bridging between leaf "sites" but allowing intra-leaf-site connect= ivity then the leaves can be LANs but the root is not, such that I cannot b= ridge through the root. But all hosts at a given leaf site can see each oth= er. So root Ethernet end systems are directly attached or two VIDs are used= in the root site. If the objective is that there are multiple ethernet attached end stations = at both the leaf and root sites, and the objective is to enforce L2 isolati= on everywhere then I need two VIDs extended to the end system attachement p= oint in the local LANs by whatever means.... And I do not see adding VLANs in any particular spot, simply selection of t= he VID and associated semantics where VIDs are translated. The actual point= of S-tag imposition could be a PE, or cloud be a NID/CLE on the customer p= rem (more likely scenario here to extend OAM demarc to the prem), or some s= witch in a RAN downstream of the MPLS PE... blah blah blah. And if ETREE is= extended into a customer site LAN and outside of the provider domain, then= two C-tags would have to be used that mapped to S-tags at the PBN boundary= ... Make sense? Dave -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Wednesday, April 25, 2012 4:39 PM To: David Allan I; l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Dave, but the ACs are root/leaf (that's what the whole vpls etree is about = - see the reqt draft), so per the 2vlan draft the root/leaf vlan must be ad= ded. Thumb typed - please be tolerant David Allan I wrote: HI Daniel: In the example provided, "ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" A B the service is not ETREE in the domains of the ingress and egress VID. It i= s ELAN. SO there is no root/leaf attribute to shovel around. It would requi= re two VIDs in each domain if the ETREE semantics were to be telescoped E2E= . Otherwise it is a provisioning of the VID translation tables at the interme= diate nodes (A&B that I've added to the picture) that would determine the V= ID values used in each domain. Or in the example above, what the ingress, E= tree and egress VID values were. Cheers Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Wednesday, April 25, 2012 3:46 PM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? And to this I asked how this mapping works - how does the egress pe recover= the ingress vid when it gets the frame tagged with only the root/leaf vid?= How can you convey the ingress vid plus the root/leaf attribute in the sam= e number of bits? What am I missing? Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, David Allen already explained the solution. >From David: ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. Ingress VID does not have to equal Egress VID but regardless there is only = ever one VID on a frame at a time. -end This works when customer makes ingress VLAN ID not equal to or equal to egr= ess VLAN ID. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Wednesday, April 25, 2012 11:39 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi Lucy, The scenario we are discussing is not the E-Tree E-NNI, but a general scena= rio where frames arriving at the root or leaf AC are already double tagged= . In this case, the dual vlan solution cannot preserve the vlans without ad= ding a third one, can it? Maybe Shahram can add details on the scenario he had in mind Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has S-VLAN preservation attribute for ENNI only because there is no s-v= lan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN preser= vation attribute is used. It applies to E-Tree as well. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Tuesday, April 24, 2012 2:12 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, even if the current MEF framework doesn't require s-vlan preservation, I be= lieve it's to the industry's benefit to adopt a solution that is not constr= ained to a specific enni model that, like all things networking, is likely = to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service provider= s' inputs. It had a fair reason to assume S-VLAN over ENNI by then. It may = open B-VLAN for the future. It is better for us not to discuss a future fr= amework here, because it will lead us to nowhere. Here, we want to extend V= PLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Va= inshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume tha= t the VLAN tags at the E-NNI will always be according to the current MEF mo= del? Or should we try to be as transparent as possible to user VLAN encapsu= lation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case VLAN t= ag) to signal VPLS information (in this case root/leaf origin) is necessari= ly tied to specific assumptions on user payload encapsulation (in this case= , that S-VLAN tag is "available" to encode root/leaf). I don't think this i= s a future-proof assumption, it's very likely that other network models wil= l come up that require S-VLAN preservation, which in the 2-VLAN approach wo= uld necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, "l2vpn@i= etf.org" >, "A= lexander.Vainshtein@ecitele.com" <= Alexander.Vainshtein@ecitele.com> Cc: "yuqun.cao@gmail.com" > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic alrea= dy has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com= Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L i= nformation, customer payload or PW? The customer payload will be always mod= ified to carry R/L information in 2-VLAN approach, while PW with CW will ca= rry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is access= ed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to acces= s H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L informati= on? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > com>> > To: "Rogers, Josh" >, Lucy yong > >, Daniel Cohn <= DanielC@orckit.com>, Sam Cao > > > Cc: "l2vpn@ietf.org" > > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, = but: > > IMO one of the advantages of the CW-based solution is that it is orthogon= al to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffi= c. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and,= in a more generic way, localization of effects of changes in the PE config= uration. > > In particular, adding a Leaf AC to a PE that previously has been only sup= porting Root ACs (or vice versa), removal of the last Leaf or last Root AC = from a PE that previously has been supporting a mix etc. affect only the PE= where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadva= ntage of the CW-based approach - I believe it strongly depends on specific = implementations. And some changes in the forwarding process are required in= any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org > [l2vpn-bounces@ietf.org] on behalf of > Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a > more complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become > more complex. > > Gile's comparison slide still concisely captures the differences > between these methods, in my opinion. I haven't seen any new ideas or > thoughts brought to the group in the past week or two on the subject. > I would hate for both proposed methods to die on the vine because we > couldn't decide between two methods that have nothing inherently wrong wi= th either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree >>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may >>double all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn >>[mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the >>processing in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >>PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW >>(for traffic coming from a root AC) [[LY]] Not that simple. You >>construct either two P2MP PWs to all other PEs and let egress PE >>performing filtering, or construct one P2MP PW to leaf-only PEs and >>two P2MP PWs to root and leaf PEs and let ingress PE perform >>forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so >>don't feel terribly strong about this objection. Is this a real >>problem for others (now or in the future), or is this objection in the we= eds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. >>I encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao >>>[mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>(Wim)'; giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>PE have both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn >>>[mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com>; Sam Cao >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong >>>[mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com>>com> >>>Cc: l2vpn@ietf.org; >>>Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; >>>Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; >>>Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>both approaches can benefit from it. I was off for a while and >>>captures some discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues >>>with silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >>>am not clear on all the issues. Could you be more specific? As I >>>mentioned in below, two PW approach makes VPLS transport construction >>>and packet forwarding more complex, I can see potential backward >>>compatibility issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>double all of them. >>> >>>E-tree is an Ethernet service and there is already VLAN based >>>solution in IEEE, can we just utilize it without complicating VPLS >>>transport construction? This also makes interworking with Eth only netwo= rk easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh >>>[mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); >>>'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vain= shtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are >>>you saying that you no longer are interested in that method in >>>preference of the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org >>>[mailto:l2vpn-bounces@ietf.org] On >>>Behalf Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; >>>'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; >>>'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.= Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron >>>[mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord >>>>; Alexander >>>Vainshtein >>>>>.com>> >>>Cc: l2vpn@ietf.org >>>>; Vladimir Kleiner >>>>; >>>Andrew Sergeev >>>>; Idan >>>Kaspit >; >>>Mishael Wexler >>>>; >>>Rotem Cohen > >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly >>>have put in a third column on the CW approach. And hopefully the >>>minutes will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to >>>be forming around the two alternatives of two PWEs or two VLANs. I >>>believe three of the authors of the CW approach are also authors of >>>the two VLAN approach and one is also an author of the two PWE >>>approach. So perhaps it's best to let those four individuals say >>>which approach they prefer and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of >>>> various solution drafts off the mailing list. As far as I know, no >>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>> meeting. I think the CW approach has not been rejected by the WG >>>> yet, or the WG has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein >>>> >>> le.com>> >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree >>>>> approaches based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/ >>>>> ?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in >>>>> the PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?includ >>>>> e_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>> I wonder whether the WG has taken a decision to reject the >>>>> approach based on the CW usage? I do not remember any recent >>>>> discussion of this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and >>>>> contains information which is CONFIDENTIAL and which may be >>>>> proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original >>>>> and all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or >>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>intended solely for the use of the individual or entity to which it is a= ddressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail >>>is strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is >>addressed. If you are not the intended recipient of this E-mail, you >>are hereby notified that any dissemination, distribution, copying, or >>action taken in relation to the contents of and attachments to this >>E-mail is strictly prohibited and may be unlawful. If you have >>received this E-mail in error, please notify the sender immediately >>and permanently delete the original and any copy of this E-mail and any p= rintout. > > > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** From josh.rogers@twcable.com Wed Apr 25 14:42:03 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BD521E803D for ; Wed, 25 Apr 2012 14:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.624 X-Spam-Level: X-Spam-Status: No, score=-0.624 tagged_above=-999 required=5 tests=[AWL=0.838, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ob1wB062hn0H for ; Wed, 25 Apr 2012 14:42:01 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 4107E21E803C for ; Wed, 25 Apr 2012 14:42:01 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,483,1330923600"; d="scan'208";a="372693849" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 25 Apr 2012 17:41:01 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Wed, 25 Apr 2012 17:42:00 -0400 From: "Rogers, Josh" To: "Fedyk, Donald (Don)" , David Allan I , Daniel Cohn , "l2vpn@ietf.org" Date: Wed, 25 Apr 2012 17:41:43 -0400 Subject: Re: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0jLD6CAA4PtR5CQl2PWO4NCk/iWA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: l2vpn@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, 25 Apr 2012 21:42:03 -0000 Dave/Daniel/Lucy/Others Debating how many tags necessary when S-Tag preservation is desired, I think you all may have gone off on a tangent here. The original discussion was about how to deal with the situation where the S-Tag is preserved at a handoff (either an ENNI, or Service Multiplexed UNI) I believe there were two suggestions, one was that you push on a 'ETREE' tag (one of two values, for either a frame sourced from a root AC or another for a frame from a leaf AC), and the second solution was to 'map'. Imagine the following topology: +-----+ +-----+ +-----+ +-----+ | CE1 |--| PE1 |--| PE2 |--| CE2 | +-----+ +-----+ +-----+ +-----+ | | +-----+ +-----+ +-----+ +-----+ | CE3 |--| PE3 |--| PE4 |--| CE4 | +-----+ +-----+ +-----+ +-----+ Where: Site Type VLAN CE1 Root X CE2 Leaf 2 CE3 Leaf 3 CE4 Leaf 3 So, there are a lot of SP's who are keen on the way many services can be handed to a customer on a single UNI, but coordinating a single VLAN per service, with the customer (MEF used to call this EVPL when it was many point to point services terminating on a single UNI). So, imagine that we have two ETREE instances, and an internet service all terminating on a single UNI connecting to CE1. We have negotiated VLAN ID's with the customer, and they are expecting to reach CE2 using VLAN 2, CE3 and CE4 using VLAN 3, and Internet service on VLAN 10. As a frame from CE1 comes into PE1 destined for CE2 (so the customer has tagged it with VID 2), using the 2VLAN method, since this is coming from a root site, do we a) place the Root S-Tag in front of VID 2, then ship it across, and pop off the ETREE S-Tag (some SP's wish to Pop the original customer tag VID 2 as well) -or- b) swap VID2 for the ETREE Root S-Tag, send the frame to PE2 where it will remove the S-Tag (and either push VID2 back on, or leave it off depending on SP preference) The reference to 'double tagging' was talking about solution A above, since there is both the service VID that is coordinated with the customer, as well as the Etree VID which designates the source (root or leaf) Hope that clears more than it confuses, Josh On 4/25/12 4:22 PM, "Fedyk, Donald (Don)" wrote: >Hi Dave > >Yes the only point I would add is Dual VLAN means One VID for Root and >one VID for Leaf. Not two TAGs at a time on the frame but two allocated >for the service. > >The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks >about Encapsulation Overhead as a VLAN Tag. While that is true in a PWE >sense it is still a single VLAN Tag at a time in a Ethernet E-tree sense. > The compelling driver for Dual VLAN is having a Etree service that works >in many environments and the DUAL VLAN (really dual VLAN interface on a >VSI) uses the same mechanism (one VID for root and one VID for Leaf at a >time) as specified in the IEEE. In a pure Ethernet bridging world the >VLAN TAGs for Etree are not typically an overhead since translation is >used. > >Don > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >David Allan I >Sent: Wednesday, April 25, 2012 5:05 PM >To: Daniel Cohn; l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >OK I feel like I am digressing a fair distance from the actual >problem.... But here goes: > >So the scenarios center around "how ETREE do you want to be?".... > >If the ACs are root/leaf, then if they are P2P (single ethernet end >station attached to each AC) this is moot. ETREE semantics are enforced >by the 2VID domain in the center of the example. If you assumed nodes A&B >in the example were L2VPN PEs, the tagging and the PW tag imposition all >happened at the same point in the network. > >If they are not simple P2P all the way to end systems and the objective >is to avoid bridging between leaf "sites" but allowing intra-leaf-site >connectivity then the leaves can be LANs but the root is not, such that I >cannot bridge through the root. But all hosts at a given leaf site can >see each other. So root Ethernet end systems are directly attached or two >VIDs are used in the root site. > >If the objective is that there are multiple ethernet attached end >stations at both the leaf and root sites, and the objective is to enforce >L2 isolation everywhere then I need two VIDs extended to the end system >attachement point in the local LANs by whatever means.... > >And I do not see adding VLANs in any particular spot, simply selection of >the VID and associated semantics where VIDs are translated. The actual >point of S-tag imposition could be a PE, or cloud be a NID/CLE on the >customer prem (more likely scenario here to extend OAM demarc to the >prem), or some switch in a RAN downstream of the MPLS PE... blah blah >blah. And if ETREE is extended into a customer site LAN and outside of >the provider domain, then two C-tags would have to be used that mapped to >S-tags at the PBN boundary... > >Make sense? >Dave > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, April 25, 2012 4:39 PM >To: David Allan I; l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >Dave, but the ACs are root/leaf (that's what the whole vpls etree is >about - see the reqt draft), so per the 2vlan draft the root/leaf vlan >must be added. > >Thumb typed - please be tolerant > >David Allan I wrote: > >HI Daniel: > >In the example provided, > >"ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" > A B > >the service is not ETREE in the domains of the ingress and egress VID. It >is ELAN. SO there is no root/leaf attribute to shovel around. It would >require two VIDs in each domain if the ETREE semantics were to be >telescoped E2E. > >Otherwise it is a provisioning of the VID translation tables at the >intermediate nodes (A&B that I've added to the picture) that would >determine the VID values used in each domain. Or in the example above, >what the ingress, Etree and egress VID values were. > >Cheers >Dave > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Daniel Cohn >Sent: Wednesday, April 25, 2012 3:46 PM >To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >Alexander.Vainshtein@ecitele.com >Cc: yuqun.cao@gmail.com >Subject: RE: The status of the approaches to the E-Tree solution? > >And to this I asked how this mapping works - how does the egress pe >recover the ingress vid when it gets the frame tagged with only the >root/leaf vid? How can you convey the ingress vid plus the root/leaf >attribute in the same number of bits? >What am I missing? > >Daniel > >Thumb typed - please be tolerant > >Lucy yong wrote: > >Daniel, > >David Allen already explained the solution. > >From David: >ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. > >Ingress VID does not have to equal Egress VID but regardless there is >only ever one VID on a frame at a time. > >-end > >This works when customer makes ingress VLAN ID not equal to or equal to >egress VLAN ID. > >Regards, >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Daniel Cohn >Sent: Wednesday, April 25, 2012 11:39 AM >To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >Alexander.Vainshtein@ecitele.com >Cc: yuqun.cao@gmail.com >Subject: RE: The status of the approaches to the E-Tree solution? > >Hi Lucy, > >The scenario we are discussing is not the E-Tree E-NNI, but a general >scenario where frames arriving at the root or leaf AC are already double >tagged. In this case, the dual vlan solution cannot preserve the vlans >without adding a third one, can it? > >Maybe Shahram can add details on the scenario he had in mind > >Thumb typed - please be tolerant > >Lucy yong wrote: > >Daniel, > >MEF has S-VLAN preservation attribute for ENNI only because there is no >s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN >preservation attribute is used. It applies to E-Tree as well. > >Regards, >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Daniel Cohn >Sent: Tuesday, April 24, 2012 2:12 AM >To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >Alexander.Vainshtein@ecitele.com >Cc: yuqun.cao@gmail.com >Subject: RE: The status of the approaches to the E-Tree solution? > >Lucy, > >even if the current MEF framework doesn't require s-vlan preservation, I >believe it's to the industry's benefit to adopt a solution that is not >constrained to a specific enni model that, like all things networking, is >likely to evolve. Especially when such a solution is available. > >Daniel > >Thumb typed - please be tolerant > >Lucy yong wrote: > >Daniel, > >MEF has worked in ENNI interface for a long time with many service >providers' inputs. It had a fair reason to assume S-VLAN over ENNI by >then. It may open B-VLAN for the future. It is better for us not to >discuss a future framework here, because it will lead us to nowhere. >Here, we want to extend VPLS in supporting E-Tree. > >Best Regards, >Lucy > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Daniel Cohn >Sent: Sunday, April 22, 2012 7:34 AM >To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >Alexander.Vainshtein@ecitele.com >Cc: yuqun.cao@gmail.com >Subject: RE: The status of the approaches to the E-Tree solution? > >Shahram and all, > >This question already came up in our discussions - is it safe to assume >that the VLAN tags at the E-NNI will always be according to the current >MEF model? Or should we try to be as transparent as possible to user VLAN >encapsulation at the E-NNI, to accommodate future frameworks? >I believe that any approach that looks at user payload (in this case VLAN >tag) to signal VPLS information (in this case root/leaf origin) is >necessarily tied to specific assumptions on user payload encapsulation >(in this case, that S-VLAN tag is "available" to encode root/leaf). I >don't think this is a future-proof assumption, it's very likely that >other network models will come up that require S-VLAN preservation, which >in the 2-VLAN approach would necessitate adding a third VLAN-ID. > >Daniel > >From: Shahram Davari > >To: Lizhong Jin >, >"l2vpn@ietf.org" >>, >"Alexander.Vainshtein@ecitele.com >" > >> >Cc: "yuqun.cao@gmail.com" >> >Subject: RE: The status of the approaches to the E-Tree solution? > >Hi, > >I also have a question regarding 2-VLAN. What if the customer traffic >already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? > >Thx >Shahram > >From: l2vpn-bounces@ietf.org >[mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin >Sent: Friday, April 20, 2012 9:38 AM >To: l2vpn@ietf.org; >Alexander.Vainshtein@ecitele.com >Cc: yuqun.cao@gmail.com >Subject: RE: The status of the approaches to the E-Tree solution? > >Hi, all, >The difference between 2-VLAN and CW approach is who will provide the R/L >information, customer payload or PW? The customer payload will be always >modified to carry R/L information in 2-VLAN approach, while PW with CW >will carry R/L information for CW approach. >I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is >accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used >to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L >information? > >Thanks >Lizhong > >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 Apr 2012 04:38:36 +0000 >> From: Alexander Vainshtein >> > com>> >> To: "Rogers, Josh" >>>, Lucy yong >> >, Daniel Cohn >>>, Sam Cao >> > >> Cc: "l2vpn@ietf.org" >> > >> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID: >> >> > o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi all, >> I fully understand that that what I am going to say is not very >>popular, but: >> >> IMO one of the advantages of the CW-based solution is that it is >>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of >>BUN traffic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>and, in a more generic way, localization of effects of changes in the PE >>configuration. >> >> In particular, adding a Leaf AC to a PE that previously has been only >>supporting Root ACs (or vice versa), removal of the last Leaf or last >>Root AC from a PE that previously has been supporting a mix etc. affect >>only the PE where this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main >>disadvantage of the CW-based approach - I believe it strongly depends on >>specific implementations. And some changes in the forwarding process are >>required in any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org >> [l2vpn-bounces@ietf.org] on behalf of >> Rogers, Josh [josh.rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a >> more complex model. Wether outside s-tag is used to differentiate, or >> dedicated pw's are used for the same purpose, it seems both become >> more complex. >> >> Gile's comparison slide still concisely captures the differences >> between these methods, in my opinion. I haven't seen any new ideas or >> thoughts brought to the group in the past week or two on the subject. >> I would hate for both proposed methods to die on the vine because we >> couldn't decide between two methods that have nothing inherently wrong >>with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" >>> wrote: >> >>>Send this again. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>double all of them. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: Daniel Cohn >>>[mailto:DanielC@orckit.com] >>>Sent: Wednesday, April 18, 2012 1:42 PM >>>To: Lucy yong; Rogers, Josh; Sam Cao >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I think the first option its the natural way to go. How is the >>>processing in this case more complex? >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>> >>> >>>Snipped.. >>> >>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >>>PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW >>>(for traffic coming from a root AC) [[LY]] Not that simple. You >>>construct either two P2MP PWs to all other PEs and let egress PE >>>performing filtering, or construct one P2MP PW to leaf-only PEs and >>>two P2MP PWs to root and leaf PEs and let ingress PE perform >>>forwarding and filtering. Both make node process complex. >>> >>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>>delivering the frames to remote PEs. We should utilize them with the >>>minimized changes. Dual VLAN solution is simpler than Dual PW. >>> >>>Regards, >>>Lucy >>> >>> >>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>>haven't had any first hand experience with P2MP PW's, however, so >>>don't feel terribly strong about this objection. Is this a real >>>problem for others (now or in the future), or is this objection in the >>>weeds? >>> >>>I'm not sure the 'additional complexity' is notable, or even relevant. >>>I encourage others to speak up if they disagree, as P2MP PW is only >>>conceptual to me, and I am unfamiliar with real-life use cases for it. >>> >>>Thanks, >>>Josh >>> >>> >>> >>>On 4/18/12 10:30 AM, "Lucy yong" >>>> wrote: >>> >>>>Please see inline. >>>> >>>>-----Original Message----- >>>>From: Sam Cao >>>>[mailto:yuqun.cao@gmail.com] >>>>Sent: Tuesday, April 17, 2012 7:14 AM >>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>>(Wim)'; giles.heron@gmail.com; >>>>simon.delord@gmail.com; >>>>Alexander.Vainshtein@ecitele.com>>>com> >>>>Cc: l2vpn@ietf.org; >>>>Vladimir.Kleiner@ecitele.com; >>>>Andrew.Sergeev@ecitele.com; >>>>Idan.Kaspit@ecitele.com; >>>>Mishael.Wexler@ecitele.com; >>>>Rotem.Cohen@ecitele.com >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>>> >>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>>PE have both root and leaf AC and some only have leaf ACs)? >>>>Regards, >>>>Lucy >>>> >>>>Regards, >>>> >>>>Yuqun (Sam) Cao >>>>E-mail: Yuqun.cao@gmail.com >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn >>>>[mailto:DanielC@orckit.com] >>>>Sent: Tuesday, April 17, 2012 4:56 PM >>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>>giles.heron@gmail.com; >>>>simon.delord@gmail.com; >>>>Alexander.Vainshtein@ecitele.com>>>com>; Sam Cao >>>>Cc: l2vpn@ietf.org; >>>>Vladimir.Kleiner@ecitele.com; >>>>Andrew.Sergeev@ecitele.com; >>>>Idan.Kaspit@ecitele.com; >>>>Mishael.Wexler@ecitele.com; >>>>Rotem.Cohen@ecitele.com >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Adding Sam (as l2vpn@ is holding messages) >>>> >>>>DC >>>> >>>>-----Original Message----- >>>>From: Lucy yong >>>>[mailto:lucy.yong@huawei.com] >>>>Sent: Tuesday, April 17, 2012 12:39 AM >>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>>giles.heron@gmail.com; >>>>simon.delord@gmail.com; >>>>Alexander.Vainshtein@ecitele.com>>>com> >>>>Cc: l2vpn@ietf.org; >>>>Vladimir.Kleiner@ecitele.com; >>>>Andrew.Sergeev@ecitele.com; >>>>Idan.Kaspit@ecitele.com; >>>>Mishael.Wexler@ecitele.com; >>>>Rotem.Cohen@ecitele.com >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>> >>>>Snipped, >>>> >>>>As we discussed extensively in the list, and as reflected in giles >>>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>>which will typically be a small minority. >>>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>>both approaches can benefit from it. I was off for a while and >>>>captures some discussions now. >>>> >>>>Also as per giles slide, dual vlan can have scalability issues due to >>>>additional lookup and double use of vlans in internal emulated lan >>>>interface. Also there are potential backward compatibility issues >>>>with silicon that doesn't support vlan mapping. >>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >>>>am not clear on all the issues. Could you be more specific? As I >>>>mentioned in below, two PW approach makes VPLS transport construction >>>>and packet forwarding more complex, I can see potential backward >>>>compatibility issues with 2 PW solution. >>>> >>>>Regards, >>>>Lucy >>>> >>>>Regards, >>>> >>>>Daniel >>>> >>>>Thumb typed - please be tolerant >>>> >>>>Lucy yong > wrote: >>>> >>>>In my mind, the VLAN approach means dual vlan method. >>>> >>>>The main concern for CW approach is hardware support. >>>> >>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>>double all of them. >>>> >>>>E-tree is an Ethernet service and there is already VLAN based >>>>solution in IEEE, can we just utilize it without complicating VPLS >>>>transport construction? This also makes interworking with Eth only >>>>network easier. >>>> >>>>Cheers, >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: Rogers, Josh >>>>[mailto:josh.rogers@twcable.com] >>>>Sent: Monday, April 16, 2012 8:35 AM >>>>To: Lucy yong; Henderickx, Wim (Wim); >>>>'giles.heron@gmail.com'; >>>>'simon.delord@gmail.com'; >>>>'Alexander.Vainshtein@ecitele.com>>>om>' >>>>Cc: 'l2vpn@ietf.org'; >>>>'Vladimir.Kleiner@ecitele.com'; >>>>'Andrew.Sergeev@ecitele.com'; >>>>'Idan.Kaspit@ecitele.com'; >>>>'Mishael.Wexler@ecitele.com'; >>>>'Rotem.Cohen@ecitele.com' >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>I believe the initial question was in regard to the CW method. Are >>>>you saying that you no longer are interested in that method in >>>>preference of the dual vlan method? >>>> >>>> >>>> >>>>Lucy yong > wrote: >>>> >>>> >>>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>>> >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: l2vpn-bounces@ietf.org >>>>[mailto:l2vpn-bounces@ietf.org] On >>>>Behalf Of Henderickx, Wim (Wim) >>>>Sent: Thursday, April 12, 2012 2:03 AM >>>>To: 'giles.heron@gmail.com'; >>>>'simon.delord@gmail.com'; >>>>'Alexander.Vainshtein@ecitele.com>>>om>' >>>>Cc: 'l2vpn@ietf.org'; >>>>'Vladimir.Kleiner@ecitele.com'; >>>>'Andrew.Sergeev@ecitele.com'; >>>>'Idan.Kaspit@ecitele.com'; >>>>'Mishael.Wexler@ecitele.com'; >>>>'Rotem.Cohen@ecitele.com' >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>The vlan approach is superior as it also works for eth only networks, >>>>etc. On top some vendors indicate hw issues with the cw approach. As >>>>such we have dropped more or less the cw approach. >>>> >>>>Cheers, >>>>Wim >>>>_________________ >>>>sent from blackberry >>>> >>>>----- Original Message ----- >>>>From: Giles Heron >>>>[mailto:giles.heron@gmail.com] >>>>Sent: Thursday, April 12, 2012 08:22 AM >>>>To: Simon Delord >>>>>; Alexander >>>>Vainshtein >>>>>>>.com>> >>>>Cc: l2vpn@ietf.org >>>>>; Vladimir Kleiner >>>>>; >>>>Andrew Sergeev >>>>>; Idan >>>>Kaspit >; >>>>Mishael Wexler >>>>>; >>>>Rotem Cohen > >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>Sorry - the "anonymous presentation" was mine. I should possibly >>>>have put in a third column on the CW approach. And hopefully the >>>>minutes will be posted soon. >>>> >>>>We had various discussions, as Simon stated, and consensus seemed to >>>>be forming around the two alternatives of two PWEs or two VLANs. I >>>>believe three of the authors of the CW approach are also authors of >>>>the two VLAN approach and one is also an author of the two PWE >>>>approach. So perhaps it's best to let those four individuals say >>>>which approach they prefer and why? >>>> >>>>Giles >>>> >>>>On 10/04/2012 00:45, "Simon Delord" >>>>> wrote: >>>> >>>>> Hi Alexander, >>>>> >>>>> You are right, no discussion on the WG mailing list recently, but >>>>> there have been substantial discussions among the authors of >>>>> various solution drafts off the mailing list. As far as I know, no >>>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>>> meeting. I think the CW approach has not been rejected by the WG >>>>> yet, or the WG has not yet decided on which one to adopt. >>>>> >>>>> Simon >>>>> >>>>> 2012/4/8 Alexander Vainshtein >>>>> >>>> le.com>> >>>>> >>>>>> Hi all, >>>>>> >>>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>>> >>>>>> However, looking up the L2VPN proceedings, I've found a short >>>>>> anonymous presentation called "E-Tree Update" ( >>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>>> This presentation discusses the differences of the E-Tree >>>>>> approaches based on dedicated VLANs (as in >>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?includ >>>>>> e_t >>>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/ >>>>>> ?in >>>>>> clude_te >>>>>> xt=3D1) >>>>>> and completely ignores the solution based on usage of the CW in >>>>>> the PWs connecting the PEs (as in >>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?includ >>>>>> e_t >>>>>> ext=3D1 >>>>>> ). >>>>>> >>>>>> >>>>>> >>>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>>> I wonder whether the WG has taken a decision to reject the >>>>>> approach based on the CW usage? I do not remember any recent >>>>>> discussion of this topic on the WG mailing list. >>>>>> >>>>>> >>>>>> >>>>>> Regards, and lots of thanks in advance, >>>>>> >>>>>> Sasha >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> This e-mail message is intended for the recipient only and >>>>>> contains information which is CONFIDENTIAL and which may be >>>>>> proprietary to ECI >>>> >>>>>> Telecom. If you have received this transmission in error, please >>>>>> inform us by e-mail, phone or fax, and then delete the original >>>>>> and all copies thereof. >>>>>> >>>> >>>> >>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or >>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>intended solely for the use of the individual or entity to which it is >>>>addressed. >>>>If you are not the intended recipient of this E-mail, you are hereby >>>>notified that any dissemination, distribution, copying, or action >>>>taken in relation to the contents of and attachments to this E-mail >>>>is strictly prohibited and may be unlawful. If you have received this >>>>E-mail in error, please notify the sender immediately and permanently >>>>delete the original and any copy of this E-mail and any printout. >>>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is >>>addressed. If you are not the intended recipient of this E-mail, you >>>are hereby notified that any dissemination, distribution, copying, or >>>action taken in relation to the contents of and attachments to this >>>E-mail is strictly prohibited and may be unlawful. If you have >>>received this E-mail in error, please notify the sender immediately >>>and permanently delete the original and any copy of this E-mail and any >>>printout. >> >> >> This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is addressed. >>If you are not the intended recipient of this E-mail, you are hereby >>notified that any dissemination, distribution, copying, or action taken >>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this >>E-mail in error, please notify the sender immediately and permanently >>delete the original and any copy of this E-mail and any printout. >> This e-mail message is intended for the recipient only and contains >>information which is CONFIDENTIAL and which may be proprietary to ECI >>Telecom. If you have received this transmission in error, please inform >>us by e-mail, phone or fax, and then delete the original and all copies >>thereof. >> >> >> >> ------------------------------ >> >> _______________________________________________ >> L2vpn mailing list >> L2vpn@ietf.org >> https://www.ietf.org/mailman/listinfo/l2vpn >> >> >> End of L2vpn Digest, Vol 95, Issue 25 >> *********************************** This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From david.i.allan@ericsson.com Wed Apr 25 15:19:20 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE8C11E80A2 for ; Wed, 25 Apr 2012 15:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 pOC9ASSn6TYh for ; Wed, 25 Apr 2012 15:19:18 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id A420011E80A1 for ; Wed, 25 Apr 2012 15:19:17 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3PMJEfS007478; Wed, 25 Apr 2012 17:19:16 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.69]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 25 Apr 2012 18:19:09 -0400 From: David Allan I To: "Rogers, Josh" , "Fedyk, Donald (Don)" , Daniel Cohn , "l2vpn@ietf.org" Date: Wed, 25 Apr 2012 18:19:07 -0400 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0jLD6CAA4PtR5CQl2PWO4NCk/iWAAAEL7A Message-ID: <60C093A41B5E45409A19D42CF7786DFD52324EF0A6@EUSAACMS0703.eamcs.ericsson.se> References: 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-BeenThere: l2vpn@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, 25 Apr 2012 22:19:20 -0000 Yes, if the discussion was options on preserving CUSTOMER tag information, = we did march off on a tangent. Now I hate to be pedantic but when you wrote: "The reference to 'double tagging' was talking about solution A above, sinc= e there is both the service VID that is coordinated with the customer, as w= ell as the Etree VID which designates the source (root or leaf)" I presume you meant "the customer VID is coordinated with the provider", "N= ot the service VID that is coordinated with the customer". The customer tag= infers the ETREE instance for a VID based UNI. And the customer does not n= eed to know the provider ETREE VIDs....the provider needs to know what tags= the customer wants mapped to specific provider services.... Cheers Dave -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Wednesday, April 25, 2012 5:42 PM To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Dave/Daniel/Lucy/Others Debating how many tags necessary when S-Tag preserv= ation is desired, I think you all may have gone off on a tangent here. The original discussi= on was about how to deal with the situation where the S-Tag is preserved at= a handoff (either an ENNI, or Service Multiplexed UNI) I believe there were two suggestions, one was that you push on a 'ETREE' tag (one of two values, for either a frame sourced from a root AC or anothe= r for a frame from a leaf AC), and the second solution was to 'map'. Imagine the following topology: +-----+ +-----+ +-----+ +-----+ | CE1 |--| PE1 |--| PE2 |--| CE2 | +-----+ +-----+ +-----+ +-----+ | | +-----+ +-----+ +-----+ +-----+ | CE3 |--| PE3 |--| PE4 |--| CE4 | +-----+ +-----+ +-----+ +-----+ Where: Site Type VLAN CE1 Root X CE2 Leaf 2 CE3 Leaf 3 CE4 Leaf 3 So, there are a lot of SP's who are keen on the way many services can be ha= nded to a customer on a single UNI, but coordinating a single VLAN per serv= ice, with the customer (MEF used to call this EVPL when it was many point t= o point services terminating on a single UNI). So, imagine that we have tw= o ETREE instances, and an internet service all terminating on a single UNI = connecting to CE1. We have negotiated VLAN ID's with the customer, and the= y are expecting to reach CE2 using VLAN 2, CE3 and CE4 using VLAN 3, and In= ternet service on VLAN 10. As a frame from CE1 comes into PE1 destined for= CE2 (so the customer has tagged it with VID 2), using the 2VLAN method, si= nce this is coming from a root site, do we a) place the Root S-Tag in front of VID 2, then ship it across, and pop off= the ETREE S-Tag (some SP's wish to Pop the original customer tag VID 2 as = well) -or- b) swap VID2 for the ETREE Root S-Tag, send the frame to PE2 where it will = remove the S-Tag (and either push VID2 back on, or leave it off depending o= n SP preference) The reference to 'double tagging' was talking about solution A above, since= there is both the service VID that is coordinated with the customer, as we= ll as the Etree VID which designates the source (root or leaf) Hope that clears more than it confuses, Josh On 4/25/12 4:22 PM, "Fedyk, Donald (Don)" wrote: >Hi Dave > >Yes the only point I would add is Dual VLAN means One VID for Root and >one VID for Leaf. Not two TAGs at a time on the frame but two allocated >for the service. > >The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks >about Encapsulation Overhead as a VLAN Tag. While that is true in a PWE >sense it is still a single VLAN Tag at a time in a Ethernet E-tree sense. > The compelling driver for Dual VLAN is having a Etree service that >works in many environments and the DUAL VLAN (really dual VLAN >interface on a >VSI) uses the same mechanism (one VID for root and one VID for Leaf at >a >time) as specified in the IEEE. In a pure Ethernet bridging world the >VLAN TAGs for Etree are not typically an overhead since translation is >used. > >Don > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >Of David Allan I >Sent: Wednesday, April 25, 2012 5:05 PM >To: Daniel Cohn; l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >OK I feel like I am digressing a fair distance from the actual >problem.... But here goes: > >So the scenarios center around "how ETREE do you want to be?".... > >If the ACs are root/leaf, then if they are P2P (single ethernet end >station attached to each AC) this is moot. ETREE semantics are enforced >by the 2VID domain in the center of the example. If you assumed nodes >A&B in the example were L2VPN PEs, the tagging and the PW tag >imposition all happened at the same point in the network. > >If they are not simple P2P all the way to end systems and the objective >is to avoid bridging between leaf "sites" but allowing intra-leaf-site >connectivity then the leaves can be LANs but the root is not, such that >I cannot bridge through the root. But all hosts at a given leaf site >can see each other. So root Ethernet end systems are directly attached >or two VIDs are used in the root site. > >If the objective is that there are multiple ethernet attached end >stations at both the leaf and root sites, and the objective is to >enforce >L2 isolation everywhere then I need two VIDs extended to the end system >attachement point in the local LANs by whatever means.... > >And I do not see adding VLANs in any particular spot, simply selection >of the VID and associated semantics where VIDs are translated. The >actual point of S-tag imposition could be a PE, or cloud be a NID/CLE >on the customer prem (more likely scenario here to extend OAM demarc to >the prem), or some switch in a RAN downstream of the MPLS PE... blah >blah blah. And if ETREE is extended into a customer site LAN and >outside of the provider domain, then two C-tags would have to be used >that mapped to S-tags at the PBN boundary... > >Make sense? >Dave > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, April 25, 2012 4:39 PM >To: David Allan I; l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >Dave, but the ACs are root/leaf (that's what the whole vpls etree is >about - see the reqt draft), so per the 2vlan draft the root/leaf vlan >must be added. > >Thumb typed - please be tolerant > >David Allan I wrote: > >HI Daniel: > >In the example provided, > >"ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" > A B > >the service is not ETREE in the domains of the ingress and egress VID. >It is ELAN. SO there is no root/leaf attribute to shovel around. It >would require two VIDs in each domain if the ETREE semantics were to be >telescoped E2E. > >Otherwise it is a provisioning of the VID translation tables at the >intermediate nodes (A&B that I've added to the picture) that would >determine the VID values used in each domain. Or in the example above, >what the ingress, Etree and egress VID values were. > >Cheers >Dave > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >Of Daniel Cohn >Sent: Wednesday, April 25, 2012 3:46 PM >To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >Cc: yuqun.cao@gmail.com >Subject: RE: The status of the approaches to the E-Tree solution? > >And to this I asked how this mapping works - how does the egress pe >recover the ingress vid when it gets the frame tagged with only the >root/leaf vid? How can you convey the ingress vid plus the root/leaf >attribute in the same number of bits? >What am I missing? > >Daniel > >Thumb typed - please be tolerant > >Lucy yong wrote: > >Daniel, > >David Allen already explained the solution. > >From David: >ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. > >Ingress VID does not have to equal Egress VID but regardless there is >only ever one VID on a frame at a time. > >-end > >This works when customer makes ingress VLAN ID not equal to or equal to >egress VLAN ID. > >Regards, >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >Of Daniel Cohn >Sent: Wednesday, April 25, 2012 11:39 AM >To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >Cc: yuqun.cao@gmail.com >Subject: RE: The status of the approaches to the E-Tree solution? > >Hi Lucy, > >The scenario we are discussing is not the E-Tree E-NNI, but a general >scenario where frames arriving at the root or leaf AC are already >double tagged. In this case, the dual vlan solution cannot preserve the >vlans without adding a third one, can it? > >Maybe Shahram can add details on the scenario he had in mind > >Thumb typed - please be tolerant > >Lucy yong wrote: > >Daniel, > >MEF has S-VLAN preservation attribute for ENNI only because there is no >s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN >preservation attribute is used. It applies to E-Tree as well. > >Regards, >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >Of Daniel Cohn >Sent: Tuesday, April 24, 2012 2:12 AM >To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >Cc: yuqun.cao@gmail.com >Subject: RE: The status of the approaches to the E-Tree solution? > >Lucy, > >even if the current MEF framework doesn't require s-vlan preservation, >I believe it's to the industry's benefit to adopt a solution that is >not constrained to a specific enni model that, like all things >networking, is likely to evolve. Especially when such a solution is availa= ble. > >Daniel > >Thumb typed - please be tolerant > >Lucy yong wrote: > >Daniel, > >MEF has worked in ENNI interface for a long time with many service >providers' inputs. It had a fair reason to assume S-VLAN over ENNI by >then. It may open B-VLAN for the future. It is better for us not to >discuss a future framework here, because it will lead us to nowhere. >Here, we want to extend VPLS in supporting E-Tree. > >Best Regards, >Lucy > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >Of Daniel Cohn >Sent: Sunday, April 22, 2012 7:34 AM >To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >Alexander.Vainshtein@ecitele.com >Cc: yuqun.cao@gmail.com >Subject: RE: The status of the approaches to the E-Tree solution? > >Shahram and all, > >This question already came up in our discussions - is it safe to assume >that the VLAN tags at the E-NNI will always be according to the current >MEF model? Or should we try to be as transparent as possible to user >VLAN encapsulation at the E-NNI, to accommodate future frameworks? >I believe that any approach that looks at user payload (in this case >VLAN >tag) to signal VPLS information (in this case root/leaf origin) is >necessarily tied to specific assumptions on user payload encapsulation >(in this case, that S-VLAN tag is "available" to encode root/leaf). I >don't think this is a future-proof assumption, it's very likely that >other network models will come up that require S-VLAN preservation, >which in the 2-VLAN approach would necessitate adding a third VLAN-ID. > >Daniel > >From: Shahram Davari > >To: Lizhong Jin >, >"l2vpn@ietf.org" >>, >"Alexander.Vainshtein@ecitele.comom> >" >om> >> >Cc: "yuqun.cao@gmail.com" >> >Subject: RE: The status of the approaches to the E-Tree solution? > >Hi, > >I also have a question regarding 2-VLAN. What if the customer traffic >already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? > >Thx >Shahram > >From: l2vpn-bounces@ietf.org >[mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin >Sent: Friday, April 20, 2012 9:38 AM >To: l2vpn@ietf.org; >Alexander.Vainshtein@ecitele.comm> >Cc: yuqun.cao@gmail.com >Subject: RE: The status of the approaches to the E-Tree solution? > >Hi, all, >The difference between 2-VLAN and CW approach is who will provide the >R/L information, customer payload or PW? The customer payload will be >always modified to carry R/L information in 2-VLAN approach, while PW >with CW will carry R/L information for CW approach. >I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is >accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is >used to access H-VPLS, how could the PE on VPWS side adds VLAN to >indicate R/L information? > >Thanks >Lizhong > >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 Apr 2012 04:38:36 +0000 >> From: Alexander Vainshtein >> > com>> >> To: "Rogers, Josh" >>>, Lucy yong >> >, Daniel >>Cohn >, Sam Cao >> > >> Cc: "l2vpn@ietf.org" >> > >> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID: >> >> > t o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi all, >> I fully understand that that what I am going to say is not very >>popular, but: >> >> IMO one of the advantages of the CW-based solution is that it is >>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery >>of BUN traffic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>and, in a more generic way, localization of effects of changes in the >>PE configuration. >> >> In particular, adding a Leaf AC to a PE that previously has been only >>supporting Root ACs (or vice versa), removal of the last Leaf or last >>Root AC from a PE that previously has been supporting a mix etc. >>affect only the PE where this operation happens and not the rest of the P= Es. >> >> As for the need for HW changes that have been mentioned as a main >>disadvantage of the CW-based approach - I believe it strongly depends >>on specific implementations. And some changes in the forwarding >>process are required in any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org >> [l2vpn-bounces@ietf.org] on behalf of >> Rogers, Josh >> [josh.rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a >> more complex model. Wether outside s-tag is used to differentiate, >> or dedicated pw's are used for the same purpose, it seems both become >> more complex. >> >> Gile's comparison slide still concisely captures the differences >>between these methods, in my opinion. I haven't seen any new ideas or >>thoughts brought to the group in the past week or two on the subject. >> I would hate for both proposed methods to die on the vine because we >>couldn't decide between two methods that have nothing inherently wrong >>with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" >>> wrote: >> >>>Send this again. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>double all of them. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: Daniel Cohn >>>[mailto:DanielC@orckit.com] >>>Sent: Wednesday, April 18, 2012 1:42 PM >>>To: Lucy yong; Rogers, Josh; Sam Cao >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I think the first option its the natural way to go. How is the >>>processing in this case more complex? >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>> >>> >>>Snipped.. >>> >>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only >>>P2MP PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP >>>PW (for traffic coming from a root AC) [[LY]] Not that simple. You >>>construct either two P2MP PWs to all other PEs and let egress PE >>>performing filtering, or construct one P2MP PW to leaf-only PEs and >>>two P2MP PWs to root and leaf PEs and let ingress PE perform >>>forwarding and filtering. Both make node process complex. >>> >>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>>delivering the frames to remote PEs. We should utilize them with the >>>minimized changes. Dual VLAN solution is simpler than Dual PW. >>> >>>Regards, >>>Lucy >>> >>> >>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>>haven't had any first hand experience with P2MP PW's, however, so >>>don't feel terribly strong about this objection. Is this a real >>>problem for others (now or in the future), or is this objection in >>>the weeds? >>> >>>I'm not sure the 'additional complexity' is notable, or even relevant. >>>I encourage others to speak up if they disagree, as P2MP PW is only >>>conceptual to me, and I am unfamiliar with real-life use cases for it. >>> >>>Thanks, >>>Josh >>> >>> >>> >>>On 4/18/12 10:30 AM, "Lucy yong" >>>> wrote: >>> >>>>Please see inline. >>>> >>>>-----Original Message----- >>>>From: Sam Cao >>>>[mailto:yuqun.cao@gmail.com] >>>>Sent: Tuesday, April 17, 2012 7:14 AM >>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>>(Wim)'; giles.heron@gmail.com; >>>>simon.delord@gmail.com; >>>>Alexander.Vainshtein@ecitele.com>>>com> >>>>Cc: l2vpn@ietf.org; >>>>Vladimir.Kleiner@ecitele.com; >>>>Andrew.Sergeev@ecitele.com; >>>>Idan.Kaspit@ecitele.com; >>>>Mishael.Wexler@ecitele.com; >>>>Rotem.Cohen@ecitele.com >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>>> >>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>>PE have both root and leaf AC and some only have leaf ACs)? >>>>Regards, >>>>Lucy >>>> >>>>Regards, >>>> >>>>Yuqun (Sam) Cao >>>>E-mail: Yuqun.cao@gmail.com >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn >>>>[mailto:DanielC@orckit.com] >>>>Sent: Tuesday, April 17, 2012 4:56 PM >>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>>giles.heron@gmail.com; >>>>simon.delord@gmail.com; >>>>Alexander.Vainshtein@ecitele.com>>>com>; Sam Cao >>>>Cc: l2vpn@ietf.org; >>>>Vladimir.Kleiner@ecitele.com; >>>>Andrew.Sergeev@ecitele.com; >>>>Idan.Kaspit@ecitele.com; >>>>Mishael.Wexler@ecitele.com; >>>>Rotem.Cohen@ecitele.com >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Adding Sam (as l2vpn@ is holding messages) >>>> >>>>DC >>>> >>>>-----Original Message----- >>>>From: Lucy yong >>>>[mailto:lucy.yong@huawei.com] >>>>Sent: Tuesday, April 17, 2012 12:39 AM >>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>>giles.heron@gmail.com; >>>>simon.delord@gmail.com; >>>>Alexander.Vainshtein@ecitele.com>>>com> >>>>Cc: l2vpn@ietf.org; >>>>Vladimir.Kleiner@ecitele.com; >>>>Andrew.Sergeev@ecitele.com; >>>>Idan.Kaspit@ecitele.com; >>>>Mishael.Wexler@ecitele.com; >>>>Rotem.Cohen@ecitele.com >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>> >>>>Snipped, >>>> >>>>As we discussed extensively in the list, and as reflected in giles >>>>slide, 2 pws are only needed between pes with both root and leaf >>>>acs, which will typically be a small minority. >>>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>>both approaches can benefit from it. I was off for a while and >>>>captures some discussions now. >>>> >>>>Also as per giles slide, dual vlan can have scalability issues due >>>>to additional lookup and double use of vlans in internal emulated >>>>lan interface. Also there are potential backward compatibility >>>>issues with silicon that doesn't support vlan mapping. >>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. >>>>I am not clear on all the issues. Could you be more specific? As I >>>>mentioned in below, two PW approach makes VPLS transport >>>>construction and packet forwarding more complex, I can see potential >>>>backward compatibility issues with 2 PW solution. >>>> >>>>Regards, >>>>Lucy >>>> >>>>Regards, >>>> >>>>Daniel >>>> >>>>Thumb typed - please be tolerant >>>> >>>>Lucy yong > wrote: >>>> >>>>In my mind, the VLAN approach means dual vlan method. >>>> >>>>The main concern for CW approach is hardware support. >>>> >>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and >>>>unknown unicast traffic, and some P2MP PWs for multicast traffic. It >>>>may double all of them. >>>> >>>>E-tree is an Ethernet service and there is already VLAN based >>>>solution in IEEE, can we just utilize it without complicating VPLS >>>>transport construction? This also makes interworking with Eth only >>>>network easier. >>>> >>>>Cheers, >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: Rogers, Josh >>>>[mailto:josh.rogers@twcable.com] >>>>Sent: Monday, April 16, 2012 8:35 AM >>>>To: Lucy yong; Henderickx, Wim (Wim); >>>>'giles.heron@gmail.com'; >>>>'simon.delord@gmail.com'; >>>>'Alexander.Vainshtein@ecitele.com>>>e.c >>>>om>' >>>>Cc: 'l2vpn@ietf.org'; >>>>'Vladimir.Kleiner@ecitele.com'; >>>>'Andrew.Sergeev@ecitele.com'; >>>>'Idan.Kaspit@ecitele.com'; >>>>'Mishael.Wexler@ecitele.com'; >>>>'Rotem.Cohen@ecitele.com' >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>I believe the initial question was in regard to the CW method. Are >>>>you saying that you no longer are interested in that method in >>>>preference of the dual vlan method? >>>> >>>> >>>> >>>>Lucy yong > wrote: >>>> >>>> >>>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>>> >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: l2vpn-bounces@ietf.org >>>>[mailto:l2vpn-bounces@ietf.org] On >>>>Behalf Of Henderickx, Wim (Wim) >>>>Sent: Thursday, April 12, 2012 2:03 AM >>>>To: 'giles.heron@gmail.com'; >>>>'simon.delord@gmail.com'; >>>>'Alexander.Vainshtein@ecitele.com>>>e.c >>>>om>' >>>>Cc: 'l2vpn@ietf.org'; >>>>'Vladimir.Kleiner@ecitele.com'; >>>>'Andrew.Sergeev@ecitele.com'; >>>>'Idan.Kaspit@ecitele.com'; >>>>'Mishael.Wexler@ecitele.com'; >>>>'Rotem.Cohen@ecitele.com' >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>The vlan approach is superior as it also works for eth only >>>>networks, etc. On top some vendors indicate hw issues with the cw >>>>approach. As such we have dropped more or less the cw approach. >>>> >>>>Cheers, >>>>Wim >>>>_________________ >>>>sent from blackberry >>>> >>>>----- Original Message ----- >>>>From: Giles Heron >>>>[mailto:giles.heron@gmail.com] >>>>Sent: Thursday, April 12, 2012 08:22 AM >>>>To: Simon Delord >>>>>; Alexander >>>>Vainshtein >>>>>>>e >>>>.com>> >>>>Cc: l2vpn@ietf.org >>>>>; Vladimir Kleiner >>>>>; >>>>Andrew Sergeev >>>>>; >>>>Idan Kaspit >>>>>; >>>>Mishael Wexler >>>>>; >>>>Rotem Cohen >>>>> >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>Sorry - the "anonymous presentation" was mine. I should possibly >>>>have put in a third column on the CW approach. And hopefully the >>>>minutes will be posted soon. >>>> >>>>We had various discussions, as Simon stated, and consensus seemed to >>>>be forming around the two alternatives of two PWEs or two VLANs. I >>>>believe three of the authors of the CW approach are also authors of >>>>the two VLAN approach and one is also an author of the two PWE >>>>approach. So perhaps it's best to let those four individuals say >>>>which approach they prefer and why? >>>> >>>>Giles >>>> >>>>On 10/04/2012 00:45, "Simon Delord" >>>>> wrote: >>>> >>>>> Hi Alexander, >>>>> >>>>> You are right, no discussion on the WG mailing list recently, but >>>>> there have been substantial discussions among the authors of >>>>> various solution drafts off the mailing list. As far as I know, no >>>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>>> meeting. I think the CW approach has not been rejected by the WG >>>>> yet, or the WG has not yet decided on which one to adopt. >>>>> >>>>> Simon >>>>> >>>>> 2012/4/8 Alexander Vainshtein >>>>> >>>> e >>>>> le.com>> >>>>> >>>>>> Hi all, >>>>>> >>>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>>> >>>>>> However, looking up the L2VPN proceedings, I've found a short >>>>>> anonymous presentation called "E-Tree Update" ( >>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>>> This presentation discusses the differences of the E-Tree >>>>>> approaches based on dedicated VLANs (as in >>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?inclu >>>>>> d >>>>>> e_t >>>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw >>>>>> / >>>>>> ?in >>>>>> clude_te >>>>>> xt=3D1) >>>>>> and completely ignores the solution based on usage of the CW in >>>>>> the PWs connecting the PEs (as in >>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?inclu >>>>>> d >>>>>> e_t >>>>>> ext=3D1 >>>>>> ). >>>>>> >>>>>> >>>>>> >>>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>>> I wonder whether the WG has taken a decision to reject the >>>>>> approach based on the CW usage? I do not remember any recent >>>>>> discussion of this topic on the WG mailing list. >>>>>> >>>>>> >>>>>> >>>>>> Regards, and lots of thanks in advance, >>>>>> >>>>>> Sasha >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> This e-mail message is intended for the recipient only and >>>>>> contains information which is CONFIDENTIAL and which may be >>>>>> proprietary to ECI >>>> >>>>>> Telecom. If you have received this transmission in error, please >>>>>> inform us by e-mail, phone or fax, and then delete the original >>>>>> and all copies thereof. >>>>>> >>>> >>>> >>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or >>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>intended solely for the use of the individual or entity to which it >>>>is addressed. >>>>If you are not the intended recipient of this E-mail, you are hereby >>>>notified that any dissemination, distribution, copying, or action >>>>taken in relation to the contents of and attachments to this E-mail >>>>is strictly prohibited and may be unlawful. If you have received >>>>this E-mail in error, please notify the sender immediately and >>>>permanently delete the original and any copy of this E-mail and any pri= ntout. >>>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or >>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>intended solely for the use of the individual or entity to which it >>>is addressed. If you are not the intended recipient of this E-mail, >>>you are hereby notified that any dissemination, distribution, >>>copying, or action taken in relation to the contents of and >>>attachments to this E-mail is strictly prohibited and may be >>>unlawful. If you have received this E-mail in error, please notify >>>the sender immediately and permanently delete the original and any >>>copy of this E-mail and any printout. >> >> >> This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is addressed. >>If you are not the intended recipient of this E-mail, you are hereby >>notified that any dissemination, distribution, copying, or action >>taken in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this >>E-mail in error, please notify the sender immediately and permanently >>delete the original and any copy of this E-mail and any printout. >> This e-mail message is intended for the recipient only and contains >>information which is CONFIDENTIAL and which may be proprietary to ECI >>Telecom. If you have received this transmission in error, please >>inform us by e-mail, phone or fax, and then delete the original and >>all copies thereof. >> >> >> >> ------------------------------ >> >> _______________________________________________ >> L2vpn mailing list >> L2vpn@ietf.org >> https://www.ietf.org/mailman/listinfo/l2vpn >> >> >> End of L2vpn Digest, Vol 95, Issue 25 >> *********************************** This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From lucy.yong@huawei.com Wed Apr 25 15:24:25 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60B121E803F for ; Wed, 25 Apr 2012 15:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HS_INDEX_PARAM=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 UcYdjLiEuD5c for ; Wed, 25 Apr 2012 15:24:22 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 85D8A11E808C for ; Wed, 25 Apr 2012 15:24:18 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFF46675; Wed, 25 Apr 2012 18:24:18 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 15:22:25 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Wed, 25 Apr 2012 15:22:02 -0700 From: Lucy yong To: "Rogers, Josh" , "Fedyk, Donald (Don)" , David Allan I , Daniel Cohn , "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0jLD6Ce/4Txq0Y50G6N17p5MncdwAA6bjA Date: Wed, 25 Apr 2012 22:22:24 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264C202@dfweml505-mbx> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Kvlr OeLG Vdbg a8Ll ciTp gDK/ gtck hPhM iEFs lR3B oFXs te/B tm9U zneT 0GJq 0RwF; 5; ZABhAG4AaQBlAGwAYwBAAG8AcgBjAGsAaQB0AC4AYwBvAG0AOwBkAGEAdgBpAGQALgBpAC4AYQBsAGwAYQBuAEAAZQByAGkAYwBzAHMAbwBuAC4AYwBvAG0AOwBkAG8AbgBhAGwAZAAuAGYAZQBkAHkAawBAAGEAbABjAGEAdABlAGwALQBsAHUAYwBlAG4AdAAuAGMAbwBtADsAagBvAHMAaAAuAHIAbwBnAGUAcgBzAEAAdAB3AGMAYQBiAGwAZQAuAGMAbwBtADsAbAAyAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {BEA51078-B34E-4C7E-93E9-9C1E01E21552}; bAB1AGMAeQAuAHkAbwBuAGcAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Wed, 25 Apr 2012 22:22:15 GMT; UgBFADoAIABUAGgAZQAgAHMAdABhAHQAdQBzACAAbwBmACAAdABoAGUAIABhAHAAcAByAG8AYQBjAGgAZQBzACAAdABvACAAdABoAGUAIABFAC0AVAByAGUAZQAgAHMAbwBsAHUAdABpAG8AbgA/AA== x-cr-puzzleid: {BEA51078-B34E-4C7E-93E9-9C1E01E21552} x-originating-ip: [10.47.142.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@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, 25 Apr 2012 22:24:25 -0000 Hi Josh, Please see inline. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of R= ogers, Josh Sent: Wednesday, April 25, 2012 4:42 PM To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? Dave/Daniel/Lucy/Others Debating how many tags necessary when S-Tag preservation is desired, I think you all may have gone off on a tangent here. The original discussion was about how to deal with the situation where the S-Tag is preserved at a handoff (either an ENNI, or Service Multiplexed UNI) [[LY]] in MEF, S-Tag applies to ENNI only, not UNI. An UNI can support mult= iplexed services, i.e. terminate many EVCs. In this case, each EVC associat= es with one or multiple c-tags. EVC has a service attribute for listing ass= ociated c-tags. I believe there were two suggestions, one was that you push on a 'ETREE' tag (one of two values, for either a frame sourced from a root AC or another for a frame from a leaf AC), and the second solution was to 'map'. [[LY]] This is not my understanding. Here we talk about incoming frame alr= eady has c-tag and s-tag, which is not UNI case. In addition, it seems that= Daniel say that only option A works. Imagine the following topology: +-----+ +-----+ +-----+ +-----+ | CE1 |--| PE1 |--| PE2 |--| CE2 | +-----+ +-----+ +-----+ +-----+ | | +-----+ +-----+ +-----+ +-----+ | CE3 |--| PE3 |--| PE4 |--| CE4 | +-----+ +-----+ +-----+ +-----+ Where: Site Type VLAN CE1 Root X CE2 Leaf 2 CE3 Leaf 3 CE4 Leaf 3 So, there are a lot of SP's who are keen on the way many services can be handed to a customer on a single UNI, but coordinating a single VLAN per service, with the customer (MEF used to call this EVPL when it was many point to point services terminating on a single UNI). So, imagine that we have two ETREE instances, and an internet service all terminating on a single UNI connecting to CE1. We have negotiated VLAN ID's with the customer, and they are expecting to reach CE2 using VLAN 2, CE3 and CE4 using VLAN 3, and Internet service on VLAN 10. As a frame from CE1 comes into PE1 destined for CE2 (so the customer has tagged it with VID 2), using the 2VLAN method, since this is coming from a root site, do we a) place the Root S-Tag in front of VID 2, then ship it across, and pop off the ETREE S-Tag (some SP's wish to Pop the original customer tag VID 2 as well) -or- b) swap VID2 for the ETREE Root S-Tag, send the frame to PE2 where it will remove the S-Tag (and either push VID2 back on, or leave it off depending on SP preference) The reference to 'double tagging' was talking about solution A above, since there is both the service VID that is coordinated with the customer, as well as the Etree VID which designates the source (root or leaf) [[LY]] Since dual VLAN solution tries to inline with IEEE solution, if this= is the use case, we suggests to go with option B, not A. So please don't d= iscuss option A more. Regards, Lucy Hope that clears more than it confuses, Josh On 4/25/12 4:22 PM, "Fedyk, Donald (Don)" wrote: >Hi Dave > >Yes the only point I would add is Dual VLAN means One VID for Root and >one VID for Leaf. Not two TAGs at a time on the frame but two allocated >for the service. > >The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks >about Encapsulation Overhead as a VLAN Tag. While that is true in a PWE >sense it is still a single VLAN Tag at a time in a Ethernet E-tree sense. > The compelling driver for Dual VLAN is having a Etree service that works >in many environments and the DUAL VLAN (really dual VLAN interface on a >VSI) uses the same mechanism (one VID for root and one VID for Leaf at a >time) as specified in the IEEE. In a pure Ethernet bridging world the >VLAN TAGs for Etree are not typically an overhead since translation is >used. > >Don > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >David Allan I >Sent: Wednesday, April 25, 2012 5:05 PM >To: Daniel Cohn; l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >OK I feel like I am digressing a fair distance from the actual >problem.... But here goes: > >So the scenarios center around "how ETREE do you want to be?".... > >If the ACs are root/leaf, then if they are P2P (single ethernet end >station attached to each AC) this is moot. ETREE semantics are enforced >by the 2VID domain in the center of the example. If you assumed nodes A&B >in the example were L2VPN PEs, the tagging and the PW tag imposition all >happened at the same point in the network. > >If they are not simple P2P all the way to end systems and the objective >is to avoid bridging between leaf "sites" but allowing intra-leaf-site >connectivity then the leaves can be LANs but the root is not, such that I >cannot bridge through the root. But all hosts at a given leaf site can >see each other. So root Ethernet end systems are directly attached or two >VIDs are used in the root site. > >If the objective is that there are multiple ethernet attached end >stations at both the leaf and root sites, and the objective is to enforce >L2 isolation everywhere then I need two VIDs extended to the end system >attachement point in the local LANs by whatever means.... > >And I do not see adding VLANs in any particular spot, simply selection of >the VID and associated semantics where VIDs are translated. The actual >point of S-tag imposition could be a PE, or cloud be a NID/CLE on the >customer prem (more likely scenario here to extend OAM demarc to the >prem), or some switch in a RAN downstream of the MPLS PE... blah blah >blah. And if ETREE is extended into a customer site LAN and outside of >the provider domain, then two C-tags would have to be used that mapped to >S-tags at the PBN boundary... > >Make sense? >Dave > >-----Original Message----- >From: Daniel Cohn [mailto:DanielC@orckit.com] >Sent: Wednesday, April 25, 2012 4:39 PM >To: David Allan I; l2vpn@ietf.org >Subject: RE: The status of the approaches to the E-Tree solution? > >Dave, but the ACs are root/leaf (that's what the whole vpls etree is >about - see the reqt draft), so per the 2vlan draft the root/leaf vlan >must be added. > >Thumb typed - please be tolerant > >David Allan I wrote: > >HI Daniel: > >In the example provided, > >"ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" > A B > >the service is not ETREE in the domains of the ingress and egress VID. It >is ELAN. SO there is no root/leaf attribute to shovel around. It would >require two VIDs in each domain if the ETREE semantics were to be >telescoped E2E. > >Otherwise it is a provisioning of the VID translation tables at the >intermediate nodes (A&B that I've added to the picture) that would >determine the VID values used in each domain. Or in the example above, >what the ingress, Etree and egress VID values were. > >Cheers >Dave > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Daniel Cohn >Sent: Wednesday, April 25, 2012 3:46 PM >To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >Alexander.Vainshtein@ecitele.com >Cc: yuqun.cao@gmail.com >Subject: RE: The status of the approaches to the E-Tree solution? > >And to this I asked how this mapping works - how does the egress pe >recover the ingress vid when it gets the frame tagged with only the >root/leaf vid? How can you convey the ingress vid plus the root/leaf >attribute in the same number of bits? >What am I missing? > >Daniel > >Thumb typed - please be tolerant > >Lucy yong wrote: > >Daniel, > >David Allen already explained the solution. > >From David: >ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. > >Ingress VID does not have to equal Egress VID but regardless there is >only ever one VID on a frame at a time. > >-end > >This works when customer makes ingress VLAN ID not equal to or equal to >egress VLAN ID. > >Regards, >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Daniel Cohn >Sent: Wednesday, April 25, 2012 11:39 AM >To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >Alexander.Vainshtein@ecitele.com >Cc: yuqun.cao@gmail.com >Subject: RE: The status of the approaches to the E-Tree solution? > >Hi Lucy, > >The scenario we are discussing is not the E-Tree E-NNI, but a general >scenario where frames arriving at the root or leaf AC are already double >tagged. In this case, the dual vlan solution cannot preserve the vlans >without adding a third one, can it? > >Maybe Shahram can add details on the scenario he had in mind > >Thumb typed - please be tolerant > >Lucy yong wrote: > >Daniel, > >MEF has S-VLAN preservation attribute for ENNI only because there is no >s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN >preservation attribute is used. It applies to E-Tree as well. > >Regards, >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Daniel Cohn >Sent: Tuesday, April 24, 2012 2:12 AM >To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >Alexander.Vainshtein@ecitele.com >Cc: yuqun.cao@gmail.com >Subject: RE: The status of the approaches to the E-Tree solution? > >Lucy, > >even if the current MEF framework doesn't require s-vlan preservation, I >believe it's to the industry's benefit to adopt a solution that is not >constrained to a specific enni model that, like all things networking, is >likely to evolve. Especially when such a solution is available. > >Daniel > >Thumb typed - please be tolerant > >Lucy yong wrote: > >Daniel, > >MEF has worked in ENNI interface for a long time with many service >providers' inputs. It had a fair reason to assume S-VLAN over ENNI by >then. It may open B-VLAN for the future. It is better for us not to >discuss a future framework here, because it will lead us to nowhere. >Here, we want to extend VPLS in supporting E-Tree. > >Best Regards, >Lucy > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Daniel Cohn >Sent: Sunday, April 22, 2012 7:34 AM >To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >Alexander.Vainshtein@ecitele.com >Cc: yuqun.cao@gmail.com >Subject: RE: The status of the approaches to the E-Tree solution? > >Shahram and all, > >This question already came up in our discussions - is it safe to assume >that the VLAN tags at the E-NNI will always be according to the current >MEF model? Or should we try to be as transparent as possible to user VLAN >encapsulation at the E-NNI, to accommodate future frameworks? >I believe that any approach that looks at user payload (in this case VLAN >tag) to signal VPLS information (in this case root/leaf origin) is >necessarily tied to specific assumptions on user payload encapsulation >(in this case, that S-VLAN tag is "available" to encode root/leaf). I >don't think this is a future-proof assumption, it's very likely that >other network models will come up that require S-VLAN preservation, which >in the 2-VLAN approach would necessitate adding a third VLAN-ID. > >Daniel > >From: Shahram Davari > >To: Lizhong Jin >, >"l2vpn@ietf.org" >>, >"Alexander.Vainshtein@ecitele.com >" > >> >Cc: "yuqun.cao@gmail.com" >> >Subject: RE: The status of the approaches to the E-Tree solution? > >Hi, > >I also have a question regarding 2-VLAN. What if the customer traffic >already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? > >Thx >Shahram > >From: l2vpn-bounces@ietf.org >[mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin >Sent: Friday, April 20, 2012 9:38 AM >To: l2vpn@ietf.org; >Alexander.Vainshtein@ecitele.com >Cc: yuqun.cao@gmail.com >Subject: RE: The status of the approaches to the E-Tree solution? > >Hi, all, >The difference between 2-VLAN and CW approach is who will provide the R/L >information, customer payload or PW? The customer payload will be always >modified to carry R/L information in 2-VLAN approach, while PW with CW >will carry R/L information for CW approach. >I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is >accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used >to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L >information? > >Thanks >Lizhong > >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 Apr 2012 04:38:36 +0000 >> From: Alexander Vainshtein >> > com>> >> To: "Rogers, Josh" >>>, Lucy yong >> >, Daniel Cohn >>>, Sam Cao >> > >> Cc: "l2vpn@ietf.org" >> > >> Subject: RE: The status of the approaches to the E-Tree solution? >> Message-ID: >> >> > o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> >> Content-Type: text/plain; charset=3D"us-ascii" >> >> Hi all, >> I fully understand that that what I am going to say is not very >>popular, but: >> >> IMO one of the advantages of the CW-based solution is that it is >>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of >>BUN traffic. >> >> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>and, in a more generic way, localization of effects of changes in the PE >>configuration. >> >> In particular, adding a Leaf AC to a PE that previously has been only >>supporting Root ACs (or vice versa), removal of the last Leaf or last >>Root AC from a PE that previously has been supporting a mix etc. affect >>only the PE where this operation happens and not the rest of the PEs. >> >> As for the need for HW changes that have been mentioned as a main >>disadvantage of the CW-based approach - I believe it strongly depends on >>specific implementations. And some changes in the forwarding process are >>required in any solution. >> >> My 2c, >> Sasha >> >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org >> [l2vpn-bounces@ietf.org] on behalf of >> Rogers, Josh [josh.rogers@twcable.com] >> Sent: Wednesday, April 18, 2012 9:57 PM >> To: Lucy yong; Daniel Cohn; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: Re: The status of the approaches to the E-Tree solution? >> >> Again, the P2MP situation throws me. Is this something that is used >> commonly? >> >> I'm under the impression that adding P2MP to any model results in a >> more complex model. Wether outside s-tag is used to differentiate, or >> dedicated pw's are used for the same purpose, it seems both become >> more complex. >> >> Gile's comparison slide still concisely captures the differences >> between these methods, in my opinion. I haven't seen any new ideas or >> thoughts brought to the group in the past week or two on the subject. >> I would hate for both proposed methods to die on the vine because we >> couldn't decide between two methods that have nothing inherently wrong >>with either. >> >> -Josh >> >> >> On 4/18/12 1:53 PM, "Lucy yong" >>> wrote: >> >>>Send this again. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>double all of them. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: Daniel Cohn >>>[mailto:DanielC@orckit.com] >>>Sent: Wednesday, April 18, 2012 1:42 PM >>>To: Lucy yong; Rogers, Josh; Sam Cao >>>Cc: l2vpn@ietf.org >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I think the first option its the natural way to go. How is the >>>processing in this case more complex? >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>> >>> >>>Snipped.. >>> >>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >>>PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW >>>(for traffic coming from a root AC) [[LY]] Not that simple. You >>>construct either two P2MP PWs to all other PEs and let egress PE >>>performing filtering, or construct one P2MP PW to leaf-only PEs and >>>two P2MP PWs to root and leaf PEs and let ingress PE perform >>>forwarding and filtering. Both make node process complex. >>> >>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>>delivering the frames to remote PEs. We should utilize them with the >>>minimized changes. Dual VLAN solution is simpler than Dual PW. >>> >>>Regards, >>>Lucy >>> >>> >>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>>haven't had any first hand experience with P2MP PW's, however, so >>>don't feel terribly strong about this objection. Is this a real >>>problem for others (now or in the future), or is this objection in the >>>weeds? >>> >>>I'm not sure the 'additional complexity' is notable, or even relevant. >>>I encourage others to speak up if they disagree, as P2MP PW is only >>>conceptual to me, and I am unfamiliar with real-life use cases for it. >>> >>>Thanks, >>>Josh >>> >>> >>> >>>On 4/18/12 10:30 AM, "Lucy yong" >>>> wrote: >>> >>>>Please see inline. >>>> >>>>-----Original Message----- >>>>From: Sam Cao >>>>[mailto:yuqun.cao@gmail.com] >>>>Sent: Tuesday, April 17, 2012 7:14 AM >>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>>(Wim)'; giles.heron@gmail.com; >>>>simon.delord@gmail.com; >>>>Alexander.Vainshtein@ecitele.com>>>com> >>>>Cc: l2vpn@ietf.org; >>>>Vladimir.Kleiner@ecitele.com; >>>>Andrew.Sergeev@ecitele.com; >>>>Idan.Kaspit@ecitele.com; >>>>Mishael.Wexler@ecitele.com; >>>>Rotem.Cohen@ecitele.com >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>>> >>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>>PE have both root and leaf AC and some only have leaf ACs)? >>>>Regards, >>>>Lucy >>>> >>>>Regards, >>>> >>>>Yuqun (Sam) Cao >>>>E-mail: Yuqun.cao@gmail.com >>>> >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn >>>>[mailto:DanielC@orckit.com] >>>>Sent: Tuesday, April 17, 2012 4:56 PM >>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>>giles.heron@gmail.com; >>>>simon.delord@gmail.com; >>>>Alexander.Vainshtein@ecitele.com>>>com>; Sam Cao >>>>Cc: l2vpn@ietf.org; >>>>Vladimir.Kleiner@ecitele.com; >>>>Andrew.Sergeev@ecitele.com; >>>>Idan.Kaspit@ecitele.com; >>>>Mishael.Wexler@ecitele.com; >>>>Rotem.Cohen@ecitele.com >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>Adding Sam (as l2vpn@ is holding messages) >>>> >>>>DC >>>> >>>>-----Original Message----- >>>>From: Lucy yong >>>>[mailto:lucy.yong@huawei.com] >>>>Sent: Tuesday, April 17, 2012 12:39 AM >>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>>giles.heron@gmail.com; >>>>simon.delord@gmail.com; >>>>Alexander.Vainshtein@ecitele.com>>>com> >>>>Cc: l2vpn@ietf.org; >>>>Vladimir.Kleiner@ecitele.com; >>>>Andrew.Sergeev@ecitele.com; >>>>Idan.Kaspit@ecitele.com; >>>>Mishael.Wexler@ecitele.com; >>>>Rotem.Cohen@ecitele.com >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>> >>>>Snipped, >>>> >>>>As we discussed extensively in the list, and as reflected in giles >>>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>>which will typically be a small minority. >>>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>>both approaches can benefit from it. I was off for a while and >>>>captures some discussions now. >>>> >>>>Also as per giles slide, dual vlan can have scalability issues due to >>>>additional lookup and double use of vlans in internal emulated lan >>>>interface. Also there are potential backward compatibility issues >>>>with silicon that doesn't support vlan mapping. >>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >>>>am not clear on all the issues. Could you be more specific? As I >>>>mentioned in below, two PW approach makes VPLS transport construction >>>>and packet forwarding more complex, I can see potential backward >>>>compatibility issues with 2 PW solution. >>>> >>>>Regards, >>>>Lucy >>>> >>>>Regards, >>>> >>>>Daniel >>>> >>>>Thumb typed - please be tolerant >>>> >>>>Lucy yong > wrote: >>>> >>>>In my mind, the VLAN approach means dual vlan method. >>>> >>>>The main concern for CW approach is hardware support. >>>> >>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>>double all of them. >>>> >>>>E-tree is an Ethernet service and there is already VLAN based >>>>solution in IEEE, can we just utilize it without complicating VPLS >>>>transport construction? This also makes interworking with Eth only >>>>network easier. >>>> >>>>Cheers, >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: Rogers, Josh >>>>[mailto:josh.rogers@twcable.com] >>>>Sent: Monday, April 16, 2012 8:35 AM >>>>To: Lucy yong; Henderickx, Wim (Wim); >>>>'giles.heron@gmail.com'; >>>>'simon.delord@gmail.com'; >>>>'Alexander.Vainshtein@ecitele.com>>>om>' >>>>Cc: 'l2vpn@ietf.org'; >>>>'Vladimir.Kleiner@ecitele.com'; >>>>'Andrew.Sergeev@ecitele.com'; >>>>'Idan.Kaspit@ecitele.com'; >>>>'Mishael.Wexler@ecitele.com'; >>>>'Rotem.Cohen@ecitele.com' >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>I believe the initial question was in regard to the CW method. Are >>>>you saying that you no longer are interested in that method in >>>>preference of the dual vlan method? >>>> >>>> >>>> >>>>Lucy yong > wrote: >>>> >>>> >>>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>>> >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: l2vpn-bounces@ietf.org >>>>[mailto:l2vpn-bounces@ietf.org] On >>>>Behalf Of Henderickx, Wim (Wim) >>>>Sent: Thursday, April 12, 2012 2:03 AM >>>>To: 'giles.heron@gmail.com'; >>>>'simon.delord@gmail.com'; >>>>'Alexander.Vainshtein@ecitele.com>>>om>' >>>>Cc: 'l2vpn@ietf.org'; >>>>'Vladimir.Kleiner@ecitele.com'; >>>>'Andrew.Sergeev@ecitele.com'; >>>>'Idan.Kaspit@ecitele.com'; >>>>'Mishael.Wexler@ecitele.com'; >>>>'Rotem.Cohen@ecitele.com' >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>The vlan approach is superior as it also works for eth only networks, >>>>etc. On top some vendors indicate hw issues with the cw approach. As >>>>such we have dropped more or less the cw approach. >>>> >>>>Cheers, >>>>Wim >>>>_________________ >>>>sent from blackberry >>>> >>>>----- Original Message ----- >>>>From: Giles Heron >>>>[mailto:giles.heron@gmail.com] >>>>Sent: Thursday, April 12, 2012 08:22 AM >>>>To: Simon Delord >>>>>; Alexander >>>>Vainshtein >>>>>>>.com>> >>>>Cc: l2vpn@ietf.org >>>>>; Vladimir Kleiner >>>>>; >>>>Andrew Sergeev >>>>>; Idan >>>>Kaspit >; >>>>Mishael Wexler >>>>>; >>>>Rotem Cohen > >>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>> >>>>Sorry - the "anonymous presentation" was mine. I should possibly >>>>have put in a third column on the CW approach. And hopefully the >>>>minutes will be posted soon. >>>> >>>>We had various discussions, as Simon stated, and consensus seemed to >>>>be forming around the two alternatives of two PWEs or two VLANs. I >>>>believe three of the authors of the CW approach are also authors of >>>>the two VLAN approach and one is also an author of the two PWE >>>>approach. So perhaps it's best to let those four individuals say >>>>which approach they prefer and why? >>>> >>>>Giles >>>> >>>>On 10/04/2012 00:45, "Simon Delord" >>>>> wrote: >>>> >>>>> Hi Alexander, >>>>> >>>>> You are right, no discussion on the WG mailing list recently, but >>>>> there have been substantial discussions among the authors of >>>>> various solution drafts off the mailing list. As far as I know, no >>>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>>> meeting. I think the CW approach has not been rejected by the WG >>>>> yet, or the WG has not yet decided on which one to adopt. >>>>> >>>>> Simon >>>>> >>>>> 2012/4/8 Alexander Vainshtein >>>>> >>>> le.com>> >>>>> >>>>>> Hi all, >>>>>> >>>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>>> >>>>>> However, looking up the L2VPN proceedings, I've found a short >>>>>> anonymous presentation called "E-Tree Update" ( >>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>>> This presentation discusses the differences of the E-Tree >>>>>> approaches based on dedicated VLANs (as in >>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?includ >>>>>> e_t >>>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/ >>>>>> ?in >>>>>> clude_te >>>>>> xt=3D1) >>>>>> and completely ignores the solution based on usage of the CW in >>>>>> the PWs connecting the PEs (as in >>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?includ >>>>>> e_t >>>>>> ext=3D1 >>>>>> ). >>>>>> >>>>>> >>>>>> >>>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>>> I wonder whether the WG has taken a decision to reject the >>>>>> approach based on the CW usage? I do not remember any recent >>>>>> discussion of this topic on the WG mailing list. >>>>>> >>>>>> >>>>>> >>>>>> Regards, and lots of thanks in advance, >>>>>> >>>>>> Sasha >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> This e-mail message is intended for the recipient only and >>>>>> contains information which is CONFIDENTIAL and which may be >>>>>> proprietary to ECI >>>> >>>>>> Telecom. If you have received this transmission in error, please >>>>>> inform us by e-mail, phone or fax, and then delete the original >>>>>> and all copies thereof. >>>>>> >>>> >>>> >>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or >>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>intended solely for the use of the individual or entity to which it is >>>>addressed. >>>>If you are not the intended recipient of this E-mail, you are hereby >>>>notified that any dissemination, distribution, copying, or action >>>>taken in relation to the contents of and attachments to this E-mail >>>>is strictly prohibited and may be unlawful. If you have received this >>>>E-mail in error, please notify the sender immediately and permanently >>>>delete the original and any copy of this E-mail and any printout. >>>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is >>>addressed. If you are not the intended recipient of this E-mail, you >>>are hereby notified that any dissemination, distribution, copying, or >>>action taken in relation to the contents of and attachments to this >>>E-mail is strictly prohibited and may be unlawful. If you have >>>received this E-mail in error, please notify the sender immediately >>>and permanently delete the original and any copy of this E-mail and any >>>printout. >> >> >> This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject >>to copyright belonging to Time Warner Cable. This E-mail is intended >>solely for the use of the individual or entity to which it is addressed. >>If you are not the intended recipient of this E-mail, you are hereby >>notified that any dissemination, distribution, copying, or action taken >>in relation to the contents of and attachments to this E-mail is >>strictly prohibited and may be unlawful. If you have received this >>E-mail in error, please notify the sender immediately and permanently >>delete the original and any copy of this E-mail and any printout. >> This e-mail message is intended for the recipient only and contains >>information which is CONFIDENTIAL and which may be proprietary to ECI >>Telecom. If you have received this transmission in error, please inform >>us by e-mail, phone or fax, and then delete the original and all copies >>thereof. >> >> >> >> ------------------------------ >> >> _______________________________________________ >> L2vpn mailing list >> L2vpn@ietf.org >> https://www.ietf.org/mailman/listinfo/l2vpn >> >> >> End of L2vpn Digest, Vol 95, Issue 25 >> *********************************** This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From josh.rogers@twcable.com Wed Apr 25 16:21:53 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5411E21E804D for ; Wed, 25 Apr 2012 16:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.208 X-Spam-Level: X-Spam-Status: No, score=-0.208 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HS_INDEX_PARAM=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 BsMcYYygG5be for ; Wed, 25 Apr 2012 16:21:50 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id B34B111E8076 for ; Wed, 25 Apr 2012 16:21:49 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,483,1330923600"; d="scan'208";a="356156612" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 25 Apr 2012 19:20:22 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Wed, 25 Apr 2012 19:21:48 -0400 From: "Rogers, Josh" To: David Allan I , "Fedyk, Donald (Don)" , Daniel Cohn , "l2vpn@ietf.org" Date: Wed, 25 Apr 2012 19:21:43 -0400 Subject: Re: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0jOi+SczvVvIwpS3O2J1dybpgusA== Message-ID: In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD52324EF0A6@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: l2vpn@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, 25 Apr 2012 23:21:53 -0000 > Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. I have to apologize, because I think I led y'all down that path (I referred to the outermost tag, the same tag that the MPLS psuedowire is using for vlan mode encamp, as the S-Tag, even though the customer is the one placing it on the frame. Same as I described below, but I either used term S-Tag incorrectly, or ambiguously. >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... So, I think this could be cleared up some still. What I was referring to is the VID that the customer is using to put frames in, the VID which they should use to ensure the frame goes into the correct ETREE instance. You drew a distinction between 'customer VID' vs 'provider VID', but since it is negotiated, I haven't really seen a distinction, which I think is what has caused all the confusion. In the two discussion points/solutions I mentioned, the first one, "A", describes both a coordinated VID which the customer should use, and the service provider uses to distinguish between services on the same UNI, as well as a second, outer, VID which is used by the SP to determine the source AC type. In my example, if you were to sniff inside the psuedowire between PE1 and PE2 to see CE2 destined traffic, wish solution A, you might see "4001:2:Payload", where 4001 designates it is from a root AC, 2 designates the ETREE instance, and Payload is the customer's traffic (which may include a C-Tag), where with solution B, you would see "4001:Payload", and VID 2 would have to be swapped for 4001 as it enters the PE2-CE2 AC, giving the customer "2:Payload" just as they sent it (alternatively SP may choose to simply drop tag entirely and provide "Payload" to customer, this can cause problems with PVST on some devices, but I still see it done occasionally) ** Note, for the example above, I'm assuming 4001 is used as a 'standard' for root sourced frames, and 4002 is used for leaf sourced frames, for the ETREE R/L tags. Have I undone the confusion, or made it worse? -Josh On 4/25/12 5:19 PM, "David Allan I" wrote: >Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. > >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" > >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... > >Cheers >Dave > > > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Wednesday, April 25, 2012 5:42 PM >To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >Dave/Daniel/Lucy/Others Debating how many tags necessary when S-Tag >preservation is desired, > > >I think you all may have gone off on a tangent here. The original >discussion was about how to deal with the situation where the S-Tag is >preserved at a handoff (either an ENNI, or Service Multiplexed UNI) > >I believe there were two suggestions, one was that you push on a 'ETREE' >tag (one of two values, for either a frame sourced from a root AC or >another for a frame from a leaf AC), and the second solution was to 'map'. > > >Imagine the following topology: > >+-----+ +-----+ +-----+ +-----+ >| CE1 |--| PE1 |--| PE2 |--| CE2 | >+-----+ +-----+ +-----+ +-----+ > | | >+-----+ +-----+ +-----+ +-----+ >| CE3 |--| PE3 |--| PE4 |--| CE4 | >+-----+ +-----+ +-----+ +-----+ > >Where: > >Site Type VLAN >CE1 Root X >CE2 Leaf 2 >CE3 Leaf 3 >CE4 Leaf 3 > > >So, there are a lot of SP's who are keen on the way many services can be >handed to a customer on a single UNI, but coordinating a single VLAN per >service, with the customer (MEF used to call this EVPL when it was many >point to point services terminating on a single UNI). So, imagine that >we have two ETREE instances, and an internet service all terminating on a >single UNI connecting to CE1. We have negotiated VLAN ID's with the >customer, and they are expecting to reach CE2 using VLAN 2, CE3 and CE4 >using VLAN 3, and Internet service on VLAN 10. As a frame from CE1 comes >into PE1 destined for CE2 (so the customer has tagged it with VID 2), >using the 2VLAN method, since this is coming from a root site, do we > >a) place the Root S-Tag in front of VID 2, then ship it across, and pop >off the ETREE S-Tag (some SP's wish to Pop the original customer tag VID >2 as well) > >-or- > >b) swap VID2 for the ETREE Root S-Tag, send the frame to PE2 where it >will remove the S-Tag (and either push VID2 back on, or leave it off >depending on SP preference) > >The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf) > > >Hope that clears more than it confuses, >Josh > > > >On 4/25/12 4:22 PM, "Fedyk, Donald (Don)" > wrote: > >>Hi Dave >> >>Yes the only point I would add is Dual VLAN means One VID for Root and >>one VID for Leaf. Not two TAGs at a time on the frame but two allocated >>for the service. >> >>The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks >>about Encapsulation Overhead as a VLAN Tag. While that is true in a PWE >>sense it is still a single VLAN Tag at a time in a Ethernet E-tree sense. >> The compelling driver for Dual VLAN is having a Etree service that >>works in many environments and the DUAL VLAN (really dual VLAN >>interface on a >>VSI) uses the same mechanism (one VID for root and one VID for Leaf at >>a >>time) as specified in the IEEE. In a pure Ethernet bridging world the >>VLAN TAGs for Etree are not typically an overhead since translation is >>used. >> >>Don >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of David Allan I >>Sent: Wednesday, April 25, 2012 5:05 PM >>To: Daniel Cohn; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>OK I feel like I am digressing a fair distance from the actual >>problem.... But here goes: >> >>So the scenarios center around "how ETREE do you want to be?".... >> >>If the ACs are root/leaf, then if they are P2P (single ethernet end >>station attached to each AC) this is moot. ETREE semantics are enforced >>by the 2VID domain in the center of the example. If you assumed nodes >>A&B in the example were L2VPN PEs, the tagging and the PW tag >>imposition all happened at the same point in the network. >> >>If they are not simple P2P all the way to end systems and the objective >>is to avoid bridging between leaf "sites" but allowing intra-leaf-site >>connectivity then the leaves can be LANs but the root is not, such that >>I cannot bridge through the root. But all hosts at a given leaf site >>can see each other. So root Ethernet end systems are directly attached >>or two VIDs are used in the root site. >> >>If the objective is that there are multiple ethernet attached end >>stations at both the leaf and root sites, and the objective is to >>enforce >>L2 isolation everywhere then I need two VIDs extended to the end system >>attachement point in the local LANs by whatever means.... >> >>And I do not see adding VLANs in any particular spot, simply selection >>of the VID and associated semantics where VIDs are translated. The >>actual point of S-tag imposition could be a PE, or cloud be a NID/CLE >>on the customer prem (more likely scenario here to extend OAM demarc to >>the prem), or some switch in a RAN downstream of the MPLS PE... blah >>blah blah. And if ETREE is extended into a customer site LAN and >>outside of the provider domain, then two C-tags would have to be used >>that mapped to S-tags at the PBN boundary... >> >>Make sense? >>Dave >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 25, 2012 4:39 PM >>To: David Allan I; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Dave, but the ACs are root/leaf (that's what the whole vpls etree is >>about - see the reqt draft), so per the 2vlan draft the root/leaf vlan >>must be added. >> >>Thumb typed - please be tolerant >> >>David Allan I wrote: >> >>HI Daniel: >> >>In the example provided, >> >>"ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" >> A B >> >>the service is not ETREE in the domains of the ingress and egress VID. >>It is ELAN. SO there is no root/leaf attribute to shovel around. It >>would require two VIDs in each domain if the ETREE semantics were to be >>telescoped E2E. >> >>Otherwise it is a provisioning of the VID translation tables at the >>intermediate nodes (A&B that I've added to the picture) that would >>determine the VID values used in each domain. Or in the example above, >>what the ingress, Etree and egress VID values were. >> >>Cheers >>Dave >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 3:46 PM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>And to this I asked how this mapping works - how does the egress pe >>recover the ingress vid when it gets the frame tagged with only the >>root/leaf vid? How can you convey the ingress vid plus the root/leaf >>attribute in the same number of bits? >>What am I missing? >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>David Allen already explained the solution. >> >>From David: >>ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. >> >>Ingress VID does not have to equal Egress VID but regardless there is >>only ever one VID on a frame at a time. >> >>-end >> >>This works when customer makes ingress VLAN ID not equal to or equal to >>egress VLAN ID. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 11:39 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Lucy, >> >>The scenario we are discussing is not the E-Tree E-NNI, but a general >>scenario where frames arriving at the root or leaf AC are already >>double tagged. In this case, the dual vlan solution cannot preserve the >>vlans without adding a third one, can it? >> >>Maybe Shahram can add details on the scenario he had in mind >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has S-VLAN preservation attribute for ENNI only because there is no >>s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN >>preservation attribute is used. It applies to E-Tree as well. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Tuesday, April 24, 2012 2:12 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Lucy, >> >>even if the current MEF framework doesn't require s-vlan preservation, >>I believe it's to the industry's benefit to adopt a solution that is >>not constrained to a specific enni model that, like all things >>networking, is likely to evolve. Especially when such a solution is >>available. >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has worked in ENNI interface for a long time with many service >>providers' inputs. It had a fair reason to assume S-VLAN over ENNI by >>then. It may open B-VLAN for the future. It is better for us not to >>discuss a future framework here, because it will lead us to nowhere. >>Here, we want to extend VPLS in supporting E-Tree. >> >>Best Regards, >>Lucy >> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Sunday, April 22, 2012 7:34 AM >>To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Shahram and all, >> >>This question already came up in our discussions - is it safe to assume >>that the VLAN tags at the E-NNI will always be according to the current >>MEF model? Or should we try to be as transparent as possible to user >>VLAN encapsulation at the E-NNI, to accommodate future frameworks? >>I believe that any approach that looks at user payload (in this case >>VLAN >>tag) to signal VPLS information (in this case root/leaf origin) is >>necessarily tied to specific assumptions on user payload encapsulation >>(in this case, that S-VLAN tag is "available" to encode root/leaf). I >>don't think this is a future-proof assumption, it's very likely that >>other network models will come up that require S-VLAN preservation, >>which in the 2-VLAN approach would necessitate adding a third VLAN-ID. >> >>Daniel >> >>From: Shahram Davari > >>To: Lizhong Jin >, >>"l2vpn@ietf.org" >>>, >>"Alexander.Vainshtein@ecitele.com>om> >>" >>>om> >>> >>Cc: "yuqun.cao@gmail.com" >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, >> >>I also have a question regarding 2-VLAN. What if the customer traffic >>already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? >> >>Thx >>Shahram >> >>From: l2vpn-bounces@ietf.org >>[mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin >>Sent: Friday, April 20, 2012 9:38 AM >>To: l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com>m> >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, all, >>The difference between 2-VLAN and CW approach is who will provide the >>R/L information, customer payload or PW? The customer payload will be >>always modified to carry R/L information in 2-VLAN approach, while PW >>with CW will carry R/L information for CW approach. >>I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is >>accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is >>used to access H-VPLS, how could the PE on VPWS side adds VLAN to >>indicate R/L information? >> >>Thanks >>Lizhong >> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Thu, 19 Apr 2012 04:38:36 +0000 >>> From: Alexander Vainshtein >>> >> com>> >>> To: "Rogers, Josh" >>>>, Lucy yong >>> >, Daniel >>>Cohn >, Sam Cao >>> > >>> Cc: "l2vpn@ietf.org" >>> > >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> Message-ID: >>> >>> >> t o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> >>> Content-Type: text/plain; charset=3D"us-ascii" >>> >>> Hi all, >>> I fully understand that that what I am going to say is not very >>>popular, but: >>> >>> IMO one of the advantages of the CW-based solution is that it is >>>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery >>>of BUN traffic. >>> >>> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>>and, in a more generic way, localization of effects of changes in the >>>PE configuration. >>> >>> In particular, adding a Leaf AC to a PE that previously has been only >>>supporting Root ACs (or vice versa), removal of the last Leaf or last >>>Root AC from a PE that previously has been supporting a mix etc. >>>affect only the PE where this operation happens and not the rest of the >>>PEs. >>> >>> As for the need for HW changes that have been mentioned as a main >>>disadvantage of the CW-based approach - I believe it strongly depends >>>on specific implementations. And some changes in the forwarding >>>process are required in any solution. >>> >>> My 2c, >>> Sasha >>> >>> >>> >>> ________________________________________ >>> From: l2vpn-bounces@ietf.org >>> [l2vpn-bounces@ietf.org] on behalf of >>> Rogers, Josh >>> [josh.rogers@twcable.com] >>> Sent: Wednesday, April 18, 2012 9:57 PM >>> To: Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: Re: The status of the approaches to the E-Tree solution? >>> >>> Again, the P2MP situation throws me. Is this something that is used >>> commonly? >>> >>> I'm under the impression that adding P2MP to any model results in a >>> more complex model. Wether outside s-tag is used to differentiate, >>> or dedicated pw's are used for the same purpose, it seems both become >>> more complex. >>> >>> Gile's comparison slide still concisely captures the differences >>>between these methods, in my opinion. I haven't seen any new ideas or >>>thoughts brought to the group in the past week or two on the subject. >>> I would hate for both proposed methods to die on the vine because we >>>couldn't decide between two methods that have nothing inherently wrong >>>with either. >>> >>> -Josh >>> >>> >>> On 4/18/12 1:53 PM, "Lucy yong" >>>> wrote: >>> >>>>Send this again. >>>> >>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>>double all of them. >>>> >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn >>>>[mailto:DanielC@orckit.com] >>>>Sent: Wednesday, April 18, 2012 1:42 PM >>>>To: Lucy yong; Rogers, Josh; Sam Cao >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>I think the first option its the natural way to go. How is the >>>>processing in this case more complex? >>>> >>>>Thumb typed - please be tolerant >>>> >>>>Lucy yong > wrote: >>>> >>>> >>>> >>>>Snipped.. >>>> >>>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only >>>>P2MP PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP >>>>PW (for traffic coming from a root AC) [[LY]] Not that simple. You >>>>construct either two P2MP PWs to all other PEs and let egress PE >>>>performing filtering, or construct one P2MP PW to leaf-only PEs and >>>>two P2MP PWs to root and leaf PEs and let ingress PE perform >>>>forwarding and filtering. Both make node process complex. >>>> >>>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>>>delivering the frames to remote PEs. We should utilize them with the >>>>minimized changes. Dual VLAN solution is simpler than Dual PW. >>>> >>>>Regards, >>>>Lucy >>>> >>>> >>>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>>>haven't had any first hand experience with P2MP PW's, however, so >>>>don't feel terribly strong about this objection. Is this a real >>>>problem for others (now or in the future), or is this objection in >>>>the weeds? >>>> >>>>I'm not sure the 'additional complexity' is notable, or even relevant. >>>>I encourage others to speak up if they disagree, as P2MP PW is only >>>>conceptual to me, and I am unfamiliar with real-life use cases for it. >>>> >>>>Thanks, >>>>Josh >>>> >>>> >>>> >>>>On 4/18/12 10:30 AM, "Lucy yong" >>>>> wrote: >>>> >>>>>Please see inline. >>>>> >>>>>-----Original Message----- >>>>>From: Sam Cao >>>>>[mailto:yuqun.cao@gmail.com] >>>>>Sent: Tuesday, April 17, 2012 7:14 AM >>>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>>>(Wim)'; giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>>>> >>>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>>>PE have both root and leaf AC and some only have leaf ACs)? >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Yuqun (Sam) Cao >>>>>E-mail: Yuqun.cao@gmail.com >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn >>>>>[mailto:DanielC@orckit.com] >>>>>Sent: Tuesday, April 17, 2012 4:56 PM >>>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com>; Sam Cao >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Adding Sam (as l2vpn@ is holding messages) >>>>> >>>>>DC >>>>> >>>>>-----Original Message----- >>>>>From: Lucy yong >>>>>[mailto:lucy.yong@huawei.com] >>>>>Sent: Tuesday, April 17, 2012 12:39 AM >>>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>> >>>>>Snipped, >>>>> >>>>>As we discussed extensively in the list, and as reflected in giles >>>>>slide, 2 pws are only needed between pes with both root and leaf >>>>>acs, which will typically be a small minority. >>>>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>>>both approaches can benefit from it. I was off for a while and >>>>>captures some discussions now. >>>>> >>>>>Also as per giles slide, dual vlan can have scalability issues due >>>>>to additional lookup and double use of vlans in internal emulated >>>>>lan interface. Also there are potential backward compatibility >>>>>issues with silicon that doesn't support vlan mapping. >>>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. >>>>>I am not clear on all the issues. Could you be more specific? As I >>>>>mentioned in below, two PW approach makes VPLS transport >>>>>construction and packet forwarding more complex, I can see potential >>>>>backward compatibility issues with 2 PW solution. >>>>> >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Daniel >>>>> >>>>>Thumb typed - please be tolerant >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>>In my mind, the VLAN approach means dual vlan method. >>>>> >>>>>The main concern for CW approach is hardware support. >>>>> >>>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and >>>>>unknown unicast traffic, and some P2MP PWs for multicast traffic. It >>>>>may double all of them. >>>>> >>>>>E-tree is an Ethernet service and there is already VLAN based >>>>>solution in IEEE, can we just utilize it without complicating VPLS >>>>>transport construction? This also makes interworking with Eth only >>>>>network easier. >>>>> >>>>>Cheers, >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: Rogers, Josh >>>>>[mailto:josh.rogers@twcable.com] >>>>>Sent: Monday, April 16, 2012 8:35 AM >>>>>To: Lucy yong; Henderickx, Wim (Wim); >>>>>'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com'; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>I believe the initial question was in regard to the CW method. Are >>>>>you saying that you no longer are interested in that method in >>>>>preference of the dual vlan method? >>>>> >>>>> >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>> >>>>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>>>> >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: l2vpn-bounces@ietf.org >>>>>[mailto:l2vpn-bounces@ietf.org] On >>>>>Behalf Of Henderickx, Wim (Wim) >>>>>Sent: Thursday, April 12, 2012 2:03 AM >>>>>To: 'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com'; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>The vlan approach is superior as it also works for eth only >>>>>networks, etc. On top some vendors indicate hw issues with the cw >>>>>approach. As such we have dropped more or less the cw approach. >>>>> >>>>>Cheers, >>>>>Wim >>>>>_________________ >>>>>sent from blackberry >>>>> >>>>>----- Original Message ----- >>>>>From: Giles Heron >>>>>[mailto:giles.heron@gmail.com] >>>>>Sent: Thursday, April 12, 2012 08:22 AM >>>>>To: Simon Delord >>>>>>; Alexander >>>>>Vainshtein >>>>>>>>>e >>>>>.com>> >>>>>Cc: l2vpn@ietf.org >>>>>>; Vladimir Kleiner >>>>>>; >>>>>Andrew Sergeev >>>>>>; >>>>>Idan Kaspit >>>>>>; >>>>>Mishael Wexler >>>>>>; >>>>>Rotem Cohen >>>>>> >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>Sorry - the "anonymous presentation" was mine. I should possibly >>>>>have put in a third column on the CW approach. And hopefully the >>>>>minutes will be posted soon. >>>>> >>>>>We had various discussions, as Simon stated, and consensus seemed to >>>>>be forming around the two alternatives of two PWEs or two VLANs. I >>>>>believe three of the authors of the CW approach are also authors of >>>>>the two VLAN approach and one is also an author of the two PWE >>>>>approach. So perhaps it's best to let those four individuals say >>>>>which approach they prefer and why? >>>>> >>>>>Giles >>>>> >>>>>On 10/04/2012 00:45, "Simon Delord" >>>>>> wrote: >>>>> >>>>>> Hi Alexander, >>>>>> >>>>>> You are right, no discussion on the WG mailing list recently, but >>>>>> there have been substantial discussions among the authors of >>>>>> various solution drafts off the mailing list. As far as I know, no >>>>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>>>> meeting. I think the CW approach has not been rejected by the WG >>>>>> yet, or the WG has not yet decided on which one to adopt. >>>>>> >>>>>> Simon >>>>>> >>>>>> 2012/4/8 Alexander Vainshtein >>>>>> >>>>> e >>>>>> le.com>> >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>>>> >>>>>>> However, looking up the L2VPN proceedings, I've found a short >>>>>>> anonymous presentation called "E-Tree Update" ( >>>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>>>> This presentation discusses the differences of the E-Tree >>>>>>> approaches based on dedicated VLANs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw >>>>>>> / >>>>>>> ?in >>>>>>> clude_te >>>>>>> xt=3D1) >>>>>>> and completely ignores the solution based on usage of the CW in >>>>>>> the PWs connecting the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1 >>>>>>> ). >>>>>>> >>>>>>> >>>>>>> >>>>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>>>> I wonder whether the WG has taken a decision to reject the >>>>>>> approach based on the CW usage? I do not remember any recent >>>>>>> discussion of this topic on the WG mailing list. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, and lots of thanks in advance, >>>>>>> >>>>>>> Sasha >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This e-mail message is intended for the recipient only and >>>>>>> contains information which is CONFIDENTIAL and which may be >>>>>>> proprietary to ECI >>>>> >>>>>>> Telecom. If you have received this transmission in error, please >>>>>>> inform us by e-mail, phone or fax, and then delete the original >>>>>>> and all copies thereof. >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>>proprietary information, which is privileged, confidential, or >>>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>>intended solely for the use of the individual or entity to which it >>>>>is addressed. >>>>>If you are not the intended recipient of this E-mail, you are hereby >>>>>notified that any dissemination, distribution, copying, or action >>>>>taken in relation to the contents of and attachments to this E-mail >>>>>is strictly prohibited and may be unlawful. If you have received >>>>>this E-mail in error, please notify the sender immediately and >>>>>permanently delete the original and any copy of this E-mail and any >>>>>printout. >>>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or >>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>intended solely for the use of the individual or entity to which it >>>>is addressed. If you are not the intended recipient of this E-mail, >>>>you are hereby notified that any dissemination, distribution, >>>>copying, or action taken in relation to the contents of and >>>>attachments to this E-mail is strictly prohibited and may be >>>>unlawful. If you have received this E-mail in error, please notify >>>>the sender immediately and permanently delete the original and any >>>>copy of this E-mail and any printout. >>> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> This e-mail message is intended for the recipient only and contains >>>information which is CONFIDENTIAL and which may be proprietary to ECI >>>Telecom. If you have received this transmission in error, please >>>inform us by e-mail, phone or fax, and then delete the original and >>>all copies thereof. >>> >>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> L2vpn mailing list >>> L2vpn@ietf.org >>> https://www.ietf.org/mailman/listinfo/l2vpn >>> >>> >>> End of L2vpn Digest, Vol 95, Issue 25 >>> *********************************** > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From josh.rogers@twcable.com Wed Apr 25 16:23:42 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19C621E804D for ; Wed, 25 Apr 2012 16:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.231 X-Spam-Level: X-Spam-Status: No, score=-0.231 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HS_INDEX_PARAM=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 rxoXn1-yoPI9 for ; Wed, 25 Apr 2012 16:23:39 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF7C11E8076 for ; Wed, 25 Apr 2012 16:23:36 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,483,1330923600"; d="scan'208";a="356157093" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 25 Apr 2012 19:22:09 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Wed, 25 Apr 2012 19:23:35 -0400 From: "Rogers, Josh" To: Lucy yong , "Fedyk, Donald (Don)" , David Allan I , Daniel Cohn , "l2vpn@ietf.org" Date: Wed, 25 Apr 2012 19:23:26 -0400 Subject: Re: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0jOm+ZUGAiKOKOQpeI9+OYDFcXZw== Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D3264C202@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: l2vpn@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, 25 Apr 2012 23:23:42 -0000 [[LY]] This is not my understanding. Here we talk about incoming frame already has c-tag and s-tag, which is not UNI case. In addition, it seems that Daniel say that only option A works. That=B9s funny, I thought someone said that only option B would work. I think technically either is possible, but I am unclear which the 2VLAN draft would advise (or if it even does) -Josh On 4/25/12 5:22 PM, "Lucy yong" wrote: >Hi Josh, > >Please see inline. > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Rogers, Josh >Sent: Wednesday, April 25, 2012 4:42 PM >To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >Dave/Daniel/Lucy/Others Debating how many tags necessary when S-Tag >preservation is desired, > > >I think you all may have gone off on a tangent here. The original >discussion was about how to deal with the situation where the S-Tag is >preserved at a handoff (either an ENNI, or Service Multiplexed UNI) >[[LY]] in MEF, S-Tag applies to ENNI only, not UNI. An UNI can support >multiplexed services, i.e. terminate many EVCs. In this case, each EVC >associates with one or multiple c-tags. EVC has a service attribute for >listing associated c-tags. > >I believe there were two suggestions, one was that you push on a 'ETREE' >tag (one of two values, for either a frame sourced from a root AC or >another for a frame from a leaf AC), and the second solution was to 'map'. >[[LY]] This is not my understanding. Here we talk about incoming frame >already has c-tag and s-tag, which is not UNI case. In addition, it seems >that Daniel say that only option A works. > > >Imagine the following topology: > >+-----+ +-----+ +-----+ +-----+ >| CE1 |--| PE1 |--| PE2 |--| CE2 | >+-----+ +-----+ +-----+ +-----+ > | | >+-----+ +-----+ +-----+ +-----+ >| CE3 |--| PE3 |--| PE4 |--| CE4 | >+-----+ +-----+ +-----+ +-----+ > >Where: > >Site Type VLAN >CE1 Root X >CE2 Leaf 2 >CE3 Leaf 3 >CE4 Leaf 3 > > >So, there are a lot of SP's who are keen on the way many services can be >handed to a customer on a single UNI, but coordinating a single VLAN per >service, with the customer (MEF used to call this EVPL when it was many >point to point services terminating on a single UNI). So, imagine that we >have two ETREE instances, and an internet service all terminating on a >single UNI connecting to CE1. We have negotiated VLAN ID's with the >customer, and they are expecting to reach CE2 using VLAN 2, CE3 and CE4 >using VLAN 3, and Internet service on VLAN 10. As a frame from CE1 comes >into PE1 destined for CE2 (so the customer has tagged it with VID 2), >using the 2VLAN method, since this is coming from a root site, do we > >a) place the Root S-Tag in front of VID 2, then ship it across, and pop >off the ETREE S-Tag (some SP's wish to Pop the original customer tag VID 2 >as well) > >-or- > >b) swap VID2 for the ETREE Root S-Tag, send the frame to PE2 where it will >remove the S-Tag (and either push VID2 back on, or leave it off depending >on SP preference) > >The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the customer, >as well as the Etree VID which designates the source (root or leaf) >[[LY]] Since dual VLAN solution tries to inline with IEEE solution, if >this is the use case, we suggests to go with option B, not A. So please >don't discuss option A more. > >Regards, >Lucy > > >Hope that clears more than it confuses, >Josh > > > >On 4/25/12 4:22 PM, "Fedyk, Donald (Don)" > wrote: > >>Hi Dave >> >>Yes the only point I would add is Dual VLAN means One VID for Root and >>one VID for Leaf. Not two TAGs at a time on the frame but two allocated >>for the service. >> >>The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks >>about Encapsulation Overhead as a VLAN Tag. While that is true in a PWE >>sense it is still a single VLAN Tag at a time in a Ethernet E-tree sense. >> The compelling driver for Dual VLAN is having a Etree service that works >>in many environments and the DUAL VLAN (really dual VLAN interface on a >>VSI) uses the same mechanism (one VID for root and one VID for Leaf at a >>time) as specified in the IEEE. In a pure Ethernet bridging world the >>VLAN TAGs for Etree are not typically an overhead since translation is >>used. >> >>Don >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>David Allan I >>Sent: Wednesday, April 25, 2012 5:05 PM >>To: Daniel Cohn; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>OK I feel like I am digressing a fair distance from the actual >>problem.... But here goes: >> >>So the scenarios center around "how ETREE do you want to be?".... >> >>If the ACs are root/leaf, then if they are P2P (single ethernet end >>station attached to each AC) this is moot. ETREE semantics are enforced >>by the 2VID domain in the center of the example. If you assumed nodes A&B >>in the example were L2VPN PEs, the tagging and the PW tag imposition all >>happened at the same point in the network. >> >>If they are not simple P2P all the way to end systems and the objective >>is to avoid bridging between leaf "sites" but allowing intra-leaf-site >>connectivity then the leaves can be LANs but the root is not, such that I >>cannot bridge through the root. But all hosts at a given leaf site can >>see each other. So root Ethernet end systems are directly attached or two >>VIDs are used in the root site. >> >>If the objective is that there are multiple ethernet attached end >>stations at both the leaf and root sites, and the objective is to enforce >>L2 isolation everywhere then I need two VIDs extended to the end system >>attachement point in the local LANs by whatever means.... >> >>And I do not see adding VLANs in any particular spot, simply selection of >>the VID and associated semantics where VIDs are translated. The actual >>point of S-tag imposition could be a PE, or cloud be a NID/CLE on the >>customer prem (more likely scenario here to extend OAM demarc to the >>prem), or some switch in a RAN downstream of the MPLS PE... blah blah >>blah. And if ETREE is extended into a customer site LAN and outside of >>the provider domain, then two C-tags would have to be used that mapped to >>S-tags at the PBN boundary... >> >>Make sense? >>Dave >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 25, 2012 4:39 PM >>To: David Allan I; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Dave, but the ACs are root/leaf (that's what the whole vpls etree is >>about - see the reqt draft), so per the 2vlan draft the root/leaf vlan >>must be added. >> >>Thumb typed - please be tolerant >> >>David Allan I wrote: >> >>HI Daniel: >> >>In the example provided, >> >>"ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" >> A B >> >>the service is not ETREE in the domains of the ingress and egress VID. It >>is ELAN. SO there is no root/leaf attribute to shovel around. It would >>require two VIDs in each domain if the ETREE semantics were to be >>telescoped E2E. >> >>Otherwise it is a provisioning of the VID translation tables at the >>intermediate nodes (A&B that I've added to the picture) that would >>determine the VID values used in each domain. Or in the example above, >>what the ingress, Etree and egress VID values were. >> >>Cheers >>Dave >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>Daniel Cohn >>Sent: Wednesday, April 25, 2012 3:46 PM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>And to this I asked how this mapping works - how does the egress pe >>recover the ingress vid when it gets the frame tagged with only the >>root/leaf vid? How can you convey the ingress vid plus the root/leaf >>attribute in the same number of bits? >>What am I missing? >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>David Allen already explained the solution. >> >>From David: >>ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. >> >>Ingress VID does not have to equal Egress VID but regardless there is >>only ever one VID on a frame at a time. >> >>-end >> >>This works when customer makes ingress VLAN ID not equal to or equal to >>egress VLAN ID. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>Daniel Cohn >>Sent: Wednesday, April 25, 2012 11:39 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Lucy, >> >>The scenario we are discussing is not the E-Tree E-NNI, but a general >>scenario where frames arriving at the root or leaf AC are already double >>tagged. In this case, the dual vlan solution cannot preserve the vlans >>without adding a third one, can it? >> >>Maybe Shahram can add details on the scenario he had in mind >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has S-VLAN preservation attribute for ENNI only because there is no >>s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN >>preservation attribute is used. It applies to E-Tree as well. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>Daniel Cohn >>Sent: Tuesday, April 24, 2012 2:12 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Lucy, >> >>even if the current MEF framework doesn't require s-vlan preservation, I >>believe it's to the industry's benefit to adopt a solution that is not >>constrained to a specific enni model that, like all things networking, is >>likely to evolve. Especially when such a solution is available. >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has worked in ENNI interface for a long time with many service >>providers' inputs. It had a fair reason to assume S-VLAN over ENNI by >>then. It may open B-VLAN for the future. It is better for us not to >>discuss a future framework here, because it will lead us to nowhere. >>Here, we want to extend VPLS in supporting E-Tree. >> >>Best Regards, >>Lucy >> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>Daniel Cohn >>Sent: Sunday, April 22, 2012 7:34 AM >>To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Shahram and all, >> >>This question already came up in our discussions - is it safe to assume >>that the VLAN tags at the E-NNI will always be according to the current >>MEF model? Or should we try to be as transparent as possible to user VLAN >>encapsulation at the E-NNI, to accommodate future frameworks? >>I believe that any approach that looks at user payload (in this case VLAN >>tag) to signal VPLS information (in this case root/leaf origin) is >>necessarily tied to specific assumptions on user payload encapsulation >>(in this case, that S-VLAN tag is "available" to encode root/leaf). I >>don't think this is a future-proof assumption, it's very likely that >>other network models will come up that require S-VLAN preservation, which >>in the 2-VLAN approach would necessitate adding a third VLAN-ID. >> >>Daniel >> >>From: Shahram Davari > >>To: Lizhong Jin >, >>"l2vpn@ietf.org" >>>, >>"Alexander.Vainshtein@ecitele.com>> >>" >>>> >>> >>Cc: "yuqun.cao@gmail.com" >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, >> >>I also have a question regarding 2-VLAN. What if the customer traffic >>already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? >> >>Thx >>Shahram >> >>From: l2vpn-bounces@ietf.org >>[mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin >>Sent: Friday, April 20, 2012 9:38 AM >>To: l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, all, >>The difference between 2-VLAN and CW approach is who will provide the R/L >>information, customer payload or PW? The customer payload will be always >>modified to carry R/L information in 2-VLAN approach, while PW with CW >>will carry R/L information for CW approach. >>I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is >>accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used >>to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L >>information? >> >>Thanks >>Lizhong >> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Thu, 19 Apr 2012 04:38:36 +0000 >>> From: Alexander Vainshtein >>> >> com>> >>> To: "Rogers, Josh" >>>>, Lucy yong >>> >, Daniel Cohn >>>>, Sam Cao >>> > >>> Cc: "l2vpn@ietf.org" >>> > >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> Message-ID: >>> >>> >> o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> >>> Content-Type: text/plain; charset=3D"us-ascii" >>> >>> Hi all, >>> I fully understand that that what I am going to say is not very >>>popular, but: >>> >>> IMO one of the advantages of the CW-based solution is that it is >>>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of >>>BUN traffic. >>> >>> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>>and, in a more generic way, localization of effects of changes in the PE >>>configuration. >>> >>> In particular, adding a Leaf AC to a PE that previously has been only >>>supporting Root ACs (or vice versa), removal of the last Leaf or last >>>Root AC from a PE that previously has been supporting a mix etc. affect >>>only the PE where this operation happens and not the rest of the PEs. >>> >>> As for the need for HW changes that have been mentioned as a main >>>disadvantage of the CW-based approach - I believe it strongly depends on >>>specific implementations. And some changes in the forwarding process are >>>required in any solution. >>> >>> My 2c, >>> Sasha >>> >>> >>> >>> ________________________________________ >>> From: l2vpn-bounces@ietf.org >>> [l2vpn-bounces@ietf.org] on behalf of >>> Rogers, Josh [josh.rogers@twcable.com] >>> Sent: Wednesday, April 18, 2012 9:57 PM >>> To: Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: Re: The status of the approaches to the E-Tree solution? >>> >>> Again, the P2MP situation throws me. Is this something that is used >>> commonly? >>> >>> I'm under the impression that adding P2MP to any model results in a >>> more complex model. Wether outside s-tag is used to differentiate, or >>> dedicated pw's are used for the same purpose, it seems both become >>> more complex. >>> >>> Gile's comparison slide still concisely captures the differences >>> between these methods, in my opinion. I haven't seen any new ideas or >>> thoughts brought to the group in the past week or two on the subject. >>> I would hate for both proposed methods to die on the vine because we >>> couldn't decide between two methods that have nothing inherently wrong >>>with either. >>> >>> -Josh >>> >>> >>> On 4/18/12 1:53 PM, "Lucy yong" >>>> wrote: >>> >>>>Send this again. >>>> >>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>>double all of them. >>>> >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn >>>>[mailto:DanielC@orckit.com] >>>>Sent: Wednesday, April 18, 2012 1:42 PM >>>>To: Lucy yong; Rogers, Josh; Sam Cao >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>I think the first option its the natural way to go. How is the >>>>processing in this case more complex? >>>> >>>>Thumb typed - please be tolerant >>>> >>>>Lucy yong > wrote: >>>> >>>> >>>> >>>>Snipped.. >>>> >>>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >>>>PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW >>>>(for traffic coming from a root AC) [[LY]] Not that simple. You >>>>construct either two P2MP PWs to all other PEs and let egress PE >>>>performing filtering, or construct one P2MP PW to leaf-only PEs and >>>>two P2MP PWs to root and leaf PEs and let ingress PE perform >>>>forwarding and filtering. Both make node process complex. >>>> >>>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>>>delivering the frames to remote PEs. We should utilize them with the >>>>minimized changes. Dual VLAN solution is simpler than Dual PW. >>>> >>>>Regards, >>>>Lucy >>>> >>>> >>>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>>>haven't had any first hand experience with P2MP PW's, however, so >>>>don't feel terribly strong about this objection. Is this a real >>>>problem for others (now or in the future), or is this objection in the >>>>weeds? >>>> >>>>I'm not sure the 'additional complexity' is notable, or even relevant. >>>>I encourage others to speak up if they disagree, as P2MP PW is only >>>>conceptual to me, and I am unfamiliar with real-life use cases for it. >>>> >>>>Thanks, >>>>Josh >>>> >>>> >>>> >>>>On 4/18/12 10:30 AM, "Lucy yong" >>>>> wrote: >>>> >>>>>Please see inline. >>>>> >>>>>-----Original Message----- >>>>>From: Sam Cao >>>>>[mailto:yuqun.cao@gmail.com] >>>>>Sent: Tuesday, April 17, 2012 7:14 AM >>>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>>>(Wim)'; giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>>>> >>>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>>>PE have both root and leaf AC and some only have leaf ACs)? >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Yuqun (Sam) Cao >>>>>E-mail: Yuqun.cao@gmail.com >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn >>>>>[mailto:DanielC@orckit.com] >>>>>Sent: Tuesday, April 17, 2012 4:56 PM >>>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com>; Sam Cao >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Adding Sam (as l2vpn@ is holding messages) >>>>> >>>>>DC >>>>> >>>>>-----Original Message----- >>>>>From: Lucy yong >>>>>[mailto:lucy.yong@huawei.com] >>>>>Sent: Tuesday, April 17, 2012 12:39 AM >>>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>> >>>>>Snipped, >>>>> >>>>>As we discussed extensively in the list, and as reflected in giles >>>>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>>>which will typically be a small minority. >>>>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>>>both approaches can benefit from it. I was off for a while and >>>>>captures some discussions now. >>>>> >>>>>Also as per giles slide, dual vlan can have scalability issues due to >>>>>additional lookup and double use of vlans in internal emulated lan >>>>>interface. Also there are potential backward compatibility issues >>>>>with silicon that doesn't support vlan mapping. >>>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >>>>>am not clear on all the issues. Could you be more specific? As I >>>>>mentioned in below, two PW approach makes VPLS transport construction >>>>>and packet forwarding more complex, I can see potential backward >>>>>compatibility issues with 2 PW solution. >>>>> >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Daniel >>>>> >>>>>Thumb typed - please be tolerant >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>>In my mind, the VLAN approach means dual vlan method. >>>>> >>>>>The main concern for CW approach is hardware support. >>>>> >>>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>>>double all of them. >>>>> >>>>>E-tree is an Ethernet service and there is already VLAN based >>>>>solution in IEEE, can we just utilize it without complicating VPLS >>>>>transport construction? This also makes interworking with Eth only >>>>>network easier. >>>>> >>>>>Cheers, >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: Rogers, Josh >>>>>[mailto:josh.rogers@twcable.com] >>>>>Sent: Monday, April 16, 2012 8:35 AM >>>>>To: Lucy yong; Henderickx, Wim (Wim); >>>>>'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com'; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>I believe the initial question was in regard to the CW method. Are >>>>>you saying that you no longer are interested in that method in >>>>>preference of the dual vlan method? >>>>> >>>>> >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>> >>>>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>>>> >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: l2vpn-bounces@ietf.org >>>>>[mailto:l2vpn-bounces@ietf.org] On >>>>>Behalf Of Henderickx, Wim (Wim) >>>>>Sent: Thursday, April 12, 2012 2:03 AM >>>>>To: 'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com'; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>The vlan approach is superior as it also works for eth only networks, >>>>>etc. On top some vendors indicate hw issues with the cw approach. As >>>>>such we have dropped more or less the cw approach. >>>>> >>>>>Cheers, >>>>>Wim >>>>>_________________ >>>>>sent from blackberry >>>>> >>>>>----- Original Message ----- >>>>>From: Giles Heron >>>>>[mailto:giles.heron@gmail.com] >>>>>Sent: Thursday, April 12, 2012 08:22 AM >>>>>To: Simon Delord >>>>>>; Alexander >>>>>Vainshtein >>>>>>>>>.com>> >>>>>Cc: l2vpn@ietf.org >>>>>>; Vladimir Kleiner >>>>>>; >>>>>Andrew Sergeev >>>>>>; Idan >>>>>Kaspit >; >>>>>Mishael Wexler >>>>>>; >>>>>Rotem Cohen > >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>Sorry - the "anonymous presentation" was mine. I should possibly >>>>>have put in a third column on the CW approach. And hopefully the >>>>>minutes will be posted soon. >>>>> >>>>>We had various discussions, as Simon stated, and consensus seemed to >>>>>be forming around the two alternatives of two PWEs or two VLANs. I >>>>>believe three of the authors of the CW approach are also authors of >>>>>the two VLAN approach and one is also an author of the two PWE >>>>>approach. So perhaps it's best to let those four individuals say >>>>>which approach they prefer and why? >>>>> >>>>>Giles >>>>> >>>>>On 10/04/2012 00:45, "Simon Delord" >>>>>> wrote: >>>>> >>>>>> Hi Alexander, >>>>>> >>>>>> You are right, no discussion on the WG mailing list recently, but >>>>>> there have been substantial discussions among the authors of >>>>>> various solution drafts off the mailing list. As far as I know, no >>>>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>>>> meeting. I think the CW approach has not been rejected by the WG >>>>>> yet, or the WG has not yet decided on which one to adopt. >>>>>> >>>>>> Simon >>>>>> >>>>>> 2012/4/8 Alexander Vainshtein >>>>>> >>>>> le.com>> >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>>>> >>>>>>> However, looking up the L2VPN proceedings, I've found a short >>>>>>> anonymous presentation called "E-Tree Update" ( >>>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>>>> This presentation discusses the differences of the E-Tree >>>>>>> approaches based on dedicated VLANs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?includ >>>>>>> e_t >>>>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/ >>>>>>> ?in >>>>>>> clude_te >>>>>>> xt=3D1) >>>>>>> and completely ignores the solution based on usage of the CW in >>>>>>> the PWs connecting the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?includ >>>>>>> e_t >>>>>>> ext=3D1 >>>>>>> ). >>>>>>> >>>>>>> >>>>>>> >>>>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>>>> I wonder whether the WG has taken a decision to reject the >>>>>>> approach based on the CW usage? I do not remember any recent >>>>>>> discussion of this topic on the WG mailing list. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, and lots of thanks in advance, >>>>>>> >>>>>>> Sasha >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This e-mail message is intended for the recipient only and >>>>>>> contains information which is CONFIDENTIAL and which may be >>>>>>> proprietary to ECI >>>>> >>>>>>> Telecom. If you have received this transmission in error, please >>>>>>> inform us by e-mail, phone or fax, and then delete the original >>>>>>> and all copies thereof. >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>>proprietary information, which is privileged, confidential, or >>>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>>intended solely for the use of the individual or entity to which it is >>>>>addressed. >>>>>If you are not the intended recipient of this E-mail, you are hereby >>>>>notified that any dissemination, distribution, copying, or action >>>>>taken in relation to the contents of and attachments to this E-mail >>>>>is strictly prohibited and may be unlawful. If you have received this >>>>>E-mail in error, please notify the sender immediately and permanently >>>>>delete the original and any copy of this E-mail and any printout. >>>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or subject >>>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>>solely for the use of the individual or entity to which it is >>>>addressed. If you are not the intended recipient of this E-mail, you >>>>are hereby notified that any dissemination, distribution, copying, or >>>>action taken in relation to the contents of and attachments to this >>>>E-mail is strictly prohibited and may be unlawful. If you have >>>>received this E-mail in error, please notify the sender immediately >>>>and permanently delete the original and any copy of this E-mail and any >>>>printout. >>> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action taken >>>in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> This e-mail message is intended for the recipient only and contains >>>information which is CONFIDENTIAL and which may be proprietary to ECI >>>Telecom. If you have received this transmission in error, please inform >>>us by e-mail, phone or fax, and then delete the original and all copies >>>thereof. >>> >>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> L2vpn mailing list >>> L2vpn@ietf.org >>> https://www.ietf.org/mailman/listinfo/l2vpn >>> >>> >>> End of L2vpn Digest, Vol 95, Issue 25 >>> *********************************** > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From donald.fedyk@alcatel-lucent.com Wed Apr 25 16:53:07 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AD011E8076 for ; Wed, 25 Apr 2012 16:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.265 X-Spam-Level: X-Spam-Status: No, score=-7.265 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 YXxu5tzLMTv1 for ; Wed, 25 Apr 2012 16:53:04 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1B29C11E8096 for ; Wed, 25 Apr 2012 16:53:04 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q3PNqwKJ027938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Apr 2012 18:52:58 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q3PNqwSF011118 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Apr 2012 18:52:58 -0500 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.145]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Wed, 25 Apr 2012 18:52:58 -0500 From: "Fedyk, Donald (Don)" To: "Rogers, Josh" , David Allan I , Daniel Cohn , "l2vpn@ietf.org" Date: Wed, 25 Apr 2012 18:52:50 -0500 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0jOi+SczvVvIwpS3O2J1dybpgusAAAs8iA Message-ID: References: <60C093A41B5E45409A19D42CF7786DFD52324EF0A6@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {A104BE34-DB00-4E72-8038-31FCFB163838} x-cr-hashedpuzzle: BdO0 BdVA EMHl GBBD JnWC LCRd NVwX UXGq XWrL ZMEP ZxVf asOz ijYv k3C2 mD5i px5K; 4; ZABhAG4AaQBlAGwAYwBAAG8AcgBjAGsAaQB0AC4AYwBvAG0AOwBkAGEAdgBpAGQALgBpAC4AYQBsAGwAYQBuAEAAZQByAGkAYwBzAHMAbwBuAC4AYwBvAG0AOwBqAG8AcwBoAC4AcgBvAGcAZQByAHMAQAB0AHcAYwBhAGIAbABlAC4AYwBvAG0AOwBsADIAdgBwAG4AQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {A104BE34-DB00-4E72-8038-31FCFB163838}; ZABvAG4AYQBsAGQALgBmAGUAZAB5AGsAQABhAGwAYwBhAHQAZQBsAC0AbAB1AGMAZQBuAHQALgBjAG8AbQA=; Wed, 25 Apr 2012 23:52:50 GMT; UgBFADoAIABUAGgAZQAgAHMAdABhAHQAdQBzACAAbwBmACAAdABoAGUAIABhAHAAcAByAG8AYQBjAGgAZQBzACAAdABvACAAdABoAGUAIABFAC0AVAByAGUAZQAgAHMAbwBsAHUAdABpAG8AbgA/AA== acceptlanguage: en-US 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.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 X-BeenThere: l2vpn@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, 25 Apr 2012 23:53:07 -0000 Hi Josh Is there a draft that describes solution A? Solution B is what I've seen in the IEEE. One argument is that A is adding an extra TAG that offers little value. The= TAG you have labeled 2 may need to be swapped anyway. Stacking S-TAGs is = why PBB was developed. Cheers, Don -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Wednesday, April 25, 2012 7:22 PM To: David Allan I; Fedyk, Donald (Don); Daniel Cohn; l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? > Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. I have to apologize, because I think I led y'all down that path (I referred to the outermost tag, the same tag that the MPLS psuedowire is using for vlan mode encamp, as the S-Tag, even though the customer is the one placing it on the frame. Same as I described below, but I either used term S-Tag incorrectly, or ambiguously. >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... So, I think this could be cleared up some still. What I was referring to is the VID that the customer is using to put frames in, the VID which they should use to ensure the frame goes into the correct ETREE instance. You drew a distinction between 'customer VID' vs 'provider VID', but since it is negotiated, I haven't really seen a distinction, which I think is what has caused all the confusion. In the two discussion points/solutions I mentioned, the first one, "A", describes both a coordinated VID which the customer should use, and the service provider uses to distinguish between services on the same UNI, as well as a second, outer, VID which is used by the SP to determine the source AC type. In my example, if you were to sniff inside the psuedowire between PE1 and PE2 to see CE2 destined traffic, wish solution A, you might see "4001:2:Payload", where 4001 designates it is from a root AC, 2 designates the ETREE instance, and Payload is the customer's traffic (which may include a C-Tag), where with solution B, you would see "4001:Payload", and VID 2 would have to be swapped for 4001 as it enters the PE2-CE2 AC, giving the customer "2:Payload" just as they sent it (alternatively SP may choose to simply drop tag entirely and provide "Payload" to customer, this can cause problems with PVST on some devices, but I still see it done occasionally) ** Note, for the example above, I'm assuming 4001 is used as a 'standard' for root sourced frames, and 4002 is used for leaf sourced frames, for the ETREE R/L tags. Have I undone the confusion, or made it worse? -Josh On 4/25/12 5:19 PM, "David Allan I" wrote: >Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. > >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" > >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... > >Cheers >Dave > > > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Wednesday, April 25, 2012 5:42 PM >To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >Dave/Daniel/Lucy/Others Debating how many tags necessary when S-Tag >preservation is desired, > > >I think you all may have gone off on a tangent here. The original >discussion was about how to deal with the situation where the S-Tag is >preserved at a handoff (either an ENNI, or Service Multiplexed UNI) > >I believe there were two suggestions, one was that you push on a 'ETREE' >tag (one of two values, for either a frame sourced from a root AC or >another for a frame from a leaf AC), and the second solution was to 'map'. > > >Imagine the following topology: > >+-----+ +-----+ +-----+ +-----+ >| CE1 |--| PE1 |--| PE2 |--| CE2 | >+-----+ +-----+ +-----+ +-----+ > | | >+-----+ +-----+ +-----+ +-----+ >| CE3 |--| PE3 |--| PE4 |--| CE4 | >+-----+ +-----+ +-----+ +-----+ > >Where: > >Site Type VLAN >CE1 Root X >CE2 Leaf 2 >CE3 Leaf 3 >CE4 Leaf 3 > > >So, there are a lot of SP's who are keen on the way many services can be >handed to a customer on a single UNI, but coordinating a single VLAN per >service, with the customer (MEF used to call this EVPL when it was many >point to point services terminating on a single UNI). So, imagine that >we have two ETREE instances, and an internet service all terminating on a >single UNI connecting to CE1. We have negotiated VLAN ID's with the >customer, and they are expecting to reach CE2 using VLAN 2, CE3 and CE4 >using VLAN 3, and Internet service on VLAN 10. As a frame from CE1 comes >into PE1 destined for CE2 (so the customer has tagged it with VID 2), >using the 2VLAN method, since this is coming from a root site, do we > >a) place the Root S-Tag in front of VID 2, then ship it across, and pop >off the ETREE S-Tag (some SP's wish to Pop the original customer tag VID >2 as well) > >-or- > >b) swap VID2 for the ETREE Root S-Tag, send the frame to PE2 where it >will remove the S-Tag (and either push VID2 back on, or leave it off >depending on SP preference) > >The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf) > > >Hope that clears more than it confuses, >Josh > > > >On 4/25/12 4:22 PM, "Fedyk, Donald (Don)" > wrote: > >>Hi Dave >> >>Yes the only point I would add is Dual VLAN means One VID for Root and >>one VID for Leaf. Not two TAGs at a time on the frame but two allocated >>for the service. >> >>The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks >>about Encapsulation Overhead as a VLAN Tag. While that is true in a PWE >>sense it is still a single VLAN Tag at a time in a Ethernet E-tree sense. >> The compelling driver for Dual VLAN is having a Etree service that >>works in many environments and the DUAL VLAN (really dual VLAN >>interface on a >>VSI) uses the same mechanism (one VID for root and one VID for Leaf at >>a >>time) as specified in the IEEE. In a pure Ethernet bridging world the >>VLAN TAGs for Etree are not typically an overhead since translation is >>used. >> >>Don >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of David Allan I >>Sent: Wednesday, April 25, 2012 5:05 PM >>To: Daniel Cohn; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>OK I feel like I am digressing a fair distance from the actual >>problem.... But here goes: >> >>So the scenarios center around "how ETREE do you want to be?".... >> >>If the ACs are root/leaf, then if they are P2P (single ethernet end >>station attached to each AC) this is moot. ETREE semantics are enforced >>by the 2VID domain in the center of the example. If you assumed nodes >>A&B in the example were L2VPN PEs, the tagging and the PW tag >>imposition all happened at the same point in the network. >> >>If they are not simple P2P all the way to end systems and the objective >>is to avoid bridging between leaf "sites" but allowing intra-leaf-site >>connectivity then the leaves can be LANs but the root is not, such that >>I cannot bridge through the root. But all hosts at a given leaf site >>can see each other. So root Ethernet end systems are directly attached >>or two VIDs are used in the root site. >> >>If the objective is that there are multiple ethernet attached end >>stations at both the leaf and root sites, and the objective is to >>enforce >>L2 isolation everywhere then I need two VIDs extended to the end system >>attachement point in the local LANs by whatever means.... >> >>And I do not see adding VLANs in any particular spot, simply selection >>of the VID and associated semantics where VIDs are translated. The >>actual point of S-tag imposition could be a PE, or cloud be a NID/CLE >>on the customer prem (more likely scenario here to extend OAM demarc to >>the prem), or some switch in a RAN downstream of the MPLS PE... blah >>blah blah. And if ETREE is extended into a customer site LAN and >>outside of the provider domain, then two C-tags would have to be used >>that mapped to S-tags at the PBN boundary... >> >>Make sense? >>Dave >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 25, 2012 4:39 PM >>To: David Allan I; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Dave, but the ACs are root/leaf (that's what the whole vpls etree is >>about - see the reqt draft), so per the 2vlan draft the root/leaf vlan >>must be added. >> >>Thumb typed - please be tolerant >> >>David Allan I wrote: >> >>HI Daniel: >> >>In the example provided, >> >>"ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" >> A B >> >>the service is not ETREE in the domains of the ingress and egress VID. >>It is ELAN. SO there is no root/leaf attribute to shovel around. It >>would require two VIDs in each domain if the ETREE semantics were to be >>telescoped E2E. >> >>Otherwise it is a provisioning of the VID translation tables at the >>intermediate nodes (A&B that I've added to the picture) that would >>determine the VID values used in each domain. Or in the example above, >>what the ingress, Etree and egress VID values were. >> >>Cheers >>Dave >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 3:46 PM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>And to this I asked how this mapping works - how does the egress pe >>recover the ingress vid when it gets the frame tagged with only the >>root/leaf vid? How can you convey the ingress vid plus the root/leaf >>attribute in the same number of bits? >>What am I missing? >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>David Allen already explained the solution. >> >>From David: >>ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. >> >>Ingress VID does not have to equal Egress VID but regardless there is >>only ever one VID on a frame at a time. >> >>-end >> >>This works when customer makes ingress VLAN ID not equal to or equal to >>egress VLAN ID. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 11:39 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Lucy, >> >>The scenario we are discussing is not the E-Tree E-NNI, but a general >>scenario where frames arriving at the root or leaf AC are already >>double tagged. In this case, the dual vlan solution cannot preserve the >>vlans without adding a third one, can it? >> >>Maybe Shahram can add details on the scenario he had in mind >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has S-VLAN preservation attribute for ENNI only because there is no >>s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN >>preservation attribute is used. It applies to E-Tree as well. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Tuesday, April 24, 2012 2:12 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Lucy, >> >>even if the current MEF framework doesn't require s-vlan preservation, >>I believe it's to the industry's benefit to adopt a solution that is >>not constrained to a specific enni model that, like all things >>networking, is likely to evolve. Especially when such a solution is >>available. >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has worked in ENNI interface for a long time with many service >>providers' inputs. It had a fair reason to assume S-VLAN over ENNI by >>then. It may open B-VLAN for the future. It is better for us not to >>discuss a future framework here, because it will lead us to nowhere. >>Here, we want to extend VPLS in supporting E-Tree. >> >>Best Regards, >>Lucy >> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Sunday, April 22, 2012 7:34 AM >>To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Shahram and all, >> >>This question already came up in our discussions - is it safe to assume >>that the VLAN tags at the E-NNI will always be according to the current >>MEF model? Or should we try to be as transparent as possible to user >>VLAN encapsulation at the E-NNI, to accommodate future frameworks? >>I believe that any approach that looks at user payload (in this case >>VLAN >>tag) to signal VPLS information (in this case root/leaf origin) is >>necessarily tied to specific assumptions on user payload encapsulation >>(in this case, that S-VLAN tag is "available" to encode root/leaf). I >>don't think this is a future-proof assumption, it's very likely that >>other network models will come up that require S-VLAN preservation, >>which in the 2-VLAN approach would necessitate adding a third VLAN-ID. >> >>Daniel >> >>From: Shahram Davari > >>To: Lizhong Jin >, >>"l2vpn@ietf.org" >>>, >>"Alexander.Vainshtein@ecitele.com>om> >>" >>>om> >>> >>Cc: "yuqun.cao@gmail.com" >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, >> >>I also have a question regarding 2-VLAN. What if the customer traffic >>already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? >> >>Thx >>Shahram >> >>From: l2vpn-bounces@ietf.org >>[mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin >>Sent: Friday, April 20, 2012 9:38 AM >>To: l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com>m> >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, all, >>The difference between 2-VLAN and CW approach is who will provide the >>R/L information, customer payload or PW? The customer payload will be >>always modified to carry R/L information in 2-VLAN approach, while PW >>with CW will carry R/L information for CW approach. >>I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is >>accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is >>used to access H-VPLS, how could the PE on VPWS side adds VLAN to >>indicate R/L information? >> >>Thanks >>Lizhong >> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Thu, 19 Apr 2012 04:38:36 +0000 >>> From: Alexander Vainshtein >>> >> com>> >>> To: "Rogers, Josh" >>>>, Lucy yong >>> >, Daniel >>>Cohn >, Sam Cao >>> > >>> Cc: "l2vpn@ietf.org" >>> > >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> Message-ID: >>> >>> >> t o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> >>> Content-Type: text/plain; charset=3D"us-ascii" >>> >>> Hi all, >>> I fully understand that that what I am going to say is not very >>>popular, but: >>> >>> IMO one of the advantages of the CW-based solution is that it is >>>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery >>>of BUN traffic. >>> >>> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>>and, in a more generic way, localization of effects of changes in the >>>PE configuration. >>> >>> In particular, adding a Leaf AC to a PE that previously has been only >>>supporting Root ACs (or vice versa), removal of the last Leaf or last >>>Root AC from a PE that previously has been supporting a mix etc. >>>affect only the PE where this operation happens and not the rest of the >>>PEs. >>> >>> As for the need for HW changes that have been mentioned as a main >>>disadvantage of the CW-based approach - I believe it strongly depends >>>on specific implementations. And some changes in the forwarding >>>process are required in any solution. >>> >>> My 2c, >>> Sasha >>> >>> >>> >>> ________________________________________ >>> From: l2vpn-bounces@ietf.org >>> [l2vpn-bounces@ietf.org] on behalf of >>> Rogers, Josh >>> [josh.rogers@twcable.com] >>> Sent: Wednesday, April 18, 2012 9:57 PM >>> To: Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: Re: The status of the approaches to the E-Tree solution? >>> >>> Again, the P2MP situation throws me. Is this something that is used >>> commonly? >>> >>> I'm under the impression that adding P2MP to any model results in a >>> more complex model. Wether outside s-tag is used to differentiate, >>> or dedicated pw's are used for the same purpose, it seems both become >>> more complex. >>> >>> Gile's comparison slide still concisely captures the differences >>>between these methods, in my opinion. I haven't seen any new ideas or >>>thoughts brought to the group in the past week or two on the subject. >>> I would hate for both proposed methods to die on the vine because we >>>couldn't decide between two methods that have nothing inherently wrong >>>with either. >>> >>> -Josh >>> >>> >>> On 4/18/12 1:53 PM, "Lucy yong" >>>> wrote: >>> >>>>Send this again. >>>> >>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>>double all of them. >>>> >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn >>>>[mailto:DanielC@orckit.com] >>>>Sent: Wednesday, April 18, 2012 1:42 PM >>>>To: Lucy yong; Rogers, Josh; Sam Cao >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>I think the first option its the natural way to go. How is the >>>>processing in this case more complex? >>>> >>>>Thumb typed - please be tolerant >>>> >>>>Lucy yong > wrote: >>>> >>>> >>>> >>>>Snipped.. >>>> >>>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only >>>>P2MP PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP >>>>PW (for traffic coming from a root AC) [[LY]] Not that simple. You >>>>construct either two P2MP PWs to all other PEs and let egress PE >>>>performing filtering, or construct one P2MP PW to leaf-only PEs and >>>>two P2MP PWs to root and leaf PEs and let ingress PE perform >>>>forwarding and filtering. Both make node process complex. >>>> >>>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>>>delivering the frames to remote PEs. We should utilize them with the >>>>minimized changes. Dual VLAN solution is simpler than Dual PW. >>>> >>>>Regards, >>>>Lucy >>>> >>>> >>>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>>>haven't had any first hand experience with P2MP PW's, however, so >>>>don't feel terribly strong about this objection. Is this a real >>>>problem for others (now or in the future), or is this objection in >>>>the weeds? >>>> >>>>I'm not sure the 'additional complexity' is notable, or even relevant. >>>>I encourage others to speak up if they disagree, as P2MP PW is only >>>>conceptual to me, and I am unfamiliar with real-life use cases for it. >>>> >>>>Thanks, >>>>Josh >>>> >>>> >>>> >>>>On 4/18/12 10:30 AM, "Lucy yong" >>>>> wrote: >>>> >>>>>Please see inline. >>>>> >>>>>-----Original Message----- >>>>>From: Sam Cao >>>>>[mailto:yuqun.cao@gmail.com] >>>>>Sent: Tuesday, April 17, 2012 7:14 AM >>>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>>>(Wim)'; giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>>>> >>>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>>>PE have both root and leaf AC and some only have leaf ACs)? >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Yuqun (Sam) Cao >>>>>E-mail: Yuqun.cao@gmail.com >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn >>>>>[mailto:DanielC@orckit.com] >>>>>Sent: Tuesday, April 17, 2012 4:56 PM >>>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com>; Sam Cao >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Adding Sam (as l2vpn@ is holding messages) >>>>> >>>>>DC >>>>> >>>>>-----Original Message----- >>>>>From: Lucy yong >>>>>[mailto:lucy.yong@huawei.com] >>>>>Sent: Tuesday, April 17, 2012 12:39 AM >>>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>> >>>>>Snipped, >>>>> >>>>>As we discussed extensively in the list, and as reflected in giles >>>>>slide, 2 pws are only needed between pes with both root and leaf >>>>>acs, which will typically be a small minority. >>>>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>>>both approaches can benefit from it. I was off for a while and >>>>>captures some discussions now. >>>>> >>>>>Also as per giles slide, dual vlan can have scalability issues due >>>>>to additional lookup and double use of vlans in internal emulated >>>>>lan interface. Also there are potential backward compatibility >>>>>issues with silicon that doesn't support vlan mapping. >>>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. >>>>>I am not clear on all the issues. Could you be more specific? As I >>>>>mentioned in below, two PW approach makes VPLS transport >>>>>construction and packet forwarding more complex, I can see potential >>>>>backward compatibility issues with 2 PW solution. >>>>> >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Daniel >>>>> >>>>>Thumb typed - please be tolerant >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>>In my mind, the VLAN approach means dual vlan method. >>>>> >>>>>The main concern for CW approach is hardware support. >>>>> >>>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and >>>>>unknown unicast traffic, and some P2MP PWs for multicast traffic. It >>>>>may double all of them. >>>>> >>>>>E-tree is an Ethernet service and there is already VLAN based >>>>>solution in IEEE, can we just utilize it without complicating VPLS >>>>>transport construction? This also makes interworking with Eth only >>>>>network easier. >>>>> >>>>>Cheers, >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: Rogers, Josh >>>>>[mailto:josh.rogers@twcable.com] >>>>>Sent: Monday, April 16, 2012 8:35 AM >>>>>To: Lucy yong; Henderickx, Wim (Wim); >>>>>'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com'; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>I believe the initial question was in regard to the CW method. Are >>>>>you saying that you no longer are interested in that method in >>>>>preference of the dual vlan method? >>>>> >>>>> >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>> >>>>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>>>> >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: l2vpn-bounces@ietf.org >>>>>[mailto:l2vpn-bounces@ietf.org] On >>>>>Behalf Of Henderickx, Wim (Wim) >>>>>Sent: Thursday, April 12, 2012 2:03 AM >>>>>To: 'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com'; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>The vlan approach is superior as it also works for eth only >>>>>networks, etc. On top some vendors indicate hw issues with the cw >>>>>approach. As such we have dropped more or less the cw approach. >>>>> >>>>>Cheers, >>>>>Wim >>>>>_________________ >>>>>sent from blackberry >>>>> >>>>>----- Original Message ----- >>>>>From: Giles Heron >>>>>[mailto:giles.heron@gmail.com] >>>>>Sent: Thursday, April 12, 2012 08:22 AM >>>>>To: Simon Delord >>>>>>; Alexander >>>>>Vainshtein >>>>>>>>>e >>>>>.com>> >>>>>Cc: l2vpn@ietf.org >>>>>>; Vladimir Kleiner >>>>>>; >>>>>Andrew Sergeev >>>>>>; >>>>>Idan Kaspit >>>>>>; >>>>>Mishael Wexler >>>>>>; >>>>>Rotem Cohen >>>>>> >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>Sorry - the "anonymous presentation" was mine. I should possibly >>>>>have put in a third column on the CW approach. And hopefully the >>>>>minutes will be posted soon. >>>>> >>>>>We had various discussions, as Simon stated, and consensus seemed to >>>>>be forming around the two alternatives of two PWEs or two VLANs. I >>>>>believe three of the authors of the CW approach are also authors of >>>>>the two VLAN approach and one is also an author of the two PWE >>>>>approach. So perhaps it's best to let those four individuals say >>>>>which approach they prefer and why? >>>>> >>>>>Giles >>>>> >>>>>On 10/04/2012 00:45, "Simon Delord" >>>>>> wrote: >>>>> >>>>>> Hi Alexander, >>>>>> >>>>>> You are right, no discussion on the WG mailing list recently, but >>>>>> there have been substantial discussions among the authors of >>>>>> various solution drafts off the mailing list. As far as I know, no >>>>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>>>> meeting. I think the CW approach has not been rejected by the WG >>>>>> yet, or the WG has not yet decided on which one to adopt. >>>>>> >>>>>> Simon >>>>>> >>>>>> 2012/4/8 Alexander Vainshtein >>>>>> >>>>> e >>>>>> le.com>> >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>>>> >>>>>>> However, looking up the L2VPN proceedings, I've found a short >>>>>>> anonymous presentation called "E-Tree Update" ( >>>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>>>> This presentation discusses the differences of the E-Tree >>>>>>> approaches based on dedicated VLANs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw >>>>>>> / >>>>>>> ?in >>>>>>> clude_te >>>>>>> xt=3D1) >>>>>>> and completely ignores the solution based on usage of the CW in >>>>>>> the PWs connecting the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1 >>>>>>> ). >>>>>>> >>>>>>> >>>>>>> >>>>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>>>> I wonder whether the WG has taken a decision to reject the >>>>>>> approach based on the CW usage? I do not remember any recent >>>>>>> discussion of this topic on the WG mailing list. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, and lots of thanks in advance, >>>>>>> >>>>>>> Sasha >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This e-mail message is intended for the recipient only and >>>>>>> contains information which is CONFIDENTIAL and which may be >>>>>>> proprietary to ECI >>>>> >>>>>>> Telecom. If you have received this transmission in error, please >>>>>>> inform us by e-mail, phone or fax, and then delete the original >>>>>>> and all copies thereof. >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>>proprietary information, which is privileged, confidential, or >>>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>>intended solely for the use of the individual or entity to which it >>>>>is addressed. >>>>>If you are not the intended recipient of this E-mail, you are hereby >>>>>notified that any dissemination, distribution, copying, or action >>>>>taken in relation to the contents of and attachments to this E-mail >>>>>is strictly prohibited and may be unlawful. If you have received >>>>>this E-mail in error, please notify the sender immediately and >>>>>permanently delete the original and any copy of this E-mail and any >>>>>printout. >>>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or >>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>intended solely for the use of the individual or entity to which it >>>>is addressed. If you are not the intended recipient of this E-mail, >>>>you are hereby notified that any dissemination, distribution, >>>>copying, or action taken in relation to the contents of and >>>>attachments to this E-mail is strictly prohibited and may be >>>>unlawful. If you have received this E-mail in error, please notify >>>>the sender immediately and permanently delete the original and any >>>>copy of this E-mail and any printout. >>> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> This e-mail message is intended for the recipient only and contains >>>information which is CONFIDENTIAL and which may be proprietary to ECI >>>Telecom. If you have received this transmission in error, please >>>inform us by e-mail, phone or fax, and then delete the original and >>>all copies thereof. >>> >>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> L2vpn mailing list >>> L2vpn@ietf.org >>> https://www.ietf.org/mailman/listinfo/l2vpn >>> >>> >>> End of L2vpn Digest, Vol 95, Issue 25 >>> *********************************** > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From jiangyuanlong@huawei.com Wed Apr 25 18:58:54 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6218021E8094 for ; Wed, 25 Apr 2012 18:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599] 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 rpk85OdRqRZI for ; Wed, 25 Apr 2012 18:58:53 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id CC56821E8043 for ; Wed, 25 Apr 2012 18:58:52 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFF56571; Wed, 25 Apr 2012 21:58:52 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 18:57:14 -0700 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 18:57:19 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.137]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Thu, 26 Apr 2012 09:57:13 +0800 From: Jiangyuanlong To: David Allan I , Daniel Cohn , "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNI0/l6GqoqS6Ta0Siyw6GaodXKQ== Date: Thu, 26 Apr 2012 01:57:12 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3F1D7@SZXEML508-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Cbbq DZOf DjF5 FaBR Gw5P Hk+T HoHC JiNg LzIG OOMi R0fe XkfQ ZheU fSBJ gWST k7Qm; 3; ZABhAG4AaQBlAGwAYwBAAG8AcgBjAGsAaQB0AC4AYwBvAG0AOwBkAGEAdgBpAGQALgBpAC4AYQBsAGwAYQBuAEAAZQByAGkAYwBzAHMAbwBuAC4AYwBvAG0AOwBsADIAdgBwAG4AQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {D22AFBA7-4418-481E-A420-A2EEA14FE5B1}; agBpAGEAbgBnAHkAdQBhAG4AbABvAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Thu, 26 Apr 2012 01:57:06 GMT; UgBFADoAIABUAGgAZQAgAHMAdABhAHQAdQBzACAAbwBmACAAdABoAGUAIABhAHAAcAByAG8AYQBjAGgAZQBzACAAdABvACAAdABoAGUAIABFAC0AVAByAGUAZQAgAHMAbwBsAHUAdABpAG8AbgA/AA== x-cr-puzzleid: {D22AFBA7-4418-481E-A420-A2EEA14FE5B1} x-originating-ip: [10.70.40.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@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, 26 Apr 2012 01:58:54 -0000 A good analysis of the implication for S-VLAN access. This reminds me of an= old email in the mailing list proposing E-Tree over E-Tree. It seems both = E-LAN over E-Tree and E-Tree over E-Tree scenarios can be supported with Du= al VLAN as you analyzed. However I am not sure any SP has such requirements yet. Best Regards, Yuanlong ---------------------------------------------------------------------- Date: Wed, 25 Apr 2012 17:04:57 -0400 From: David Allan I To: Daniel Cohn , "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <60C093A41B5E45409A19D42CF7786DFD52324EEFF1@EUSAACMS0703.eamcs.ericsson.se= > =09 Content-Type: text/plain; charset=3D"us-ascii" OK I feel like I am digressing a fair distance from the actual problem.... = But here goes: So the scenarios center around "how ETREE do you want to be?".... If the ACs are root/leaf, then if they are P2P (single ethernet end station= attached to each AC) this is moot. ETREE semantics are enforced by the 2VI= D domain in the center of the example. If you assumed nodes A&B in the exam= ple were L2VPN PEs, the tagging and the PW tag imposition all happened at t= he same point in the network. If they are not simple P2P all the way to end systems and the objective is = to avoid bridging between leaf "sites" but allowing intra-leaf-site connect= ivity then the leaves can be LANs but the root is not, such that I cannot b= ridge through the root. But all hosts at a given leaf site can see each oth= er. So root Ethernet end systems are directly attached or two VIDs are used= in the root site. If the objective is that there are multiple ethernet attached end stations = at both the leaf and root sites, and the objective is to enforce L2 isolati= on everywhere then I need two VIDs extended to the end system attachement p= oint in the local LANs by whatever means.... And I do not see adding VLANs in any particular spot, simply selection of t= he VID and associated semantics where VIDs are translated. The actual point= of S-tag imposition could be a PE, or cloud be a NID/CLE on the customer p= rem (more likely scenario here to extend OAM demarc to the prem), or some s= witch in a RAN downstream of the MPLS PE... blah blah blah. And if ETREE is= extended into a customer site LAN and outside of the provider domain, then= two C-tags would have to be used that mapped to S-tags at the PBN boundary= ... Make sense? Dave -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Wednesday, April 25, 2012 4:39 PM To: David Allan I; l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Dave, but the ACs are root/leaf (that's what the whole vpls etree is about = - see the reqt draft), so per the 2vlan draft the root/leaf vlan must be ad= ded. Thumb typed - please be tolerant David Allan I wrote: HI Daniel: In the example provided, "ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" A B the service is not ETREE in the domains of the ingress and egress VID. It i= s ELAN. SO there is no root/leaf attribute to shovel around. It would requi= re two VIDs in each domain if the ETREE semantics were to be telescoped E2E= . Otherwise it is a provisioning of the VID translation tables at the interme= diate nodes (A&B that I've added to the picture) that would determine the V= ID values used in each domain. Or in the example above, what the ingress, E= tree and egress VID values were. Cheers Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Wednesday, April 25, 2012 3:46 PM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? And to this I asked how this mapping works - how does the egress pe recover= the ingress vid when it gets the frame tagged with only the root/leaf vid?= How can you convey the ingress vid plus the root/leaf attribute in the sam= e number of bits? What am I missing? Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, David Allen already explained the solution. From jiangyuanlong@huawei.com Wed Apr 25 19:07:58 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6383321E80AF for ; Wed, 25 Apr 2012 19:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] 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 azKo4SgGYlvD for ; Wed, 25 Apr 2012 19:07:57 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE6221E8043 for ; Wed, 25 Apr 2012 19:07:57 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFN59801; Wed, 25 Apr 2012 22:07:57 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 19:04:27 -0700 Received: from SZXEML438-HUB.china.huawei.com (10.72.61.73) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 19:04:25 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.137]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Thu, 26 Apr 2012 10:03:55 +0800 From: Jiangyuanlong To: "Fedyk, Donald (Don" , "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNI1DlcoUNyRbclUW9hL/CzU216w== Date: Thu, 26 Apr 2012 02:04:21 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3F1EA@SZXEML508-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: BUiF Bl5t D+p+ EnBq H5tl JSnT Lizr Mri8 OlQM PFOA UKpW VUKY Vzyx WIpc W/Lj XV3R; 2; ZABvAG4AYQBsAGQALgBmAGUAZAB5AGsAQABhAGwAYwBhAHQAZQBsAC0AbAB1AGMAZQBuAHQALgBjAG8AbQA7AGwAMgB2AHAAbgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {256FCC9A-0BA6-4B04-A046-68D046CEA7E6}; agBpAGEAbgBnAHkAdQBhAG4AbABvAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Thu, 26 Apr 2012 02:04:18 GMT; UgBFADoAIABUAGgAZQAgAHMAdABhAHQAdQBzACAAbwBmACAAdABoAGUAIABhAHAAcAByAG8AYQBjAGgAZQBzACAAdABvACAAdABoAGUAIABFAC0AVAByAGUAZQAgAHMAbwBsAHUAdABpAG8AbgA/AA== x-cr-puzzleid: {256FCC9A-0BA6-4B04-A046-68D046CEA7E6} x-originating-ip: [10.70.40.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@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, 26 Apr 2012 02:07:58 -0000 Don, Exactly, that is the intention of the Dual VLAN draft. Thanks, Yuanlong ------------------------------ Date: Wed, 25 Apr 2012 16:22:38 -0500 From: "Fedyk, Donald (Don)" To: David Allan I , Daniel Cohn , "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: =09 Content-Type: text/plain; charset=3D"us-ascii" Hi Dave Yes the only point I would add is Dual VLAN means One VID for Root and one = VID for Leaf. Not two TAGs at a time on the frame but two allocated for the= service. The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks abo= ut Encapsulation Overhead as a VLAN Tag. While that is true in a PWE sense = it is still a single VLAN Tag at a time in a Ethernet E-tree sense. The co= mpelling driver for Dual VLAN is having a Etree service that works in many = environments and the DUAL VLAN (really dual VLAN interface on a VSI) uses t= he same mechanism (one VID for root and one VID for Leaf at a time) as spec= ified in the IEEE. In a pure Ethernet bridging world the VLAN TAGs for Etre= e are not typically an overhead since translation is used. Don -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= avid Allan I Sent: Wednesday, April 25, 2012 5:05 PM To: Daniel Cohn; l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? OK I feel like I am digressing a fair distance from the actual problem.... = But here goes: So the scenarios center around "how ETREE do you want to be?".... If the ACs are root/leaf, then if they are P2P (single ethernet end station= attached to each AC) this is moot. ETREE semantics are enforced by the 2VI= D domain in the center of the example. If you assumed nodes A&B in the exam= ple were L2VPN PEs, the tagging and the PW tag imposition all happened at t= he same point in the network. If they are not simple P2P all the way to end systems and the objective is = to avoid bridging between leaf "sites" but allowing intra-leaf-site connect= ivity then the leaves can be LANs but the root is not, such that I cannot b= ridge through the root. But all hosts at a given leaf site can see each oth= er. So root Ethernet end systems are directly attached or two VIDs are used= in the root site. If the objective is that there are multiple ethernet attached end stations = at both the leaf and root sites, and the objective is to enforce L2 isolati= on everywhere then I need two VIDs extended to the end system attachement p= oint in the local LANs by whatever means.... And I do not see adding VLANs in any particular spot, simply selection of t= he VID and associated semantics where VIDs are translated. The actual point= of S-tag imposition could be a PE, or cloud be a NID/CLE on the customer p= rem (more likely scenario here to extend OAM demarc to the prem), or some s= witch in a RAN downstream of the MPLS PE... blah blah blah. And if ETREE is= extended into a customer site LAN and outside of the provider domain, then= two C-tags would have to be used that mapped to S-tags at the PBN boundary= ... Make sense? Dave -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Wednesday, April 25, 2012 4:39 PM To: David Allan I; l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Dave, but the ACs are root/leaf (that's what the whole vpls etree is about = - see the reqt draft), so per the 2vlan draft the root/leaf vlan must be ad= ded. Thumb typed - please be tolerant David Allan I wrote: HI Daniel: In the example provided, "ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" A B the service is not ETREE in the domains of the ingress and egress VID. It i= s ELAN. SO there is no root/leaf attribute to shovel around. It would requi= re two VIDs in each domain if the ETREE semantics were to be telescoped E2E= . Otherwise it is a provisioning of the VID translation tables at the interme= diate nodes (A&B that I've added to the picture) that would determine the V= ID values used in each domain. Or in the example above, what the ingress, E= tree and egress VID values were. Cheers Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: Wednesday, April 25, 2012 3:46 PM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; A= lexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? And to this I asked how this mapping works - how does the egress pe recover= the ingress vid when it gets the frame tagged with only the root/leaf vid?= How can you convey the ingress vid plus the root/leaf attribute in the sam= e number of bits? What am I missing? Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, David Allen already explained the solution. --- stipped ----------------- From yuqun.cao@gmail.com Wed Apr 25 19:11:12 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BADE221F8848 for ; Wed, 25 Apr 2012 19:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.893 X-Spam-Level: X-Spam-Status: No, score=-2.893 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyHxwi+Gj-zo for ; Wed, 25 Apr 2012 19:11:10 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9191F21F8846 for ; Wed, 25 Apr 2012 19:11:10 -0700 (PDT) Received: by dady13 with SMTP id y13so1327819dad.27 for ; Wed, 25 Apr 2012 19:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :in-reply-to:x-mimeole; bh=K5ulThO54x/L1GHR77j7GLAA9wj+VIkKDXZM+Lnasnc=; b=QOcVC+GbCXkC3XQUrmLqsoN2VO4zEfgMnHP1/95+45BfpCAK20P/ctaRTvkvZgJglT fD6exmR3izg57dUkLqQsonTukKnham2PD0BJh+48Pj401oXsfrkSIia5w0CsakJQo7Kf YJhV9yfKvfIYazgIuIaaMlKA8gTMH3uRAh2O8orX3yJhOu22Yzd4n+mGOAi61QeV1yVI Dda70hknzFqfwA9gbj5cW5tYWfkrhxxVzpF9H9spEK0ChGm3EnpUudRN5S3xJDgmjTp7 hxm9B5UxfVkr8LC3jUqPlIDsEX8PURZcVCkfPUKyrjlHR0AZWOZabibNWD+Imr+JgjpQ VA2A== Received: by 10.68.240.5 with SMTP id vw5mr11697341pbc.110.1335406269098; Wed, 25 Apr 2012 19:11:09 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id d6sm1790111pbi.23.2012.04.25.19.11.04 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Apr 2012 19:11:07 -0700 (PDT) From: "Sam Cao" To: References: Subject: RE: L2vpn Digest, Vol 95, Issue 93 Date: Thu, 26 Apr 2012 10:11:03 +0800 Message-ID: <2CF7D8B0066C43E793BFBB6EC21D3117@R01842> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac0jJrsymEv6P9vTQlaKer/7cNnolQAKbiaQ In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: l2vpn@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, 26 Apr 2012 02:11:12 -0000 Lucy, I am confused with "use local translation instead of mapping". My understanding on this is, there is VLAN mapping negotiation between ingress PE and egress PE. This meeting global VLAN allocation is proposed, but based on my understanding, we should add new VLAN ID, for raw mode or tagged mode. Anything missing? Thanks, Sam -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of l2vpn-request@ietf.org Sent: Thursday, April 26, 2012 5:02 AM To: l2vpn@ietf.org Subject: L2vpn Digest, Vol 95, Issue 93 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/l2vpn Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send L2vpn mailing list submissions to l2vpn@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/l2vpn or, via email, send a message with subject or body 'help' to l2vpn-request@ietf.org You can reach the person managing the list at l2vpn-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of L2vpn digest..." Today's Topics: 1. RE: The status of the approaches to the E-Tree solution? (Lucy yong) ---------------------------------------------------------------------- Message: 1 Date: Wed, 25 Apr 2012 20:59:59 +0000 From: Lucy yong To: Daniel Cohn , "Rogers, Josh" , Shahram Davari , Lizhong Jin , "l2vpn@ietf.org" , "Alexander.Vainshtein@ecitele.com" Cc: "yuqun.cao@gmail.com" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264C1A2@dfweml505-mbx> Content-Type: text/plain; charset="utf-8" The current VLAN draft does not assume double tag frame at AC. If we have to consider this case, the solution was discussed in the e-mail. I should use local translation instead of mapping in previous e-mail, which makes it more clear. In this case, PE knows which S-VLAN ID is used on an AC, so PE inserts the same S-VLAN ID on the frames going toward to the AC. This is the part you missed. Lucy -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Wednesday, April 25, 2012 3:31 PM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, don't understand what you mean by "obey the rule first". Say you get a frame with double tag at a leaf ac. According to the 2 vlan draft, you must add the leaf vlan before forwarding the frame to the mpls, otherwise the egress pe won't know it can only forward the frame over root acs. If you remove the outer tag on ingress, how can you recover it on egress? If you don't remove it, you get a 3-deep stack. Daniel Thumb typed - please be tolerant Lucy yong wrote: Local mapping is sufficient for this. If a customer wish both ingress VLAN ID and egress VLAN ID are the same, it obeys the rule first, then local translate in MPLS will work perfectly. Lucy -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Wednesday, April 25, 2012 2:46 PM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? And to this I asked how this mapping works - how does the egress pe recover the ingress vid when it gets the frame tagged with only the root/leaf vid? How can you convey the ingress vid plus the root/leaf attribute in the same number of bits? What am I missing? Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, David Allen already explained the solution. >From David: ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. Ingress VID does not have to equal Egress VID but regardless there is only ever one VID on a frame at a time. -end This works when customer makes ingress VLAN ID not equal to or equal to egress VLAN ID. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: Wednesday, April 25, 2012 11:39 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi Lucy, The scenario we are discussing is not the E-Tree E-NNI, but a general scenario where frames arriving at the root or leaf AC are already double tagged. In this case, the dual vlan solution cannot preserve the vlans without adding a third one, can it? Maybe Shahram can add details on the scenario he had in mind Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has S-VLAN preservation attribute for ENNI only because there is no s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN preservation attribute is used. It applies to E-Tree as well. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: Tuesday, April 24, 2012 2:12 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, even if the current MEF framework doesn't require s-vlan preservation, I believe it's to the industry's benefit to adopt a solution that is not constrained to a specific enni model that, like all things networking, is likely to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service providers' inputs. It had a fair reason to assume S-VLAN over ENNI by then. It may open B-VLAN for the future. It is better for us not to discuss a future framework here, because it will lead us to nowhere. Here, we want to extend VPLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume that the VLAN tags at the E-NNI will always be according to the current MEF model? Or should we try to be as transparent as possible to user VLAN encapsulation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case VLAN tag) to signal VPLS information (in this case root/leaf origin) is necessarily tied to specific assumptions on user payload encapsulation (in this case, that S-VLAN tag is "available" to encode root/leaf). I don't think this is a future-proof assumption, it's very likely that other network models will come up that require S-VLAN preservation, which in the 2-VLAN approach would necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, "l2vpn@ietf.org" >, "Alexander.Vainshtein@ecitele.com" > Cc: "yuqun.cao@gmail.com" > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW will carry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > > To: "Rogers, Josh" >, Lucy yong > >, Daniel Cohn >, Sam Cao > > > Cc: "l2vpn@ietf.org" > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, but: > > IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BUN traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes in the PE configuration. > > In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root AC from a PE that previously has been supporting a mix etc. affect only the PE where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers, Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a more > complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become more > complex. > > Gile's comparison slide still concisely captures the differences between > these methods, in my opinion. I haven't seen any new ideas or thoughts > brought to the group in the past week or two on the subject. I would hate > for both proposed methods to die on the vine because we couldn't decide > between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may double >>all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the processing >>in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >>traffic coming from a root AC) >>[[LY]] Not that simple. You construct either two P2MP PWs to all other >>PEs and let egress PE performing filtering, or construct one P2MP PW to >>leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >>perform forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so don't >>feel terribly strong about this objection. Is this a real problem for >>others (now or in the future), or is this objection in the weeds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. I >>encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>>giles.heron@gmail.com; simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs after >>>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>>P2MP >>>PWs if need. There is no difference between P2MP or normal PW setup. But, >>>can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>>both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong [mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, both >>>approaches can benefit from it. I was off for a while and captures some >>>discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues with >>>silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>>not clear on all the issues. Could you be more specific? As I mentioned >>>in below, two PW approach makes VPLS transport construction and packet >>>forwarding more complex, I can see potential backward compatibility >>>issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>>traffic, and some P2MP PWs for multicast traffic. It may double all of >>>them. >>> >>>E-tree is an Ethernet service and there is already VLAN based solution >>>in IEEE, can we just utilize it without complicating VPLS transport >>>construction? This also makes interworking with Eth only network easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are you >>>saying that you no longer are interested in that method in preference of >>>the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron [mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord >; Alexander Vainshtein >>>> >>>Cc: l2vpn@ietf.org >; Vladimir Kleiner >>>>; Andrew Sergeev >>>>; Idan Kaspit >; >>>Mishael Wexler >; Rotem Cohen >>>> >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly have >>>put in a third column on the CW approach. And hopefully the minutes >>>will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to be >>>forming around the two alternatives of two PWEs or two VLANs. I believe >>>three of the authors of the CW approach are also authors of the two VLAN >>>approach and one is also an author of the two PWE approach. So perhaps >>>it's best to let those four individuals say which approach they prefer >>>and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of various >>>> solution drafts off the mailing list. As far as I know, no consensus >>>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>>> think the CW approach has not been rejected by the WG yet, or the WG >>>> has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein > >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree approaches >>>>> based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>>> ext=1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>>> clude_te >>>>> xt=1) >>>>> and completely ignores the solution based on usage of the CW in the >>>>> PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>>> ext=1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>>> wonder whether the WG has taken a decision to reject the approach >>>>> based on the CW usage? I do not remember any recent discussion of >>>>> this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and contains >>>>> information which is CONFIDENTIAL and which may be proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original and >>>>> all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action taken >>>in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use of the individual or entity to which it is addressed. If you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 93 ************************************* From jiangyuanlong@huawei.com Wed Apr 25 19:23:23 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380CE11E809D for ; Wed, 25 Apr 2012 19:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HS_INDEX_PARAM=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 q0eOq8HkFOvs for ; Wed, 25 Apr 2012 19:23:20 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1262211E80B4 for ; Wed, 25 Apr 2012 19:23:20 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFN60583; Wed, 25 Apr 2012 22:23:19 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 19:21:20 -0700 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 19:21:24 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.137]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Thu, 26 Apr 2012 10:21:21 +0800 From: Jiangyuanlong To: "Fedyk, Donald (Don" , "Rogers, Josh" Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNI1NEA18PKDoBDEy6zAcXiVu2Lg== Date: Thu, 26 Apr 2012 02:21:20 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3F298@SZXEML508-MBS.china.huawei.com> References: 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.70.40.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 26 Apr 2012 02:23:23 -0000 Hi Don and Josh, draft-jiang-l2vpn-vpls-pe-etree-05 discussed S-VLAN access in the following= way: "... For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames received f= rom the root ACs can be translated to the root S-VLAN in the VPLS network d= omain. Alternatively, the PBB VPLS PE model (where an IEEE 802.1ah bridge m= odule is embedded in the PE) as described in [PBB-VPLS] can be used, and a = root B-VLAN or leaf B-VLAN can be added in this case. In a similar way, the traffic from the leaf ACs is tagged and transported o= n the leaf C-VLAN, S-VLAN or B-VLAN.=20 " It seems option B is in line with the 1st sentence, not sure where option A= came from, but do you have any concerns with the description in the 2nd se= ntence? Regards, Yuanlong ---------------------------------------------------------------------- Date: Wed, 25 Apr 2012 18:52:50 -0500 From: "Fedyk, Donald (Don)" To: "Rogers, Josh" , David Allan I , Daniel Cohn , "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: =09 Content-Type: text/plain; charset=3D"us-ascii" Hi Josh Is there a draft that describes solution A? Solution B is what I've seen in the IEEE. One argument is that A is adding an extra TAG that offers little value. The= TAG you have labeled 2 may need to be swapped anyway. Stacking S-TAGs is = why PBB was developed. Cheers, Don -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Wednesday, April 25, 2012 7:22 PM To: David Allan I; Fedyk, Donald (Don); Daniel Cohn; l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? > Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. I have to apologize, because I think I led y'all down that path (I referred to the outermost tag, the same tag that the MPLS psuedowire is using for vlan mode encamp, as the S-Tag, even though the customer is the one placing it on the frame. Same as I described below, but I either used term S-Tag incorrectly, or ambiguously. >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... So, I think this could be cleared up some still. What I was referring to is the VID that the customer is using to put frames in, the VID which they should use to ensure the frame goes into the correct ETREE instance. You drew a distinction between 'customer VID' vs 'provider VID', but since it is negotiated, I haven't really seen a distinction, which I think is what has caused all the confusion. In the two discussion points/solutions I mentioned, the first one, "A", describes both a coordinated VID which the customer should use, and the service provider uses to distinguish between services on the same UNI, as well as a second, outer, VID which is used by the SP to determine the source AC type. In my example, if you were to sniff inside the psuedowire between PE1 and PE2 to see CE2 destined traffic, wish solution A, you might see "4001:2:Payload", where 4001 designates it is from a root AC, 2 designates the ETREE instance, and Payload is the customer's traffic (which may include a C-Tag), where with solution B, you would see "4001:Payload", and VID 2 would have to be swapped for 4001 as it enters the PE2-CE2 AC, giving the customer "2:Payload" just as they sent it (alternatively SP may choose to simply drop tag entirely and provide "Payload" to customer, this can cause problems with PVST on some devices, but I still see it done occasionally) ** Note, for the example above, I'm assuming 4001 is used as a 'standard' for root sourced frames, and 4002 is used for leaf sourced frames, for the ETREE R/L tags. Have I undone the confusion, or made it worse? -Josh On 4/25/12 5:19 PM, "David Allan I" wrote: >Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. > >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" > >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... > >Cheers >Dave > > > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Wednesday, April 25, 2012 5:42 PM >To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >Dave/Daniel/Lucy/Others Debating how many tags necessary when S-Tag >preservation is desired, > > >I think you all may have gone off on a tangent here. The original >discussion was about how to deal with the situation where the S-Tag is >preserved at a handoff (either an ENNI, or Service Multiplexed UNI) > >I believe there were two suggestions, one was that you push on a 'ETREE' >tag (one of two values, for either a frame sourced from a root AC or >another for a frame from a leaf AC), and the second solution was to 'map'. > > >Imagine the following topology: > >+-----+ +-----+ +-----+ +-----+ >| CE1 |--| PE1 |--| PE2 |--| CE2 | >+-----+ +-----+ +-----+ +-----+ > | | >+-----+ +-----+ +-----+ +-----+ >| CE3 |--| PE3 |--| PE4 |--| CE4 | >+-----+ +-----+ +-----+ +-----+ > >Where: > >Site Type VLAN >CE1 Root X >CE2 Leaf 2 >CE3 Leaf 3 >CE4 Leaf 3 > > >So, there are a lot of SP's who are keen on the way many services can be >handed to a customer on a single UNI, but coordinating a single VLAN per >service, with the customer (MEF used to call this EVPL when it was many >point to point services terminating on a single UNI). So, imagine that >we have two ETREE instances, and an internet service all terminating on a >single UNI connecting to CE1. We have negotiated VLAN ID's with the >customer, and they are expecting to reach CE2 using VLAN 2, CE3 and CE4 >using VLAN 3, and Internet service on VLAN 10. As a frame from CE1 comes >into PE1 destined for CE2 (so the customer has tagged it with VID 2), >using the 2VLAN method, since this is coming from a root site, do we > >a) place the Root S-Tag in front of VID 2, then ship it across, and pop >off the ETREE S-Tag (some SP's wish to Pop the original customer tag VID >2 as well) > >-or- > >b) swap VID2 for the ETREE Root S-Tag, send the frame to PE2 where it >will remove the S-Tag (and either push VID2 back on, or leave it off >depending on SP preference) > >The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf) > > >Hope that clears more than it confuses, >Josh > > > >On 4/25/12 4:22 PM, "Fedyk, Donald (Don)" > wrote: > >>Hi Dave >> >>Yes the only point I would add is Dual VLAN means One VID for Root and >>one VID for Leaf. Not two TAGs at a time on the frame but two allocated >>for the service. >> >>The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks >>about Encapsulation Overhead as a VLAN Tag. While that is true in a PWE >>sense it is still a single VLAN Tag at a time in a Ethernet E-tree sense. >> The compelling driver for Dual VLAN is having a Etree service that >>works in many environments and the DUAL VLAN (really dual VLAN >>interface on a >>VSI) uses the same mechanism (one VID for root and one VID for Leaf at >>a >>time) as specified in the IEEE. In a pure Ethernet bridging world the >>VLAN TAGs for Etree are not typically an overhead since translation is >>used. >> >>Don >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of David Allan I >>Sent: Wednesday, April 25, 2012 5:05 PM >>To: Daniel Cohn; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>OK I feel like I am digressing a fair distance from the actual >>problem.... But here goes: >> >>So the scenarios center around "how ETREE do you want to be?".... >> >>If the ACs are root/leaf, then if they are P2P (single ethernet end >>station attached to each AC) this is moot. ETREE semantics are enforced >>by the 2VID domain in the center of the example. If you assumed nodes >>A&B in the example were L2VPN PEs, the tagging and the PW tag >>imposition all happened at the same point in the network. >> >>If they are not simple P2P all the way to end systems and the objective >>is to avoid bridging between leaf "sites" but allowing intra-leaf-site >>connectivity then the leaves can be LANs but the root is not, such that >>I cannot bridge through the root. But all hosts at a given leaf site >>can see each other. So root Ethernet end systems are directly attached >>or two VIDs are used in the root site. >> >>If the objective is that there are multiple ethernet attached end >>stations at both the leaf and root sites, and the objective is to >>enforce >>L2 isolation everywhere then I need two VIDs extended to the end system >>attachement point in the local LANs by whatever means.... >> >>And I do not see adding VLANs in any particular spot, simply selection >>of the VID and associated semantics where VIDs are translated. The >>actual point of S-tag imposition could be a PE, or cloud be a NID/CLE >>on the customer prem (more likely scenario here to extend OAM demarc to >>the prem), or some switch in a RAN downstream of the MPLS PE... blah >>blah blah. And if ETREE is extended into a customer site LAN and >>outside of the provider domain, then two C-tags would have to be used >>that mapped to S-tags at the PBN boundary... >> >>Make sense? >>Dave >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 25, 2012 4:39 PM >>To: David Allan I; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Dave, but the ACs are root/leaf (that's what the whole vpls etree is >>about - see the reqt draft), so per the 2vlan draft the root/leaf vlan >>must be added. >> >>Thumb typed - please be tolerant >> >>David Allan I wrote: >> >>HI Daniel: >> >>In the example provided, >> >>"ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" >> A B >> >>the service is not ETREE in the domains of the ingress and egress VID. >>It is ELAN. SO there is no root/leaf attribute to shovel around. It >>would require two VIDs in each domain if the ETREE semantics were to be >>telescoped E2E. >> >>Otherwise it is a provisioning of the VID translation tables at the >>intermediate nodes (A&B that I've added to the picture) that would >>determine the VID values used in each domain. Or in the example above, >>what the ingress, Etree and egress VID values were. >> >>Cheers >>Dave >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 3:46 PM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>And to this I asked how this mapping works - how does the egress pe >>recover the ingress vid when it gets the frame tagged with only the >>root/leaf vid? How can you convey the ingress vid plus the root/leaf >>attribute in the same number of bits? >>What am I missing? >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>David Allen already explained the solution. >> >>From David: >>ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. >> >>Ingress VID does not have to equal Egress VID but regardless there is >>only ever one VID on a frame at a time. >> >>-end >> >>This works when customer makes ingress VLAN ID not equal to or equal to >>egress VLAN ID. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 11:39 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Lucy, >> >>The scenario we are discussing is not the E-Tree E-NNI, but a general >>scenario where frames arriving at the root or leaf AC are already >>double tagged. In this case, the dual vlan solution cannot preserve the >>vlans without adding a third one, can it? >> >>Maybe Shahram can add details on the scenario he had in mind >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has S-VLAN preservation attribute for ENNI only because there is no >>s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN >>preservation attribute is used. It applies to E-Tree as well. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Tuesday, April 24, 2012 2:12 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Lucy, >> >>even if the current MEF framework doesn't require s-vlan preservation, >>I believe it's to the industry's benefit to adopt a solution that is >>not constrained to a specific enni model that, like all things >>networking, is likely to evolve. Especially when such a solution is >>available. >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has worked in ENNI interface for a long time with many service >>providers' inputs. It had a fair reason to assume S-VLAN over ENNI by >>then. It may open B-VLAN for the future. It is better for us not to >>discuss a future framework here, because it will lead us to nowhere. >>Here, we want to extend VPLS in supporting E-Tree. >> >>Best Regards, >>Lucy >> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Sunday, April 22, 2012 7:34 AM >>To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Shahram and all, >> >>This question already came up in our discussions - is it safe to assume >>that the VLAN tags at the E-NNI will always be according to the current >>MEF model? Or should we try to be as transparent as possible to user >>VLAN encapsulation at the E-NNI, to accommodate future frameworks? >>I believe that any approach that looks at user payload (in this case >>VLAN >>tag) to signal VPLS information (in this case root/leaf origin) is >>necessarily tied to specific assumptions on user payload encapsulation >>(in this case, that S-VLAN tag is "available" to encode root/leaf). I >>don't think this is a future-proof assumption, it's very likely that >>other network models will come up that require S-VLAN preservation, >>which in the 2-VLAN approach would necessitate adding a third VLAN-ID. >> >>Daniel >> >>From: Shahram Davari > >>To: Lizhong Jin >, >>"l2vpn@ietf.org" >>>, >>"Alexander.Vainshtein@ecitele.com>om> >>" >>>om> >>> >>Cc: "yuqun.cao@gmail.com" >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, >> >>I also have a question regarding 2-VLAN. What if the customer traffic >>already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? >> >>Thx >>Shahram >> >>From: l2vpn-bounces@ietf.org >>[mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin >>Sent: Friday, April 20, 2012 9:38 AM >>To: l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com>m> >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, all, >>The difference between 2-VLAN and CW approach is who will provide the >>R/L information, customer payload or PW? The customer payload will be >>always modified to carry R/L information in 2-VLAN approach, while PW >>with CW will carry R/L information for CW approach. >>I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is >>accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is >>used to access H-VPLS, how could the PE on VPWS side adds VLAN to >>indicate R/L information? >> >>Thanks >>Lizhong >> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Thu, 19 Apr 2012 04:38:36 +0000 >>> From: Alexander Vainshtein >>> >> com>> >>> To: "Rogers, Josh" >>>>, Lucy yong >>> >, Daniel >>>Cohn >, Sam Cao >>> > >>> Cc: "l2vpn@ietf.org" >>> > >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> Message-ID: >>> >>> >> t o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> >>> Content-Type: text/plain; charset=3D"us-ascii" >>> >>> Hi all, >>> I fully understand that that what I am going to say is not very >>>popular, but: >>> >>> IMO one of the advantages of the CW-based solution is that it is >>>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery >>>of BUN traffic. >>> >>> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>>and, in a more generic way, localization of effects of changes in the >>>PE configuration. >>> >>> In particular, adding a Leaf AC to a PE that previously has been only >>>supporting Root ACs (or vice versa), removal of the last Leaf or last >>>Root AC from a PE that previously has been supporting a mix etc. >>>affect only the PE where this operation happens and not the rest of the >>>PEs. >>> >>> As for the need for HW changes that have been mentioned as a main >>>disadvantage of the CW-based approach - I believe it strongly depends >>>on specific implementations. And some changes in the forwarding >>>process are required in any solution. >>> >>> My 2c, >>> Sasha >>> >>> >>> >>> ________________________________________ >>> From: l2vpn-bounces@ietf.org >>> [l2vpn-bounces@ietf.org] on behalf of >>> Rogers, Josh >>> [josh.rogers@twcable.com] >>> Sent: Wednesday, April 18, 2012 9:57 PM >>> To: Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: Re: The status of the approaches to the E-Tree solution? >>> >>> Again, the P2MP situation throws me. Is this something that is used >>> commonly? >>> >>> I'm under the impression that adding P2MP to any model results in a >>> more complex model. Wether outside s-tag is used to differentiate, >>> or dedicated pw's are used for the same purpose, it seems both become >>> more complex. >>> >>> Gile's comparison slide still concisely captures the differences >>>between these methods, in my opinion. I haven't seen any new ideas or >>>thoughts brought to the group in the past week or two on the subject. >>> I would hate for both proposed methods to die on the vine because we >>>couldn't decide between two methods that have nothing inherently wrong >>>with either. >>> >>> -Josh >>> >>> >>> On 4/18/12 1:53 PM, "Lucy yong" >>>> wrote: >>> >>>>Send this again. >>>> >>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>>double all of them. >>>> >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn >>>>[mailto:DanielC@orckit.com] >>>>Sent: Wednesday, April 18, 2012 1:42 PM >>>>To: Lucy yong; Rogers, Josh; Sam Cao >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>I think the first option its the natural way to go. How is the >>>>processing in this case more complex? >>>> >>>>Thumb typed - please be tolerant >>>> >>>>Lucy yong > wrote: >>>> >>>> >>>> >>>>Snipped.. >>>> >>>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only >>>>P2MP PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP >>>>PW (for traffic coming from a root AC) [[LY]] Not that simple. You >>>>construct either two P2MP PWs to all other PEs and let egress PE >>>>performing filtering, or construct one P2MP PW to leaf-only PEs and >>>>two P2MP PWs to root and leaf PEs and let ingress PE perform >>>>forwarding and filtering. Both make node process complex. >>>> >>>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>>>delivering the frames to remote PEs. We should utilize them with the >>>>minimized changes. Dual VLAN solution is simpler than Dual PW. >>>> >>>>Regards, >>>>Lucy >>>> >>>> >>>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>>>haven't had any first hand experience with P2MP PW's, however, so >>>>don't feel terribly strong about this objection. Is this a real >>>>problem for others (now or in the future), or is this objection in >>>>the weeds? >>>> >>>>I'm not sure the 'additional complexity' is notable, or even relevant. >>>>I encourage others to speak up if they disagree, as P2MP PW is only >>>>conceptual to me, and I am unfamiliar with real-life use cases for it. >>>> >>>>Thanks, >>>>Josh >>>> >>>> >>>> >>>>On 4/18/12 10:30 AM, "Lucy yong" >>>>> wrote: >>>> >>>>>Please see inline. >>>>> >>>>>-----Original Message----- >>>>>From: Sam Cao >>>>>[mailto:yuqun.cao@gmail.com] >>>>>Sent: Tuesday, April 17, 2012 7:14 AM >>>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>>>(Wim)'; giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>>>> >>>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>>>PE have both root and leaf AC and some only have leaf ACs)? >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Yuqun (Sam) Cao >>>>>E-mail: Yuqun.cao@gmail.com >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn >>>>>[mailto:DanielC@orckit.com] >>>>>Sent: Tuesday, April 17, 2012 4:56 PM >>>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com>; Sam Cao >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Adding Sam (as l2vpn@ is holding messages) >>>>> >>>>>DC >>>>> >>>>>-----Original Message----- >>>>>From: Lucy yong >>>>>[mailto:lucy.yong@huawei.com] >>>>>Sent: Tuesday, April 17, 2012 12:39 AM >>>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>> >>>>>Snipped, >>>>> >>>>>As we discussed extensively in the list, and as reflected in giles >>>>>slide, 2 pws are only needed between pes with both root and leaf >>>>>acs, which will typically be a small minority. >>>>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>>>both approaches can benefit from it. I was off for a while and >>>>>captures some discussions now. >>>>> >>>>>Also as per giles slide, dual vlan can have scalability issues due >>>>>to additional lookup and double use of vlans in internal emulated >>>>>lan interface. Also there are potential backward compatibility >>>>>issues with silicon that doesn't support vlan mapping. >>>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. >>>>>I am not clear on all the issues. Could you be more specific? As I >>>>>mentioned in below, two PW approach makes VPLS transport >>>>>construction and packet forwarding more complex, I can see potential >>>>>backward compatibility issues with 2 PW solution. >>>>> >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Daniel >>>>> >>>>>Thumb typed - please be tolerant >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>>In my mind, the VLAN approach means dual vlan method. >>>>> >>>>>The main concern for CW approach is hardware support. >>>>> >>>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and >>>>>unknown unicast traffic, and some P2MP PWs for multicast traffic. It >>>>>may double all of them. >>>>> >>>>>E-tree is an Ethernet service and there is already VLAN based >>>>>solution in IEEE, can we just utilize it without complicating VPLS >>>>>transport construction? This also makes interworking with Eth only >>>>>network easier. >>>>> >>>>>Cheers, >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: Rogers, Josh >>>>>[mailto:josh.rogers@twcable.com] >>>>>Sent: Monday, April 16, 2012 8:35 AM >>>>>To: Lucy yong; Henderickx, Wim (Wim); >>>>>'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com'; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>I believe the initial question was in regard to the CW method. Are >>>>>you saying that you no longer are interested in that method in >>>>>preference of the dual vlan method? >>>>> >>>>> >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>> >>>>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>>>> >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: l2vpn-bounces@ietf.org >>>>>[mailto:l2vpn-bounces@ietf.org] On >>>>>Behalf Of Henderickx, Wim (Wim) >>>>>Sent: Thursday, April 12, 2012 2:03 AM >>>>>To: 'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com'; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>The vlan approach is superior as it also works for eth only >>>>>networks, etc. On top some vendors indicate hw issues with the cw >>>>>approach. As such we have dropped more or less the cw approach. >>>>> >>>>>Cheers, >>>>>Wim >>>>>_________________ >>>>>sent from blackberry >>>>> >>>>>----- Original Message ----- >>>>>From: Giles Heron >>>>>[mailto:giles.heron@gmail.com] >>>>>Sent: Thursday, April 12, 2012 08:22 AM >>>>>To: Simon Delord >>>>>>; Alexander >>>>>Vainshtein >>>>>>>>>e >>>>>.com>> >>>>>Cc: l2vpn@ietf.org >>>>>>; Vladimir Kleiner >>>>>>; >>>>>Andrew Sergeev >>>>>>; >>>>>Idan Kaspit >>>>>>; >>>>>Mishael Wexler >>>>>>; >>>>>Rotem Cohen >>>>>> >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>Sorry - the "anonymous presentation" was mine. I should possibly >>>>>have put in a third column on the CW approach. And hopefully the >>>>>minutes will be posted soon. >>>>> >>>>>We had various discussions, as Simon stated, and consensus seemed to >>>>>be forming around the two alternatives of two PWEs or two VLANs. I >>>>>believe three of the authors of the CW approach are also authors of >>>>>the two VLAN approach and one is also an author of the two PWE >>>>>approach. So perhaps it's best to let those four individuals say >>>>>which approach they prefer and why? >>>>> >>>>>Giles >>>>> >>>>>On 10/04/2012 00:45, "Simon Delord" >>>>>> wrote: >>>>> >>>>>> Hi Alexander, >>>>>> >>>>>> You are right, no discussion on the WG mailing list recently, but >>>>>> there have been substantial discussions among the authors of >>>>>> various solution drafts off the mailing list. As far as I know, no >>>>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>>>> meeting. I think the CW approach has not been rejected by the WG >>>>>> yet, or the WG has not yet decided on which one to adopt. >>>>>> >>>>>> Simon >>>>>> >>>>>> 2012/4/8 Alexander Vainshtein >>>>>> >>>>> e >>>>>> le.com>> >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>>>> >>>>>>> However, looking up the L2VPN proceedings, I've found a short >>>>>>> anonymous presentation called "E-Tree Update" ( >>>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>>>> This presentation discusses the differences of the E-Tree >>>>>>> approaches based on dedicated VLANs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw >>>>>>> / >>>>>>> ?in >>>>>>> clude_te >>>>>>> xt=3D1) >>>>>>> and completely ignores the solution based on usage of the CW in >>>>>>> the PWs connecting the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1 >>>>>>> ). >>>>>>> >>>>>>> >>>>>>> >>>>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>>>> I wonder whether the WG has taken a decision to reject the >>>>>>> approach based on the CW usage? I do not remember any recent >>>>>>> discussion of this topic on the WG mailing list. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, and lots of thanks in advance, >>>>>>> >>>>>>> Sasha >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This e-mail message is intended for the recipient only and >>>>>>> contains information which is CONFIDENTIAL and which may be >>>>>>> proprietary to ECI >>>>> >>>>>>> Telecom. If you have received this transmission in error, please >>>>>>> inform us by e-mail, phone or fax, and then delete the original >>>>>>> and all copies thereof. >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>>proprietary information, which is privileged, confidential, or >>>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>>intended solely for the use of the individual or entity to which it >>>>>is addressed. >>>>>If you are not the intended recipient of this E-mail, you are hereby >>>>>notified that any dissemination, distribution, copying, or action >>>>>taken in relation to the contents of and attachments to this E-mail >>>>>is strictly prohibited and may be unlawful. If you have received >>>>>this E-mail in error, please notify the sender immediately and >>>>>permanently delete the original and any copy of this E-mail and any >>>>>printout. >>>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or >>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>intended solely for the use of the individual or entity to which it >>>>is addressed. If you are not the intended recipient of this E-mail, >>>>you are hereby notified that any dissemination, distribution, >>>>copying, or action taken in relation to the contents of and >>>>attachments to this E-mail is strictly prohibited and may be >>>>unlawful. If you have received this E-mail in error, please notify >>>>the sender immediately and permanently delete the original and any >>>>copy of this E-mail and any printout. >>> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> This e-mail message is intended for the recipient only and contains >>>information which is CONFIDENTIAL and which may be proprietary to ECI >>>Telecom. If you have received this transmission in error, please >>>inform us by e-mail, phone or fax, and then delete the original and >>>all copies thereof. >>> >>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> L2vpn mailing list >>> L2vpn@ietf.org >>> https://www.ietf.org/mailman/listinfo/l2vpn >>> >>> >>> End of L2vpn Digest, Vol 95, Issue 25 >>> *********************************** > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 101 ************************************** From jiangyuanlong@huawei.com Wed Apr 25 20:58:41 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66F321F85ED for ; Wed, 25 Apr 2012 20:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] 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 opUN+oWF4IYg for ; Wed, 25 Apr 2012 20:58:40 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 08DE521F85D7 for ; Wed, 25 Apr 2012 20:58:39 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFF63551; Wed, 25 Apr 2012 23:58:39 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 20:55:42 -0700 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 20:55:40 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.137]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 26 Apr 2012 11:55:34 +0800 From: Jiangyuanlong To: "Rogers, Josh" , David Allan I Subject: Re: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNI2BukTGH5wT9DEWubl+C4L3kTQ== Date: Thu, 26 Apr 2012 03:55:33 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3F2C5@SZXEML508-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: BPU6 Cejt Dvnu G7Ke IDKn JZWo NuIq QQOB Q7Yc Si3r UTZr VmvK XHt8 aKCc aS+/ cMvp; 3; ZABhAHYAaQBkAC4AaQAuAGEAbABsAGEAbgBAAGUAcgBpAGMAcwBzAG8AbgAuAGMAbwBtADsAagBvAHMAaAAuAHIAbwBnAGUAcgBzAEAAdAB3AGMAYQBiAGwAZQAuAGMAbwBtADsAbAAyAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {39A41FDA-2CCA-4772-A891-8528E617C1BB}; agBpAGEAbgBnAHkAdQBhAG4AbABvAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Thu, 26 Apr 2012 03:55:29 GMT; UgBlADoAIABUAGgAZQAgAHMAdABhAHQAdQBzACAAbwBmACAAdABoAGUAIABhAHAAcAByAG8AYQBjAGgAZQBzACAAdABvACAAdABoAGUAIABFAC0AVAByAGUAZQAgAHMAbwBsAHUAdABpAG8AbgA/AA== x-cr-puzzleid: {39A41FDA-2CCA-4772-A891-8528E617C1BB} x-originating-ip: [10.70.40.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 26 Apr 2012 03:58:41 -0000 Hi Josh, Please see my comments in line. Regards, Yuanlong ---------------------------------------------------------------------- Date: Wed, 25 Apr 2012 19:21:43 -0400 From: "Rogers, Josh" To: David Allan I , "Fedyk, Donald (Don)" , Daniel Cohn , "l2vpn@ietf.org" Subject: Re: The status of the approaches to the E-Tree solution? Message-ID: Content-Type: text/plain; charset=3D"us-ascii" > Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. I have to apologize, because I think I led y'all down that path (I referred to the outermost tag, the same tag that the MPLS psuedowire is using for vlan mode encamp, as the S-Tag, even though the customer is the one placing it on the frame. Same as I described below, but I either used term S-Tag incorrectly, or ambiguously. >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... So, I think this could be cleared up some still. What I was referring to is the VID that the customer is using to put frames in, the VID which they should use to ensure the frame goes into the correct ETREE instance. You drew a distinction between 'customer VID' vs 'provider VID', but since it is negotiated, I haven't really seen a distinction, which I think is what has caused all the confusion. =20 [JY] I think Dave is considering the E-Tree from an end to end point of vie= w, that is, the E-Tree UNI is where the customer accesses the provider netw= orks, thus the customer in his context is more in line with the BBF or MEF = definition (as you know, the E-Tree UNI as defined in MEF sees at most one = stack of C-VLAN). But the customer in your context is more in line with our= IETF tradition, where there is no clear demarcation point for Ethernet UNI= , IMHO. Just as Dave raised in another email, S-VLAN access will mean another netwo= rk section in the access which may be providing E-LAN or E-Tree (or called = sub E-LAN/sub E-Tree - to be distinct from the E-Tree in discussion), and e= ven such services can be supported with IEEE compatible mechanisms. In the two discussion points/solutions I mentioned, the first one, "A", describes both a coordinated VID which the customer should use, and the service provider uses to distinguish between services on the same UNI, as well as a second, outer, VID which is used by the SP to determine the source AC type. In my example, if you were to sniff inside the psuedowire between PE1 and PE2 to see CE2 destined traffic, wish solution A, you might see "4001:2:Payload", where 4001 designates it is from a root AC, 2 designates the ETREE instance, and Payload is the customer's traffic (which may include a C-Tag), where with solution B, you would see "4001:Payload", and VID 2 would have to be swapped for 4001 as it enters the PE2-CE2 AC, giving the customer "2:Payload" just as they sent it (alternatively SP may choose to simply drop tag entirely and provide "Payload" to customer, this can cause problems with PVST on some devices, but I still see it done occasionally) [JY] SVLAN translation is acceptable from the analysis of Dave. SVLAN over = SVLAN is out of the scope of Dual VLAN I-D.=20 Hope this helps the discussion. ** Note, for the example above, I'm assuming 4001 is used as a 'standard' for root sourced frames, and 4002 is used for leaf sourced frames, for the ETREE R/L tags. Have I undone the confusion, or made it worse? -Josh On 4/25/12 5:19 PM, "David Allan I" wrote: >Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. > >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" > >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... > >Cheers >Dave > > > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Wednesday, April 25, 2012 5:42 PM >To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >Dave/Daniel/Lucy/Others Debating how many tags necessary when S-Tag >preservation is desired, > > >I think you all may have gone off on a tangent here. The original >discussion was about how to deal with the situation where the S-Tag is >preserved at a handoff (either an ENNI, or Service Multiplexed UNI) > >I believe there were two suggestions, one was that you push on a 'ETREE' >tag (one of two values, for either a frame sourced from a root AC or >another for a frame from a leaf AC), and the second solution was to 'map'. > > >Imagine the following topology: > >+-----+ +-----+ +-----+ +-----+ >| CE1 |--| PE1 |--| PE2 |--| CE2 | >+-----+ +-----+ +-----+ +-----+ > | | >+-----+ +-----+ +-----+ +-----+ >| CE3 |--| PE3 |--| PE4 |--| CE4 | >+-----+ +-----+ +-----+ +-----+ > >Where: > >Site Type VLAN >CE1 Root X >CE2 Leaf 2 >CE3 Leaf 3 >CE4 Leaf 3 > > >So, there are a lot of SP's who are keen on the way many services can be >handed to a customer on a single UNI, but coordinating a single VLAN per >service, with the customer (MEF used to call this EVPL when it was many >point to point services terminating on a single UNI). So, imagine that >we have two ETREE instances, and an internet service all terminating on a >single UNI connecting to CE1. We have negotiated VLAN ID's with the >customer, and they are expecting to reach CE2 using VLAN 2, CE3 and CE4 >using VLAN 3, and Internet service on VLAN 10. As a frame from CE1 comes >into PE1 destined for CE2 (so the customer has tagged it with VID 2), >using the 2VLAN method, since this is coming from a root site, do we > >a) place the Root S-Tag in front of VID 2, then ship it across, and pop >off the ETREE S-Tag (some SP's wish to Pop the original customer tag VID >2 as well) > >-or- > >b) swap VID2 for the ETREE Root S-Tag, send the frame to PE2 where it >will remove the S-Tag (and either push VID2 back on, or leave it off >depending on SP preference) > >The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf) > > >Hope that clears more than it confuses, >Josh > > > >On 4/25/12 4:22 PM, "Fedyk, Donald (Don)" > wrote: > >>Hi Dave >> >>Yes the only point I would add is Dual VLAN means One VID for Root and >>one VID for Leaf. Not two TAGs at a time on the frame but two allocated >>for the service. >> >>The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks >>about Encapsulation Overhead as a VLAN Tag. While that is true in a PWE >>sense it is still a single VLAN Tag at a time in a Ethernet E-tree sense. >> The compelling driver for Dual VLAN is having a Etree service that >>works in many environments and the DUAL VLAN (really dual VLAN >>interface on a >>VSI) uses the same mechanism (one VID for root and one VID for Leaf at >>a >>time) as specified in the IEEE. In a pure Ethernet bridging world the >>VLAN TAGs for Etree are not typically an overhead since translation is >>used. >> >>Don >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of David Allan I >>Sent: Wednesday, April 25, 2012 5:05 PM >>To: Daniel Cohn; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>OK I feel like I am digressing a fair distance from the actual >>problem.... But here goes: >> >>So the scenarios center around "how ETREE do you want to be?".... >> >>If the ACs are root/leaf, then if they are P2P (single ethernet end >>station attached to each AC) this is moot. ETREE semantics are enforced >>by the 2VID domain in the center of the example. If you assumed nodes >>A&B in the example were L2VPN PEs, the tagging and the PW tag >>imposition all happened at the same point in the network. >> >>If they are not simple P2P all the way to end systems and the objective >>is to avoid bridging between leaf "sites" but allowing intra-leaf-site >>connectivity then the leaves can be LANs but the root is not, such that >>I cannot bridge through the root. But all hosts at a given leaf site >>can see each other. So root Ethernet end systems are directly attached >>or two VIDs are used in the root site. >> >>If the objective is that there are multiple ethernet attached end >>stations at both the leaf and root sites, and the objective is to >>enforce >>L2 isolation everywhere then I need two VIDs extended to the end system >>attachement point in the local LANs by whatever means.... >> >>And I do not see adding VLANs in any particular spot, simply selection >>of the VID and associated semantics where VIDs are translated. The >>actual point of S-tag imposition could be a PE, or cloud be a NID/CLE >>on the customer prem (more likely scenario here to extend OAM demarc to >>the prem), or some switch in a RAN downstream of the MPLS PE... blah >>blah blah. And if ETREE is extended into a customer site LAN and >>outside of the provider domain, then two C-tags would have to be used >>that mapped to S-tags at the PBN boundary... >> >>Make sense? >>Dave >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 25, 2012 4:39 PM >>To: David Allan I; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Dave, but the ACs are root/leaf (that's what the whole vpls etree is >>about - see the reqt draft), so per the 2vlan draft the root/leaf vlan >>must be added. >> >>Thumb typed - please be tolerant >> >>David Allan I wrote: >> >>HI Daniel: >> >>In the example provided, >> >>"ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" >> A B >> >>the service is not ETREE in the domains of the ingress and egress VID. >>It is ELAN. SO there is no root/leaf attribute to shovel around. It >>would require two VIDs in each domain if the ETREE semantics were to be >>telescoped E2E. >> >>Otherwise it is a provisioning of the VID translation tables at the >>intermediate nodes (A&B that I've added to the picture) that would >>determine the VID values used in each domain. Or in the example above, >>what the ingress, Etree and egress VID values were. >> >>Cheers >>Dave >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 3:46 PM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>And to this I asked how this mapping works - how does the egress pe >>recover the ingress vid when it gets the frame tagged with only the >>root/leaf vid? How can you convey the ingress vid plus the root/leaf >>attribute in the same number of bits? >>What am I missing? >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>David Allen already explained the solution. >> >>From David: >>ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. >> >>Ingress VID does not have to equal Egress VID but regardless there is >>only ever one VID on a frame at a time. >> >>-end >> >>This works when customer makes ingress VLAN ID not equal to or equal to >>egress VLAN ID. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 11:39 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Lucy, >> >>The scenario we are discussing is not the E-Tree E-NNI, but a general >>scenario where frames arriving at the root or leaf AC are already >>double tagged. In this case, the dual vlan solution cannot preserve the >>vlans without adding a third one, can it? >> >>Maybe Shahram can add details on the scenario he had in mind >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has S-VLAN preservation attribute for ENNI only because there is no >>s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN >>preservation attribute is used. It applies to E-Tree as well. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Tuesday, April 24, 2012 2:12 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Lucy, >> >>even if the current MEF framework doesn't require s-vlan preservation, >>I believe it's to the industry's benefit to adopt a solution that is >>not constrained to a specific enni model that, like all things >>networking, is likely to evolve. Especially when such a solution is >>available. >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has worked in ENNI interface for a long time with many service >>providers' inputs. It had a fair reason to assume S-VLAN over ENNI by >>then. It may open B-VLAN for the future. It is better for us not to >>discuss a future framework here, because it will lead us to nowhere. >>Here, we want to extend VPLS in supporting E-Tree. >> >>Best Regards, >>Lucy >> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Sunday, April 22, 2012 7:34 AM >>To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Shahram and all, >> >>This question already came up in our discussions - is it safe to assume >>that the VLAN tags at the E-NNI will always be according to the current >>MEF model? Or should we try to be as transparent as possible to user >>VLAN encapsulation at the E-NNI, to accommodate future frameworks? >>I believe that any approach that looks at user payload (in this case >>VLAN >>tag) to signal VPLS information (in this case root/leaf origin) is >>necessarily tied to specific assumptions on user payload encapsulation >>(in this case, that S-VLAN tag is "available" to encode root/leaf). I >>don't think this is a future-proof assumption, it's very likely that >>other network models will come up that require S-VLAN preservation, >>which in the 2-VLAN approach would necessitate adding a third VLAN-ID. >> >>Daniel >> >>From: Shahram Davari > >>To: Lizhong Jin >, >>"l2vpn@ietf.org" >>>, >>"Alexander.Vainshtein@ecitele.com>om> >>" >>>om> >>> >>Cc: "yuqun.cao@gmail.com" >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, >> >>I also have a question regarding 2-VLAN. What if the customer traffic >>already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? >> >>Thx >>Shahram >> >>From: l2vpn-bounces@ietf.org >>[mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin >>Sent: Friday, April 20, 2012 9:38 AM >>To: l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com>m> >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, all, >>The difference between 2-VLAN and CW approach is who will provide the >>R/L information, customer payload or PW? The customer payload will be >>always modified to carry R/L information in 2-VLAN approach, while PW >>with CW will carry R/L information for CW approach. >>I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is >>accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is >>used to access H-VPLS, how could the PE on VPWS side adds VLAN to >>indicate R/L information? >> >>Thanks >>Lizhong >> From david.i.allan@ericsson.com Thu Apr 26 05:55:49 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D2F21F8841 for ; Thu, 26 Apr 2012 05:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 Z4w86l6Dd2cw for ; Thu, 26 Apr 2012 05:55:47 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id CC81821F8798 for ; Thu, 26 Apr 2012 05:55:46 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q3QCtFu7013960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Apr 2012 07:55:32 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.69]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 26 Apr 2012 08:55:28 -0400 From: David Allan I To: "Rogers, Josh" , Lucy yong , "Fedyk, Donald (Don)" , Daniel Cohn , "l2vpn@ietf.org" Date: Thu, 26 Apr 2012 08:55:27 -0400 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0jOm+ZUGAiKOKOQpeI9+OYDFcXZwAcSQMw Message-ID: <60C093A41B5E45409A19D42CF7786DFD52324EF1FB@EUSAACMS0703.eamcs.ericsson.se> References: <2691CE0099834E4A9C5044EEC662BB9D3264C202@dfweml505-mbx> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: l2vpn@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, 26 Apr 2012 12:55:49 -0000 Both scenarios are possible according to my read of 802.1.ad. For 'a', a C-tagged frame simply has the s-tag inserted.... For 'b' a C-component strips the C-tag before presenting the frame on a cus= tomer network port that is unique to the S-tag (e.g. internal to a PB.)... Dave -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Wednesday, April 25, 2012 7:23 PM To: Lucy yong; Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.= org Subject: Re: The status of the approaches to the E-Tree solution? [[LY]] This is not my understanding. Here we talk about incoming frame alr= eady has c-tag and s-tag, which is not UNI case. In addition, it seems that= Daniel say that only option A works. That=B9s funny, I thought someone said that only option B would work. I th= ink technically either is possible, but I am unclear which the 2VLAN draft = would advise (or if it even does) -Josh On 4/25/12 5:22 PM, "Lucy yong" wrote: >Hi Josh, > >Please see inline. > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >Of Rogers, Josh >Sent: Wednesday, April 25, 2012 4:42 PM >To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >Dave/Daniel/Lucy/Others Debating how many tags necessary when S-Tag >preservation is desired, > > >I think you all may have gone off on a tangent here. The original >discussion was about how to deal with the situation where the S-Tag is >preserved at a handoff (either an ENNI, or Service Multiplexed UNI) >[[LY]] in MEF, S-Tag applies to ENNI only, not UNI. An UNI can support >multiplexed services, i.e. terminate many EVCs. In this case, each EVC >associates with one or multiple c-tags. EVC has a service attribute for >listing associated c-tags. > >I believe there were two suggestions, one was that you push on a 'ETREE' >tag (one of two values, for either a frame sourced from a root AC or >another for a frame from a leaf AC), and the second solution was to 'map'. >[[LY]] This is not my understanding. Here we talk about incoming frame >already has c-tag and s-tag, which is not UNI case. In addition, it >seems that Daniel say that only option A works. > > >Imagine the following topology: > >+-----+ +-----+ +-----+ +-----+ >| CE1 |--| PE1 |--| PE2 |--| CE2 | >+-----+ +-----+ +-----+ +-----+ > | | >+-----+ +-----+ +-----+ +-----+ >| CE3 |--| PE3 |--| PE4 |--| CE4 | >+-----+ +-----+ +-----+ +-----+ > >Where: > >Site Type VLAN >CE1 Root X >CE2 Leaf 2 >CE3 Leaf 3 >CE4 Leaf 3 > > >So, there are a lot of SP's who are keen on the way many services can >be handed to a customer on a single UNI, but coordinating a single VLAN >per service, with the customer (MEF used to call this EVPL when it was >many point to point services terminating on a single UNI). So, imagine >that we have two ETREE instances, and an internet service all >terminating on a single UNI connecting to CE1. We have negotiated VLAN >ID's with the customer, and they are expecting to reach CE2 using VLAN >2, CE3 and CE4 using VLAN 3, and Internet service on VLAN 10. As a >frame from CE1 comes into PE1 destined for CE2 (so the customer has >tagged it with VID 2), using the 2VLAN method, since this is coming >from a root site, do we > >a) place the Root S-Tag in front of VID 2, then ship it across, and pop >off the ETREE S-Tag (some SP's wish to Pop the original customer tag >VID 2 as well) > >-or- > >b) swap VID2 for the ETREE Root S-Tag, send the frame to PE2 where it >will remove the S-Tag (and either push VID2 back on, or leave it off >depending on SP preference) > >The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf) [[LY]] Since dual VLAN solution tries to inline with IEEE >solution, if this is the use case, we suggests to go with option B, not >A. So please don't discuss option A more. > >Regards, >Lucy > > >Hope that clears more than it confuses, Josh > > > >On 4/25/12 4:22 PM, "Fedyk, Donald (Don)" > wrote: > >>Hi Dave >> >>Yes the only point I would add is Dual VLAN means One VID for Root and >>one VID for Leaf. Not two TAGs at a time on the frame but two >>allocated for the service. >> >>The confusing part is no doubt that Dual PWE/Dual VLAN comparison >>talks about Encapsulation Overhead as a VLAN Tag. While that is true >>in a PWE sense it is still a single VLAN Tag at a time in a Ethernet E-tr= ee sense. >> The compelling driver for Dual VLAN is having a Etree service that >>works in many environments and the DUAL VLAN (really dual VLAN >>interface on a >>VSI) uses the same mechanism (one VID for root and one VID for Leaf at >>a >>time) as specified in the IEEE. In a pure Ethernet bridging world the >>VLAN TAGs for Etree are not typically an overhead since translation is >>used. >> >>Don >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of David Allan I >>Sent: Wednesday, April 25, 2012 5:05 PM >>To: Daniel Cohn; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>OK I feel like I am digressing a fair distance from the actual >>problem.... But here goes: >> >>So the scenarios center around "how ETREE do you want to be?".... >> >>If the ACs are root/leaf, then if they are P2P (single ethernet end >>station attached to each AC) this is moot. ETREE semantics are >>enforced by the 2VID domain in the center of the example. If you >>assumed nodes A&B in the example were L2VPN PEs, the tagging and the >>PW tag imposition all happened at the same point in the network. >> >>If they are not simple P2P all the way to end systems and the >>objective is to avoid bridging between leaf "sites" but allowing >>intra-leaf-site connectivity then the leaves can be LANs but the root >>is not, such that I cannot bridge through the root. But all hosts at a >>given leaf site can see each other. So root Ethernet end systems are >>directly attached or two VIDs are used in the root site. >> >>If the objective is that there are multiple ethernet attached end >>stations at both the leaf and root sites, and the objective is to >>enforce >>L2 isolation everywhere then I need two VIDs extended to the end >>system attachement point in the local LANs by whatever means.... >> >>And I do not see adding VLANs in any particular spot, simply selection >>of the VID and associated semantics where VIDs are translated. The >>actual point of S-tag imposition could be a PE, or cloud be a NID/CLE >>on the customer prem (more likely scenario here to extend OAM demarc >>to the prem), or some switch in a RAN downstream of the MPLS PE... >>blah blah blah. And if ETREE is extended into a customer site LAN and >>outside of the provider domain, then two C-tags would have to be used >>that mapped to S-tags at the PBN boundary... >> >>Make sense? >>Dave >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 25, 2012 4:39 PM >>To: David Allan I; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Dave, but the ACs are root/leaf (that's what the whole vpls etree is >>about - see the reqt draft), so per the 2vlan draft the root/leaf vlan >>must be added. >> >>Thumb typed - please be tolerant >> >>David Allan I wrote: >> >>HI Daniel: >> >>In the example provided, >> >>"ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" >> A B >> >>the service is not ETREE in the domains of the ingress and egress VID. >>It is ELAN. SO there is no root/leaf attribute to shovel around. It >>would require two VIDs in each domain if the ETREE semantics were to >>be telescoped E2E. >> >>Otherwise it is a provisioning of the VID translation tables at the >>intermediate nodes (A&B that I've added to the picture) that would >>determine the VID values used in each domain. Or in the example above, >>what the ingress, Etree and egress VID values were. >> >>Cheers >>Dave >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 3:46 PM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>And to this I asked how this mapping works - how does the egress pe >>recover the ingress vid when it gets the frame tagged with only the >>root/leaf vid? How can you convey the ingress vid plus the root/leaf >>attribute in the same number of bits? >>What am I missing? >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>David Allen already explained the solution. >> >>From David: >>ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. >> >>Ingress VID does not have to equal Egress VID but regardless there is >>only ever one VID on a frame at a time. >> >>-end >> >>This works when customer makes ingress VLAN ID not equal to or equal >>to egress VLAN ID. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 11:39 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Lucy, >> >>The scenario we are discussing is not the E-Tree E-NNI, but a general >>scenario where frames arriving at the root or leaf AC are already >>double tagged. In this case, the dual vlan solution cannot preserve >>the vlans without adding a third one, can it? >> >>Maybe Shahram can add details on the scenario he had in mind >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has S-VLAN preservation attribute for ENNI only because there is >>no s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, >>S-VALN preservation attribute is used. It applies to E-Tree as well. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Tuesday, April 24, 2012 2:12 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Lucy, >> >>even if the current MEF framework doesn't require s-vlan preservation, >>I believe it's to the industry's benefit to adopt a solution that is >>not constrained to a specific enni model that, like all things >>networking, is likely to evolve. Especially when such a solution is avail= able. >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has worked in ENNI interface for a long time with many service >>providers' inputs. It had a fair reason to assume S-VLAN over ENNI by >>then. It may open B-VLAN for the future. It is better for us not to >>discuss a future framework here, because it will lead us to nowhere. >>Here, we want to extend VPLS in supporting E-Tree. >> >>Best Regards, >>Lucy >> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Sunday, April 22, 2012 7:34 AM >>To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Shahram and all, >> >>This question already came up in our discussions - is it safe to >>assume that the VLAN tags at the E-NNI will always be according to the >>current MEF model? Or should we try to be as transparent as possible >>to user VLAN encapsulation at the E-NNI, to accommodate future frameworks= ? >>I believe that any approach that looks at user payload (in this case >>VLAN >>tag) to signal VPLS information (in this case root/leaf origin) is >>necessarily tied to specific assumptions on user payload encapsulation >>(in this case, that S-VLAN tag is "available" to encode root/leaf). I >>don't think this is a future-proof assumption, it's very likely that >>other network models will come up that require S-VLAN preservation, >>which in the 2-VLAN approach would necessitate adding a third VLAN-ID. >> >>Daniel >> >>From: Shahram Davari > >>To: Lizhong Jin >, >>"l2vpn@ietf.org" >>>, >>"Alexander.Vainshtein@ecitele.com>com >>> >>" >>>com >>> >>> >>Cc: "yuqun.cao@gmail.com" >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, >> >>I also have a question regarding 2-VLAN. What if the customer traffic >>already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? >> >>Thx >>Shahram >> >>From: l2vpn-bounces@ietf.org >>[mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin >>Sent: Friday, April 20, 2012 9:38 AM >>To: l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com>om> >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, all, >>The difference between 2-VLAN and CW approach is who will provide the >>R/L information, customer payload or PW? The customer payload will be >>always modified to carry R/L information in 2-VLAN approach, while PW >>with CW will carry R/L information for CW approach. >>I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is >>accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is >>used to access H-VPLS, how could the PE on VPWS side adds VLAN to >>indicate R/L information? >> >>Thanks >>Lizhong >> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Thu, 19 Apr 2012 04:38:36 +0000 >>> From: Alexander Vainshtein >>> >> com>> >>> To: "Rogers, Josh" >>>>, Lucy yong >>> >, Daniel >>>Cohn >, Sam Cao >>> > >>> Cc: "l2vpn@ietf.org" >>> > >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> Message-ID: >>> >>> >> lt >>> o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> >>> Content-Type: text/plain; charset=3D"us-ascii" >>> >>> Hi all, >>> I fully understand that that what I am going to say is not very >>>popular, but: >>> >>> IMO one of the advantages of the CW-based solution is that it is >>>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery >>>of BUN traffic. >>> >>> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>>and, in a more generic way, localization of effects of changes in the >>>PE configuration. >>> >>> In particular, adding a Leaf AC to a PE that previously has been >>>only supporting Root ACs (or vice versa), removal of the last Leaf or >>>last Root AC from a PE that previously has been supporting a mix etc. >>>affect only the PE where this operation happens and not the rest of the = PEs. >>> >>> As for the need for HW changes that have been mentioned as a main >>>disadvantage of the CW-based approach - I believe it strongly depends >>>on specific implementations. And some changes in the forwarding >>>process are required in any solution. >>> >>> My 2c, >>> Sasha >>> >>> >>> >>> ________________________________________ >>> From: l2vpn-bounces@ietf.org >>> [l2vpn-bounces@ietf.org] on behalf of >>> Rogers, Josh >>> [josh.rogers@twcable.com] >>> Sent: Wednesday, April 18, 2012 9:57 PM >>> To: Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: Re: The status of the approaches to the E-Tree solution? >>> >>> Again, the P2MP situation throws me. Is this something that is used >>> commonly? >>> >>> I'm under the impression that adding P2MP to any model results in a >>> more complex model. Wether outside s-tag is used to differentiate, >>> or dedicated pw's are used for the same purpose, it seems both >>> become more complex. >>> >>> Gile's comparison slide still concisely captures the differences >>>between these methods, in my opinion. I haven't seen any new ideas >>>or thoughts brought to the group in the past week or two on the subject= . >>> I would hate for both proposed methods to die on the vine because we >>>couldn't decide between two methods that have nothing inherently >>>wrong with either. >>> >>> -Josh >>> >>> >>> On 4/18/12 1:53 PM, "Lucy yong" >>>> wrote: >>> >>>>Send this again. >>>> >>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and >>>>unknown unicast traffic, and some P2MP PWs for multicast traffic. It >>>>may double all of them. >>>> >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn >>>>[mailto:DanielC@orckit.com] >>>>Sent: Wednesday, April 18, 2012 1:42 PM >>>>To: Lucy yong; Rogers, Josh; Sam Cao >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>I think the first option its the natural way to go. How is the >>>>processing in this case more complex? >>>> >>>>Thumb typed - please be tolerant >>>> >>>>Lucy yong > wrote: >>>> >>>> >>>> >>>>Snipped.. >>>> >>>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only >>>>P2MP PW (for traffic coming from a leaf AC), or onto a Root/Leaf >>>>P2MP PW (for traffic coming from a root AC) [[LY]] Not that simple. >>>>You construct either two P2MP PWs to all other PEs and let egress PE >>>>performing filtering, or construct one P2MP PW to leaf-only PEs and >>>>two P2MP PWs to root and leaf PEs and let ingress PE perform >>>>forwarding and filtering. Both make node process complex. >>>> >>>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW >>>>for delivering the frames to remote PEs. We should utilize them with >>>>the minimized changes. Dual VLAN solution is simpler than Dual PW. >>>> >>>>Regards, >>>>Lucy >>>> >>>> >>>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>>>haven't had any first hand experience with P2MP PW's, however, so >>>>don't feel terribly strong about this objection. Is this a real >>>>problem for others (now or in the future), or is this objection in >>>>the weeds? >>>> >>>>I'm not sure the 'additional complexity' is notable, or even relevant. >>>>I encourage others to speak up if they disagree, as P2MP PW is only >>>>conceptual to me, and I am unfamiliar with real-life use cases for it. >>>> >>>>Thanks, >>>>Josh >>>> >>>> >>>> >>>>On 4/18/12 10:30 AM, "Lucy yong" >>>>> wrote: >>>> >>>>>Please see inline. >>>>> >>>>>-----Original Message----- >>>>>From: Sam Cao >>>>>[mailto:yuqun.cao@gmail.com] >>>>>Sent: Tuesday, April 17, 2012 7:14 AM >>>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>>>(Wim)'; giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>>>after improving Dual-PW approach. If consider P2MP, Dual-PW >>>>>approach setup 2 P2MP PWs if need. There is no difference between >>>>>P2MP or normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP= PW? >>>>> >>>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>>>PE have both root and leaf AC and some only have leaf ACs)? >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Yuqun (Sam) Cao >>>>>E-mail: Yuqun.cao@gmail.com >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn >>>>>[mailto:DanielC@orckit.com] >>>>>Sent: Tuesday, April 17, 2012 4:56 PM >>>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com>; Sam Cao >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Adding Sam (as l2vpn@ is holding messages) >>>>> >>>>>DC >>>>> >>>>>-----Original Message----- >>>>>From: Lucy yong >>>>>[mailto:lucy.yong@huawei.com] >>>>>Sent: Tuesday, April 17, 2012 12:39 AM >>>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>> >>>>>Snipped, >>>>> >>>>>As we discussed extensively in the list, and as reflected in giles >>>>>slide, 2 pws are only needed between pes with both root and leaf >>>>>acs, which will typically be a small minority. >>>>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>>>both approaches can benefit from it. I was off for a while and >>>>>captures some discussions now. >>>>> >>>>>Also as per giles slide, dual vlan can have scalability issues due >>>>>to additional lookup and double use of vlans in internal emulated >>>>>lan interface. Also there are potential backward compatibility >>>>>issues with silicon that doesn't support vlan mapping. >>>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. >>>>>I am not clear on all the issues. Could you be more specific? As I >>>>>mentioned in below, two PW approach makes VPLS transport >>>>>construction and packet forwarding more complex, I can see >>>>>potential backward compatibility issues with 2 PW solution. >>>>> >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Daniel >>>>> >>>>>Thumb typed - please be tolerant >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>>In my mind, the VLAN approach means dual vlan method. >>>>> >>>>>The main concern for CW approach is hardware support. >>>>> >>>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and >>>>>unknown unicast traffic, and some P2MP PWs for multicast traffic. >>>>>It may double all of them. >>>>> >>>>>E-tree is an Ethernet service and there is already VLAN based >>>>>solution in IEEE, can we just utilize it without complicating VPLS >>>>>transport construction? This also makes interworking with Eth only >>>>>network easier. >>>>> >>>>>Cheers, >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: Rogers, Josh >>>>>[mailto:josh.rogers@twcable.com] >>>>>Sent: Monday, April 16, 2012 8:35 AM >>>>>To: Lucy yong; Henderickx, Wim (Wim); >>>>>'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com' >>>>>; 'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>I believe the initial question was in regard to the CW method. Are >>>>>you saying that you no longer are interested in that method in >>>>>preference of the dual vlan method? >>>>> >>>>> >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>> >>>>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>>>> >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: l2vpn-bounces@ietf.org >>>>>[mailto:l2vpn-bounces@ietf.org] On >>>>>Behalf Of Henderickx, Wim (Wim) >>>>>Sent: Thursday, April 12, 2012 2:03 AM >>>>>To: 'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com' >>>>>; 'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>The vlan approach is superior as it also works for eth only >>>>>networks, etc. On top some vendors indicate hw issues with the cw >>>>>approach. As such we have dropped more or less the cw approach. >>>>> >>>>>Cheers, >>>>>Wim >>>>>_________________ >>>>>sent from blackberry >>>>> >>>>>----- Original Message ----- >>>>>From: Giles Heron >>>>>[mailto:giles.heron@gmail.com] >>>>>Sent: Thursday, April 12, 2012 08:22 AM >>>>>To: Simon Delord >>>>>>; Alexander >>>>>Vainshtein >>>>>>>>>le >>>>>.com>> >>>>>Cc: l2vpn@ietf.org >>>>>>; Vladimir Kleiner >>>>>> >>>>>; >>>>>Andrew Sergeev >>>>>>; >>>>>Idan Kaspit >>>>>>; >>>>>Mishael Wexler >>>>>>; >>>>>Rotem Cohen >>>>>> >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>Sorry - the "anonymous presentation" was mine. I should possibly >>>>>have put in a third column on the CW approach. And hopefully the >>>>>minutes will be posted soon. >>>>> >>>>>We had various discussions, as Simon stated, and consensus seemed >>>>>to be forming around the two alternatives of two PWEs or two VLANs. >>>>>I believe three of the authors of the CW approach are also authors >>>>>of the two VLAN approach and one is also an author of the two PWE >>>>>approach. So perhaps it's best to let those four individuals say >>>>>which approach they prefer and why? >>>>> >>>>>Giles >>>>> >>>>>On 10/04/2012 00:45, "Simon Delord" >>>>>> wrote: >>>>> >>>>>> Hi Alexander, >>>>>> >>>>>> You are right, no discussion on the WG mailing list recently, but >>>>>> there have been substantial discussions among the authors of >>>>>> various solution drafts off the mailing list. As far as I know, >>>>>> no consensus yet before ietf83, not sure the progress in the >>>>>> Paris WG meeting. I think the CW approach has not been rejected >>>>>> by the WG yet, or the WG has not yet decided on which one to adopt. >>>>>> >>>>>> Simon >>>>>> >>>>>> 2012/4/8 Alexander Vainshtein >>>>>> >>>>> te >>>>>> le.com>> >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>>>> >>>>>>> However, looking up the L2VPN proceedings, I've found a short >>>>>>> anonymous presentation called "E-Tree Update" ( >>>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>>>> This presentation discusses the differences of the E-Tree >>>>>>> approaches based on dedicated VLANs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?incl >>>>>>> ud >>>>>>> e_t >>>>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-p >>>>>>> w/ >>>>>>> ?in >>>>>>> clude_te >>>>>>> xt=3D1) >>>>>>> and completely ignores the solution based on usage of the CW in >>>>>>> the PWs connecting the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?incl >>>>>>> ud >>>>>>> e_t >>>>>>> ext=3D1 >>>>>>> ). >>>>>>> >>>>>>> >>>>>>> >>>>>>> The Minutes of the Paris L2VPN session are not yet available, >>>>>>> but I wonder whether the WG has taken a decision to reject the >>>>>>> approach based on the CW usage? I do not remember any recent >>>>>>> discussion of this topic on the WG mailing list. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, and lots of thanks in advance, >>>>>>> >>>>>>> Sasha >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This e-mail message is intended for the recipient only and >>>>>>> contains information which is CONFIDENTIAL and which may be >>>>>>> proprietary to ECI >>>>> >>>>>>> Telecom. If you have received this transmission in error, please >>>>>>> inform us by e-mail, phone or fax, and then delete the original >>>>>>> and all copies thereof. >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>This E-mail and any of its attachments may contain Time Warner >>>>>Cable proprietary information, which is privileged, confidential, >>>>>or subject to copyright belonging to Time Warner Cable. This E-mail >>>>>is intended solely for the use of the individual or entity to which >>>>>it is addressed. >>>>>If you are not the intended recipient of this E-mail, you are >>>>>hereby notified that any dissemination, distribution, copying, or >>>>>action taken in relation to the contents of and attachments to this >>>>>E-mail is strictly prohibited and may be unlawful. If you have >>>>>received this E-mail in error, please notify the sender immediately >>>>>and permanently delete the original and any copy of this E-mail and an= y printout. >>>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or >>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>intended solely for the use of the individual or entity to which it >>>>is addressed. If you are not the intended recipient of this E-mail, >>>>you are hereby notified that any dissemination, distribution, >>>>copying, or action taken in relation to the contents of and >>>>attachments to this E-mail is strictly prohibited and may be >>>>unlawful. If you have received this E-mail in error, please notify >>>>the sender immediately and permanently delete the original and any >>>>copy of this E-mail and any printout. >>> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or >>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>intended solely for the use of the individual or entity to which it is a= ddressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail >>>is strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> This e-mail message is intended for the recipient only and contains >>>information which is CONFIDENTIAL and which may be proprietary to ECI >>>Telecom. If you have received this transmission in error, please >>>inform us by e-mail, phone or fax, and then delete the original and >>>all copies thereof. >>> >>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> L2vpn mailing list >>> L2vpn@ietf.org >>> https://www.ietf.org/mailman/listinfo/l2vpn >>> >>> >>> End of L2vpn Digest, Vol 95, Issue 25 >>> *********************************** > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject >to copyright belonging to Time Warner Cable. This E-mail is intended >solely for the use of the individual or entity to which it is >addressed. If you are not the intended recipient of this E-mail, you >are hereby notified that any dissemination, distribution, copying, or >action taken in relation to the contents of and attachments to this >E-mail is strictly prohibited and may be unlawful. If you have received >this E-mail in error, please notify the sender immediately and >permanently delete the original and any copy of this E-mail and any printo= ut. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From lucy.yong@huawei.com Thu Apr 26 08:32:50 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECBC21E80D5 for ; Thu, 26 Apr 2012 08:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HS_INDEX_PARAM=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 i9Wpl07kYapN for ; Thu, 26 Apr 2012 08:32:47 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8E80D21E80D1 for ; Thu, 26 Apr 2012 08:32:47 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFP19370; Thu, 26 Apr 2012 11:32:47 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 26 Apr 2012 08:30:09 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Thu, 26 Apr 2012 08:29:45 -0700 From: Lucy yong To: "Rogers, Josh" , "Fedyk, Donald (Don)" , David Allan I , Daniel Cohn , "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0jLD6Ce/4Txq0Y50G6N17p5MncdwAA6bjAABFMSgAAEvqPQA== Date: Thu, 26 Apr 2012 15:30:10 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264C3A8@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D3264C202@dfweml505-mbx> 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.80] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@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, 26 Apr 2012 15:32:50 -0000 Josh, Dual VLAN draft describes option B only, which aligns with IEEE spec.. Not = sure which doc. talks about option A and suggest not discussing option A on= email anymore. Regards, Lucy -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Wednesday, April 25, 2012 6:23 PM To: Lucy yong; Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.= org Subject: Re: The status of the approaches to the E-Tree solution? [[LY]] This is not my understanding. Here we talk about incoming frame already has c-tag and s-tag, which is not UNI case. In addition, it seems that Daniel say that only option A works. That=B9s funny, I thought someone said that only option B would work. I think technically either is possible, but I am unclear which the 2VLAN draft would advise (or if it even does) -Josh On 4/25/12 5:22 PM, "Lucy yong" wrote: >Hi Josh, > >Please see inline. > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Rogers, Josh >Sent: Wednesday, April 25, 2012 4:42 PM >To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >Dave/Daniel/Lucy/Others Debating how many tags necessary when S-Tag >preservation is desired, > > >I think you all may have gone off on a tangent here. The original >discussion was about how to deal with the situation where the S-Tag is >preserved at a handoff (either an ENNI, or Service Multiplexed UNI) >[[LY]] in MEF, S-Tag applies to ENNI only, not UNI. An UNI can support >multiplexed services, i.e. terminate many EVCs. In this case, each EVC >associates with one or multiple c-tags. EVC has a service attribute for >listing associated c-tags. > >I believe there were two suggestions, one was that you push on a 'ETREE' >tag (one of two values, for either a frame sourced from a root AC or >another for a frame from a leaf AC), and the second solution was to 'map'. >[[LY]] This is not my understanding. Here we talk about incoming frame >already has c-tag and s-tag, which is not UNI case. In addition, it seems >that Daniel say that only option A works. > > >Imagine the following topology: > >+-----+ +-----+ +-----+ +-----+ >| CE1 |--| PE1 |--| PE2 |--| CE2 | >+-----+ +-----+ +-----+ +-----+ > | | >+-----+ +-----+ +-----+ +-----+ >| CE3 |--| PE3 |--| PE4 |--| CE4 | >+-----+ +-----+ +-----+ +-----+ > >Where: > >Site Type VLAN >CE1 Root X >CE2 Leaf 2 >CE3 Leaf 3 >CE4 Leaf 3 > > >So, there are a lot of SP's who are keen on the way many services can be >handed to a customer on a single UNI, but coordinating a single VLAN per >service, with the customer (MEF used to call this EVPL when it was many >point to point services terminating on a single UNI). So, imagine that we >have two ETREE instances, and an internet service all terminating on a >single UNI connecting to CE1. We have negotiated VLAN ID's with the >customer, and they are expecting to reach CE2 using VLAN 2, CE3 and CE4 >using VLAN 3, and Internet service on VLAN 10. As a frame from CE1 comes >into PE1 destined for CE2 (so the customer has tagged it with VID 2), >using the 2VLAN method, since this is coming from a root site, do we > >a) place the Root S-Tag in front of VID 2, then ship it across, and pop >off the ETREE S-Tag (some SP's wish to Pop the original customer tag VID 2 >as well) > >-or- > >b) swap VID2 for the ETREE Root S-Tag, send the frame to PE2 where it will >remove the S-Tag (and either push VID2 back on, or leave it off depending >on SP preference) > >The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the customer, >as well as the Etree VID which designates the source (root or leaf) >[[LY]] Since dual VLAN solution tries to inline with IEEE solution, if >this is the use case, we suggests to go with option B, not A. So please >don't discuss option A more. > >Regards, >Lucy > > >Hope that clears more than it confuses, >Josh > > > >On 4/25/12 4:22 PM, "Fedyk, Donald (Don)" > wrote: > >>Hi Dave >> >>Yes the only point I would add is Dual VLAN means One VID for Root and >>one VID for Leaf. Not two TAGs at a time on the frame but two allocated >>for the service. >> >>The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks >>about Encapsulation Overhead as a VLAN Tag. While that is true in a PWE >>sense it is still a single VLAN Tag at a time in a Ethernet E-tree sense. >> The compelling driver for Dual VLAN is having a Etree service that works >>in many environments and the DUAL VLAN (really dual VLAN interface on a >>VSI) uses the same mechanism (one VID for root and one VID for Leaf at a >>time) as specified in the IEEE. In a pure Ethernet bridging world the >>VLAN TAGs for Etree are not typically an overhead since translation is >>used. >> >>Don >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>David Allan I >>Sent: Wednesday, April 25, 2012 5:05 PM >>To: Daniel Cohn; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>OK I feel like I am digressing a fair distance from the actual >>problem.... But here goes: >> >>So the scenarios center around "how ETREE do you want to be?".... >> >>If the ACs are root/leaf, then if they are P2P (single ethernet end >>station attached to each AC) this is moot. ETREE semantics are enforced >>by the 2VID domain in the center of the example. If you assumed nodes A&B >>in the example were L2VPN PEs, the tagging and the PW tag imposition all >>happened at the same point in the network. >> >>If they are not simple P2P all the way to end systems and the objective >>is to avoid bridging between leaf "sites" but allowing intra-leaf-site >>connectivity then the leaves can be LANs but the root is not, such that I >>cannot bridge through the root. But all hosts at a given leaf site can >>see each other. So root Ethernet end systems are directly attached or two >>VIDs are used in the root site. >> >>If the objective is that there are multiple ethernet attached end >>stations at both the leaf and root sites, and the objective is to enforce >>L2 isolation everywhere then I need two VIDs extended to the end system >>attachement point in the local LANs by whatever means.... >> >>And I do not see adding VLANs in any particular spot, simply selection of >>the VID and associated semantics where VIDs are translated. The actual >>point of S-tag imposition could be a PE, or cloud be a NID/CLE on the >>customer prem (more likely scenario here to extend OAM demarc to the >>prem), or some switch in a RAN downstream of the MPLS PE... blah blah >>blah. And if ETREE is extended into a customer site LAN and outside of >>the provider domain, then two C-tags would have to be used that mapped to >>S-tags at the PBN boundary... >> >>Make sense? >>Dave >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 25, 2012 4:39 PM >>To: David Allan I; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Dave, but the ACs are root/leaf (that's what the whole vpls etree is >>about - see the reqt draft), so per the 2vlan draft the root/leaf vlan >>must be added. >> >>Thumb typed - please be tolerant >> >>David Allan I wrote: >> >>HI Daniel: >> >>In the example provided, >> >>"ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" >> A B >> >>the service is not ETREE in the domains of the ingress and egress VID. It >>is ELAN. SO there is no root/leaf attribute to shovel around. It would >>require two VIDs in each domain if the ETREE semantics were to be >>telescoped E2E. >> >>Otherwise it is a provisioning of the VID translation tables at the >>intermediate nodes (A&B that I've added to the picture) that would >>determine the VID values used in each domain. Or in the example above, >>what the ingress, Etree and egress VID values were. >> >>Cheers >>Dave >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>Daniel Cohn >>Sent: Wednesday, April 25, 2012 3:46 PM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>And to this I asked how this mapping works - how does the egress pe >>recover the ingress vid when it gets the frame tagged with only the >>root/leaf vid? How can you convey the ingress vid plus the root/leaf >>attribute in the same number of bits? >>What am I missing? >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>David Allen already explained the solution. >> >>From David: >>ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. >> >>Ingress VID does not have to equal Egress VID but regardless there is >>only ever one VID on a frame at a time. >> >>-end >> >>This works when customer makes ingress VLAN ID not equal to or equal to >>egress VLAN ID. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>Daniel Cohn >>Sent: Wednesday, April 25, 2012 11:39 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Lucy, >> >>The scenario we are discussing is not the E-Tree E-NNI, but a general >>scenario where frames arriving at the root or leaf AC are already double >>tagged. In this case, the dual vlan solution cannot preserve the vlans >>without adding a third one, can it? >> >>Maybe Shahram can add details on the scenario he had in mind >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has S-VLAN preservation attribute for ENNI only because there is no >>s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN >>preservation attribute is used. It applies to E-Tree as well. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>Daniel Cohn >>Sent: Tuesday, April 24, 2012 2:12 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Lucy, >> >>even if the current MEF framework doesn't require s-vlan preservation, I >>believe it's to the industry's benefit to adopt a solution that is not >>constrained to a specific enni model that, like all things networking, is >>likely to evolve. Especially when such a solution is available. >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has worked in ENNI interface for a long time with many service >>providers' inputs. It had a fair reason to assume S-VLAN over ENNI by >>then. It may open B-VLAN for the future. It is better for us not to >>discuss a future framework here, because it will lead us to nowhere. >>Here, we want to extend VPLS in supporting E-Tree. >> >>Best Regards, >>Lucy >> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>Daniel Cohn >>Sent: Sunday, April 22, 2012 7:34 AM >>To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Shahram and all, >> >>This question already came up in our discussions - is it safe to assume >>that the VLAN tags at the E-NNI will always be according to the current >>MEF model? Or should we try to be as transparent as possible to user VLAN >>encapsulation at the E-NNI, to accommodate future frameworks? >>I believe that any approach that looks at user payload (in this case VLAN >>tag) to signal VPLS information (in this case root/leaf origin) is >>necessarily tied to specific assumptions on user payload encapsulation >>(in this case, that S-VLAN tag is "available" to encode root/leaf). I >>don't think this is a future-proof assumption, it's very likely that >>other network models will come up that require S-VLAN preservation, which >>in the 2-VLAN approach would necessitate adding a third VLAN-ID. >> >>Daniel >> >>From: Shahram Davari > >>To: Lizhong Jin >, >>"l2vpn@ietf.org" >>>, >>"Alexander.Vainshtein@ecitele.com>> >>" >>>> >>> >>Cc: "yuqun.cao@gmail.com" >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, >> >>I also have a question regarding 2-VLAN. What if the customer traffic >>already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? >> >>Thx >>Shahram >> >>From: l2vpn-bounces@ietf.org >>[mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin >>Sent: Friday, April 20, 2012 9:38 AM >>To: l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, all, >>The difference between 2-VLAN and CW approach is who will provide the R/L >>information, customer payload or PW? The customer payload will be always >>modified to carry R/L information in 2-VLAN approach, while PW with CW >>will carry R/L information for CW approach. >>I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is >>accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used >>to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L >>information? >> >>Thanks >>Lizhong >> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Thu, 19 Apr 2012 04:38:36 +0000 >>> From: Alexander Vainshtein >>> >> com>> >>> To: "Rogers, Josh" >>>>, Lucy yong >>> >, Daniel Cohn >>>>, Sam Cao >>> > >>> Cc: "l2vpn@ietf.org" >>> > >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> Message-ID: >>> >>> >> o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> >>> Content-Type: text/plain; charset=3D"us-ascii" >>> >>> Hi all, >>> I fully understand that that what I am going to say is not very >>>popular, but: >>> >>> IMO one of the advantages of the CW-based solution is that it is >>>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of >>>BUN traffic. >>> >>> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>>and, in a more generic way, localization of effects of changes in the PE >>>configuration. >>> >>> In particular, adding a Leaf AC to a PE that previously has been only >>>supporting Root ACs (or vice versa), removal of the last Leaf or last >>>Root AC from a PE that previously has been supporting a mix etc. affect >>>only the PE where this operation happens and not the rest of the PEs. >>> >>> As for the need for HW changes that have been mentioned as a main >>>disadvantage of the CW-based approach - I believe it strongly depends on >>>specific implementations. And some changes in the forwarding process are >>>required in any solution. >>> >>> My 2c, >>> Sasha >>> >>> >>> >>> ________________________________________ >>> From: l2vpn-bounces@ietf.org >>> [l2vpn-bounces@ietf.org] on behalf of >>> Rogers, Josh [josh.rogers@twcable.com] >>> Sent: Wednesday, April 18, 2012 9:57 PM >>> To: Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: Re: The status of the approaches to the E-Tree solution? >>> >>> Again, the P2MP situation throws me. Is this something that is used >>> commonly? >>> >>> I'm under the impression that adding P2MP to any model results in a >>> more complex model. Wether outside s-tag is used to differentiate, or >>> dedicated pw's are used for the same purpose, it seems both become >>> more complex. >>> >>> Gile's comparison slide still concisely captures the differences >>> between these methods, in my opinion. I haven't seen any new ideas or >>> thoughts brought to the group in the past week or two on the subject. >>> I would hate for both proposed methods to die on the vine because we >>> couldn't decide between two methods that have nothing inherently wrong >>>with either. >>> >>> -Josh >>> >>> >>> On 4/18/12 1:53 PM, "Lucy yong" >>>> wrote: >>> >>>>Send this again. >>>> >>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>>double all of them. >>>> >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn >>>>[mailto:DanielC@orckit.com] >>>>Sent: Wednesday, April 18, 2012 1:42 PM >>>>To: Lucy yong; Rogers, Josh; Sam Cao >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>I think the first option its the natural way to go. How is the >>>>processing in this case more complex? >>>> >>>>Thumb typed - please be tolerant >>>> >>>>Lucy yong > wrote: >>>> >>>> >>>> >>>>Snipped.. >>>> >>>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP >>>>PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW >>>>(for traffic coming from a root AC) [[LY]] Not that simple. You >>>>construct either two P2MP PWs to all other PEs and let egress PE >>>>performing filtering, or construct one P2MP PW to leaf-only PEs and >>>>two P2MP PWs to root and leaf PEs and let ingress PE perform >>>>forwarding and filtering. Both make node process complex. >>>> >>>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>>>delivering the frames to remote PEs. We should utilize them with the >>>>minimized changes. Dual VLAN solution is simpler than Dual PW. >>>> >>>>Regards, >>>>Lucy >>>> >>>> >>>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>>>haven't had any first hand experience with P2MP PW's, however, so >>>>don't feel terribly strong about this objection. Is this a real >>>>problem for others (now or in the future), or is this objection in the >>>>weeds? >>>> >>>>I'm not sure the 'additional complexity' is notable, or even relevant. >>>>I encourage others to speak up if they disagree, as P2MP PW is only >>>>conceptual to me, and I am unfamiliar with real-life use cases for it. >>>> >>>>Thanks, >>>>Josh >>>> >>>> >>>> >>>>On 4/18/12 10:30 AM, "Lucy yong" >>>>> wrote: >>>> >>>>>Please see inline. >>>>> >>>>>-----Original Message----- >>>>>From: Sam Cao >>>>>[mailto:yuqun.cao@gmail.com] >>>>>Sent: Tuesday, April 17, 2012 7:14 AM >>>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>>>(Wim)'; giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>>>> >>>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>>>PE have both root and leaf AC and some only have leaf ACs)? >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Yuqun (Sam) Cao >>>>>E-mail: Yuqun.cao@gmail.com >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn >>>>>[mailto:DanielC@orckit.com] >>>>>Sent: Tuesday, April 17, 2012 4:56 PM >>>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com>; Sam Cao >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Adding Sam (as l2vpn@ is holding messages) >>>>> >>>>>DC >>>>> >>>>>-----Original Message----- >>>>>From: Lucy yong >>>>>[mailto:lucy.yong@huawei.com] >>>>>Sent: Tuesday, April 17, 2012 12:39 AM >>>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>> >>>>>Snipped, >>>>> >>>>>As we discussed extensively in the list, and as reflected in giles >>>>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>>>which will typically be a small minority. >>>>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>>>both approaches can benefit from it. I was off for a while and >>>>>captures some discussions now. >>>>> >>>>>Also as per giles slide, dual vlan can have scalability issues due to >>>>>additional lookup and double use of vlans in internal emulated lan >>>>>interface. Also there are potential backward compatibility issues >>>>>with silicon that doesn't support vlan mapping. >>>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I >>>>>am not clear on all the issues. Could you be more specific? As I >>>>>mentioned in below, two PW approach makes VPLS transport construction >>>>>and packet forwarding more complex, I can see potential backward >>>>>compatibility issues with 2 PW solution. >>>>> >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Daniel >>>>> >>>>>Thumb typed - please be tolerant >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>>In my mind, the VLAN approach means dual vlan method. >>>>> >>>>>The main concern for CW approach is hardware support. >>>>> >>>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>>>double all of them. >>>>> >>>>>E-tree is an Ethernet service and there is already VLAN based >>>>>solution in IEEE, can we just utilize it without complicating VPLS >>>>>transport construction? This also makes interworking with Eth only >>>>>network easier. >>>>> >>>>>Cheers, >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: Rogers, Josh >>>>>[mailto:josh.rogers@twcable.com] >>>>>Sent: Monday, April 16, 2012 8:35 AM >>>>>To: Lucy yong; Henderickx, Wim (Wim); >>>>>'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com'; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>I believe the initial question was in regard to the CW method. Are >>>>>you saying that you no longer are interested in that method in >>>>>preference of the dual vlan method? >>>>> >>>>> >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>> >>>>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>>>> >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: l2vpn-bounces@ietf.org >>>>>[mailto:l2vpn-bounces@ietf.org] On >>>>>Behalf Of Henderickx, Wim (Wim) >>>>>Sent: Thursday, April 12, 2012 2:03 AM >>>>>To: 'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com'; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>The vlan approach is superior as it also works for eth only networks, >>>>>etc. On top some vendors indicate hw issues with the cw approach. As >>>>>such we have dropped more or less the cw approach. >>>>> >>>>>Cheers, >>>>>Wim >>>>>_________________ >>>>>sent from blackberry >>>>> >>>>>----- Original Message ----- >>>>>From: Giles Heron >>>>>[mailto:giles.heron@gmail.com] >>>>>Sent: Thursday, April 12, 2012 08:22 AM >>>>>To: Simon Delord >>>>>>; Alexander >>>>>Vainshtein >>>>>>>>>.com>> >>>>>Cc: l2vpn@ietf.org >>>>>>; Vladimir Kleiner >>>>>>; >>>>>Andrew Sergeev >>>>>>; Idan >>>>>Kaspit >; >>>>>Mishael Wexler >>>>>>; >>>>>Rotem Cohen > >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>Sorry - the "anonymous presentation" was mine. I should possibly >>>>>have put in a third column on the CW approach. And hopefully the >>>>>minutes will be posted soon. >>>>> >>>>>We had various discussions, as Simon stated, and consensus seemed to >>>>>be forming around the two alternatives of two PWEs or two VLANs. I >>>>>believe three of the authors of the CW approach are also authors of >>>>>the two VLAN approach and one is also an author of the two PWE >>>>>approach. So perhaps it's best to let those four individuals say >>>>>which approach they prefer and why? >>>>> >>>>>Giles >>>>> >>>>>On 10/04/2012 00:45, "Simon Delord" >>>>>> wrote: >>>>> >>>>>> Hi Alexander, >>>>>> >>>>>> You are right, no discussion on the WG mailing list recently, but >>>>>> there have been substantial discussions among the authors of >>>>>> various solution drafts off the mailing list. As far as I know, no >>>>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>>>> meeting. I think the CW approach has not been rejected by the WG >>>>>> yet, or the WG has not yet decided on which one to adopt. >>>>>> >>>>>> Simon >>>>>> >>>>>> 2012/4/8 Alexander Vainshtein >>>>>> >>>>> le.com>> >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>>>> >>>>>>> However, looking up the L2VPN proceedings, I've found a short >>>>>>> anonymous presentation called "E-Tree Update" ( >>>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>>>> This presentation discusses the differences of the E-Tree >>>>>>> approaches based on dedicated VLANs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?includ >>>>>>> e_t >>>>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/ >>>>>>> ?in >>>>>>> clude_te >>>>>>> xt=3D1) >>>>>>> and completely ignores the solution based on usage of the CW in >>>>>>> the PWs connecting the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?includ >>>>>>> e_t >>>>>>> ext=3D1 >>>>>>> ). >>>>>>> >>>>>>> >>>>>>> >>>>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>>>> I wonder whether the WG has taken a decision to reject the >>>>>>> approach based on the CW usage? I do not remember any recent >>>>>>> discussion of this topic on the WG mailing list. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, and lots of thanks in advance, >>>>>>> >>>>>>> Sasha >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This e-mail message is intended for the recipient only and >>>>>>> contains information which is CONFIDENTIAL and which may be >>>>>>> proprietary to ECI >>>>> >>>>>>> Telecom. If you have received this transmission in error, please >>>>>>> inform us by e-mail, phone or fax, and then delete the original >>>>>>> and all copies thereof. >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>>proprietary information, which is privileged, confidential, or >>>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>>intended solely for the use of the individual or entity to which it is >>>>>addressed. >>>>>If you are not the intended recipient of this E-mail, you are hereby >>>>>notified that any dissemination, distribution, copying, or action >>>>>taken in relation to the contents of and attachments to this E-mail >>>>>is strictly prohibited and may be unlawful. If you have received this >>>>>E-mail in error, please notify the sender immediately and permanently >>>>>delete the original and any copy of this E-mail and any printout. >>>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or subject >>>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>>solely for the use of the individual or entity to which it is >>>>addressed. If you are not the intended recipient of this E-mail, you >>>>are hereby notified that any dissemination, distribution, copying, or >>>>action taken in relation to the contents of and attachments to this >>>>E-mail is strictly prohibited and may be unlawful. If you have >>>>received this E-mail in error, please notify the sender immediately >>>>and permanently delete the original and any copy of this E-mail and any >>>>printout. >>> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action taken >>>in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> This e-mail message is intended for the recipient only and contains >>>information which is CONFIDENTIAL and which may be proprietary to ECI >>>Telecom. If you have received this transmission in error, please inform >>>us by e-mail, phone or fax, and then delete the original and all copies >>>thereof. >>> >>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> L2vpn mailing list >>> L2vpn@ietf.org >>> https://www.ietf.org/mailman/listinfo/l2vpn >>> >>> >>> End of L2vpn Digest, Vol 95, Issue 25 >>> *********************************** > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From lucy.yong@huawei.com Thu Apr 26 08:40:57 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B197521F86BE for ; Thu, 26 Apr 2012 08:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HS_INDEX_PARAM=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 AAcbAnceG0YT for ; Thu, 26 Apr 2012 08:40:55 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAF021E8089 for ; Thu, 26 Apr 2012 08:40:55 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFP19845; Thu, 26 Apr 2012 11:40:55 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 26 Apr 2012 08:38:30 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Thu, 26 Apr 2012 08:38:06 -0700 From: Lucy yong To: Sam Cao , "l2vpn@ietf.org" Subject: RE: L2vpn Digest, Vol 95, Issue 93 Thread-Topic: L2vpn Digest, Vol 95, Issue 93 Thread-Index: Ac0jJrsymEv6P9vTQlaKer/7cNnolQAKbiaQABxH6TA= Date: Thu, 26 Apr 2012 15:38:31 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264C3B9@dfweml505-mbx> References: <2CF7D8B0066C43E793BFBB6EC21D3117@R01842> In-Reply-To: <2CF7D8B0066C43E793BFBB6EC21D3117@R01842> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.140.80] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@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, 26 Apr 2012 15:40:57 -0000 Sam, I think we are talking two different things. S-VLAN IDs for root and leaf a= re necessary to be informed between PE and remote PE. Here we talk about th= e frames from/to s-tagged port and how PE performs local translation in sup= porting E-Tree. If you are still confused, please read many e-mail responses for original s= ubject carefully. Regards, Lucy =20 -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of S= am Cao Sent: Wednesday, April 25, 2012 9:11 PM To: l2vpn@ietf.org Subject: RE: L2vpn Digest, Vol 95, Issue 93 Lucy, I am confused with "use local translation instead of mapping". My understanding on this is, there is VLAN mapping negotiation between ingress PE and egress PE. This meeting global VLAN allocation is proposed, but base= d on my understanding, we should add new VLAN ID, for raw mode or tagged mode= . Anything missing? Thanks, Sam -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of l2vpn-request@ietf.org Sent: Thursday, April 26, 2012 5:02 AM To: l2vpn@ietf.org Subject: L2vpn Digest, Vol 95, Issue 93 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to=20 https://www.ietf.org/mailman/listinfo/l2vpn Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send L2vpn mailing list submissions to l2vpn@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/l2vpn or, via email, send a message with subject or body 'help' to l2vpn-request@ietf.org You can reach the person managing the list at l2vpn-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of L2vpn digest..." Today's Topics: 1. RE: The status of the approaches to the E-Tree solution? (Lucy yong) ---------------------------------------------------------------------- Message: 1 Date: Wed, 25 Apr 2012 20:59:59 +0000 From: Lucy yong To: Daniel Cohn , "Rogers, Josh" , Shahram Davari , Lizhong Jin , "l2vpn@ietf.org" , "Alexander.Vainshtein@ecitele.com" Cc: "yuqun.cao@gmail.com" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264C1A2@dfweml505-mbx> Content-Type: text/plain; charset=3D"utf-8" The current VLAN draft does not assume double tag frame at AC. If we have t= o consider this case, the solution was discussed in the e-mail. I should use local translation instead of mapping in previous e-mail, which makes it mor= e clear. In this case, PE knows which S-VLAN ID is used on an AC, so PE inserts the same S-VLAN ID on the frames going toward to the AC. This is th= e part you missed. Lucy -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Wednesday, April 25, 2012 3:31 PM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, don't understand what you mean by "obey the rule first". Say you get a frame with double tag at a leaf ac. According to the 2 vlan draft, you must add the leaf vlan before forwarding the frame to the mpls, otherwise the egress pe won't know it can only forward the frame over root acs. If you remove the outer tag on ingress, how can you recover it on egress? If you don't remove it, you get a 3-deep stack. Daniel Thumb typed - please be tolerant Lucy yong wrote: Local mapping is sufficient for this. If a customer wish both ingress VLAN ID and egress VLAN ID are the same, it obeys the rule first, then local translate in MPLS will work perfectly. Lucy -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Wednesday, April 25, 2012 2:46 PM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? And to this I asked how this mapping works - how does the egress pe recover the ingress vid when it gets the frame tagged with only the root/leaf vid? How can you convey the ingress vid plus the root/leaf attribute in the same number of bits? What am I missing? Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, David Allen already explained the solution.=20 >From David: ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. Ingress VID does not have to equal Egress VID but regardless there is only ever one VID on a frame at a time. -end This works when customer makes ingress VLAN ID not equal to or equal to egress VLAN ID. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: Wednesday, April 25, 2012 11:39 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi Lucy, The scenario we are discussing is not the E-Tree E-NNI, but a general scenario where frames arriving at the root or leaf AC are already double tagged. In this case, the dual vlan solution cannot preserve the vlans without adding a third one, can it? Maybe Shahram can add details on the scenario he had in mind Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has S-VLAN preservation attribute for ENNI only because there is no s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN preservation attribute is used. It applies to E-Tree as well. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: Tuesday, April 24, 2012 2:12 AM To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Lucy, even if the current MEF framework doesn't require s-vlan preservation, I believe it's to the industry's benefit to adopt a solution that is not constrained to a specific enni model that, like all things networking, is likely to evolve. Especially when such a solution is available. Daniel Thumb typed - please be tolerant Lucy yong wrote: Daniel, MEF has worked in ENNI interface for a long time with many service providers' inputs. It had a fair reason to assume S-VLAN over ENNI by then. It may open B-VLAN for the future. It is better for us not to discuss a future framework here, because it will lead us to nowhere. Here, we want to extend VPLS in supporting E-Tree. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: Sunday, April 22, 2012 7:34 AM To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Shahram and all, This question already came up in our discussions - is it safe to assume tha= t the VLAN tags at the E-NNI will always be according to the current MEF model? Or should we try to be as transparent as possible to user VLAN encapsulation at the E-NNI, to accommodate future frameworks? I believe that any approach that looks at user payload (in this case VLAN tag) to signal VPLS information (in this case root/leaf origin) is necessarily tied to specific assumptions on user payload encapsulation (in this case, that S-VLAN tag is "available" to encode root/leaf). I don't think this is a future-proof assumption, it's very likely that other networ= k models will come up that require S-VLAN preservation, which in the 2-VLAN approach would necessitate adding a third VLAN-ID. Daniel From: Shahram Davari > To: Lizhong Jin >, "l2vpn@ietf.org" >, "Alexander.Vainshtein@ecitele.com" > Cc: "yuqun.cao@gmail.com" > Subject: RE: The status of the approaches to the E-Tree solution? Hi, I also have a question regarding 2-VLAN. What if the customer traffic already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? Thx Shahram From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin Sent: Friday, April 20, 2012 9:38 AM To: l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com Cc: yuqun.cao@gmail.com Subject: RE: The status of the approaches to the E-Tree solution? Hi, all, The difference between 2-VLAN and CW approach is who will provide the R/L information, customer payload or PW? The customer payload will be always modified to carry R/L information in 2-VLAN approach, while PW with CW will carry R/L information for CW approach. I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate R/L information? Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2012 04:38:36 +0000 > From: Alexander Vainshtein > > To: "Rogers, Josh" >, Lucy yong > >, Daniel Cohn >, Sam Cao > > > Cc: "l2vpn@ietf.org" > > Subject: RE: The status of the approaches to the E-Tree solution? > Message-ID: > > > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all, > I fully understand that that what I am going to say is not very popular, but: > > IMO one of the advantages of the CW-based solution is that it is orthogonal to usage (or non-usage) of P2MP PWs for effective delivery of BU= N traffic. > > Another advantage is preservation of full mesh of P2P PWs in a VPLS, and, in a more generic way, localization of effects of changes in the PE configuration. > > In particular, adding a Leaf AC to a PE that previously has been only supporting Root ACs (or vice versa), removal of the last Leaf or last Root AC from a PE that previously has been supporting a mix etc. affect only the PE where this operation happens and not the rest of the PEs. > > As for the need for HW changes that have been mentioned as a main disadvantage of the CW-based approach - I believe it strongly depends on specific implementations. And some changes in the forwarding process are required in any solution. > > My 2c, > Sasha > > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Rogers= , Josh [josh.rogers@twcable.com] > Sent: Wednesday, April 18, 2012 9:57 PM > To: Lucy yong; Daniel Cohn; Sam Cao > Cc: l2vpn@ietf.org > Subject: Re: The status of the approaches to the E-Tree solution? > > Again, the P2MP situation throws me. Is this something that is used > commonly? > > I'm under the impression that adding P2MP to any model results in a more > complex model. Wether outside s-tag is used to differentiate, or > dedicated pw's are used for the same purpose, it seems both become more > complex. > > Gile's comparison slide still concisely captures the differences between > these methods, in my opinion. I haven't seen any new ideas or thoughts > brought to the group in the past week or two on the subject. I would hat= e > for both proposed methods to die on the vine because we couldn't decide > between two methods that have nothing inherently wrong with either. > > -Josh > > > On 4/18/12 1:53 PM, "Lucy yong" > wrote: > >>Send this again. >> >>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>unicast traffic, and some P2MP PWs for multicast traffic. It may double >>all of them. >> >>Lucy >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 18, 2012 1:42 PM >>To: Lucy yong; Rogers, Josh; Sam Cao >>Cc: l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>I think the first option its the natural way to go. How is the processing >>in this case more complex? >> >>Thumb typed - please be tolerant >> >>Lucy yong > wrote: >> >> >> >>Snipped.. >> >>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP PW >>(for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW (for >>traffic coming from a root AC) >>[[LY]] Not that simple. You construct either two P2MP PWs to all other >>PEs and let egress PE performing filtering, or construct one P2MP PW to >>leaf-only PEs and two P2MP PWs to root and leaf PEs and let ingress PE >>perform forwarding and filtering. Both make node process complex. >> >>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>delivering the frames to remote PEs. We should utilize them with the >>minimized changes. Dual VLAN solution is simpler than Dual PW. >> >>Regards, >>Lucy >> >> >>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>haven't had any first hand experience with P2MP PW's, however, so don't >>feel terribly strong about this objection. Is this a real problem for >>others (now or in the future), or is this objection in the weeds? >> >>I'm not sure the 'additional complexity' is notable, or even relevant. I >>encourage others to speak up if they disagree, as P2MP PW is only >>conceptual to me, and I am unfamiliar with real-life use cases for it. >> >>Thanks, >>Josh >> >> >> >>On 4/18/12 10:30 AM, "Lucy yong" > wrote: >> >>>Please see inline. >>> >>>-----Original Message----- >>>From: Sam Cao [mailto:yuqun.cao@gmail.com] >>>Sent: Tuesday, April 17, 2012 7:14 AM >>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim (Wim)'; >>>giles.heron@gmail.com; simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Yes, 2 pws are only needed between pes with both root and leaf acs after >>>improving Dual-PW approach. If consider P2MP, Dual-PW approach setup 2 >>>P2MP >>>PWs if need. There is no difference between P2MP or normal PW setup. But= , >>>can Leaf-ACs be bound to Root PE of P2MP PW? >>> >>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with both >>>root and leaf ACs set up two or one P2MP PW to other PEs (some PE have >>>both root and leaf AC and some only have leaf ACs)? >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Yuqun (Sam) Cao >>>E-mail: Yuqun.cao@gmail.com >>> >>> >>>-----Original Message----- >>>From: Daniel Cohn [mailto:DanielC@orckit.com] >>>Sent: Tuesday, April 17, 2012 4:56 PM >>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; >>>simon.delord@gmail.com; Alexander.Vainshtein@ecitele.com; Sam Cao >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>Adding Sam (as l2vpn@ is holding messages) >>> >>>DC >>> >>>-----Original Message----- >>>From: Lucy yong [mailto:lucy.yong@huawei.com] >>>Sent: Tuesday, April 17, 2012 12:39 AM >>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>giles.heron@gmail.com; simon.delord@gmail.com; >>>Alexander.Vainshtein@ecitele.com >>>Cc: l2vpn@ietf.org; Vladimir.Kleiner@ecitele.com; >>>Andrew.Sergeev@ecitele.com; Idan.Kaspit@ecitele.com; >>>Mishael.Wexler@ecitele.com; Rotem.Cohen@ecitele.com >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>> >>>Snipped, >>> >>>As we discussed extensively in the list, and as reflected in giles >>>slide, 2 pws are only needed between pes with both root and leaf acs, >>>which will typically be a small minority. >>>[[LY]] Don't know if the assumption is true. Even it is the case, both >>>approaches can benefit from it. I was off for a while and captures some >>>discussions now. >>> >>>Also as per giles slide, dual vlan can have scalability issues due to >>>additional lookup and double use of vlans in internal emulated lan >>>interface. Also there are potential backward compatibility issues with >>>silicon that doesn't support vlan mapping. >>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I am >>>not clear on all the issues. Could you be more specific? As I mentioned >>>in below, two PW approach makes VPLS transport construction and packet >>>forwarding more complex, I can see potential backward compatibility >>>issues with 2 PW solution. >>> >>>Regards, >>>Lucy >>> >>>Regards, >>> >>>Daniel >>> >>>Thumb typed - please be tolerant >>> >>>Lucy yong > wrote: >>> >>>In my mind, the VLAN approach means dual vlan method. >>> >>>The main concern for CW approach is hardware support. >>> >>>Two PW approach can be complex too if the VPLS instance for E-Tree uses >>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown unicast >>>traffic, and some P2MP PWs for multicast traffic. It may double all of >>>them. >>> >>>E-tree is an Ethernet service and there is already VLAN based solution >>>in IEEE, can we just utilize it without complicating VPLS transport >>>construction? This also makes interworking with Eth only network easier. >>> >>>Cheers, >>>Lucy >>> >>>-----Original Message----- >>>From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>>Sent: Monday, April 16, 2012 8:35 AM >>>To: Lucy yong; Henderickx, Wim (Wim); 'giles.heron@gmail.com'; >>>'simon.delord@gmail.com'; 'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>>Subject: RE: The status of the approaches to the E-Tree solution? >>> >>>I believe the initial question was in regard to the CW method. Are you >>>saying that you no longer are interested in that method in preference of >>>the dual vlan method? >>> >>> >>> >>>Lucy yong > wrote: >>> >>> >>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>> >>>Lucy >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>Of Henderickx, Wim (Wim) >>>Sent: Thursday, April 12, 2012 2:03 AM >>>To: 'giles.heron@gmail.com'; 'simon.delord@gmail.com'; >>>'Alexander.Vainshtein@ecitele.com' >>>Cc: 'l2vpn@ietf.org'; 'Vladimir.Kleiner@ecitele.com'; >>>'Andrew.Sergeev@ecitele.com'; 'Idan.Kaspit@ecitele.com'; >>>'Mishael.Wexler@ecitele.com'; 'Rotem.Cohen@ecitele.com' >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>The vlan approach is superior as it also works for eth only networks, >>>etc. On top some vendors indicate hw issues with the cw approach. As >>>such we have dropped more or less the cw approach. >>> >>>Cheers, >>>Wim >>>_________________ >>>sent from blackberry >>> >>>----- Original Message ----- >>>From: Giles Heron [mailto:giles.heron@gmail.com] >>>Sent: Thursday, April 12, 2012 08:22 AM >>>To: Simon Delord >= ; Alexander Vainshtein >>>> >>>Cc: l2vpn@ietf.org >; Vladimir Kleiner >>>>; Andrew Sergeev >>>>; Idan Kaspit >; >>>Mishael Wexler >; Rotem Cohen >>>> >>>Subject: Re: The status of the approaches to the E-Tree solution? >>> >>>Sorry - the "anonymous presentation" was mine. I should possibly have >>>put in a third column on the CW approach. And hopefully the minutes >>>will be posted soon. >>> >>>We had various discussions, as Simon stated, and consensus seemed to be >>>forming around the two alternatives of two PWEs or two VLANs. I believe >>>three of the authors of the CW approach are also authors of the two VLAN >>>approach and one is also an author of the two PWE approach. So perhaps >>>it's best to let those four individuals say which approach they prefer >>>and why? >>> >>>Giles >>> >>>On 10/04/2012 00:45, "Simon Delord" > wrote: >>> >>>> Hi Alexander, >>>> >>>> You are right, no discussion on the WG mailing list recently, but >>>> there have been substantial discussions among the authors of various >>>> solution drafts off the mailing list. As far as I know, no consensus >>>> yet before ietf83, not sure the progress in the Paris WG meeting. I >>>> think the CW approach has not been rejected by the WG yet, or the WG >>>> has not yet decided on which one to adopt. >>>> >>>> Simon >>>> >>>> 2012/4/8 Alexander Vainshtein > >>>> >>>>> Hi all, >>>>> >>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>> >>>>> However, looking up the L2VPN proceedings, I've found a short >>>>> anonymous presentation called "E-Tree Update" ( >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>> This presentation discusses the differences of the E-Tree approaches >>>>> based on dedicated VLANs (as in >>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?include_t >>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/?in >>>>> clude_te >>>>> xt=3D1) >>>>> and completely ignores the solution based on usage of the CW in the >>>>> PWs connecting the PEs (as in >>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?include_t >>>>> ext=3D1 >>>>> ). >>>>> >>>>> >>>>> >>>>> The Minutes of the Paris L2VPN session are not yet available, but I >>>>> wonder whether the WG has taken a decision to reject the approach >>>>> based on the CW usage? I do not remember any recent discussion of >>>>> this topic on the WG mailing list. >>>>> >>>>> >>>>> >>>>> Regards, and lots of thanks in advance, >>>>> >>>>> Sasha >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail message is intended for the recipient only and contains >>>>> information which is CONFIDENTIAL and which may be proprietary to ECI >>> >>>>> Telecom. If you have received this transmission in error, please >>>>> inform us by e-mail, phone or fax, and then delete the original and >>>>> all copies thereof. >>>>> >>> >>> >>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action taken >>>in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use of the individual or entity to which it is addressed. If you >>are not the intended recipient of this E-mail, you are hereby notified >>that any dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely fo= r the use of the individual or entity to which it is addressed. If you are no= t the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may b= e unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. > > > > ------------------------------ > > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn > > > End of L2vpn Digest, Vol 95, Issue 25 > *********************************** ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 93 ************************************* From lucy.yong@huawei.com Thu Apr 26 08:41:57 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CD821E80A3 for ; Thu, 26 Apr 2012 08:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HS_INDEX_PARAM=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 RzKKRug8snFA for ; Thu, 26 Apr 2012 08:41:54 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E60AC21E80C4 for ; Thu, 26 Apr 2012 08:41:53 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFH19147; Thu, 26 Apr 2012 11:41:53 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 26 Apr 2012 08:39:42 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Thu, 26 Apr 2012 08:39:41 -0700 From: Lucy yong To: Jiangyuanlong , "Fedyk, Donald (Don" , "Rogers, Josh" Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNI1NEe/4Txq0Y50G6N17p5Mncd5atPrZA Date: Thu, 26 Apr 2012 15:39:40 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264C3CB@dfweml505-mbx> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3F298@SZXEML508-MBS.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3F298@SZXEML508-MBS.china.huawei.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.80] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 26 Apr 2012 15:41:57 -0000 Yuanlong, I am glad that the draft already covers this. Cheers, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of J= iangyuanlong Sent: Wednesday, April 25, 2012 9:21 PM To: Fedyk, Donald (Don; Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Don and Josh, draft-jiang-l2vpn-vpls-pe-etree-05 discussed S-VLAN access in the following= way: "... For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames received f= rom the root ACs can be translated to the root S-VLAN in the VPLS network d= omain. Alternatively, the PBB VPLS PE model (where an IEEE 802.1ah bridge m= odule is embedded in the PE) as described in [PBB-VPLS] can be used, and a = root B-VLAN or leaf B-VLAN can be added in this case. In a similar way, the traffic from the leaf ACs is tagged and transported o= n the leaf C-VLAN, S-VLAN or B-VLAN.=20 " It seems option B is in line with the 1st sentence, not sure where option A= came from, but do you have any concerns with the description in the 2nd se= ntence? Regards, Yuanlong ---------------------------------------------------------------------- Date: Wed, 25 Apr 2012 18:52:50 -0500 From: "Fedyk, Donald (Don)" To: "Rogers, Josh" , David Allan I , Daniel Cohn , "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: =09 Content-Type: text/plain; charset=3D"us-ascii" Hi Josh Is there a draft that describes solution A? Solution B is what I've seen in the IEEE. One argument is that A is adding an extra TAG that offers little value. The= TAG you have labeled 2 may need to be swapped anyway. Stacking S-TAGs is = why PBB was developed. Cheers, Don -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Wednesday, April 25, 2012 7:22 PM To: David Allan I; Fedyk, Donald (Don); Daniel Cohn; l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? > Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. I have to apologize, because I think I led y'all down that path (I referred to the outermost tag, the same tag that the MPLS psuedowire is using for vlan mode encamp, as the S-Tag, even though the customer is the one placing it on the frame. Same as I described below, but I either used term S-Tag incorrectly, or ambiguously. >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... So, I think this could be cleared up some still. What I was referring to is the VID that the customer is using to put frames in, the VID which they should use to ensure the frame goes into the correct ETREE instance. You drew a distinction between 'customer VID' vs 'provider VID', but since it is negotiated, I haven't really seen a distinction, which I think is what has caused all the confusion. In the two discussion points/solutions I mentioned, the first one, "A", describes both a coordinated VID which the customer should use, and the service provider uses to distinguish between services on the same UNI, as well as a second, outer, VID which is used by the SP to determine the source AC type. In my example, if you were to sniff inside the psuedowire between PE1 and PE2 to see CE2 destined traffic, wish solution A, you might see "4001:2:Payload", where 4001 designates it is from a root AC, 2 designates the ETREE instance, and Payload is the customer's traffic (which may include a C-Tag), where with solution B, you would see "4001:Payload", and VID 2 would have to be swapped for 4001 as it enters the PE2-CE2 AC, giving the customer "2:Payload" just as they sent it (alternatively SP may choose to simply drop tag entirely and provide "Payload" to customer, this can cause problems with PVST on some devices, but I still see it done occasionally) ** Note, for the example above, I'm assuming 4001 is used as a 'standard' for root sourced frames, and 4002 is used for leaf sourced frames, for the ETREE R/L tags. Have I undone the confusion, or made it worse? -Josh On 4/25/12 5:19 PM, "David Allan I" wrote: >Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. > >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" > >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... > >Cheers >Dave > > > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Wednesday, April 25, 2012 5:42 PM >To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >Dave/Daniel/Lucy/Others Debating how many tags necessary when S-Tag >preservation is desired, > > >I think you all may have gone off on a tangent here. The original >discussion was about how to deal with the situation where the S-Tag is >preserved at a handoff (either an ENNI, or Service Multiplexed UNI) > >I believe there were two suggestions, one was that you push on a 'ETREE' >tag (one of two values, for either a frame sourced from a root AC or >another for a frame from a leaf AC), and the second solution was to 'map'. > > >Imagine the following topology: > >+-----+ +-----+ +-----+ +-----+ >| CE1 |--| PE1 |--| PE2 |--| CE2 | >+-----+ +-----+ +-----+ +-----+ > | | >+-----+ +-----+ +-----+ +-----+ >| CE3 |--| PE3 |--| PE4 |--| CE4 | >+-----+ +-----+ +-----+ +-----+ > >Where: > >Site Type VLAN >CE1 Root X >CE2 Leaf 2 >CE3 Leaf 3 >CE4 Leaf 3 > > >So, there are a lot of SP's who are keen on the way many services can be >handed to a customer on a single UNI, but coordinating a single VLAN per >service, with the customer (MEF used to call this EVPL when it was many >point to point services terminating on a single UNI). So, imagine that >we have two ETREE instances, and an internet service all terminating on a >single UNI connecting to CE1. We have negotiated VLAN ID's with the >customer, and they are expecting to reach CE2 using VLAN 2, CE3 and CE4 >using VLAN 3, and Internet service on VLAN 10. As a frame from CE1 comes >into PE1 destined for CE2 (so the customer has tagged it with VID 2), >using the 2VLAN method, since this is coming from a root site, do we > >a) place the Root S-Tag in front of VID 2, then ship it across, and pop >off the ETREE S-Tag (some SP's wish to Pop the original customer tag VID >2 as well) > >-or- > >b) swap VID2 for the ETREE Root S-Tag, send the frame to PE2 where it >will remove the S-Tag (and either push VID2 back on, or leave it off >depending on SP preference) > >The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf) > > >Hope that clears more than it confuses, >Josh > > > >On 4/25/12 4:22 PM, "Fedyk, Donald (Don)" > wrote: > >>Hi Dave >> >>Yes the only point I would add is Dual VLAN means One VID for Root and >>one VID for Leaf. Not two TAGs at a time on the frame but two allocated >>for the service. >> >>The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks >>about Encapsulation Overhead as a VLAN Tag. While that is true in a PWE >>sense it is still a single VLAN Tag at a time in a Ethernet E-tree sense. >> The compelling driver for Dual VLAN is having a Etree service that >>works in many environments and the DUAL VLAN (really dual VLAN >>interface on a >>VSI) uses the same mechanism (one VID for root and one VID for Leaf at >>a >>time) as specified in the IEEE. In a pure Ethernet bridging world the >>VLAN TAGs for Etree are not typically an overhead since translation is >>used. >> >>Don >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of David Allan I >>Sent: Wednesday, April 25, 2012 5:05 PM >>To: Daniel Cohn; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>OK I feel like I am digressing a fair distance from the actual >>problem.... But here goes: >> >>So the scenarios center around "how ETREE do you want to be?".... >> >>If the ACs are root/leaf, then if they are P2P (single ethernet end >>station attached to each AC) this is moot. ETREE semantics are enforced >>by the 2VID domain in the center of the example. If you assumed nodes >>A&B in the example were L2VPN PEs, the tagging and the PW tag >>imposition all happened at the same point in the network. >> >>If they are not simple P2P all the way to end systems and the objective >>is to avoid bridging between leaf "sites" but allowing intra-leaf-site >>connectivity then the leaves can be LANs but the root is not, such that >>I cannot bridge through the root. But all hosts at a given leaf site >>can see each other. So root Ethernet end systems are directly attached >>or two VIDs are used in the root site. >> >>If the objective is that there are multiple ethernet attached end >>stations at both the leaf and root sites, and the objective is to >>enforce >>L2 isolation everywhere then I need two VIDs extended to the end system >>attachement point in the local LANs by whatever means.... >> >>And I do not see adding VLANs in any particular spot, simply selection >>of the VID and associated semantics where VIDs are translated. The >>actual point of S-tag imposition could be a PE, or cloud be a NID/CLE >>on the customer prem (more likely scenario here to extend OAM demarc to >>the prem), or some switch in a RAN downstream of the MPLS PE... blah >>blah blah. And if ETREE is extended into a customer site LAN and >>outside of the provider domain, then two C-tags would have to be used >>that mapped to S-tags at the PBN boundary... >> >>Make sense? >>Dave >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 25, 2012 4:39 PM >>To: David Allan I; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Dave, but the ACs are root/leaf (that's what the whole vpls etree is >>about - see the reqt draft), so per the 2vlan draft the root/leaf vlan >>must be added. >> >>Thumb typed - please be tolerant >> >>David Allan I wrote: >> >>HI Daniel: >> >>In the example provided, >> >>"ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" >> A B >> >>the service is not ETREE in the domains of the ingress and egress VID. >>It is ELAN. SO there is no root/leaf attribute to shovel around. It >>would require two VIDs in each domain if the ETREE semantics were to be >>telescoped E2E. >> >>Otherwise it is a provisioning of the VID translation tables at the >>intermediate nodes (A&B that I've added to the picture) that would >>determine the VID values used in each domain. Or in the example above, >>what the ingress, Etree and egress VID values were. >> >>Cheers >>Dave >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 3:46 PM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>And to this I asked how this mapping works - how does the egress pe >>recover the ingress vid when it gets the frame tagged with only the >>root/leaf vid? How can you convey the ingress vid plus the root/leaf >>attribute in the same number of bits? >>What am I missing? >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>David Allen already explained the solution. >> >>From David: >>ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. >> >>Ingress VID does not have to equal Egress VID but regardless there is >>only ever one VID on a frame at a time. >> >>-end >> >>This works when customer makes ingress VLAN ID not equal to or equal to >>egress VLAN ID. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 11:39 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Lucy, >> >>The scenario we are discussing is not the E-Tree E-NNI, but a general >>scenario where frames arriving at the root or leaf AC are already >>double tagged. In this case, the dual vlan solution cannot preserve the >>vlans without adding a third one, can it? >> >>Maybe Shahram can add details on the scenario he had in mind >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has S-VLAN preservation attribute for ENNI only because there is no >>s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN >>preservation attribute is used. It applies to E-Tree as well. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Tuesday, April 24, 2012 2:12 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Lucy, >> >>even if the current MEF framework doesn't require s-vlan preservation, >>I believe it's to the industry's benefit to adopt a solution that is >>not constrained to a specific enni model that, like all things >>networking, is likely to evolve. Especially when such a solution is >>available. >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has worked in ENNI interface for a long time with many service >>providers' inputs. It had a fair reason to assume S-VLAN over ENNI by >>then. It may open B-VLAN for the future. It is better for us not to >>discuss a future framework here, because it will lead us to nowhere. >>Here, we want to extend VPLS in supporting E-Tree. >> >>Best Regards, >>Lucy >> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Sunday, April 22, 2012 7:34 AM >>To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Shahram and all, >> >>This question already came up in our discussions - is it safe to assume >>that the VLAN tags at the E-NNI will always be according to the current >>MEF model? Or should we try to be as transparent as possible to user >>VLAN encapsulation at the E-NNI, to accommodate future frameworks? >>I believe that any approach that looks at user payload (in this case >>VLAN >>tag) to signal VPLS information (in this case root/leaf origin) is >>necessarily tied to specific assumptions on user payload encapsulation >>(in this case, that S-VLAN tag is "available" to encode root/leaf). I >>don't think this is a future-proof assumption, it's very likely that >>other network models will come up that require S-VLAN preservation, >>which in the 2-VLAN approach would necessitate adding a third VLAN-ID. >> >>Daniel >> >>From: Shahram Davari > >>To: Lizhong Jin >, >>"l2vpn@ietf.org" >>>, >>"Alexander.Vainshtein@ecitele.com>om> >>" >>>om> >>> >>Cc: "yuqun.cao@gmail.com" >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, >> >>I also have a question regarding 2-VLAN. What if the customer traffic >>already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? >> >>Thx >>Shahram >> >>From: l2vpn-bounces@ietf.org >>[mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin >>Sent: Friday, April 20, 2012 9:38 AM >>To: l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com>m> >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, all, >>The difference between 2-VLAN and CW approach is who will provide the >>R/L information, customer payload or PW? The customer payload will be >>always modified to carry R/L information in 2-VLAN approach, while PW >>with CW will carry R/L information for CW approach. >>I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is >>accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is >>used to access H-VPLS, how could the PE on VPWS side adds VLAN to >>indicate R/L information? >> >>Thanks >>Lizhong >> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Thu, 19 Apr 2012 04:38:36 +0000 >>> From: Alexander Vainshtein >>> >> com>> >>> To: "Rogers, Josh" >>>>, Lucy yong >>> >, Daniel >>>Cohn >, Sam Cao >>> > >>> Cc: "l2vpn@ietf.org" >>> > >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> Message-ID: >>> >>> >> t o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> >>> Content-Type: text/plain; charset=3D"us-ascii" >>> >>> Hi all, >>> I fully understand that that what I am going to say is not very >>>popular, but: >>> >>> IMO one of the advantages of the CW-based solution is that it is >>>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery >>>of BUN traffic. >>> >>> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>>and, in a more generic way, localization of effects of changes in the >>>PE configuration. >>> >>> In particular, adding a Leaf AC to a PE that previously has been only >>>supporting Root ACs (or vice versa), removal of the last Leaf or last >>>Root AC from a PE that previously has been supporting a mix etc. >>>affect only the PE where this operation happens and not the rest of the >>>PEs. >>> >>> As for the need for HW changes that have been mentioned as a main >>>disadvantage of the CW-based approach - I believe it strongly depends >>>on specific implementations. And some changes in the forwarding >>>process are required in any solution. >>> >>> My 2c, >>> Sasha >>> >>> >>> >>> ________________________________________ >>> From: l2vpn-bounces@ietf.org >>> [l2vpn-bounces@ietf.org] on behalf of >>> Rogers, Josh >>> [josh.rogers@twcable.com] >>> Sent: Wednesday, April 18, 2012 9:57 PM >>> To: Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: Re: The status of the approaches to the E-Tree solution? >>> >>> Again, the P2MP situation throws me. Is this something that is used >>> commonly? >>> >>> I'm under the impression that adding P2MP to any model results in a >>> more complex model. Wether outside s-tag is used to differentiate, >>> or dedicated pw's are used for the same purpose, it seems both become >>> more complex. >>> >>> Gile's comparison slide still concisely captures the differences >>>between these methods, in my opinion. I haven't seen any new ideas or >>>thoughts brought to the group in the past week or two on the subject. >>> I would hate for both proposed methods to die on the vine because we >>>couldn't decide between two methods that have nothing inherently wrong >>>with either. >>> >>> -Josh >>> >>> >>> On 4/18/12 1:53 PM, "Lucy yong" >>>> wrote: >>> >>>>Send this again. >>>> >>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>>double all of them. >>>> >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn >>>>[mailto:DanielC@orckit.com] >>>>Sent: Wednesday, April 18, 2012 1:42 PM >>>>To: Lucy yong; Rogers, Josh; Sam Cao >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>I think the first option its the natural way to go. How is the >>>>processing in this case more complex? >>>> >>>>Thumb typed - please be tolerant >>>> >>>>Lucy yong > wrote: >>>> >>>> >>>> >>>>Snipped.. >>>> >>>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only >>>>P2MP PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP >>>>PW (for traffic coming from a root AC) [[LY]] Not that simple. You >>>>construct either two P2MP PWs to all other PEs and let egress PE >>>>performing filtering, or construct one P2MP PW to leaf-only PEs and >>>>two P2MP PWs to root and leaf PEs and let ingress PE perform >>>>forwarding and filtering. Both make node process complex. >>>> >>>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>>>delivering the frames to remote PEs. We should utilize them with the >>>>minimized changes. Dual VLAN solution is simpler than Dual PW. >>>> >>>>Regards, >>>>Lucy >>>> >>>> >>>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>>>haven't had any first hand experience with P2MP PW's, however, so >>>>don't feel terribly strong about this objection. Is this a real >>>>problem for others (now or in the future), or is this objection in >>>>the weeds? >>>> >>>>I'm not sure the 'additional complexity' is notable, or even relevant. >>>>I encourage others to speak up if they disagree, as P2MP PW is only >>>>conceptual to me, and I am unfamiliar with real-life use cases for it. >>>> >>>>Thanks, >>>>Josh >>>> >>>> >>>> >>>>On 4/18/12 10:30 AM, "Lucy yong" >>>>> wrote: >>>> >>>>>Please see inline. >>>>> >>>>>-----Original Message----- >>>>>From: Sam Cao >>>>>[mailto:yuqun.cao@gmail.com] >>>>>Sent: Tuesday, April 17, 2012 7:14 AM >>>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>>>(Wim)'; giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>>>> >>>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>>>PE have both root and leaf AC and some only have leaf ACs)? >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Yuqun (Sam) Cao >>>>>E-mail: Yuqun.cao@gmail.com >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn >>>>>[mailto:DanielC@orckit.com] >>>>>Sent: Tuesday, April 17, 2012 4:56 PM >>>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com>; Sam Cao >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Adding Sam (as l2vpn@ is holding messages) >>>>> >>>>>DC >>>>> >>>>>-----Original Message----- >>>>>From: Lucy yong >>>>>[mailto:lucy.yong@huawei.com] >>>>>Sent: Tuesday, April 17, 2012 12:39 AM >>>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>> >>>>>Snipped, >>>>> >>>>>As we discussed extensively in the list, and as reflected in giles >>>>>slide, 2 pws are only needed between pes with both root and leaf >>>>>acs, which will typically be a small minority. >>>>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>>>both approaches can benefit from it. I was off for a while and >>>>>captures some discussions now. >>>>> >>>>>Also as per giles slide, dual vlan can have scalability issues due >>>>>to additional lookup and double use of vlans in internal emulated >>>>>lan interface. Also there are potential backward compatibility >>>>>issues with silicon that doesn't support vlan mapping. >>>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. >>>>>I am not clear on all the issues. Could you be more specific? As I >>>>>mentioned in below, two PW approach makes VPLS transport >>>>>construction and packet forwarding more complex, I can see potential >>>>>backward compatibility issues with 2 PW solution. >>>>> >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Daniel >>>>> >>>>>Thumb typed - please be tolerant >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>>In my mind, the VLAN approach means dual vlan method. >>>>> >>>>>The main concern for CW approach is hardware support. >>>>> >>>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and >>>>>unknown unicast traffic, and some P2MP PWs for multicast traffic. It >>>>>may double all of them. >>>>> >>>>>E-tree is an Ethernet service and there is already VLAN based >>>>>solution in IEEE, can we just utilize it without complicating VPLS >>>>>transport construction? This also makes interworking with Eth only >>>>>network easier. >>>>> >>>>>Cheers, >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: Rogers, Josh >>>>>[mailto:josh.rogers@twcable.com] >>>>>Sent: Monday, April 16, 2012 8:35 AM >>>>>To: Lucy yong; Henderickx, Wim (Wim); >>>>>'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com'; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>I believe the initial question was in regard to the CW method. Are >>>>>you saying that you no longer are interested in that method in >>>>>preference of the dual vlan method? >>>>> >>>>> >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>> >>>>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>>>> >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: l2vpn-bounces@ietf.org >>>>>[mailto:l2vpn-bounces@ietf.org] On >>>>>Behalf Of Henderickx, Wim (Wim) >>>>>Sent: Thursday, April 12, 2012 2:03 AM >>>>>To: 'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com'; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>The vlan approach is superior as it also works for eth only >>>>>networks, etc. On top some vendors indicate hw issues with the cw >>>>>approach. As such we have dropped more or less the cw approach. >>>>> >>>>>Cheers, >>>>>Wim >>>>>_________________ >>>>>sent from blackberry >>>>> >>>>>----- Original Message ----- >>>>>From: Giles Heron >>>>>[mailto:giles.heron@gmail.com] >>>>>Sent: Thursday, April 12, 2012 08:22 AM >>>>>To: Simon Delord >>>>>>; Alexander >>>>>Vainshtein >>>>>>>>>e >>>>>.com>> >>>>>Cc: l2vpn@ietf.org >>>>>>; Vladimir Kleiner >>>>>>; >>>>>Andrew Sergeev >>>>>>; >>>>>Idan Kaspit >>>>>>; >>>>>Mishael Wexler >>>>>>; >>>>>Rotem Cohen >>>>>> >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>Sorry - the "anonymous presentation" was mine. I should possibly >>>>>have put in a third column on the CW approach. And hopefully the >>>>>minutes will be posted soon. >>>>> >>>>>We had various discussions, as Simon stated, and consensus seemed to >>>>>be forming around the two alternatives of two PWEs or two VLANs. I >>>>>believe three of the authors of the CW approach are also authors of >>>>>the two VLAN approach and one is also an author of the two PWE >>>>>approach. So perhaps it's best to let those four individuals say >>>>>which approach they prefer and why? >>>>> >>>>>Giles >>>>> >>>>>On 10/04/2012 00:45, "Simon Delord" >>>>>> wrote: >>>>> >>>>>> Hi Alexander, >>>>>> >>>>>> You are right, no discussion on the WG mailing list recently, but >>>>>> there have been substantial discussions among the authors of >>>>>> various solution drafts off the mailing list. As far as I know, no >>>>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>>>> meeting. I think the CW approach has not been rejected by the WG >>>>>> yet, or the WG has not yet decided on which one to adopt. >>>>>> >>>>>> Simon >>>>>> >>>>>> 2012/4/8 Alexander Vainshtein >>>>>> >>>>> e >>>>>> le.com>> >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>>>> >>>>>>> However, looking up the L2VPN proceedings, I've found a short >>>>>>> anonymous presentation called "E-Tree Update" ( >>>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>>>> This presentation discusses the differences of the E-Tree >>>>>>> approaches based on dedicated VLANs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw >>>>>>> / >>>>>>> ?in >>>>>>> clude_te >>>>>>> xt=3D1) >>>>>>> and completely ignores the solution based on usage of the CW in >>>>>>> the PWs connecting the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1 >>>>>>> ). >>>>>>> >>>>>>> >>>>>>> >>>>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>>>> I wonder whether the WG has taken a decision to reject the >>>>>>> approach based on the CW usage? I do not remember any recent >>>>>>> discussion of this topic on the WG mailing list. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, and lots of thanks in advance, >>>>>>> >>>>>>> Sasha >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This e-mail message is intended for the recipient only and >>>>>>> contains information which is CONFIDENTIAL and which may be >>>>>>> proprietary to ECI >>>>> >>>>>>> Telecom. If you have received this transmission in error, please >>>>>>> inform us by e-mail, phone or fax, and then delete the original >>>>>>> and all copies thereof. >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>>proprietary information, which is privileged, confidential, or >>>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>>intended solely for the use of the individual or entity to which it >>>>>is addressed. >>>>>If you are not the intended recipient of this E-mail, you are hereby >>>>>notified that any dissemination, distribution, copying, or action >>>>>taken in relation to the contents of and attachments to this E-mail >>>>>is strictly prohibited and may be unlawful. If you have received >>>>>this E-mail in error, please notify the sender immediately and >>>>>permanently delete the original and any copy of this E-mail and any >>>>>printout. >>>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or >>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>intended solely for the use of the individual or entity to which it >>>>is addressed. If you are not the intended recipient of this E-mail, >>>>you are hereby notified that any dissemination, distribution, >>>>copying, or action taken in relation to the contents of and >>>>attachments to this E-mail is strictly prohibited and may be >>>>unlawful. If you have received this E-mail in error, please notify >>>>the sender immediately and permanently delete the original and any >>>>copy of this E-mail and any printout. >>> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> This e-mail message is intended for the recipient only and contains >>>information which is CONFIDENTIAL and which may be proprietary to ECI >>>Telecom. If you have received this transmission in error, please >>>inform us by e-mail, phone or fax, and then delete the original and >>>all copies thereof. >>> >>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> L2vpn mailing list >>> L2vpn@ietf.org >>> https://www.ietf.org/mailman/listinfo/l2vpn >>> >>> >>> End of L2vpn Digest, Vol 95, Issue 25 >>> *********************************** > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 101 ************************************** From josh.rogers@twcable.com Thu Apr 26 08:49:04 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241FD21E8101 for ; Thu, 26 Apr 2012 08:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.626 X-Spam-Level: X-Spam-Status: No, score=0.626 tagged_above=-999 required=5 tests=[AWL=-0.665, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HS_INDEX_PARAM=0.001, MIME_BASE64_TEXT=1.753] 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 okWm8wo3sako for ; Thu, 26 Apr 2012 08:49:01 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id C4BFD21E80FC for ; Thu, 26 Apr 2012 08:48:59 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,487,1330923600"; d="scan'208";a="356448593" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 26 Apr 2012 11:46:58 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Thu, 26 Apr 2012 11:48:26 -0400 From: "Rogers, Josh" To: Lucy yong , "Fedyk, Donald (Don)" , David Allan I , Daniel Cohn , "l2vpn@ietf.org" Date: Thu, 26 Apr 2012 11:48:20 -0400 Subject: Re: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0jxAQBX9cM1QJDS322Y76Rw23Lvg== Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D3264C3A8@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: l2vpn@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, 26 Apr 2012 15:49:04 -0000 QWdyZWVkLg0KDQoNCg0KT24gNC8yNi8xMiAxMDozMCBBTSwgIkx1Y3kgeW9uZyIgPGx1Y3kueW9u Z0BodWF3ZWkuY29tPiB3cm90ZToNCg0KPkpvc2gsDQo+DQo+RHVhbCBWTEFOIGRyYWZ0IGRlc2Ny aWJlcyBvcHRpb24gQiBvbmx5LCB3aGljaCBhbGlnbnMgd2l0aCBJRUVFIHNwZWMuLg0KPk5vdCBz dXJlIHdoaWNoIGRvYy4gdGFsa3MgYWJvdXQgb3B0aW9uIEEgYW5kIHN1Z2dlc3Qgbm90IGRpc2N1 c3NpbmcNCj5vcHRpb24gQSBvbiBlbWFpbCBhbnltb3JlLg0KPg0KPlJlZ2FyZHMsDQo+THVjeQ0K Pg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogUm9nZXJzLCBKb3NoIFttYWls dG86am9zaC5yb2dlcnNAdHdjYWJsZS5jb21dDQo+U2VudDogV2VkbmVzZGF5LCBBcHJpbCAyNSwg MjAxMiA2OjIzIFBNDQo+VG86IEx1Y3kgeW9uZzsgRmVkeWssIERvbmFsZCAoRG9uKTsgRGF2aWQg QWxsYW4gSTsgRGFuaWVsIENvaG47DQo+bDJ2cG5AaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogVGhl IHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPg0KPltb TFldXSAgVGhpcyBpcyBub3QgbXkgdW5kZXJzdGFuZGluZy4gSGVyZSB3ZSB0YWxrIGFib3V0IGlu Y29taW5nIGZyYW1lDQo+YWxyZWFkeSBoYXMgYy10YWcgYW5kIHMtdGFnLCB3aGljaCBpcyBub3Qg VU5JIGNhc2UuIEluIGFkZGl0aW9uLCBpdCBzZWVtcw0KPnRoYXQgRGFuaWVsIHNheSB0aGF0IG9u bHkgb3B0aW9uIEEgd29ya3MuDQo+DQo+VGhhdKn2cyBmdW5ueSwgSSB0aG91Z2h0IHNvbWVvbmUg c2FpZCB0aGF0IG9ubHkgb3B0aW9uIEIgd291bGQgd29yay4gIEkNCj50aGluayB0ZWNobmljYWxs eSBlaXRoZXIgaXMgcG9zc2libGUsIGJ1dCBJIGFtIHVuY2xlYXIgd2hpY2ggdGhlIDJWTEFODQo+ ZHJhZnQgd291bGQgYWR2aXNlIChvciBpZiBpdCBldmVuIGRvZXMpDQo+DQo+DQo+LUpvc2gNCj4N Cj4NCj4NCj5PbiA0LzI1LzEyIDU6MjIgUE0sICJMdWN5IHlvbmciIDxsdWN5LnlvbmdAaHVhd2Vp LmNvbT4gd3JvdGU6DQo+DQo+PkhpIEpvc2gsDQo+Pg0KPj5QbGVhc2Ugc2VlIGlubGluZS4NCj4+ DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IGwydnBuLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4+Um9n ZXJzLCBKb3NoDQo+PlNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjUsIDIwMTIgNDo0MiBQTQ0KPj5U bzogRmVkeWssIERvbmFsZCAoRG9uKTsgRGF2aWQgQWxsYW4gSTsgRGFuaWVsIENvaG47IGwydnBu QGlldGYub3JnDQo+PlN1YmplY3Q6IFJlOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRv IHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pg0KPj5EYXZlL0RhbmllbC9MdWN5L090aGVycyBEZWJh dGluZyBob3cgbWFueSB0YWdzIG5lY2Vzc2FyeSB3aGVuIFMtVGFnDQo+PnByZXNlcnZhdGlvbiBp cyBkZXNpcmVkLA0KPj4NCj4+DQo+PkkgdGhpbmsgeW91IGFsbCBtYXkgaGF2ZSBnb25lIG9mZiBv biBhIHRhbmdlbnQgaGVyZS4gIFRoZSBvcmlnaW5hbA0KPj5kaXNjdXNzaW9uIHdhcyBhYm91dCBo b3cgdG8gZGVhbCB3aXRoIHRoZSBzaXR1YXRpb24gd2hlcmUgdGhlIFMtVGFnIGlzDQo+PnByZXNl cnZlZCBhdCBhIGhhbmRvZmYgKGVpdGhlciBhbiBFTk5JLCBvciBTZXJ2aWNlIE11bHRpcGxleGVk IFVOSSkNCj4+W1tMWV1dIGluIE1FRiwgUy1UYWcgYXBwbGllcyB0byBFTk5JIG9ubHksIG5vdCBV TkkuIEFuIFVOSSBjYW4gc3VwcG9ydA0KPj5tdWx0aXBsZXhlZCBzZXJ2aWNlcywgaS5lLiB0ZXJt aW5hdGUgbWFueSBFVkNzLiBJbiB0aGlzIGNhc2UsIGVhY2ggRVZDDQo+PmFzc29jaWF0ZXMgd2l0 aCBvbmUgb3IgbXVsdGlwbGUgYy10YWdzLiBFVkMgaGFzIGEgc2VydmljZSBhdHRyaWJ1dGUgZm9y DQo+Pmxpc3RpbmcgYXNzb2NpYXRlZCBjLXRhZ3MuDQo+Pg0KPj5JIGJlbGlldmUgdGhlcmUgd2Vy ZSB0d28gc3VnZ2VzdGlvbnMsIG9uZSB3YXMgdGhhdCB5b3UgcHVzaCBvbiBhICdFVFJFRScNCj4+ dGFnIChvbmUgb2YgdHdvIHZhbHVlcywgZm9yIGVpdGhlciBhIGZyYW1lIHNvdXJjZWQgZnJvbSBh IHJvb3QgQUMgb3INCj4+YW5vdGhlciBmb3IgYSBmcmFtZSBmcm9tIGEgbGVhZiBBQyksIGFuZCB0 aGUgc2Vjb25kIHNvbHV0aW9uIHdhcyB0bw0KPj4nbWFwJy4NCj4+W1tMWV1dICBUaGlzIGlzIG5v dCBteSB1bmRlcnN0YW5kaW5nLiBIZXJlIHdlIHRhbGsgYWJvdXQgaW5jb21pbmcgZnJhbWUNCj4+ YWxyZWFkeSBoYXMgYy10YWcgYW5kIHMtdGFnLCB3aGljaCBpcyBub3QgVU5JIGNhc2UuIEluIGFk ZGl0aW9uLCBpdCBzZWVtcw0KPj50aGF0IERhbmllbCBzYXkgdGhhdCBvbmx5IG9wdGlvbiBBIHdv cmtzLg0KPj4NCj4+DQo+PkltYWdpbmUgdGhlIGZvbGxvd2luZyB0b3BvbG9neToNCj4+DQo+Pist LS0tLSsgICstLS0tLSsgICstLS0tLSsgICstLS0tLSsNCj4+fCBDRTEgfC0tfCBQRTEgfC0tfCBQ RTIgfC0tfCBDRTIgfA0KPj4rLS0tLS0rICArLS0tLS0rICArLS0tLS0rICArLS0tLS0rDQo+PiAg ICAgICAgICAgIHwgICAgICAgIHwNCj4+Ky0tLS0tKyAgKy0tLS0tKyAgKy0tLS0tKyAgKy0tLS0t Kw0KPj58IENFMyB8LS18IFBFMyB8LS18IFBFNCB8LS18IENFNCB8DQo+PistLS0tLSsgICstLS0t LSsgICstLS0tLSsgICstLS0tLSsNCj4+DQo+PldoZXJlOg0KPj4NCj4+U2l0ZSAgVHlwZSAgVkxB Tg0KPj5DRTEgICBSb290ICBYDQo+PkNFMiAgIExlYWYgIDINCj4+Q0UzICAgTGVhZiAgMw0KPj5D RTQgICBMZWFmICAzDQo+Pg0KPj4NCj4+U28sIHRoZXJlIGFyZSBhIGxvdCBvZiBTUCdzIHdobyBh cmUga2VlbiBvbiB0aGUgd2F5IG1hbnkgc2VydmljZXMgY2FuIGJlDQo+PmhhbmRlZCB0byBhIGN1 c3RvbWVyIG9uIGEgc2luZ2xlIFVOSSwgYnV0IGNvb3JkaW5hdGluZyBhIHNpbmdsZSBWTEFOIHBl cg0KPj5zZXJ2aWNlLCB3aXRoIHRoZSBjdXN0b21lciAoTUVGIHVzZWQgdG8gY2FsbCB0aGlzIEVW UEwgd2hlbiBpdCB3YXMgbWFueQ0KPj5wb2ludCB0byBwb2ludCBzZXJ2aWNlcyB0ZXJtaW5hdGlu ZyBvbiBhIHNpbmdsZSBVTkkpLiAgU28sIGltYWdpbmUgdGhhdA0KPj53ZQ0KPj5oYXZlIHR3byBF VFJFRSBpbnN0YW5jZXMsIGFuZCBhbiBpbnRlcm5ldCBzZXJ2aWNlIGFsbCB0ZXJtaW5hdGluZyBv biBhDQo+PnNpbmdsZSBVTkkgY29ubmVjdGluZyB0byBDRTEuICBXZSBoYXZlIG5lZ290aWF0ZWQg VkxBTiBJRCdzIHdpdGggdGhlDQo+PmN1c3RvbWVyLCBhbmQgdGhleSBhcmUgZXhwZWN0aW5nIHRv IHJlYWNoIENFMiB1c2luZyBWTEFOIDIsIENFMyBhbmQgQ0U0DQo+PnVzaW5nIFZMQU4gMywgYW5k IEludGVybmV0IHNlcnZpY2Ugb24gVkxBTiAxMC4gIEFzIGEgZnJhbWUgZnJvbSBDRTEgY29tZXMN Cj4+aW50byBQRTEgZGVzdGluZWQgZm9yIENFMiAoc28gdGhlIGN1c3RvbWVyIGhhcyB0YWdnZWQg aXQgd2l0aCBWSUQgMiksDQo+PnVzaW5nIHRoZSAyVkxBTiBtZXRob2QsIHNpbmNlIHRoaXMgaXMg Y29taW5nIGZyb20gYSByb290IHNpdGUsIGRvIHdlDQo+Pg0KPj5hKSBwbGFjZSB0aGUgUm9vdCBT LVRhZyBpbiBmcm9udCBvZiBWSUQgMiwgdGhlbiBzaGlwIGl0IGFjcm9zcywgYW5kIHBvcA0KPj5v ZmYgdGhlIEVUUkVFIFMtVGFnIChzb21lIFNQJ3Mgd2lzaCB0byBQb3AgdGhlIG9yaWdpbmFsIGN1 c3RvbWVyIHRhZyBWSUQNCj4+Mg0KPj5hcyB3ZWxsKQ0KPj4NCj4+LW9yLQ0KPj4NCj4+Yikgc3dh cCBWSUQyIGZvciB0aGUgRVRSRUUgUm9vdCBTLVRhZywgc2VuZCB0aGUgZnJhbWUgdG8gUEUyIHdo ZXJlIGl0DQo+PndpbGwNCj4+cmVtb3ZlIHRoZSBTLVRhZyAoYW5kIGVpdGhlciBwdXNoIFZJRDIg YmFjayBvbiwgb3IgbGVhdmUgaXQgb2ZmIGRlcGVuZGluZw0KPj5vbiBTUCBwcmVmZXJlbmNlKQ0K Pj4NCj4+VGhlIHJlZmVyZW5jZSB0byAnZG91YmxlIHRhZ2dpbmcnIHdhcyB0YWxraW5nIGFib3V0 IHNvbHV0aW9uIEEgYWJvdmUsDQo+PnNpbmNlIHRoZXJlIGlzIGJvdGggdGhlIHNlcnZpY2UgVklE IHRoYXQgaXMgY29vcmRpbmF0ZWQgd2l0aCB0aGUNCj4+Y3VzdG9tZXIsDQo+PmFzIHdlbGwgYXMg dGhlIEV0cmVlIFZJRCB3aGljaCBkZXNpZ25hdGVzIHRoZSBzb3VyY2UgKHJvb3Qgb3IgbGVhZikN Cj4+W1tMWV1dIFNpbmNlIGR1YWwgVkxBTiBzb2x1dGlvbiB0cmllcyB0byBpbmxpbmUgd2l0aCBJ RUVFIHNvbHV0aW9uLCBpZg0KPj50aGlzIGlzIHRoZSB1c2UgY2FzZSwgd2Ugc3VnZ2VzdHMgdG8g Z28gd2l0aCBvcHRpb24gQiwgbm90IEEuIFNvIHBsZWFzZQ0KPj5kb24ndCBkaXNjdXNzIG9wdGlv biBBIG1vcmUuDQo+Pg0KPj5SZWdhcmRzLA0KPj5MdWN5DQo+Pg0KPj4NCj4+SG9wZSB0aGF0IGNs ZWFycyBtb3JlIHRoYW4gaXQgY29uZnVzZXMsDQo+Pkpvc2gNCj4+DQo+Pg0KPj4NCj4+T24gNC8y NS8xMiA0OjIyIFBNLCAiRmVkeWssIERvbmFsZCAoRG9uKSINCj4+PGRvbmFsZC5mZWR5a0BhbGNh dGVsLWx1Y2VudC5jb20+IHdyb3RlOg0KPj4NCj4+PkhpIERhdmUNCj4+Pg0KPj4+WWVzIHRoZSBv bmx5IHBvaW50IEkgd291bGQgYWRkIGlzIER1YWwgVkxBTiBtZWFucyBPbmUgVklEIGZvciBSb290 IGFuZA0KPj4+b25lIFZJRCBmb3IgTGVhZi4gTm90IHR3byBUQUdzIGF0IGEgdGltZSBvbiB0aGUg ZnJhbWUgYnV0IHR3byBhbGxvY2F0ZWQNCj4+PmZvciB0aGUgc2VydmljZS4NCj4+Pg0KPj4+VGhl IGNvbmZ1c2luZyBwYXJ0IGlzIG5vIGRvdWJ0IHRoYXQgRHVhbCBQV0UvRHVhbCBWTEFOIGNvbXBh cmlzb24gdGFsa3MNCj4+PmFib3V0IEVuY2Fwc3VsYXRpb24gT3ZlcmhlYWQgYXMgYSBWTEFOIFRh Zy4gV2hpbGUgdGhhdCBpcyB0cnVlIGluIGEgUFdFDQo+Pj5zZW5zZSBpdCBpcyBzdGlsbCBhIHNp bmdsZSBWTEFOIFRhZyBhdCBhIHRpbWUgaW4gYSBFdGhlcm5ldCBFLXRyZWUNCj4+PnNlbnNlLg0K Pj4+IFRoZSBjb21wZWxsaW5nIGRyaXZlciBmb3IgRHVhbCBWTEFOIGlzIGhhdmluZyBhIEV0cmVl IHNlcnZpY2UgdGhhdA0KPj4+d29ya3MNCj4+PmluIG1hbnkgZW52aXJvbm1lbnRzIGFuZCB0aGUg RFVBTCBWTEFOIChyZWFsbHkgZHVhbCBWTEFOIGludGVyZmFjZSBvbiBhDQo+Pj5WU0kpIHVzZXMg dGhlIHNhbWUgbWVjaGFuaXNtIChvbmUgVklEIGZvciByb290IGFuZCBvbmUgVklEIGZvciBMZWFm IGF0IGENCj4+PnRpbWUpIGFzIHNwZWNpZmllZCBpbiB0aGUgSUVFRS4gSW4gYSBwdXJlIEV0aGVy bmV0IGJyaWRnaW5nIHdvcmxkIHRoZQ0KPj4+VkxBTiBUQUdzIGZvciBFdHJlZSBhcmUgbm90IHR5 cGljYWxseSBhbiBvdmVyaGVhZCBzaW5jZSB0cmFuc2xhdGlvbiBpcw0KPj4+dXNlZC4NCj4+Pg0K Pj4+RG9uDQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBsMnZw bi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmDQo+Pj5PZg0KPj4+RGF2aWQgQWxsYW4gSQ0KPj4+U2VudDogV2VkbmVzZGF5LCBBcHJpbCAy NSwgMjAxMiA1OjA1IFBNDQo+Pj5UbzogRGFuaWVsIENvaG47IGwydnBuQGlldGYub3JnDQo+Pj5T dWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNv bHV0aW9uPw0KPj4+DQo+Pj5PSyBJIGZlZWwgbGlrZSBJIGFtIGRpZ3Jlc3NpbmcgYSBmYWlyIGRp c3RhbmNlIGZyb20gdGhlIGFjdHVhbA0KPj4+cHJvYmxlbS4uLi4gQnV0IGhlcmUgZ29lczoNCj4+ Pg0KPj4+U28gdGhlIHNjZW5hcmlvcyBjZW50ZXIgYXJvdW5kICJob3cgRVRSRUUgZG8geW91IHdh bnQgdG8gYmU/Ii4uLi4NCj4+Pg0KPj4+SWYgdGhlIEFDcyBhcmUgcm9vdC9sZWFmLCB0aGVuIGlm IHRoZXkgYXJlIFAyUCAoc2luZ2xlIGV0aGVybmV0IGVuZA0KPj4+c3RhdGlvbiBhdHRhY2hlZCB0 byBlYWNoIEFDKSB0aGlzIGlzIG1vb3QuIEVUUkVFIHNlbWFudGljcyBhcmUgZW5mb3JjZWQNCj4+ PmJ5IHRoZSAyVklEIGRvbWFpbiBpbiB0aGUgY2VudGVyIG9mIHRoZSBleGFtcGxlLiBJZiB5b3Ug YXNzdW1lZCBub2Rlcw0KPj4+QSZCDQo+Pj5pbiB0aGUgZXhhbXBsZSB3ZXJlIEwyVlBOIFBFcywg dGhlIHRhZ2dpbmcgYW5kIHRoZSBQVyB0YWcgaW1wb3NpdGlvbiBhbGwNCj4+PmhhcHBlbmVkIGF0 IHRoZSBzYW1lIHBvaW50IGluIHRoZSBuZXR3b3JrLg0KPj4+DQo+Pj5JZiB0aGV5IGFyZSBub3Qg c2ltcGxlIFAyUCBhbGwgdGhlIHdheSB0byBlbmQgc3lzdGVtcyBhbmQgdGhlIG9iamVjdGl2ZQ0K Pj4+aXMgdG8gYXZvaWQgYnJpZGdpbmcgYmV0d2VlbiBsZWFmICJzaXRlcyIgYnV0IGFsbG93aW5n IGludHJhLWxlYWYtc2l0ZQ0KPj4+Y29ubmVjdGl2aXR5IHRoZW4gdGhlIGxlYXZlcyBjYW4gYmUg TEFOcyBidXQgdGhlIHJvb3QgaXMgbm90LCBzdWNoIHRoYXQNCj4+PkkNCj4+PmNhbm5vdCBicmlk Z2UgdGhyb3VnaCB0aGUgcm9vdC4gQnV0IGFsbCBob3N0cyBhdCBhIGdpdmVuIGxlYWYgc2l0ZSBj YW4NCj4+PnNlZSBlYWNoIG90aGVyLiBTbyByb290IEV0aGVybmV0IGVuZCBzeXN0ZW1zIGFyZSBk aXJlY3RseSBhdHRhY2hlZCBvcg0KPj4+dHdvDQo+Pj5WSURzIGFyZSB1c2VkIGluIHRoZSByb290 IHNpdGUuDQo+Pj4NCj4+PklmIHRoZSBvYmplY3RpdmUgaXMgdGhhdCB0aGVyZSBhcmUgbXVsdGlw bGUgZXRoZXJuZXQgYXR0YWNoZWQgZW5kDQo+Pj5zdGF0aW9ucyBhdCBib3RoIHRoZSBsZWFmIGFu ZCByb290IHNpdGVzLCBhbmQgdGhlIG9iamVjdGl2ZSBpcyB0bw0KPj4+ZW5mb3JjZQ0KPj4+TDIg aXNvbGF0aW9uIGV2ZXJ5d2hlcmUgdGhlbiBJIG5lZWQgdHdvIFZJRHMgZXh0ZW5kZWQgdG8gdGhl IGVuZCBzeXN0ZW0NCj4+PmF0dGFjaGVtZW50IHBvaW50IGluIHRoZSBsb2NhbCBMQU5zIGJ5IHdo YXRldmVyIG1lYW5zLi4uLg0KPj4+DQo+Pj5BbmQgSSBkbyBub3Qgc2VlIGFkZGluZyBWTEFOcyBp biBhbnkgcGFydGljdWxhciBzcG90LCBzaW1wbHkgc2VsZWN0aW9uDQo+Pj5vZg0KPj4+dGhlIFZJ RCBhbmQgYXNzb2NpYXRlZCBzZW1hbnRpY3Mgd2hlcmUgVklEcyBhcmUgdHJhbnNsYXRlZC4gVGhl IGFjdHVhbA0KPj4+cG9pbnQgb2YgUy10YWcgaW1wb3NpdGlvbiBjb3VsZCBiZSBhIFBFLCBvciBj bG91ZCBiZSBhIE5JRC9DTEUgb24gdGhlDQo+Pj5jdXN0b21lciBwcmVtIChtb3JlIGxpa2VseSBz Y2VuYXJpbyBoZXJlIHRvIGV4dGVuZCBPQU0gZGVtYXJjIHRvIHRoZQ0KPj4+cHJlbSksIG9yIHNv bWUgc3dpdGNoIGluIGEgUkFOIGRvd25zdHJlYW0gb2YgdGhlIE1QTFMgUEUuLi4gYmxhaCBibGFo DQo+Pj5ibGFoLiBBbmQgaWYgRVRSRUUgaXMgZXh0ZW5kZWQgaW50byBhIGN1c3RvbWVyIHNpdGUg TEFOIGFuZCBvdXRzaWRlIG9mDQo+Pj50aGUgcHJvdmlkZXIgZG9tYWluLCB0aGVuIHR3byBDLXRh Z3Mgd291bGQgaGF2ZSB0byBiZSB1c2VkIHRoYXQgbWFwcGVkDQo+Pj50bw0KPj4+Uy10YWdzIGF0 IHRoZSBQQk4gYm91bmRhcnkuLi4NCj4+Pg0KPj4+TWFrZSBzZW5zZT8NCj4+PkRhdmUNCj4+Pg0K Pj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IERhbmllbCBDb2huIFttYWls dG86RGFuaWVsQ0BvcmNraXQuY29tXQ0KPj4+U2VudDogV2VkbmVzZGF5LCBBcHJpbCAyNSwgMjAx MiA0OjM5IFBNDQo+Pj5UbzogRGF2aWQgQWxsYW4gSTsgbDJ2cG5AaWV0Zi5vcmcNCj4+PlN1Ympl Y3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRp b24/DQo+Pj4NCj4+PkRhdmUsIGJ1dCB0aGUgQUNzIGFyZSByb290L2xlYWYgKHRoYXQncyB3aGF0 IHRoZSB3aG9sZSB2cGxzIGV0cmVlIGlzDQo+Pj5hYm91dCAtIHNlZSB0aGUgcmVxdCBkcmFmdCks IHNvIHBlciB0aGUgMnZsYW4gZHJhZnQgdGhlIHJvb3QvbGVhZiB2bGFuDQo+Pj5tdXN0IGJlIGFk ZGVkLg0KPj4+DQo+Pj5UaHVtYiB0eXBlZCAtIHBsZWFzZSBiZSB0b2xlcmFudA0KPj4+DQo+Pj5E YXZpZCBBbGxhbiBJIDxkYXZpZC5pLmFsbGFuQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+Pj4NCj4+ PkhJIERhbmllbDoNCj4+Pg0KPj4+SW4gdGhlIGV4YW1wbGUgcHJvdmlkZWQsDQo+Pj4NCj4+PiJp bmdyZXNzIFZMQU4gSUQgPC0+IEV0cmVlIFJvb3QvTGVhZiBWSUQgPC0+IEVncmVzcyBWSUQiDQo+ Pj4gICAgICAgICAgICAgICAgICBBICAgICAgICAgICAgICAgICAgICAgICBCDQo+Pj4NCj4+PnRo ZSBzZXJ2aWNlIGlzIG5vdCBFVFJFRSBpbiB0aGUgZG9tYWlucyBvZiB0aGUgaW5ncmVzcyBhbmQg ZWdyZXNzIFZJRC4NCj4+Pkl0DQo+Pj5pcyBFTEFOLiBTTyB0aGVyZSBpcyBubyByb290L2xlYWYg YXR0cmlidXRlIHRvIHNob3ZlbCBhcm91bmQuIEl0IHdvdWxkDQo+Pj5yZXF1aXJlIHR3byBWSURz IGluIGVhY2ggZG9tYWluIGlmIHRoZSBFVFJFRSBzZW1hbnRpY3Mgd2VyZSB0byBiZQ0KPj4+dGVs ZXNjb3BlZCBFMkUuDQo+Pj4NCj4+Pk90aGVyd2lzZSBpdCBpcyBhIHByb3Zpc2lvbmluZyBvZiB0 aGUgVklEIHRyYW5zbGF0aW9uIHRhYmxlcyBhdCB0aGUNCj4+PmludGVybWVkaWF0ZSBub2RlcyAo QSZCIHRoYXQgSSd2ZSBhZGRlZCB0byB0aGUgcGljdHVyZSkgdGhhdCB3b3VsZA0KPj4+ZGV0ZXJt aW5lIHRoZSBWSUQgdmFsdWVzIHVzZWQgaW4gZWFjaCBkb21haW4uIE9yIGluIHRoZSBleGFtcGxl IGFib3ZlLA0KPj4+d2hhdCB0aGUgaW5ncmVzcywgRXRyZWUgYW5kIGVncmVzcyBWSUQgdmFsdWVz IHdlcmUuDQo+Pj4NCj4+PkNoZWVycw0KPj4+RGF2ZQ0KPj4+DQo+Pj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4+RnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBu LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPj4+T2YNCj4+PkRhbmllbCBDb2huDQo+Pj5T ZW50OiBXZWRuZXNkYXksIEFwcmlsIDI1LCAyMDEyIDM6NDYgUE0NCj4+PlRvOiBMdWN5IHlvbmc7 IFJvZ2VycywgSm9zaDsgU2hhaHJhbSBEYXZhcmk7IExpemhvbmcgSmluOw0KPj4+bDJ2cG5AaWV0 Zi5vcmc7DQo+Pj5BbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KPj4+Q2M6IHl1cXVu LmNhb0BnbWFpbC5jb20NCj4+PlN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2Fj aGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4NCj4+PkFuZCB0byB0aGlzIEkgYXNrZWQg aG93IHRoaXMgbWFwcGluZyB3b3JrcyAtIGhvdyBkb2VzIHRoZSBlZ3Jlc3MgcGUNCj4+PnJlY292 ZXIgdGhlIGluZ3Jlc3MgdmlkIHdoZW4gaXQgZ2V0cyB0aGUgZnJhbWUgdGFnZ2VkIHdpdGggb25s eSB0aGUNCj4+PnJvb3QvbGVhZiB2aWQ/IEhvdyBjYW4geW91IGNvbnZleSB0aGUgaW5ncmVzcyB2 aWQgcGx1cyB0aGUgcm9vdC9sZWFmDQo+Pj5hdHRyaWJ1dGUgaW4gdGhlIHNhbWUgbnVtYmVyIG9m IGJpdHM/DQo+Pj5XaGF0IGFtIEkgbWlzc2luZz8NCj4+Pg0KPj4+RGFuaWVsDQo+Pj4NCj4+PlRo dW1iIHR5cGVkIC0gcGxlYXNlIGJlIHRvbGVyYW50DQo+Pj4NCj4+Pkx1Y3kgeW9uZyA8bHVjeS55 b25nQGh1YXdlaS5jb20+IHdyb3RlOg0KPj4+DQo+Pj5EYW5pZWwsDQo+Pj4NCj4+PkRhdmlkIEFs bGVuIGFscmVhZHkgZXhwbGFpbmVkIHRoZSBzb2x1dGlvbi4NCj4+Pg0KPj4+RnJvbSBEYXZpZDoN Cj4+PmluZ3Jlc3MgVkxBTiBJRCA8LT4gRXRyZWUgUm9vdC9MZWFmIFZJRCA8LT4gRWdyZXNzIFZJ RC4NCj4+Pg0KPj4+SW5ncmVzcyBWSUQgZG9lcyBub3QgaGF2ZSB0byBlcXVhbCBFZ3Jlc3MgVklE IGJ1dCByZWdhcmRsZXNzIHRoZXJlIGlzDQo+Pj5vbmx5IGV2ZXIgb25lIFZJRCBvbiBhIGZyYW1l IGF0IGEgdGltZS4NCj4+Pg0KPj4+LWVuZA0KPj4+DQo+Pj5UaGlzIHdvcmtzIHdoZW4gY3VzdG9t ZXIgbWFrZXMgaW5ncmVzcyBWTEFOIElEIG5vdCBlcXVhbCB0byBvciBlcXVhbCB0bw0KPj4+ZWdy ZXNzIFZMQU4gSUQuDQo+Pj4NCj4+PlJlZ2FyZHMsDQo+Pj5MdWN5DQo+Pj4NCj4+Pi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWls dG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+Pj5PZg0KPj4+RGFuaWVsIENv aG4NCj4+PlNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjUsIDIwMTIgMTE6MzkgQU0NCj4+PlRvOiBM dWN5IHlvbmc7IFJvZ2VycywgSm9zaDsgU2hhaHJhbSBEYXZhcmk7IExpemhvbmcgSmluOw0KPj4+ bDJ2cG5AaWV0Zi5vcmc7DQo+Pj5BbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KPj4+ Q2M6IHl1cXVuLmNhb0BnbWFpbC5jb20NCj4+PlN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRo ZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4NCj4+PkhpIEx1Y3ksDQo+ Pj4NCj4+PlRoZSBzY2VuYXJpbyB3ZSBhcmUgZGlzY3Vzc2luZyBpcyBub3QgdGhlIEUtVHJlZSBF LU5OSSwgYnV0IGEgZ2VuZXJhbA0KPj4+c2NlbmFyaW8gd2hlcmUgZnJhbWVzIGFycml2aW5nIGF0 IHRoZSByb290IG9yIGxlYWYgQUMgIGFyZSBhbHJlYWR5DQo+Pj5kb3VibGUNCj4+PnRhZ2dlZC4g SW4gdGhpcyBjYXNlLCB0aGUgZHVhbCB2bGFuIHNvbHV0aW9uIGNhbm5vdCBwcmVzZXJ2ZSB0aGUg dmxhbnMNCj4+PndpdGhvdXQgYWRkaW5nIGEgdGhpcmQgb25lLCBjYW4gaXQ/DQo+Pj4NCj4+Pk1h eWJlIFNoYWhyYW0gY2FuIGFkZCBkZXRhaWxzIG9uIHRoZSBzY2VuYXJpbyBoZSBoYWQgaW4gbWlu ZA0KPj4+DQo+Pj5UaHVtYiB0eXBlZCAtIHBsZWFzZSBiZSB0b2xlcmFudA0KPj4+DQo+Pj5MdWN5 IHlvbmcgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4+Pg0KPj4+RGFuaWVsLA0KPj4+ DQo+Pj5NRUYgaGFzIFMtVkxBTiBwcmVzZXJ2YXRpb24gYXR0cmlidXRlIGZvciBFTk5JIG9ubHkg YmVjYXVzZSB0aGVyZSBpcyBubw0KPj4+cy12bGFuIGF0IFVOSS4gV2hlbiBhbiBNRU4gY29ubmVj dHMgdG8gbXVsdGlwbGUgRU5OSSBpbnRlcmZhY2VzLCBTLVZBTE4NCj4+PnByZXNlcnZhdGlvbiBh dHRyaWJ1dGUgaXMgdXNlZC4gSXQgYXBwbGllcyB0byBFLVRyZWUgYXMgd2VsbC4NCj4+Pg0KPj4+ UmVnYXJkcywNCj4+Pkx1Y3kNCj4+Pg0KPj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ PkZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYNCj4+Pk9mDQo+Pj5EYW5pZWwgQ29obg0KPj4+U2VudDogVHVlc2RheSwg QXByaWwgMjQsIDIwMTIgMjoxMiBBTQ0KPj4+VG86IEx1Y3kgeW9uZzsgUm9nZXJzLCBKb3NoOyBT aGFocmFtIERhdmFyaTsgTGl6aG9uZyBKaW47DQo+Pj5sMnZwbkBpZXRmLm9yZzsNCj4+PkFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQo+Pj5DYzogeXVxdW4uY2FvQGdtYWlsLmNvbQ0K Pj4+U3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJl ZSBzb2x1dGlvbj8NCj4+Pg0KPj4+THVjeSwNCj4+Pg0KPj4+ZXZlbiBpZiB0aGUgY3VycmVudCBN RUYgZnJhbWV3b3JrIGRvZXNuJ3QgcmVxdWlyZSBzLXZsYW4gcHJlc2VydmF0aW9uLCBJDQo+Pj5i ZWxpZXZlIGl0J3MgdG8gdGhlIGluZHVzdHJ5J3MgYmVuZWZpdCB0byBhZG9wdCBhIHNvbHV0aW9u IHRoYXQgaXMgbm90DQo+Pj5jb25zdHJhaW5lZCB0byBhIHNwZWNpZmljIGVubmkgbW9kZWwgdGhh dCwgbGlrZSBhbGwgdGhpbmdzIG5ldHdvcmtpbmcsDQo+Pj5pcw0KPj4+bGlrZWx5IHRvIGV2b2x2 ZS4gRXNwZWNpYWxseSB3aGVuIHN1Y2ggYSBzb2x1dGlvbiBpcyBhdmFpbGFibGUuDQo+Pj4NCj4+ PkRhbmllbA0KPj4+DQo+Pj5UaHVtYiB0eXBlZCAtIHBsZWFzZSBiZSB0b2xlcmFudA0KPj4+DQo+ Pj5MdWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4+Pg0KPj4+RGFuaWVs LA0KPj4+DQo+Pj5NRUYgaGFzIHdvcmtlZCBpbiBFTk5JIGludGVyZmFjZSBmb3IgYSBsb25nIHRp bWUgd2l0aCBtYW55IHNlcnZpY2UNCj4+PnByb3ZpZGVycycgaW5wdXRzLiBJdCBoYWQgYSBmYWly IHJlYXNvbiB0byBhc3N1bWUgUy1WTEFOIG92ZXIgRU5OSSBieQ0KPj4+dGhlbi4gSXQgbWF5IG9w ZW4gQi1WTEFOIGZvciB0aGUgZnV0dXJlLiBJdCBpcyBiZXR0ZXIgZm9yIHVzIG5vdCB0bw0KPj4+ ZGlzY3VzcyAgYSBmdXR1cmUgZnJhbWV3b3JrIGhlcmUsIGJlY2F1c2UgaXQgd2lsbCBsZWFkIHVz IHRvIG5vd2hlcmUuDQo+Pj5IZXJlLCB3ZSB3YW50IHRvIGV4dGVuZCBWUExTIGluIHN1cHBvcnRp bmcgRS1UcmVlLg0KPj4+DQo+Pj5CZXN0IFJlZ2FyZHMsDQo+Pj5MdWN5DQo+Pj4NCj4+PkZyb206 IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYNCj4+Pk9mDQo+Pj5EYW5pZWwgQ29obg0KPj4+U2VudDogU3VuZGF5LCBBcHJpbCAy MiwgMjAxMiA3OjM0IEFNDQo+Pj5UbzogUm9nZXJzLCBKb3NoOyBTaGFocmFtIERhdmFyaTsgTGl6 aG9uZyBKaW47IGwydnBuQGlldGYub3JnOw0KPj4+QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVs ZS5jb20NCj4+PkNjOiB5dXF1bi5jYW9AZ21haWwuY29tDQo+Pj5TdWJqZWN0OiBSRTogVGhlIHN0 YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+DQo+Pj5T aGFocmFtIGFuZCBhbGwsDQo+Pj4NCj4+PlRoaXMgcXVlc3Rpb24gYWxyZWFkeSBjYW1lIHVwIGlu IG91ciBkaXNjdXNzaW9ucyAtIGlzIGl0IHNhZmUgdG8gYXNzdW1lDQo+Pj50aGF0IHRoZSBWTEFO IHRhZ3MgYXQgdGhlIEUtTk5JIHdpbGwgYWx3YXlzIGJlIGFjY29yZGluZyB0byB0aGUgY3VycmVu dA0KPj4+TUVGIG1vZGVsPyBPciBzaG91bGQgd2UgdHJ5IHRvIGJlIGFzIHRyYW5zcGFyZW50IGFz IHBvc3NpYmxlIHRvIHVzZXINCj4+PlZMQU4NCj4+PmVuY2Fwc3VsYXRpb24gYXQgdGhlIEUtTk5J LCB0byBhY2NvbW1vZGF0ZSBmdXR1cmUgZnJhbWV3b3Jrcz8NCj4+PkkgYmVsaWV2ZSB0aGF0IGFu eSBhcHByb2FjaCB0aGF0IGxvb2tzIGF0IHVzZXIgcGF5bG9hZCAoaW4gdGhpcyBjYXNlDQo+Pj5W TEFODQo+Pj50YWcpIHRvIHNpZ25hbCBWUExTIGluZm9ybWF0aW9uIChpbiB0aGlzIGNhc2Ugcm9v dC9sZWFmIG9yaWdpbikgaXMNCj4+Pm5lY2Vzc2FyaWx5IHRpZWQgdG8gc3BlY2lmaWMgYXNzdW1w dGlvbnMgb24gdXNlciBwYXlsb2FkIGVuY2Fwc3VsYXRpb24NCj4+PihpbiB0aGlzIGNhc2UsIHRo YXQgUy1WTEFOIHRhZyBpcyAiYXZhaWxhYmxlIiB0byBlbmNvZGUgcm9vdC9sZWFmKS4gSQ0KPj4+ ZG9uJ3QgdGhpbmsgdGhpcyBpcyBhIGZ1dHVyZS1wcm9vZiBhc3N1bXB0aW9uLCBpdCdzIHZlcnkg bGlrZWx5IHRoYXQNCj4+Pm90aGVyIG5ldHdvcmsgbW9kZWxzIHdpbGwgY29tZSB1cCB0aGF0IHJl cXVpcmUgUy1WTEFOIHByZXNlcnZhdGlvbiwNCj4+PndoaWNoDQo+Pj5pbiB0aGUgMi1WTEFOIGFw cHJvYWNoIHdvdWxkIG5lY2Vzc2l0YXRlIGFkZGluZyBhIHRoaXJkIFZMQU4tSUQuDQo+Pj4NCj4+ PkRhbmllbA0KPj4+DQo+Pj5Gcm9tOiBTaGFocmFtIERhdmFyaSA8ZGF2YXJpQGJyb2FkY29tLmNv bTxtYWlsdG86ZGF2YXJpQGJyb2FkY29tLmNvbT4+DQo+Pj5UbzogTGl6aG9uZyBKaW4gPGxpemhv LmppbkBnbWFpbC5jb208bWFpbHRvOmxpemhvLmppbkBnbWFpbC5jb20+PiwNCj4+PiJsMnZwbkBp ZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+Ig0KPj4+PGwydnBuQGlldGYub3JnPG1haWx0 bzpsMnZwbkBpZXRmLm9yZz4+LA0KPj4+IkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29t PG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvDQo+Pj5tDQo+Pj4+DQo+Pj4i DQo+Pj48QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5W YWluc2h0ZWluQGVjaXRlbGUuY28NCj4+Pm0NCj4+Pj4NCj4+Pj4NCj4+PkNjOiAieXVxdW4uY2Fv QGdtYWlsLmNvbTxtYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbT4iDQo+Pj48eXVxdW4uY2FvQGdt YWlsLmNvbTxtYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbT4+DQo+Pj5TdWJqZWN0OiBSRTogVGhl IHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+DQo+ Pj5IaSwNCj4+Pg0KPj4+SSBhbHNvIGhhdmUgYSBxdWVzdGlvbiByZWdhcmRpbmcgMi1WTEFOLiBX aGF0IGlmIHRoZSBjdXN0b21lciB0cmFmZmljDQo+Pj5hbHJlYWR5IGhhcyBhbiBTLVZMQU4/IERv IHdlIG5lZWQgYSAzcmQgVkxBTiB0byBpZGVudGlmeSB0aGUgTC9SPw0KPj4+DQo+Pj5UaHgNCj4+ PlNoYWhyYW0NCj4+Pg0KPj4+RnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bDJ2 cG4tYm91bmNlc0BpZXRmLm9yZz4NCj4+PlttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIExpemhvbmcgSmluDQo+Pj5TZW50OiBGcmlkYXksIEFwcmlsIDIwLCAyMDEy IDk6MzggQU0NCj4+PlRvOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+Ow0K Pj4+QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWlu c2h0ZWluQGVjaXRlbGUuY29tDQo+Pj4+DQo+Pj5DYzogeXVxdW4uY2FvQGdtYWlsLmNvbTxtYWls dG86eXVxdW4uY2FvQGdtYWlsLmNvbT4NCj4+PlN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRo ZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4NCj4+PkhpLCBhbGwsDQo+ Pj5UaGUgZGlmZmVyZW5jZSBiZXR3ZWVuIDItVkxBTiBhbmQgQ1cgYXBwcm9hY2ggaXMgd2hvIHdp bGwgcHJvdmlkZSB0aGUNCj4+PlIvTA0KPj4+aW5mb3JtYXRpb24sIGN1c3RvbWVyIHBheWxvYWQg b3IgUFc/IFRoZSBjdXN0b21lciBwYXlsb2FkIHdpbGwgYmUgYWx3YXlzDQo+Pj5tb2RpZmllZCB0 byBjYXJyeSBSL0wgaW5mb3JtYXRpb24gaW4gMi1WTEFOIGFwcHJvYWNoLCB3aGlsZSBQVyB3aXRo IENXDQo+Pj53aWxsIGNhcnJ5IFIvTCBpbmZvcm1hdGlvbiBmb3IgQ1cgYXBwcm9hY2guDQo+Pj5J IGhhdmUgYSBxdWVzdGlvbiB3aXRoIHRoZSAyLVZMQU4gYXBwcm9hY2ggaW4gSC1WUExTIHdoZXJl IEgtVlBMUyBpcw0KPj4+YWNjZXNzZWQgYnkgVlBXUyBhcyBkZXNjcmliZWQgaW4gUkZDNDY3MiBz ZWN0aW9uIDEwLjEuMy4gSWYgVlBXUyBpcyB1c2VkDQo+Pj50byBhY2Nlc3MgSC1WUExTLCBob3cg Y291bGQgdGhlIFBFIG9uIFZQV1Mgc2lkZSBhZGRzIFZMQU4gdG8gaW5kaWNhdGUNCj4+PlIvTA0K Pj4+aW5mb3JtYXRpb24/DQo+Pj4NCj4+PlRoYW5rcw0KPj4+TGl6aG9uZw0KPj4+DQo+Pj4+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pg0KPj4+PiBNZXNzYWdlOiAyDQo+Pj4+ IERhdGU6IFRodSwgMTkgQXByIDIwMTIgMDQ6Mzg6MzYgKzAwMDANCj4+Pj4gRnJvbTogQWxleGFu ZGVyIFZhaW5zaHRlaW4NCj4+Pj4gPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1h aWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLg0KPj4+PiBjb20+Pg0KPj4+PiBUbzog IlJvZ2VycywgSm9zaCINCj4+Pj48am9zaC5yb2dlcnNAdHdjYWJsZS5jb208bWFpbHRvOmpvc2gu cm9nZXJzQHR3Y2FibGUuY29tPj4sIEx1Y3kgeW9uZw0KPj4+PiAgICAgICAgPGx1Y3kueW9uZ0Bo dWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+LCBEYW5pZWwNCj4+Pj5Db2hu DQo+Pj4+PERhbmllbENAb3Jja2l0LmNvbTxtYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tPj4sIFNh bSBDYW8NCj4+Pj4gICAgICAgIDx5dXF1bi5jYW9AZ21haWwuY29tPG1haWx0bzp5dXF1bi5jYW9A Z21haWwuY29tPj4NCj4+Pj4gQ2M6ICJsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5v cmc+Ig0KPj4+PiA8bDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPj4NCj4+Pj4g U3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBz b2x1dGlvbj8NCj4+Pj4gTWVzc2FnZS1JRDoNCj4+Pj4NCj4+Pj4gPEY5MzM2NTcxNzMxQURFNDJB NTM5N0ZDODMxQ0VBQTAyMDM0MTkyQEZSSURXUFBNQjAwMi5lY2l0ZWxlLmNvbTxtYWlsdA0KPj4+ PiBvOkY5MzM2NTcxNzMxQURFNDJBNTM5N0ZDODMxQ0VBQTAyMDM0MTkyQEZSSURXUFBNQjAwMi5l Y2l0ZWxlLmNvbT4+DQo+Pj4+IENvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXMt YXNjaWkiDQo+Pj4+DQo+Pj4+IEhpIGFsbCwNCj4+Pj4gSSBmdWxseSB1bmRlcnN0YW5kIHRoYXQg dGhhdCB3aGF0IEkgYW0gZ29pbmcgdG8gc2F5IGlzIG5vdCB2ZXJ5DQo+Pj4+cG9wdWxhciwgYnV0 Og0KPj4+Pg0KPj4+PiBJTU8gb25lIG9mIHRoZSBhZHZhbnRhZ2VzIG9mIHRoZSBDVy1iYXNlZCBz b2x1dGlvbiBpcyB0aGF0IGl0IGlzDQo+Pj4+b3J0aG9nb25hbCB0byB1c2FnZSAob3Igbm9uLXVz YWdlKSBvZiBQMk1QIFBXcyBmb3IgZWZmZWN0aXZlIGRlbGl2ZXJ5DQo+Pj4+b2YNCj4+Pj5CVU4g dHJhZmZpYy4NCj4+Pj4NCj4+Pj4gQW5vdGhlciBhZHZhbnRhZ2UgaXMgcHJlc2VydmF0aW9uIG9m IGZ1bGwgbWVzaCBvZiBQMlAgUFdzIGluIGEgVlBMUywNCj4+Pj5hbmQsIGluIGEgbW9yZSBnZW5l cmljIHdheSwgbG9jYWxpemF0aW9uIG9mIGVmZmVjdHMgb2YgY2hhbmdlcyBpbiB0aGUNCj4+Pj5Q RQ0KPj4+PmNvbmZpZ3VyYXRpb24uDQo+Pj4+DQo+Pj4+IEluIHBhcnRpY3VsYXIsIGFkZGluZyBh IExlYWYgQUMgdG8gYSBQRSB0aGF0IHByZXZpb3VzbHkgaGFzIGJlZW4gb25seQ0KPj4+PnN1cHBv cnRpbmcgUm9vdCBBQ3MgKG9yIHZpY2UgdmVyc2EpLCByZW1vdmFsIG9mIHRoZSBsYXN0IExlYWYg b3IgbGFzdA0KPj4+PlJvb3QgQUMgZnJvbSBhIFBFIHRoYXQgcHJldmlvdXNseSBoYXMgYmVlbiBz dXBwb3J0aW5nIGEgbWl4IGV0Yy4gYWZmZWN0DQo+Pj4+b25seSB0aGUgUEUgd2hlcmUgdGhpcyBv cGVyYXRpb24gaGFwcGVucyBhbmQgbm90IHRoZSByZXN0IG9mIHRoZSBQRXMuDQo+Pj4+DQo+Pj4+ IEFzIGZvciB0aGUgbmVlZCBmb3IgSFcgY2hhbmdlcyB0aGF0IGhhdmUgYmVlbiBtZW50aW9uZWQg YXMgYSBtYWluDQo+Pj4+ZGlzYWR2YW50YWdlIG9mIHRoZSBDVy1iYXNlZCBhcHByb2FjaCAtIEkg YmVsaWV2ZSBpdCBzdHJvbmdseSBkZXBlbmRzDQo+Pj4+b24NCj4+Pj5zcGVjaWZpYyBpbXBsZW1l bnRhdGlvbnMuIEFuZCBzb21lIGNoYW5nZXMgaW4gdGhlIGZvcndhcmRpbmcgcHJvY2Vzcw0KPj4+ PmFyZQ0KPj4+PnJlcXVpcmVkIGluIGFueSBzb2x1dGlvbi4NCj4+Pj4NCj4+Pj4gTXkgMmMsDQo+ Pj4+ICAgICBTYXNoYQ0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IEZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc+DQo+Pj4+IFtsMnZwbi1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnPl0gb24gYmVoYWxmIG9mDQo+Pj4+IFJv Z2VycywgSm9zaCBbam9zaC5yb2dlcnNAdHdjYWJsZS5jb208bWFpbHRvOmpvc2gucm9nZXJzQHR3 Y2FibGUuY29tPl0NCj4+Pj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxOCwgMjAxMiA5OjU3IFBN DQo+Pj4+IFRvOiBMdWN5IHlvbmc7IERhbmllbCBDb2huOyBTYW0gQ2FvDQo+Pj4+IENjOiBsMnZw bkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+DQo+Pj4+IFN1YmplY3Q6IFJlOiBUaGUg c3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4+DQo+ Pj4+IEFnYWluLCB0aGUgUDJNUCBzaXR1YXRpb24gdGhyb3dzIG1lLiAgSXMgdGhpcyBzb21ldGhp bmcgdGhhdCBpcyB1c2VkDQo+Pj4+IGNvbW1vbmx5Pw0KPj4+Pg0KPj4+PiBJJ20gdW5kZXIgdGhl IGltcHJlc3Npb24gdGhhdCBhZGRpbmcgUDJNUCB0byBhbnkgbW9kZWwgcmVzdWx0cyBpbiBhDQo+ Pj4+IG1vcmUgY29tcGxleCBtb2RlbC4gIFdldGhlciBvdXRzaWRlIHMtdGFnIGlzIHVzZWQgdG8g ZGlmZmVyZW50aWF0ZSwgb3INCj4+Pj4gZGVkaWNhdGVkIHB3J3MgYXJlIHVzZWQgZm9yIHRoZSBz YW1lIHB1cnBvc2UsIGl0IHNlZW1zIGJvdGggYmVjb21lDQo+Pj4+IG1vcmUgY29tcGxleC4NCj4+ Pj4NCj4+Pj4gR2lsZSdzIGNvbXBhcmlzb24gc2xpZGUgc3RpbGwgY29uY2lzZWx5IGNhcHR1cmVz IHRoZSBkaWZmZXJlbmNlcw0KPj4+PiBiZXR3ZWVuIHRoZXNlIG1ldGhvZHMsIGluIG15IG9waW5p b24uICBJIGhhdmVuJ3Qgc2VlbiBhbnkgbmV3IGlkZWFzIG9yDQo+Pj4+IHRob3VnaHRzIGJyb3Vn aHQgdG8gdGhlIGdyb3VwIGluIHRoZSBwYXN0IHdlZWsgb3IgdHdvIG9uIHRoZSBzdWJqZWN0Lg0K Pj4+PiBJIHdvdWxkIGhhdGUgZm9yIGJvdGggcHJvcG9zZWQgbWV0aG9kcyB0byBkaWUgb24gdGhl IHZpbmUgYmVjYXVzZSB3ZQ0KPj4+PiBjb3VsZG4ndCBkZWNpZGUgYmV0d2VlbiB0d28gbWV0aG9k cyB0aGF0IGhhdmUgbm90aGluZyBpbmhlcmVudGx5IHdyb25nDQo+Pj4+d2l0aCBlaXRoZXIuDQo+ Pj4+DQo+Pj4+IC1Kb3NoDQo+Pj4+DQo+Pj4+DQo+Pj4+IE9uIDQvMTgvMTIgMTo1MyBQTSwgIkx1 Y3kgeW9uZyINCj4+Pj48bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3 ZWkuY29tPj4gd3JvdGU6DQo+Pj4+DQo+Pj4+PlNlbmQgdGhpcyBhZ2Fpbi4NCj4+Pj4+DQo+Pj4+ PlR3byBQVyBhcHByb2FjaCBjYW4gYmUgY29tcGxleCB0b28gaWYgdGhlIFZQTFMgaW5zdGFuY2Ug Zm9yIEUtVHJlZQ0KPj4+Pj51c2VzIFAyUCBQVyBmb3IgdW5pY2FzdCB0cmFmZmljIGFuZCBQMk1Q IFBXIGZvciBicm9hZGNhc3QgYW5kIHVua25vd24NCj4+Pj4+dW5pY2FzdCB0cmFmZmljLCBhbmQg c29tZSBQMk1QIFBXcyBmb3IgbXVsdGljYXN0IHRyYWZmaWMuIEl0IG1heQ0KPj4+Pj5kb3VibGUg YWxsIG9mIHRoZW0uDQo+Pj4+Pg0KPj4+Pj5MdWN5DQo+Pj4+Pg0KPj4+Pj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+Pj5Gcm9tOiBEYW5pZWwgQ29obg0KPj4+Pj5bbWFpbHRvOkRhbmll bENAb3Jja2l0LmNvbTxtYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tPl0NCj4+Pj4+U2VudDogV2Vk bmVzZGF5LCBBcHJpbCAxOCwgMjAxMiAxOjQyIFBNDQo+Pj4+PlRvOiBMdWN5IHlvbmc7IFJvZ2Vy cywgSm9zaDsgU2FtIENhbw0KPj4+Pj5DYzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGll dGYub3JnPg0KPj4+Pj5TdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0 byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+Pj4NCj4+Pj4+SSB0aGluayB0aGUgZmlyc3Qgb3B0 aW9uIGl0cyB0aGUgbmF0dXJhbCB3YXkgdG8gZ28uIEhvdyBpcyB0aGUNCj4+Pj4+cHJvY2Vzc2lu ZyBpbiB0aGlzIGNhc2UgbW9yZSBjb21wbGV4Pw0KPj4+Pj4NCj4+Pj4+VGh1bWIgdHlwZWQgLSBw bGVhc2UgYmUgdG9sZXJhbnQNCj4+Pj4+DQo+Pj4+Pkx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdl aS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+Pj4+Pg0KPj4+Pj4N Cj4+Pj4+DQo+Pj4+PlNuaXBwZWQuLg0KPj4+Pj4NCj4+Pj4+TXVsdGktUFcgLSBPbiBpbmdyZXNz IFBFLCBmcmFtZSBpcyBwbGFjZWQgb250byBlaXRoZXIgYSBMZWFmLW9ubHkgUDJNUA0KPj4+Pj5Q VyAoZm9yIHRyYWZmaWMgY29taW5nIGZyb20gYSBsZWFmIEFDKSwgb3Igb250byBhIFJvb3QvTGVh ZiBQMk1QIFBXDQo+Pj4+Pihmb3IgdHJhZmZpYyBjb21pbmcgZnJvbSBhIHJvb3QgQUMpIFtbTFld XSBOb3QgdGhhdCBzaW1wbGUuIFlvdQ0KPj4+Pj5jb25zdHJ1Y3QgZWl0aGVyIHR3byBQMk1QIFBX cyB0byBhbGwgb3RoZXIgUEVzIGFuZCBsZXQgZWdyZXNzIFBFDQo+Pj4+PnBlcmZvcm1pbmcgZmls dGVyaW5nLCBvciBjb25zdHJ1Y3Qgb25lIFAyTVAgUFcgdG8gbGVhZi1vbmx5IFBFcyBhbmQNCj4+ Pj4+dHdvIFAyTVAgUFdzIHRvIHJvb3QgYW5kIGxlYWYgUEVzIGFuZCBsZXQgaW5ncmVzcyBQRSBw ZXJmb3JtDQo+Pj4+PmZvcndhcmRpbmcgYW5kIGZpbHRlcmluZy4gQm90aCBtYWtlIG5vZGUgcHJv Y2VzcyBjb21wbGV4Lg0KPj4+Pj4NCj4+Pj4+W1tMWV1dIFZQTFMgaXMgYnVpbHQgd2l0aCB0aGUg bWVjaGFuaXNtIHV0aWxpemluZyBQMlAgYW5kIFAyTVAgUFcgZm9yDQo+Pj4+PmRlbGl2ZXJpbmcg dGhlIGZyYW1lcyB0byByZW1vdGUgUEVzLiBXZSBzaG91bGQgdXRpbGl6ZSB0aGVtIHdpdGggdGhl DQo+Pj4+Pm1pbmltaXplZCBjaGFuZ2VzLiBEdWFsIFZMQU4gc29sdXRpb24gaXMgc2ltcGxlciB0 aGFuIER1YWwgUFcuDQo+Pj4+Pg0KPj4+Pj5SZWdhcmRzLA0KPj4+Pj5MdWN5DQo+Pj4+Pg0KPj4+ Pj4NCj4+Pj4+SSBzZWUgaG93IDJWTEFOIGlzIHNpbXBsZXIgd2hlbiBQMk1QIFBXJ3MgYXJlIGlu dm9sdmVkLCBJIHRoaW5rLiAgSQ0KPj4+Pj5oYXZlbid0IGhhZCBhbnkgZmlyc3QgaGFuZCBleHBl cmllbmNlIHdpdGggUDJNUCBQVydzLCBob3dldmVyLCBzbw0KPj4+Pj5kb24ndCBmZWVsIHRlcnJp Ymx5IHN0cm9uZyBhYm91dCB0aGlzIG9iamVjdGlvbi4gIElzIHRoaXMgYSByZWFsDQo+Pj4+PnBy b2JsZW0gZm9yIG90aGVycyAobm93IG9yIGluIHRoZSBmdXR1cmUpLCBvciBpcyB0aGlzIG9iamVj dGlvbiBpbiB0aGUNCj4+Pj4+d2VlZHM/DQo+Pj4+Pg0KPj4+Pj5JJ20gbm90IHN1cmUgdGhlICdh ZGRpdGlvbmFsIGNvbXBsZXhpdHknIGlzIG5vdGFibGUsIG9yIGV2ZW4gcmVsZXZhbnQuDQo+Pj4+ PkkgZW5jb3VyYWdlIG90aGVycyB0byBzcGVhayB1cCBpZiB0aGV5IGRpc2FncmVlLCBhcyBQMk1Q IFBXIGlzIG9ubHkNCj4+Pj4+Y29uY2VwdHVhbCB0byBtZSwgYW5kIEkgYW0gdW5mYW1pbGlhciB3 aXRoIHJlYWwtbGlmZSB1c2UgY2FzZXMgZm9yIGl0Lg0KPj4+Pj4NCj4+Pj4+VGhhbmtzLA0KPj4+ Pj5Kb3NoDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pk9uIDQvMTgvMTIgMTA6MzAgQU0sICJM dWN5IHlvbmciDQo+Pj4+PjxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1 YXdlaS5jb20+PiB3cm90ZToNCj4+Pj4+DQo+Pj4+Pj5QbGVhc2Ugc2VlIGlubGluZS4NCj4+Pj4+ Pg0KPj4+Pj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+PkZyb206IFNhbSBDYW8N Cj4+Pj4+PlttYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86eXVxdW4uY2FvQGdtYWls LmNvbT5dDQo+Pj4+Pj5TZW50OiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiA3OjE0IEFNDQo+Pj4+ Pj5UbzogJ0RhbmllbCBDb2huJzsgTHVjeSB5b25nOyAnUm9nZXJzLCBKb3NoJzsgJ0hlbmRlcmlj a3gsIFdpbQ0KPj4+Pj4+KFdpbSknOyBnaWxlcy5oZXJvbkBnbWFpbC5jb208bWFpbHRvOmdpbGVz Lmhlcm9uQGdtYWlsLmNvbT47DQo+Pj4+Pj5zaW1vbi5kZWxvcmRAZ21haWwuY29tPG1haWx0bzpz aW1vbi5kZWxvcmRAZ21haWwuY29tPjsNCj4+Pj4+PkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRl bGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLg0KPj4+Pj4+Y29tPg0K Pj4+Pj4+Q2M6IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz47DQo+Pj4+Pj5W bGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPG1haWx0bzpWbGFkaW1pci5LbGVpbmVyQGVjaXRl bGUuY29tPjsNCj4+Pj4+PkFuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPG1haWx0bzpBbmRyZXcu U2VyZ2VldkBlY2l0ZWxlLmNvbT47DQo+Pj4+Pj5JZGFuLkthc3BpdEBlY2l0ZWxlLmNvbTxtYWls dG86SWRhbi5LYXNwaXRAZWNpdGVsZS5jb20+Ow0KPj4+Pj4+TWlzaGFlbC5XZXhsZXJAZWNpdGVs ZS5jb208bWFpbHRvOk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPjsNCj4+Pj4+PlJvdGVtLkNv aGVuQGVjaXRlbGUuY29tPG1haWx0bzpSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbT4NCj4+Pj4+PlN1 YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29s dXRpb24/DQo+Pj4+Pj4NCj4+Pj4+PlllcywgMiBwd3MgYXJlIG9ubHkgbmVlZGVkIGJldHdlZW4g cGVzIHdpdGggYm90aCByb290IGFuZCBsZWFmIGFjcw0KPj4+Pj4+YWZ0ZXIgaW1wcm92aW5nIER1 YWwtUFcgYXBwcm9hY2guIElmIGNvbnNpZGVyIFAyTVAsIER1YWwtUFcgYXBwcm9hY2gNCj4+Pj4+ PnNldHVwIDIgUDJNUCBQV3MgaWYgbmVlZC4gVGhlcmUgaXMgbm8gZGlmZmVyZW5jZSBiZXR3ZWVu IFAyTVAgb3INCj4+Pj4+Pm5vcm1hbCBQVyBzZXR1cC4gQnV0LCBjYW4gTGVhZi1BQ3MgYmUgYm91 bmQgdG8gUm9vdCBQRSBvZiBQMk1QIFBXPw0KPj4+Pj4+DQo+Pj4+Pj5bW0xZXV0gTm8sIGl0IG1h a2VzIGNvbXBsZXggaW4gc2V0dGluZyB1cCBQMk1QIFBXLiBTaG91bGQgYSBQRSB3aXRoDQo+Pj4+ Pj5ib3RoIHJvb3QgYW5kIGxlYWYgQUNzIHNldCB1cCB0d28gb3Igb25lIFAyTVAgUFcgdG8gb3Ro ZXIgUEVzIChzb21lDQo+Pj4+Pj5QRSBoYXZlIGJvdGggcm9vdCBhbmQgbGVhZiBBQyBhbmQgc29t ZSBvbmx5IGhhdmUgbGVhZiBBQ3MpPw0KPj4+Pj4+UmVnYXJkcywNCj4+Pj4+Pkx1Y3kNCj4+Pj4+ Pg0KPj4+Pj4+UmVnYXJkcywNCj4+Pj4+Pg0KPj4+Pj4+WXVxdW4gKFNhbSkgQ2FvDQo+Pj4+Pj5F LW1haWw6IFl1cXVuLmNhb0BnbWFpbC5jb208bWFpbHRvOll1cXVuLmNhb0BnbWFpbC5jb20+DQo+ Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+PkZy b206IERhbmllbCBDb2huDQo+Pj4+Pj5bbWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbTxtYWlsdG86 RGFuaWVsQ0BvcmNraXQuY29tPl0NCj4+Pj4+PlNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE3LCAyMDEy IDQ6NTYgUE0NCj4+Pj4+PlRvOiBMdWN5IHlvbmc7IFJvZ2VycywgSm9zaDsgSGVuZGVyaWNreCwg V2ltIChXaW0pOw0KPj4+Pj4+Z2lsZXMuaGVyb25AZ21haWwuY29tPG1haWx0bzpnaWxlcy5oZXJv bkBnbWFpbC5jb20+Ow0KPj4+Pj4+c2ltb24uZGVsb3JkQGdtYWlsLmNvbTxtYWlsdG86c2ltb24u ZGVsb3JkQGdtYWlsLmNvbT47DQo+Pj4+Pj5BbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS4NCj4+Pj4+PmNvbT47IFNhbSBD YW8NCj4+Pj4+PkNjOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+Ow0KPj4+ Pj4+VmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbTxtYWlsdG86VmxhZGltaXIuS2xlaW5lckBl Y2l0ZWxlLmNvbT47DQo+Pj4+Pj5BbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5k cmV3LlNlcmdlZXZAZWNpdGVsZS5jb20+Ow0KPj4+Pj4+SWRhbi5LYXNwaXRAZWNpdGVsZS5jb208 bWFpbHRvOklkYW4uS2FzcGl0QGVjaXRlbGUuY29tPjsNCj4+Pj4+Pk1pc2hhZWwuV2V4bGVyQGVj aXRlbGUuY29tPG1haWx0bzpNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT47DQo+Pj4+Pj5Sb3Rl bS5Db2hlbkBlY2l0ZWxlLmNvbTxtYWlsdG86Um90ZW0uQ29oZW5AZWNpdGVsZS5jb20+DQo+Pj4+ Pj5TdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVl IHNvbHV0aW9uPw0KPj4+Pj4+DQo+Pj4+Pj5BZGRpbmcgU2FtIChhcyBsMnZwbkAgaXMgaG9sZGlu ZyBtZXNzYWdlcykNCj4+Pj4+Pg0KPj4+Pj4+REMNCj4+Pj4+Pg0KPj4+Pj4+LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+Pj4+PkZyb206IEx1Y3kgeW9uZw0KPj4+Pj4+W21haWx0bzpsdWN5 LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+XQ0KPj4+Pj4+U2Vu dDogVHVlc2RheSwgQXByaWwgMTcsIDIwMTIgMTI6MzkgQU0NCj4+Pj4+PlRvOiBEYW5pZWwgQ29o bjsgUm9nZXJzLCBKb3NoOyBIZW5kZXJpY2t4LCBXaW0gKFdpbSk7DQo+Pj4+Pj5naWxlcy5oZXJv bkBnbWFpbC5jb208bWFpbHRvOmdpbGVzLmhlcm9uQGdtYWlsLmNvbT47DQo+Pj4+Pj5zaW1vbi5k ZWxvcmRAZ21haWwuY29tPG1haWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPjsNCj4+Pj4+PkFs ZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLg0KPj4+Pj4+Y29tPg0KPj4+Pj4+Q2M6IGwydnBuQGlldGYub3JnPG1haWx0bzps MnZwbkBpZXRmLm9yZz47DQo+Pj4+Pj5WbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPG1haWx0 bzpWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPjsNCj4+Pj4+PkFuZHJldy5TZXJnZWV2QGVj aXRlbGUuY29tPG1haWx0bzpBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbT47DQo+Pj4+Pj5JZGFu Lkthc3BpdEBlY2l0ZWxlLmNvbTxtYWlsdG86SWRhbi5LYXNwaXRAZWNpdGVsZS5jb20+Ow0KPj4+ Pj4+TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb208bWFpbHRvOk1pc2hhZWwuV2V4bGVyQGVjaXRl bGUuY29tPjsNCj4+Pj4+PlJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPG1haWx0bzpSb3RlbS5Db2hl bkBlY2l0ZWxlLmNvbT4NCj4+Pj4+PlN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHBy b2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+U25p cHBlZCwNCj4+Pj4+Pg0KPj4+Pj4+QXMgd2UgZGlzY3Vzc2VkIGV4dGVuc2l2ZWx5IGluIHRoZSBs aXN0LCBhbmQgYXMgcmVmbGVjdGVkIGluIGdpbGVzDQo+Pj4+Pj5zbGlkZSwgMiBwd3MgYXJlIG9u bHkgbmVlZGVkIGJldHdlZW4gcGVzIHdpdGggYm90aCByb290IGFuZCBsZWFmIGFjcywNCj4+Pj4+ PndoaWNoIHdpbGwgdHlwaWNhbGx5IGJlIGEgc21hbGwgbWlub3JpdHkuDQo+Pj4+Pj5bW0xZXV0g RG9uJ3Qga25vdyBpZiB0aGUgYXNzdW1wdGlvbiBpcyB0cnVlLiBFdmVuIGl0IGlzIHRoZSBjYXNl LA0KPj4+Pj4+Ym90aCBhcHByb2FjaGVzIGNhbiBiZW5lZml0IGZyb20gaXQuIEkgd2FzIG9mZiBm b3IgYSB3aGlsZSBhbmQNCj4+Pj4+PmNhcHR1cmVzIHNvbWUgZGlzY3Vzc2lvbnMgbm93Lg0KPj4+ Pj4+DQo+Pj4+Pj5BbHNvIGFzIHBlciBnaWxlcyBzbGlkZSwgZHVhbCB2bGFuIGNhbiBoYXZlIHNj YWxhYmlsaXR5IGlzc3VlcyBkdWUgdG8NCj4+Pj4+PmFkZGl0aW9uYWwgbG9va3VwIGFuZCBkb3Vi bGUgdXNlIG9mIHZsYW5zIGluIGludGVybmFsIGVtdWxhdGVkIGxhbg0KPj4+Pj4+aW50ZXJmYWNl LiBBbHNvIHRoZXJlIGFyZSBwb3RlbnRpYWwgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBpc3N1ZXMN Cj4+Pj4+PndpdGggc2lsaWNvbiB0aGF0IGRvZXNuJ3Qgc3VwcG9ydCB2bGFuIG1hcHBpbmcuDQo+ Pj4+Pj5bW0xZXV0gSSB3YXMgbm90IGluIElFVEY4MyBtZWV0aW5nIGFuZCB3YWl0IG9uIHRoZSBt ZWV0aW5nIG1pbnV0ZXMuIEkNCj4+Pj4+PmFtIG5vdCBjbGVhciBvbiBhbGwgdGhlIGlzc3Vlcy4g Q291bGQgeW91IGJlIG1vcmUgc3BlY2lmaWM/IEFzIEkNCj4+Pj4+Pm1lbnRpb25lZCBpbiBiZWxv dywgdHdvIFBXIGFwcHJvYWNoIG1ha2VzIFZQTFMgdHJhbnNwb3J0IGNvbnN0cnVjdGlvbg0KPj4+ Pj4+YW5kIHBhY2tldCBmb3J3YXJkaW5nIG1vcmUgY29tcGxleCwgSSBjYW4gc2VlIHBvdGVudGlh bCBiYWNrd2FyZA0KPj4+Pj4+Y29tcGF0aWJpbGl0eSBpc3N1ZXMgd2l0aCAyIFBXIHNvbHV0aW9u Lg0KPj4+Pj4+DQo+Pj4+Pj5SZWdhcmRzLA0KPj4+Pj4+THVjeQ0KPj4+Pj4+DQo+Pj4+Pj5SZWdh cmRzLA0KPj4+Pj4+DQo+Pj4+Pj5EYW5pZWwNCj4+Pj4+Pg0KPj4+Pj4+VGh1bWIgdHlwZWQgLSBw bGVhc2UgYmUgdG9sZXJhbnQNCj4+Pj4+Pg0KPj4+Pj4+THVjeSB5b25nIDxsdWN5LnlvbmdAaHVh d2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiB3cm90ZToNCj4+Pj4+Pg0KPj4+ Pj4+SW4gbXkgbWluZCwgdGhlIFZMQU4gYXBwcm9hY2ggbWVhbnMgZHVhbCB2bGFuIG1ldGhvZC4N Cj4+Pj4+Pg0KPj4+Pj4+VGhlIG1haW4gY29uY2VybiBmb3IgQ1cgYXBwcm9hY2ggaXMgaGFyZHdh cmUgc3VwcG9ydC4NCj4+Pj4+Pg0KPj4+Pj4+VHdvIFBXIGFwcHJvYWNoIGNhbiBiZSBjb21wbGV4 IHRvbyBpZiB0aGUgVlBMUyBpbnN0YW5jZSBmb3IgRS1UcmVlDQo+Pj4+Pj51c2VzIFAyUCBQVyBm b3IgdW5pY2FzdCB0cmFmZmljIGFuZCBQMk1QIFBXIGZvciBicm9hZGNhc3QgYW5kIHVua25vd24N Cj4+Pj4+PnVuaWNhc3QgdHJhZmZpYywgYW5kIHNvbWUgUDJNUCBQV3MgZm9yIG11bHRpY2FzdCB0 cmFmZmljLiBJdCBtYXkNCj4+Pj4+PmRvdWJsZSBhbGwgb2YgdGhlbS4NCj4+Pj4+Pg0KPj4+Pj4+ RS10cmVlIGlzIGFuIEV0aGVybmV0IHNlcnZpY2UgYW5kIHRoZXJlIGlzIGFscmVhZHkgVkxBTiBi YXNlZA0KPj4+Pj4+c29sdXRpb24gaW4gSUVFRSwgY2FuIHdlIGp1c3QgdXRpbGl6ZSBpdCB3aXRo b3V0IGNvbXBsaWNhdGluZyBWUExTDQo+Pj4+Pj50cmFuc3BvcnQgY29uc3RydWN0aW9uPyBUaGlz IGFsc28gbWFrZXMgaW50ZXJ3b3JraW5nIHdpdGggRXRoIG9ubHkNCj4+Pj4+Pm5ldHdvcmsgZWFz aWVyLg0KPj4+Pj4+DQo+Pj4+Pj5DaGVlcnMsDQo+Pj4+Pj5MdWN5DQo+Pj4+Pj4NCj4+Pj4+Pi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj5Gcm9tOiBSb2dlcnMsIEpvc2gNCj4+Pj4+ PlttYWlsdG86am9zaC5yb2dlcnNAdHdjYWJsZS5jb208bWFpbHRvOmpvc2gucm9nZXJzQHR3Y2Fi bGUuY29tPl0NCj4+Pj4+PlNlbnQ6IE1vbmRheSwgQXByaWwgMTYsIDIwMTIgODozNSBBTQ0KPj4+ Pj4+VG86IEx1Y3kgeW9uZzsgSGVuZGVyaWNreCwgV2ltIChXaW0pOw0KPj4+Pj4+J2dpbGVzLmhl cm9uQGdtYWlsLmNvbTxtYWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tPic7DQo+Pj4+Pj4nc2lt b24uZGVsb3JkQGdtYWlsLmNvbTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT4nOw0KPj4+ Pj4+J0FsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFp bnNodGVpbkBlY2l0ZWxlDQo+Pj4+Pj4uDQo+Pj4+Pj5jDQo+Pj4+Pj5vbT4nDQo+Pj4+Pj5DYzog J2wydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4nOw0KPj4+Pj4+J1ZsYWRpbWly LktsZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb20+ JzsNCj4+Pj4+PidBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3LlNlcmdl ZXZAZWNpdGVsZS5jb20+JzsNCj4+Pj4+PidJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbTxtYWlsdG86 SWRhbi5LYXNwaXRAZWNpdGVsZS5jb20+JzsNCj4+Pj4+PidNaXNoYWVsLldleGxlckBlY2l0ZWxl LmNvbTxtYWlsdG86TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb20+JzsNCj4+Pj4+PidSb3RlbS5D b2hlbkBlY2l0ZWxlLmNvbTxtYWlsdG86Um90ZW0uQ29oZW5AZWNpdGVsZS5jb20+Jw0KPj4+Pj4+ U3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBz b2x1dGlvbj8NCj4+Pj4+Pg0KPj4+Pj4+SSBiZWxpZXZlIHRoZSBpbml0aWFsIHF1ZXN0aW9uIHdh cyBpbiByZWdhcmQgdG8gdGhlIENXIG1ldGhvZC4gIEFyZQ0KPj4+Pj4+eW91IHNheWluZyB0aGF0 IHlvdSBubyBsb25nZXIgYXJlIGludGVyZXN0ZWQgaW4gdGhhdCBtZXRob2QgaW4NCj4+Pj4+PnBy ZWZlcmVuY2Ugb2YgdGhlIGR1YWwgdmxhbiBtZXRob2Q/DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+ DQo+Pj4+Pj5MdWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdA aHVhd2VpLmNvbT4+IHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PkFncmVlIHdpdGggV2lt LiBWTEFOIGFwcHJvYWNoIGlzIHRoZSBiZXN0IHNvbHV0aW9uIGZvciBFLVRyZWUuDQo+Pj4+Pj4N Cj4+Pj4+Pkx1Y3kNCj4+Pj4+Pg0KPj4+Pj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ Pj4+PkZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0 Zi5vcmc+DQo+Pj4+Pj5bbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBu LWJvdW5jZXNAaWV0Zi5vcmc+XSBPbg0KPj4+Pj4+QmVoYWxmIE9mIEhlbmRlcmlja3gsIFdpbSAo V2ltKQ0KPj4+Pj4+U2VudDogVGh1cnNkYXksIEFwcmlsIDEyLCAyMDEyIDI6MDMgQU0NCj4+Pj4+ PlRvOiAnZ2lsZXMuaGVyb25AZ21haWwuY29tPG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+ JzsNCj4+Pj4+PidzaW1vbi5kZWxvcmRAZ21haWwuY29tPG1haWx0bzpzaW1vbi5kZWxvcmRAZ21h aWwuY29tPic7DQo+Pj4+Pj4nQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRv OkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUNCj4+Pj4+Pi4NCj4+Pj4+PmMNCj4+Pj4+Pm9t PicNCj4+Pj4+PkNjOiAnbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPic7DQo+ Pj4+Pj4nVmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbTxtYWlsdG86VmxhZGltaXIuS2xlaW5l ckBlY2l0ZWxlLmNvbT4nOw0KPj4+Pj4+J0FuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPG1haWx0 bzpBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbT4nOw0KPj4+Pj4+J0lkYW4uS2FzcGl0QGVjaXRl bGUuY29tPG1haWx0bzpJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbT4nOw0KPj4+Pj4+J01pc2hhZWwu V2V4bGVyQGVjaXRlbGUuY29tPG1haWx0bzpNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT4nOw0K Pj4+Pj4+J1JvdGVtLkNvaGVuQGVjaXRlbGUuY29tPG1haWx0bzpSb3RlbS5Db2hlbkBlY2l0ZWxl LmNvbT4nDQo+Pj4+Pj5TdWJqZWN0OiBSZTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0 byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+Pj4+DQo+Pj4+Pj5UaGUgdmxhbiBhcHByb2FjaCBp cyBzdXBlcmlvciBhcyBpdCBhbHNvIHdvcmtzIGZvciBldGggb25seSBuZXR3b3JrcywNCj4+Pj4+ PmV0Yy4gT24gdG9wIHNvbWUgdmVuZG9ycyBpbmRpY2F0ZSBodyBpc3N1ZXMgd2l0aCB0aGUgY3cg YXBwcm9hY2guIEFzDQo+Pj4+Pj5zdWNoIHdlIGhhdmUgZHJvcHBlZCBtb3JlIG9yIGxlc3MgdGhl IGN3IGFwcHJvYWNoLg0KPj4+Pj4+DQo+Pj4+Pj5DaGVlcnMsDQo+Pj4+Pj5XaW0NCj4+Pj4+Pl9f X19fX19fX19fX19fX19fDQo+Pj4+Pj5zZW50IGZyb20gYmxhY2tiZXJyeQ0KPj4+Pj4+DQo+Pj4+ Pj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+Pj4+Pj5Gcm9tOiBHaWxlcyBIZXJvbg0K Pj4+Pj4+W21haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb208bWFpbHRvOmdpbGVzLmhlcm9uQGdt YWlsLmNvbT5dDQo+Pj4+Pj5TZW50OiBUaHVyc2RheSwgQXByaWwgMTIsIDIwMTIgMDg6MjIgQU0N Cj4+Pj4+PlRvOiBTaW1vbiBEZWxvcmQNCj4+Pj4+PjxzaW1vbi5kZWxvcmRAZ21haWwuY29tPG1h aWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPj47IEFsZXhhbmRlcg0KPj4+Pj4+VmFpbnNodGVp bg0KPj4+Pj4+PEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5k ZXIuVmFpbnNodGVpbkBlY2l0ZWxlDQo+Pj4+Pj4uY29tPj4NCj4+Pj4+PkNjOiBsMnZwbkBpZXRm Lm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+DQo+Pj4+Pj48bDJ2cG5AaWV0Zi5vcmc8bWFpbHRv OmwydnBuQGlldGYub3JnPj47IFZsYWRpbWlyIEtsZWluZXINCj4+Pj4+PjxWbGFkaW1pci5LbGVp bmVyQGVjaXRlbGUuY29tPG1haWx0bzpWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPj47DQo+ Pj4+Pj5BbmRyZXcgU2VyZ2Vldg0KPj4+Pj4+PEFuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPG1h aWx0bzpBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbT4+OyBJZGFuDQo+Pj4+Pj5LYXNwaXQgPElk YW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0bzpJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbT4+Ow0K Pj4+Pj4+TWlzaGFlbCBXZXhsZXINCj4+Pj4+PjxNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbTxt YWlsdG86TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb20+PjsNCj4+Pj4+PlJvdGVtIENvaGVuIDxS b3RlbS5Db2hlbkBlY2l0ZWxlLmNvbTxtYWlsdG86Um90ZW0uQ29oZW5AZWNpdGVsZS5jb20+Pg0K Pj4+Pj4+U3ViamVjdDogUmU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUt VHJlZSBzb2x1dGlvbj8NCj4+Pj4+Pg0KPj4+Pj4+U29ycnkgLSB0aGUgImFub255bW91cyBwcmVz ZW50YXRpb24iIHdhcyBtaW5lLiAgSSBzaG91bGQgcG9zc2libHkNCj4+Pj4+PmhhdmUgcHV0IGlu IGEgdGhpcmQgY29sdW1uIG9uIHRoZSBDVyBhcHByb2FjaC4gIEFuZCBob3BlZnVsbHkgdGhlDQo+ Pj4+Pj5taW51dGVzIHdpbGwgYmUgcG9zdGVkIHNvb24uDQo+Pj4+Pj4NCj4+Pj4+PldlIGhhZCB2 YXJpb3VzIGRpc2N1c3Npb25zLCBhcyBTaW1vbiBzdGF0ZWQsIGFuZCBjb25zZW5zdXMgc2VlbWVk IHRvDQo+Pj4+Pj5iZSBmb3JtaW5nIGFyb3VuZCB0aGUgdHdvIGFsdGVybmF0aXZlcyBvZiB0d28g UFdFcyBvciB0d28gVkxBTnMuICBJDQo+Pj4+Pj5iZWxpZXZlIHRocmVlIG9mIHRoZSBhdXRob3Jz IG9mIHRoZSBDVyBhcHByb2FjaCBhcmUgYWxzbyBhdXRob3JzIG9mDQo+Pj4+Pj50aGUgdHdvIFZM QU4gYXBwcm9hY2ggYW5kIG9uZSBpcyBhbHNvIGFuIGF1dGhvciBvZiB0aGUgdHdvIFBXRQ0KPj4+ Pj4+YXBwcm9hY2guIFNvIHBlcmhhcHMgaXQncyBiZXN0IHRvIGxldCB0aG9zZSBmb3VyIGluZGl2 aWR1YWxzIHNheQ0KPj4+Pj4+d2hpY2ggYXBwcm9hY2ggdGhleSBwcmVmZXIgYW5kIHdoeT8NCj4+ Pj4+Pg0KPj4+Pj4+R2lsZXMNCj4+Pj4+Pg0KPj4+Pj4+T24gMTAvMDQvMjAxMiAwMDo0NSwgIlNp bW9uIERlbG9yZCINCj4+Pj4+PjxzaW1vbi5kZWxvcmRAZ21haWwuY29tPG1haWx0bzpzaW1vbi5k ZWxvcmRAZ21haWwuY29tPj4gd3JvdGU6DQo+Pj4+Pj4NCj4+Pj4+Pj4gSGkgQWxleGFuZGVyLA0K Pj4+Pj4+Pg0KPj4+Pj4+PiBZb3UgYXJlIHJpZ2h0LCBubyBkaXNjdXNzaW9uIG9uIHRoZSBXRyBt YWlsaW5nIGxpc3QgcmVjZW50bHksIGJ1dA0KPj4+Pj4+PiB0aGVyZSBoYXZlIGJlZW4gc3Vic3Rh bnRpYWwgZGlzY3Vzc2lvbnMgYW1vbmcgdGhlIGF1dGhvcnMgb2YNCj4+Pj4+Pj4gdmFyaW91cyBz b2x1dGlvbiBkcmFmdHMgb2ZmIHRoZSBtYWlsaW5nIGxpc3QuIEFzIGZhciBhcyBJIGtub3csIG5v DQo+Pj4+Pj4+IGNvbnNlbnN1cyB5ZXQgYmVmb3JlIGlldGY4Mywgbm90IHN1cmUgdGhlIHByb2dy ZXNzIGluIHRoZSBQYXJpcyBXRw0KPj4+Pj4+PiBtZWV0aW5nLiBJIHRoaW5rIHRoZSBDVyBhcHBy b2FjaCBoYXMgbm90IGJlZW4gcmVqZWN0ZWQgYnkgdGhlIFdHDQo+Pj4+Pj4+IHlldCwgb3IgdGhl IFdHIGhhcyBub3QgeWV0IGRlY2lkZWQgb24gd2hpY2ggb25lIHRvIGFkb3B0Lg0KPj4+Pj4+Pg0K Pj4+Pj4+PiBTaW1vbg0KPj4+Pj4+Pg0KPj4+Pj4+PiAyMDEyLzQvOCBBbGV4YW5kZXIgVmFpbnNo dGVpbg0KPj4+Pj4+PiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFs ZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlDQo+Pj4+Pj4+IGxlLmNvbT4+DQo+Pj4+Pj4+DQo+Pj4+ Pj4+PiAgSGkgYWxsLA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFVuZm9ydHVuYXRlbHkgSSBoYXZlIG5v dCBiZWVuIGFibGUgdG8gYXR0ZW5kIHRoZSBQYXJpcyBJRVRGLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ IEhvd2V2ZXIsIGxvb2tpbmcgdXAgdGhlIEwyVlBOIHByb2NlZWRpbmdzLCBJJ3ZlIGZvdW5kIGEg c2hvcnQNCj4+Pj4+Pj4+IGFub255bW91cyBwcmVzZW50YXRpb24gY2FsbGVkICJFLVRyZWUgVXBk YXRlIiAgKA0KPj4+Pj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84My9zbGlk ZXMvc2xpZGVzLTgzLWwydnBuLTEucHB0eCkuDQo+Pj4+Pj4+PiBUaGlzIHByZXNlbnRhdGlvbiBk aXNjdXNzZXMgdGhlIGRpZmZlcmVuY2VzIG9mIHRoZSBFLVRyZWUNCj4+Pj4+Pj4+IGFwcHJvYWNo ZXMgYmFzZWQgb24gZGVkaWNhdGVkIFZMQU5zIChhcyBpbg0KPj4+Pj4+Pj4gaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jYW8tbDJ2cG4tdnBscy1ldHJlZS8/aW5jbHVkDQo+ Pj4+Pj4+PiBlX3QNCj4+Pj4+Pj4+IGV4dD0xKSBhbmQgbXVsdGlwbGUgUFdzIGJldHdlZW4gdGhl IFBFcyAoYXMgaW4NCj4+Pj4+Pj4+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtcmFtLWwydnBuLWV0cmVlLW11bHRpcGxlLXB3Lw0KPj4+Pj4+Pj4gP2luDQo+Pj4+Pj4+PiBj bHVkZV90ZQ0KPj4+Pj4+Pj4geHQ9MSkNCj4+Pj4+Pj4+IGFuZCBjb21wbGV0ZWx5IGlnbm9yZXMg dGhlIHNvbHV0aW9uIGJhc2VkIG9uIHVzYWdlIG9mIHRoZSBDVyBpbg0KPj4+Pj4+Pj4gdGhlIFBX cyBjb25uZWN0aW5nIHRoZSBQRXMgKGFzIGluDQo+Pj4+Pj4+PiBodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWtleS1sMnZwbi12cGxzLWV0cmVlLz9pbmNsdWQNCj4+Pj4+Pj4+ IGVfdA0KPj4+Pj4+Pj4gZXh0PTENCj4+Pj4+Pj4+ICkuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4+DQo+Pj4+Pj4+PiBUaGUgTWludXRlcyBvZiB0aGUgUGFyaXMgTDJWUE4gc2Vzc2lvbiBh cmUgbm90IHlldCBhdmFpbGFibGUsIGJ1dA0KPj4+Pj4+Pj4gSSB3b25kZXIgd2hldGhlciB0aGUg V0cgaGFzIHRha2VuIGEgZGVjaXNpb24gdG8gcmVqZWN0IHRoZQ0KPj4+Pj4+Pj4gYXBwcm9hY2gg YmFzZWQgb24gdGhlIENXIHVzYWdlPyBJIGRvIG5vdCByZW1lbWJlciBhbnkgcmVjZW50DQo+Pj4+ Pj4+PiBkaXNjdXNzaW9uIG9mIHRoaXMgdG9waWMgb24gdGhlIFdHIG1haWxpbmcgbGlzdC4NCj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFJlZ2FyZHMsIGFuZCBsb3RzIG9m IHRoYW5rcyBpbiBhZHZhbmNlLA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFNhc2hhDQo+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFRoaXMgZS1t YWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQNCj4+Pj4+ Pj4+IGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2gg bWF5IGJlDQo+Pj4+Pj4+PiBwcm9wcmlldGFyeSB0byBFQ0kNCj4+Pj4+Pg0KPj4+Pj4+Pj4gVGVs ZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBs ZWFzZQ0KPj4+Pj4+Pj4gaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhl biBkZWxldGUgdGhlIG9yaWdpbmFsDQo+Pj4+Pj4+PiBhbmQgYWxsIGNvcGllcyB0aGVyZW9mLg0K Pj4+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj5U aGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdh cm5lciBDYWJsZQ0KPj4+Pj4+cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZp bGVnZWQsIGNvbmZpZGVudGlhbCwgb3INCj4+Pj4+PnN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9u Z2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMNCj4+Pj4+PmludGVuZGVk IHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2gg aXQNCj4+Pj4+PmlzDQo+Pj4+Pj5hZGRyZXNzZWQuDQo+Pj4+Pj5JZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieQ0KPj4+Pj4+ bm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBv ciBhY3Rpb24NCj4+Pj4+PnRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQg YXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwNCj4+Pj4+PmlzIHN0cmljdGx5IHByb2hpYml0ZWQg YW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcw0KPj4+Pj4+RS1t YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBl cm1hbmVudGx5DQo+Pj4+Pj5kZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlz IEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0KPj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+VGhp cyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJu ZXIgQ2FibGUNCj4+Pj4+cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVn ZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdA0KPj4+Pj50byBjb3B5cmlnaHQgYmVsb25naW5n IHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZA0KPj4+Pj5zb2xl bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlz DQo+Pj4+PmFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBv ZiB0aGlzIEUtbWFpbCwgeW91DQo+Pj4+PmFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlz c2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvcg0KPj4+Pj5hY3Rpb24gdGFrZW4g aW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzDQo+ Pj4+PkUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElm IHlvdSBoYXZlDQo+Pj4+PnJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkNCj4+Pj4+YW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0 aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZA0KPj4+Pj5hbnkNCj4+ Pj4+cHJpbnRvdXQuDQo+Pj4+DQo+Pj4+DQo+Pj4+IFRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlDQo+Pj4+cHJvcHJpZXRh cnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3Vi amVjdA0KPj4+PnRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRo aXMgRS1tYWlsIGlzIGludGVuZGVkDQo+Pj4+c29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRp dmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcw0KPj4+PmFkZHJlc3NlZC4NCj4+Pj5JZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJl IGhlcmVieQ0KPj4+Pm5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlv biwgY29weWluZywgb3IgYWN0aW9uIHRha2VuDQo+Pj4+aW4gcmVsYXRpb24gdG8gdGhlIGNvbnRl bnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcw0KPj4+PnN0cmljdGx5IHBy b2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcw0K Pj4+PkUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGFuZCBwZXJtYW5lbnRseQ0KPj4+PmRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9m IHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo+Pj4+IFRoaXMgZS1tYWlsIG1lc3NhZ2Ug aXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMNCj4+Pj5pbmZv cm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFy eSB0byBFQ0kNCj4+Pj5UZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlz c2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybQ0KPj4+PnVzIGJ5IGUtbWFpbCwgcGhvbmUgb3Ig ZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbGwgY29waWVzDQo+Pj4+dGhl cmVvZi4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+Pj4+DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4+IEwydnBuIG1haWxpbmcgbGlzdA0KPj4+PiBMMnZwbkBpZXRmLm9yZzxtYWls dG86TDJ2cG5AaWV0Zi5vcmc+DQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbDJ2cG4NCj4+Pj4NCj4+Pj4NCj4+Pj4gRW5kIG9mIEwydnBuIERpZ2VzdCwgVm9sIDk1 LCBJc3N1ZSAyNQ0KPj4+PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPj4N Cj4+DQo+PlRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWlu IFRpbWUgV2FybmVyIENhYmxlDQo+PnByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBw cml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8NCj4+Y29weXJpZ2h0IGJlbG9u Z2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5 DQo+PmZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBp cyBhZGRyZXNzZWQuIElmIHlvdQ0KPj5hcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2Yg dGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkDQo+PnRoYXQgYW55IGRpc3NlbWlu YXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluDQo+PnJlbGF0 aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMg c3RyaWN0bHkNCj4+cHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIEUtbWFpbCBpbg0KPj5lcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlDQo+Pm9yaWdpbmFsIGFuZCBh bnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0KPg0KPg0KPlRoaXMgRS1t YWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENh YmxlDQo+cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZp ZGVudGlhbCwgb3Igc3ViamVjdCB0bw0KPmNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJu ZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseQ0KPmZvciB0aGUgdXNlIG9m IHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlv dQ0KPmFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFy ZSBoZXJlYnkgbm90aWZpZWQNCj50aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24s IGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbg0KPnJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBv ZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkNCj5wcm9oaWJpdGVk IGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGlu DQo+ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFu ZW50bHkgZGVsZXRlIHRoZQ0KPm9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBh bmQgYW55IHByaW50b3V0Lg0KDQoNClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9u LCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJp Z2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5k ZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGlj aCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQg b2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWlu YXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9u IHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0 aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K From lucy.yong@huawei.com Thu Apr 26 08:55:52 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F8021E810C for ; Thu, 26 Apr 2012 08:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HS_INDEX_PARAM=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 JlPz+bA279xL for ; Thu, 26 Apr 2012 08:55:50 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id F35A521E8106 for ; Thu, 26 Apr 2012 08:55:45 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFH20080; Thu, 26 Apr 2012 11:55:44 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 26 Apr 2012 08:53:59 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Thu, 26 Apr 2012 08:53:54 -0700 From: Lucy yong To: David Allan I , "Rogers, Josh" , "Fedyk, Donald (Don)" , Daniel Cohn , "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0jLD6Ce/4Txq0Y50G6N17p5MncdwAA6bjAABFMSgAAHFv/gAAIvvcw Date: Thu, 26 Apr 2012 15:53:54 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264C406@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D3264C202@dfweml505-mbx> <60C093A41B5E45409A19D42CF7786DFD52324EF1FB@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD52324EF1FB@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: I83/ PjLN WJhS XSO2 gM1g hqqt lcMt nvie qWiW uspv v4c2 xfZ8 xto7 yVVS 4mxx 6B9K; 5; ZABhAG4AaQBlAGwAYwBAAG8AcgBjAGsAaQB0AC4AYwBvAG0AOwBkAGEAdgBpAGQALgBpAC4AYQBsAGwAYQBuAEAAZQByAGkAYwBzAHMAbwBuAC4AYwBvAG0AOwBkAG8AbgBhAGwAZAAuAGYAZQBkAHkAawBAAGEAbABjAGEAdABlAGwALQBsAHUAYwBlAG4AdAAuAGMAbwBtADsAagBvAHMAaAAuAHIAbwBnAGUAcgBzAEAAdAB3AGMAYQBiAGwAZQAuAGMAbwBtADsAbAAyAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {746ACE12-7A2F-4379-A3B6-63D488CAFC50}; bAB1AGMAeQAuAHkAbwBuAGcAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Thu, 26 Apr 2012 15:53:44 GMT; UgBFADoAIABUAGgAZQAgAHMAdABhAHQAdQBzACAAbwBmACAAdABoAGUAIABhAHAAcAByAG8AYQBjAGgAZQBzACAAdABvACAAdABoAGUAIABFAC0AVAByAGUAZQAgAHMAbwBsAHUAdABpAG8AbgA/AA== x-cr-puzzleid: {746ACE12-7A2F-4379-A3B6-63D488CAFC50} x-originating-ip: [10.47.140.80] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@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, 26 Apr 2012 15:55:52 -0000 Dave, I think that option a and b you give are different from option A and B Josh= states. Your option a and b are possible. Option A in Josh's mail adds two= S-tags on the frame, IEEE does not support this implementation. So it is b= etter for us to be away from it since we have option B. Regards, Lucy -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com]=20 Sent: Thursday, April 26, 2012 7:55 AM To: Rogers, Josh; Lucy yong; Fedyk, Donald (Don); Daniel Cohn; l2vpn@ietf.o= rg Subject: RE: The status of the approaches to the E-Tree solution? Both scenarios are possible according to my read of 802.1.ad. For 'a', a C-tagged frame simply has the s-tag inserted.... For 'b' a C-component strips the C-tag before presenting the frame on a cus= tomer network port that is unique to the S-tag (e.g. internal to a PB.)... Dave -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Wednesday, April 25, 2012 7:23 PM To: Lucy yong; Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.= org Subject: Re: The status of the approaches to the E-Tree solution? [[LY]] This is not my understanding. Here we talk about incoming frame alr= eady has c-tag and s-tag, which is not UNI case. In addition, it seems that= Daniel say that only option A works. That=B9s funny, I thought someone said that only option B would work. I th= ink technically either is possible, but I am unclear which the 2VLAN draft = would advise (or if it even does) -Josh On 4/25/12 5:22 PM, "Lucy yong" wrote: >Hi Josh, > >Please see inline. > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >Of Rogers, Josh >Sent: Wednesday, April 25, 2012 4:42 PM >To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >Dave/Daniel/Lucy/Others Debating how many tags necessary when S-Tag >preservation is desired, > > >I think you all may have gone off on a tangent here. The original >discussion was about how to deal with the situation where the S-Tag is >preserved at a handoff (either an ENNI, or Service Multiplexed UNI) >[[LY]] in MEF, S-Tag applies to ENNI only, not UNI. An UNI can support >multiplexed services, i.e. terminate many EVCs. In this case, each EVC >associates with one or multiple c-tags. EVC has a service attribute for >listing associated c-tags. > >I believe there were two suggestions, one was that you push on a 'ETREE' >tag (one of two values, for either a frame sourced from a root AC or >another for a frame from a leaf AC), and the second solution was to 'map'. >[[LY]] This is not my understanding. Here we talk about incoming frame >already has c-tag and s-tag, which is not UNI case. In addition, it >seems that Daniel say that only option A works. > > >Imagine the following topology: > >+-----+ +-----+ +-----+ +-----+ >| CE1 |--| PE1 |--| PE2 |--| CE2 | >+-----+ +-----+ +-----+ +-----+ > | | >+-----+ +-----+ +-----+ +-----+ >| CE3 |--| PE3 |--| PE4 |--| CE4 | >+-----+ +-----+ +-----+ +-----+ > >Where: > >Site Type VLAN >CE1 Root X >CE2 Leaf 2 >CE3 Leaf 3 >CE4 Leaf 3 > > >So, there are a lot of SP's who are keen on the way many services can >be handed to a customer on a single UNI, but coordinating a single VLAN >per service, with the customer (MEF used to call this EVPL when it was >many point to point services terminating on a single UNI). So, imagine >that we have two ETREE instances, and an internet service all >terminating on a single UNI connecting to CE1. We have negotiated VLAN >ID's with the customer, and they are expecting to reach CE2 using VLAN >2, CE3 and CE4 using VLAN 3, and Internet service on VLAN 10. As a >frame from CE1 comes into PE1 destined for CE2 (so the customer has >tagged it with VID 2), using the 2VLAN method, since this is coming >from a root site, do we > >a) place the Root S-Tag in front of VID 2, then ship it across, and pop >off the ETREE S-Tag (some SP's wish to Pop the original customer tag >VID 2 as well) > >-or- > >b) swap VID2 for the ETREE Root S-Tag, send the frame to PE2 where it >will remove the S-Tag (and either push VID2 back on, or leave it off >depending on SP preference) > >The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf) [[LY]] Since dual VLAN solution tries to inline with IEEE >solution, if this is the use case, we suggests to go with option B, not >A. So please don't discuss option A more. > >Regards, >Lucy > > >Hope that clears more than it confuses, Josh > > > >On 4/25/12 4:22 PM, "Fedyk, Donald (Don)" > wrote: > >>Hi Dave >> >>Yes the only point I would add is Dual VLAN means One VID for Root and >>one VID for Leaf. Not two TAGs at a time on the frame but two >>allocated for the service. >> >>The confusing part is no doubt that Dual PWE/Dual VLAN comparison >>talks about Encapsulation Overhead as a VLAN Tag. While that is true >>in a PWE sense it is still a single VLAN Tag at a time in a Ethernet E-tr= ee sense. >> The compelling driver for Dual VLAN is having a Etree service that >>works in many environments and the DUAL VLAN (really dual VLAN >>interface on a >>VSI) uses the same mechanism (one VID for root and one VID for Leaf at >>a >>time) as specified in the IEEE. In a pure Ethernet bridging world the >>VLAN TAGs for Etree are not typically an overhead since translation is >>used. >> >>Don >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of David Allan I >>Sent: Wednesday, April 25, 2012 5:05 PM >>To: Daniel Cohn; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>OK I feel like I am digressing a fair distance from the actual >>problem.... But here goes: >> >>So the scenarios center around "how ETREE do you want to be?".... >> >>If the ACs are root/leaf, then if they are P2P (single ethernet end >>station attached to each AC) this is moot. ETREE semantics are >>enforced by the 2VID domain in the center of the example. If you >>assumed nodes A&B in the example were L2VPN PEs, the tagging and the >>PW tag imposition all happened at the same point in the network. >> >>If they are not simple P2P all the way to end systems and the >>objective is to avoid bridging between leaf "sites" but allowing >>intra-leaf-site connectivity then the leaves can be LANs but the root >>is not, such that I cannot bridge through the root. But all hosts at a >>given leaf site can see each other. So root Ethernet end systems are >>directly attached or two VIDs are used in the root site. >> >>If the objective is that there are multiple ethernet attached end >>stations at both the leaf and root sites, and the objective is to >>enforce >>L2 isolation everywhere then I need two VIDs extended to the end >>system attachement point in the local LANs by whatever means.... >> >>And I do not see adding VLANs in any particular spot, simply selection >>of the VID and associated semantics where VIDs are translated. The >>actual point of S-tag imposition could be a PE, or cloud be a NID/CLE >>on the customer prem (more likely scenario here to extend OAM demarc >>to the prem), or some switch in a RAN downstream of the MPLS PE... >>blah blah blah. And if ETREE is extended into a customer site LAN and >>outside of the provider domain, then two C-tags would have to be used >>that mapped to S-tags at the PBN boundary... >> >>Make sense? >>Dave >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 25, 2012 4:39 PM >>To: David Allan I; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Dave, but the ACs are root/leaf (that's what the whole vpls etree is >>about - see the reqt draft), so per the 2vlan draft the root/leaf vlan >>must be added. >> >>Thumb typed - please be tolerant >> >>David Allan I wrote: >> >>HI Daniel: >> >>In the example provided, >> >>"ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" >> A B >> >>the service is not ETREE in the domains of the ingress and egress VID. >>It is ELAN. SO there is no root/leaf attribute to shovel around. It >>would require two VIDs in each domain if the ETREE semantics were to >>be telescoped E2E. >> >>Otherwise it is a provisioning of the VID translation tables at the >>intermediate nodes (A&B that I've added to the picture) that would >>determine the VID values used in each domain. Or in the example above, >>what the ingress, Etree and egress VID values were. >> >>Cheers >>Dave >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 3:46 PM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>And to this I asked how this mapping works - how does the egress pe >>recover the ingress vid when it gets the frame tagged with only the >>root/leaf vid? How can you convey the ingress vid plus the root/leaf >>attribute in the same number of bits? >>What am I missing? >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>David Allen already explained the solution. >> >>From David: >>ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. >> >>Ingress VID does not have to equal Egress VID but regardless there is >>only ever one VID on a frame at a time. >> >>-end >> >>This works when customer makes ingress VLAN ID not equal to or equal >>to egress VLAN ID. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 11:39 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Lucy, >> >>The scenario we are discussing is not the E-Tree E-NNI, but a general >>scenario where frames arriving at the root or leaf AC are already >>double tagged. In this case, the dual vlan solution cannot preserve >>the vlans without adding a third one, can it? >> >>Maybe Shahram can add details on the scenario he had in mind >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has S-VLAN preservation attribute for ENNI only because there is >>no s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, >>S-VALN preservation attribute is used. It applies to E-Tree as well. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Tuesday, April 24, 2012 2:12 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Lucy, >> >>even if the current MEF framework doesn't require s-vlan preservation, >>I believe it's to the industry's benefit to adopt a solution that is >>not constrained to a specific enni model that, like all things >>networking, is likely to evolve. Especially when such a solution is avail= able. >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has worked in ENNI interface for a long time with many service >>providers' inputs. It had a fair reason to assume S-VLAN over ENNI by >>then. It may open B-VLAN for the future. It is better for us not to >>discuss a future framework here, because it will lead us to nowhere. >>Here, we want to extend VPLS in supporting E-Tree. >> >>Best Regards, >>Lucy >> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Sunday, April 22, 2012 7:34 AM >>To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Shahram and all, >> >>This question already came up in our discussions - is it safe to >>assume that the VLAN tags at the E-NNI will always be according to the >>current MEF model? Or should we try to be as transparent as possible >>to user VLAN encapsulation at the E-NNI, to accommodate future frameworks= ? >>I believe that any approach that looks at user payload (in this case >>VLAN >>tag) to signal VPLS information (in this case root/leaf origin) is >>necessarily tied to specific assumptions on user payload encapsulation >>(in this case, that S-VLAN tag is "available" to encode root/leaf). I >>don't think this is a future-proof assumption, it's very likely that >>other network models will come up that require S-VLAN preservation, >>which in the 2-VLAN approach would necessitate adding a third VLAN-ID. >> >>Daniel >> >>From: Shahram Davari > >>To: Lizhong Jin >, >>"l2vpn@ietf.org" >>>, >>"Alexander.Vainshtein@ecitele.com>com >>> >>" >>>com >>> >>> >>Cc: "yuqun.cao@gmail.com" >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, >> >>I also have a question regarding 2-VLAN. What if the customer traffic >>already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? >> >>Thx >>Shahram >> >>From: l2vpn-bounces@ietf.org >>[mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin >>Sent: Friday, April 20, 2012 9:38 AM >>To: l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com>om> >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, all, >>The difference between 2-VLAN and CW approach is who will provide the >>R/L information, customer payload or PW? The customer payload will be >>always modified to carry R/L information in 2-VLAN approach, while PW >>with CW will carry R/L information for CW approach. >>I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is >>accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is >>used to access H-VPLS, how could the PE on VPWS side adds VLAN to >>indicate R/L information? >> >>Thanks >>Lizhong >> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Thu, 19 Apr 2012 04:38:36 +0000 >>> From: Alexander Vainshtein >>> >> com>> >>> To: "Rogers, Josh" >>>>, Lucy yong >>> >, Daniel >>>Cohn >, Sam Cao >>> > >>> Cc: "l2vpn@ietf.org" >>> > >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> Message-ID: >>> >>> >> lt >>> o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> >>> Content-Type: text/plain; charset=3D"us-ascii" >>> >>> Hi all, >>> I fully understand that that what I am going to say is not very >>>popular, but: >>> >>> IMO one of the advantages of the CW-based solution is that it is >>>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery >>>of BUN traffic. >>> >>> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>>and, in a more generic way, localization of effects of changes in the >>>PE configuration. >>> >>> In particular, adding a Leaf AC to a PE that previously has been >>>only supporting Root ACs (or vice versa), removal of the last Leaf or >>>last Root AC from a PE that previously has been supporting a mix etc. >>>affect only the PE where this operation happens and not the rest of the = PEs. >>> >>> As for the need for HW changes that have been mentioned as a main >>>disadvantage of the CW-based approach - I believe it strongly depends >>>on specific implementations. And some changes in the forwarding >>>process are required in any solution. >>> >>> My 2c, >>> Sasha >>> >>> >>> >>> ________________________________________ >>> From: l2vpn-bounces@ietf.org >>> [l2vpn-bounces@ietf.org] on behalf of >>> Rogers, Josh >>> [josh.rogers@twcable.com] >>> Sent: Wednesday, April 18, 2012 9:57 PM >>> To: Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: Re: The status of the approaches to the E-Tree solution? >>> >>> Again, the P2MP situation throws me. Is this something that is used >>> commonly? >>> >>> I'm under the impression that adding P2MP to any model results in a >>> more complex model. Wether outside s-tag is used to differentiate, >>> or dedicated pw's are used for the same purpose, it seems both >>> become more complex. >>> >>> Gile's comparison slide still concisely captures the differences >>>between these methods, in my opinion. I haven't seen any new ideas >>>or thoughts brought to the group in the past week or two on the subject= . >>> I would hate for both proposed methods to die on the vine because we >>>couldn't decide between two methods that have nothing inherently >>>wrong with either. >>> >>> -Josh >>> >>> >>> On 4/18/12 1:53 PM, "Lucy yong" >>>> wrote: >>> >>>>Send this again. >>>> >>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and >>>>unknown unicast traffic, and some P2MP PWs for multicast traffic. It >>>>may double all of them. >>>> >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn >>>>[mailto:DanielC@orckit.com] >>>>Sent: Wednesday, April 18, 2012 1:42 PM >>>>To: Lucy yong; Rogers, Josh; Sam Cao >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>I think the first option its the natural way to go. How is the >>>>processing in this case more complex? >>>> >>>>Thumb typed - please be tolerant >>>> >>>>Lucy yong > wrote: >>>> >>>> >>>> >>>>Snipped.. >>>> >>>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only >>>>P2MP PW (for traffic coming from a leaf AC), or onto a Root/Leaf >>>>P2MP PW (for traffic coming from a root AC) [[LY]] Not that simple. >>>>You construct either two P2MP PWs to all other PEs and let egress PE >>>>performing filtering, or construct one P2MP PW to leaf-only PEs and >>>>two P2MP PWs to root and leaf PEs and let ingress PE perform >>>>forwarding and filtering. Both make node process complex. >>>> >>>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW >>>>for delivering the frames to remote PEs. We should utilize them with >>>>the minimized changes. Dual VLAN solution is simpler than Dual PW. >>>> >>>>Regards, >>>>Lucy >>>> >>>> >>>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>>>haven't had any first hand experience with P2MP PW's, however, so >>>>don't feel terribly strong about this objection. Is this a real >>>>problem for others (now or in the future), or is this objection in >>>>the weeds? >>>> >>>>I'm not sure the 'additional complexity' is notable, or even relevant. >>>>I encourage others to speak up if they disagree, as P2MP PW is only >>>>conceptual to me, and I am unfamiliar with real-life use cases for it. >>>> >>>>Thanks, >>>>Josh >>>> >>>> >>>> >>>>On 4/18/12 10:30 AM, "Lucy yong" >>>>> wrote: >>>> >>>>>Please see inline. >>>>> >>>>>-----Original Message----- >>>>>From: Sam Cao >>>>>[mailto:yuqun.cao@gmail.com] >>>>>Sent: Tuesday, April 17, 2012 7:14 AM >>>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>>>(Wim)'; giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>>>after improving Dual-PW approach. If consider P2MP, Dual-PW >>>>>approach setup 2 P2MP PWs if need. There is no difference between >>>>>P2MP or normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP= PW? >>>>> >>>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>>>PE have both root and leaf AC and some only have leaf ACs)? >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Yuqun (Sam) Cao >>>>>E-mail: Yuqun.cao@gmail.com >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn >>>>>[mailto:DanielC@orckit.com] >>>>>Sent: Tuesday, April 17, 2012 4:56 PM >>>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com>; Sam Cao >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Adding Sam (as l2vpn@ is holding messages) >>>>> >>>>>DC >>>>> >>>>>-----Original Message----- >>>>>From: Lucy yong >>>>>[mailto:lucy.yong@huawei.com] >>>>>Sent: Tuesday, April 17, 2012 12:39 AM >>>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>> >>>>>Snipped, >>>>> >>>>>As we discussed extensively in the list, and as reflected in giles >>>>>slide, 2 pws are only needed between pes with both root and leaf >>>>>acs, which will typically be a small minority. >>>>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>>>both approaches can benefit from it. I was off for a while and >>>>>captures some discussions now. >>>>> >>>>>Also as per giles slide, dual vlan can have scalability issues due >>>>>to additional lookup and double use of vlans in internal emulated >>>>>lan interface. Also there are potential backward compatibility >>>>>issues with silicon that doesn't support vlan mapping. >>>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. >>>>>I am not clear on all the issues. Could you be more specific? As I >>>>>mentioned in below, two PW approach makes VPLS transport >>>>>construction and packet forwarding more complex, I can see >>>>>potential backward compatibility issues with 2 PW solution. >>>>> >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Daniel >>>>> >>>>>Thumb typed - please be tolerant >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>>In my mind, the VLAN approach means dual vlan method. >>>>> >>>>>The main concern for CW approach is hardware support. >>>>> >>>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and >>>>>unknown unicast traffic, and some P2MP PWs for multicast traffic. >>>>>It may double all of them. >>>>> >>>>>E-tree is an Ethernet service and there is already VLAN based >>>>>solution in IEEE, can we just utilize it without complicating VPLS >>>>>transport construction? This also makes interworking with Eth only >>>>>network easier. >>>>> >>>>>Cheers, >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: Rogers, Josh >>>>>[mailto:josh.rogers@twcable.com] >>>>>Sent: Monday, April 16, 2012 8:35 AM >>>>>To: Lucy yong; Henderickx, Wim (Wim); >>>>>'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com' >>>>>; 'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>I believe the initial question was in regard to the CW method. Are >>>>>you saying that you no longer are interested in that method in >>>>>preference of the dual vlan method? >>>>> >>>>> >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>> >>>>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>>>> >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: l2vpn-bounces@ietf.org >>>>>[mailto:l2vpn-bounces@ietf.org] On >>>>>Behalf Of Henderickx, Wim (Wim) >>>>>Sent: Thursday, April 12, 2012 2:03 AM >>>>>To: 'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com' >>>>>; 'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>The vlan approach is superior as it also works for eth only >>>>>networks, etc. On top some vendors indicate hw issues with the cw >>>>>approach. As such we have dropped more or less the cw approach. >>>>> >>>>>Cheers, >>>>>Wim >>>>>_________________ >>>>>sent from blackberry >>>>> >>>>>----- Original Message ----- >>>>>From: Giles Heron >>>>>[mailto:giles.heron@gmail.com] >>>>>Sent: Thursday, April 12, 2012 08:22 AM >>>>>To: Simon Delord >>>>>>; Alexander >>>>>Vainshtein >>>>>>>>>le >>>>>.com>> >>>>>Cc: l2vpn@ietf.org >>>>>>; Vladimir Kleiner >>>>>> >>>>>; >>>>>Andrew Sergeev >>>>>>; >>>>>Idan Kaspit >>>>>>; >>>>>Mishael Wexler >>>>>>; >>>>>Rotem Cohen >>>>>> >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>Sorry - the "anonymous presentation" was mine. I should possibly >>>>>have put in a third column on the CW approach. And hopefully the >>>>>minutes will be posted soon. >>>>> >>>>>We had various discussions, as Simon stated, and consensus seemed >>>>>to be forming around the two alternatives of two PWEs or two VLANs. >>>>>I believe three of the authors of the CW approach are also authors >>>>>of the two VLAN approach and one is also an author of the two PWE >>>>>approach. So perhaps it's best to let those four individuals say >>>>>which approach they prefer and why? >>>>> >>>>>Giles >>>>> >>>>>On 10/04/2012 00:45, "Simon Delord" >>>>>> wrote: >>>>> >>>>>> Hi Alexander, >>>>>> >>>>>> You are right, no discussion on the WG mailing list recently, but >>>>>> there have been substantial discussions among the authors of >>>>>> various solution drafts off the mailing list. As far as I know, >>>>>> no consensus yet before ietf83, not sure the progress in the >>>>>> Paris WG meeting. I think the CW approach has not been rejected >>>>>> by the WG yet, or the WG has not yet decided on which one to adopt. >>>>>> >>>>>> Simon >>>>>> >>>>>> 2012/4/8 Alexander Vainshtein >>>>>> >>>>> te >>>>>> le.com>> >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>>>> >>>>>>> However, looking up the L2VPN proceedings, I've found a short >>>>>>> anonymous presentation called "E-Tree Update" ( >>>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>>>> This presentation discusses the differences of the E-Tree >>>>>>> approaches based on dedicated VLANs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?incl >>>>>>> ud >>>>>>> e_t >>>>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-p >>>>>>> w/ >>>>>>> ?in >>>>>>> clude_te >>>>>>> xt=3D1) >>>>>>> and completely ignores the solution based on usage of the CW in >>>>>>> the PWs connecting the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?incl >>>>>>> ud >>>>>>> e_t >>>>>>> ext=3D1 >>>>>>> ). >>>>>>> >>>>>>> >>>>>>> >>>>>>> The Minutes of the Paris L2VPN session are not yet available, >>>>>>> but I wonder whether the WG has taken a decision to reject the >>>>>>> approach based on the CW usage? I do not remember any recent >>>>>>> discussion of this topic on the WG mailing list. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, and lots of thanks in advance, >>>>>>> >>>>>>> Sasha >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This e-mail message is intended for the recipient only and >>>>>>> contains information which is CONFIDENTIAL and which may be >>>>>>> proprietary to ECI >>>>> >>>>>>> Telecom. If you have received this transmission in error, please >>>>>>> inform us by e-mail, phone or fax, and then delete the original >>>>>>> and all copies thereof. >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>This E-mail and any of its attachments may contain Time Warner >>>>>Cable proprietary information, which is privileged, confidential, >>>>>or subject to copyright belonging to Time Warner Cable. This E-mail >>>>>is intended solely for the use of the individual or entity to which >>>>>it is addressed. >>>>>If you are not the intended recipient of this E-mail, you are >>>>>hereby notified that any dissemination, distribution, copying, or >>>>>action taken in relation to the contents of and attachments to this >>>>>E-mail is strictly prohibited and may be unlawful. If you have >>>>>received this E-mail in error, please notify the sender immediately >>>>>and permanently delete the original and any copy of this E-mail and an= y printout. >>>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or >>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>intended solely for the use of the individual or entity to which it >>>>is addressed. If you are not the intended recipient of this E-mail, >>>>you are hereby notified that any dissemination, distribution, >>>>copying, or action taken in relation to the contents of and >>>>attachments to this E-mail is strictly prohibited and may be >>>>unlawful. If you have received this E-mail in error, please notify >>>>the sender immediately and permanently delete the original and any >>>>copy of this E-mail and any printout. >>> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or >>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>intended solely for the use of the individual or entity to which it is a= ddressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail >>>is strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> This e-mail message is intended for the recipient only and contains >>>information which is CONFIDENTIAL and which may be proprietary to ECI >>>Telecom. If you have received this transmission in error, please >>>inform us by e-mail, phone or fax, and then delete the original and >>>all copies thereof. >>> >>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> L2vpn mailing list >>> L2vpn@ietf.org >>> https://www.ietf.org/mailman/listinfo/l2vpn >>> >>> >>> End of L2vpn Digest, Vol 95, Issue 25 >>> *********************************** > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject >to copyright belonging to Time Warner Cable. This E-mail is intended >solely for the use of the individual or entity to which it is >addressed. If you are not the intended recipient of this E-mail, you >are hereby notified that any dissemination, distribution, copying, or >action taken in relation to the contents of and attachments to this >E-mail is strictly prohibited and may be unlawful. If you have received >this E-mail in error, please notify the sender immediately and >permanently delete the original and any copy of this E-mail and any printo= ut. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From josh.rogers@twcable.com Thu Apr 26 09:02:02 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7AE21E80B4 for ; Thu, 26 Apr 2012 09:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.677 X-Spam-Level: X-Spam-Status: No, score=0.677 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HS_INDEX_PARAM=0.001, MIME_BASE64_TEXT=1.753] 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 HwtklwE73Mc1 for ; Thu, 26 Apr 2012 09:02:00 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id AB49121E80DF for ; Thu, 26 Apr 2012 09:01:58 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,487,1330923600"; d="scan'208";a="356457635" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 26 Apr 2012 11:59:34 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Thu, 26 Apr 2012 12:01:02 -0400 From: "Rogers, Josh" To: Lucy yong , David Allan I , "Fedyk, Donald (Don)" , Daniel Cohn , "l2vpn@ietf.org" Date: Thu, 26 Apr 2012 12:00:58 -0400 Subject: Re: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0jxcb6Tv97zwm+Q6qF7xP4dBizVw== Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D3264C406@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: l2vpn@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, 26 Apr 2012 16:02:02 -0000 THVjeSwNCg0KSSdtIG5vdCBzdXJlIHRoYXQgaXMgdHJ1ZS4gIEkgdGhpbmsgeW91J3JlIGhhdmlu ZyB0aGUgc2FtZSB0cm91YmxlIEkgaGFkLA0KSSB3YXMgY29uc2lkZXJpbmcgdGhlIHRhZyB0aGUg Y3VzdG9tZXIgYXBwbGllcyB0byB0aGVpciBlZ3Jlc3MgdHJhZmZpYyBhcw0KYSAnaW5zaWRlIFMt VGFnJywgYnV0IG90aGVycyBoYXZlIHN0YXRlZCB0aGV5IHdvdWxkIGNvbnNpZGVyIHRoaXMgYQ0K J0MtVGFnJywgZXZlbiB0aG91Z2ggaXQgaXMgdXNlZCBvbiB0aGUgU1AncyBuZXR3b3JrICh0byBk aXN0aW5ndWlzaA0Kc2VydmljZSBvbiB0aGUgVU5JKSAgWW91J2xsIG5vdGUgaW4gbXkgbW9zdCBy ZWNlbnRseSBleHBsYW5hdGlvbiBvZiB0aGUNCnR3byBzY2VuYXJpb3MsIEkgaW50ZW50aW9uYWxs eSBhdm9pZGVkIHJlZmVycmluZyB0byB0aGlzIGFtYmlndW91cyB0YWcgYXMNCmVpdGhlciBhbiBT LVRhZyBvciBDLVRhZy4NCg0KRGF2ZSwgY2FuIHlvdSBjbGFyaWZ5ICdDLVRhZycgaW4geW91ciBz dGF0ZW1lbnQ/ICBXaGVuIHlvdSBzYXk6DQoNCj4gRm9yICdhJywgYSBDLXRhZ2dlZCBmcmFtZSBz aW1wbHkgaGFzIHRoZSBzLXRhZyBpbnNlcnRlZC4uLi4NCg0KRG8geW91IG1lYW4gdGhhdCB0aGUg U1AgcHVzaGVzIHRoZSBTLXRhZyBvbiBpbiBmcm9udCBvZiB0aGUgY29vcmRpbmF0ZWQNCnRhZyB0 aGUgY3VzdG9tZXIgdXNlcyB0byBlbnN1cmUgdHJhZmZpYyBlbnRlcnMgdGhlIGNvcnJlY3Qgc2Vy dmljZT8gIE9yIGRvDQp5b3UgbWVhbiBzb21ldGhpbmcgZWxzZSBlbnRpcmVseT8NCg0KV2FpdKGm IEkgdGhvdWdodCB3ZSBhZ3JlZWQgdG8gbm90IGRpc2N1c3MgdGhpcyAnQScgbWV0aG9kIGFueSBs b25nZXIsIGFzIGl0DQpsZWFkcyB0byBzb21lIGhvcnJpYmxlIGJsYWNrIGhvbGUgb2YgaW5jb25z ZXF1ZW50aWFsIHRhbmdlbnRzPw0KDQotSm9zaA0KDQoNCg0KT24gNC8yNi8xMiAxMDo1MyBBTSwg Ikx1Y3kgeW9uZyIgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPiB3cm90ZToNCg0KPkRhdmUsDQo+DQo+ SSB0aGluayB0aGF0IG9wdGlvbiBhIGFuZCBiIHlvdSBnaXZlIGFyZSBkaWZmZXJlbnQgZnJvbSBv cHRpb24gQSBhbmQgQg0KPkpvc2ggc3RhdGVzLiBZb3VyIG9wdGlvbiBhIGFuZCBiIGFyZSBwb3Nz aWJsZS4gT3B0aW9uIEEgaW4gSm9zaCdzIG1haWwNCj5hZGRzIHR3byBTLXRhZ3Mgb24gdGhlIGZy YW1lLCBJRUVFIGRvZXMgbm90IHN1cHBvcnQgdGhpcyBpbXBsZW1lbnRhdGlvbi4NCj5TbyBpdCBp cyBiZXR0ZXIgZm9yIHVzIHRvIGJlIGF3YXkgZnJvbSBpdCBzaW5jZSB3ZSBoYXZlIG9wdGlvbiBC Lg0KPg0KPlJlZ2FyZHMsDQo+THVjeQ0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ RnJvbTogRGF2aWQgQWxsYW4gSSBbbWFpbHRvOmRhdmlkLmkuYWxsYW5AZXJpY3Nzb24uY29tXQ0K PlNlbnQ6IFRodXJzZGF5LCBBcHJpbCAyNiwgMjAxMiA3OjU1IEFNDQo+VG86IFJvZ2VycywgSm9z aDsgTHVjeSB5b25nOyBGZWR5aywgRG9uYWxkIChEb24pOyBEYW5pZWwgQ29objsNCj5sMnZwbkBp ZXRmLm9yZw0KPlN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRo ZSBFLVRyZWUgc29sdXRpb24/DQo+DQo+Qm90aCBzY2VuYXJpb3MgYXJlIHBvc3NpYmxlIGFjY29y ZGluZyB0byBteSByZWFkIG9mIDgwMi4xLmFkLg0KPg0KPkZvciAnYScsIGEgQy10YWdnZWQgZnJh bWUgc2ltcGx5IGhhcyB0aGUgcy10YWcgaW5zZXJ0ZWQuLi4uDQo+DQo+Rm9yICdiJyBhIEMtY29t cG9uZW50IHN0cmlwcyB0aGUgQy10YWcgYmVmb3JlIHByZXNlbnRpbmcgdGhlIGZyYW1lIG9uIGEN Cj5jdXN0b21lciBuZXR3b3JrIHBvcnQgdGhhdCBpcyB1bmlxdWUgdG8gdGhlIFMtdGFnIChlLmcu IGludGVybmFsIHRvIGENCj5QQi4pLi4uDQo+DQo+RGF2ZQ0KPg0KPi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+RnJvbTogUm9nZXJzLCBKb3NoIFttYWlsdG86am9zaC5yb2dlcnNAdHdjYWJs ZS5jb21dDQo+U2VudDogV2VkbmVzZGF5LCBBcHJpbCAyNSwgMjAxMiA3OjIzIFBNDQo+VG86IEx1 Y3kgeW9uZzsgRmVkeWssIERvbmFsZCAoRG9uKTsgRGF2aWQgQWxsYW4gSTsgRGFuaWVsIENvaG47 DQo+bDJ2cG5AaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9h Y2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPg0KPltbTFldXSAgVGhpcyBpcyBub3QgbXkg dW5kZXJzdGFuZGluZy4gSGVyZSB3ZSB0YWxrIGFib3V0IGluY29taW5nIGZyYW1lDQo+YWxyZWFk eSBoYXMgYy10YWcgYW5kIHMtdGFnLCB3aGljaCBpcyBub3QgVU5JIGNhc2UuIEluIGFkZGl0aW9u LCBpdCBzZWVtcw0KPnRoYXQgRGFuaWVsIHNheSB0aGF0IG9ubHkgb3B0aW9uIEEgd29ya3MuDQo+ DQo+VGhhdKn2cyBmdW5ueSwgSSB0aG91Z2h0IHNvbWVvbmUgc2FpZCB0aGF0IG9ubHkgb3B0aW9u IEIgd291bGQgd29yay4gIEkNCj50aGluayB0ZWNobmljYWxseSBlaXRoZXIgaXMgcG9zc2libGUs IGJ1dCBJIGFtIHVuY2xlYXIgd2hpY2ggdGhlIDJWTEFODQo+ZHJhZnQgd291bGQgYWR2aXNlIChv ciBpZiBpdCBldmVuIGRvZXMpDQo+DQo+DQo+LUpvc2gNCj4NCj4NCj4NCj5PbiA0LzI1LzEyIDU6 MjIgUE0sICJMdWN5IHlvbmciIDxsdWN5LnlvbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQo+DQo+Pkhp IEpvc2gsDQo+Pg0KPj5QbGVhc2Ugc2VlIGlubGluZS4NCj4+DQo+Pi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+PkZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4+T2YgUm9nZXJzLCBKb3NoDQo+PlNlbnQ6IFdl ZG5lc2RheSwgQXByaWwgMjUsIDIwMTIgNDo0MiBQTQ0KPj5UbzogRmVkeWssIERvbmFsZCAoRG9u KTsgRGF2aWQgQWxsYW4gSTsgRGFuaWVsIENvaG47IGwydnBuQGlldGYub3JnDQo+PlN1YmplY3Q6 IFJlOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/ DQo+Pg0KPj5EYXZlL0RhbmllbC9MdWN5L090aGVycyBEZWJhdGluZyBob3cgbWFueSB0YWdzIG5l Y2Vzc2FyeSB3aGVuIFMtVGFnDQo+PnByZXNlcnZhdGlvbiBpcyBkZXNpcmVkLA0KPj4NCj4+DQo+ PkkgdGhpbmsgeW91IGFsbCBtYXkgaGF2ZSBnb25lIG9mZiBvbiBhIHRhbmdlbnQgaGVyZS4gIFRo ZSBvcmlnaW5hbA0KPj5kaXNjdXNzaW9uIHdhcyBhYm91dCBob3cgdG8gZGVhbCB3aXRoIHRoZSBz aXR1YXRpb24gd2hlcmUgdGhlIFMtVGFnIGlzDQo+PnByZXNlcnZlZCBhdCBhIGhhbmRvZmYgKGVp dGhlciBhbiBFTk5JLCBvciBTZXJ2aWNlIE11bHRpcGxleGVkIFVOSSkNCj4+W1tMWV1dIGluIE1F RiwgUy1UYWcgYXBwbGllcyB0byBFTk5JIG9ubHksIG5vdCBVTkkuIEFuIFVOSSBjYW4gc3VwcG9y dA0KPj5tdWx0aXBsZXhlZCBzZXJ2aWNlcywgaS5lLiB0ZXJtaW5hdGUgbWFueSBFVkNzLiBJbiB0 aGlzIGNhc2UsIGVhY2ggRVZDDQo+PmFzc29jaWF0ZXMgd2l0aCBvbmUgb3IgbXVsdGlwbGUgYy10 YWdzLiBFVkMgaGFzIGEgc2VydmljZSBhdHRyaWJ1dGUgZm9yDQo+Pmxpc3RpbmcgYXNzb2NpYXRl ZCBjLXRhZ3MuDQo+Pg0KPj5JIGJlbGlldmUgdGhlcmUgd2VyZSB0d28gc3VnZ2VzdGlvbnMsIG9u ZSB3YXMgdGhhdCB5b3UgcHVzaCBvbiBhICdFVFJFRScNCj4+dGFnIChvbmUgb2YgdHdvIHZhbHVl cywgZm9yIGVpdGhlciBhIGZyYW1lIHNvdXJjZWQgZnJvbSBhIHJvb3QgQUMgb3INCj4+YW5vdGhl ciBmb3IgYSBmcmFtZSBmcm9tIGEgbGVhZiBBQyksIGFuZCB0aGUgc2Vjb25kIHNvbHV0aW9uIHdh cyB0bw0KPj4nbWFwJy4NCj4+W1tMWV1dICBUaGlzIGlzIG5vdCBteSB1bmRlcnN0YW5kaW5nLiBI ZXJlIHdlIHRhbGsgYWJvdXQgaW5jb21pbmcgZnJhbWUNCj4+YWxyZWFkeSBoYXMgYy10YWcgYW5k IHMtdGFnLCB3aGljaCBpcyBub3QgVU5JIGNhc2UuIEluIGFkZGl0aW9uLCBpdA0KPj5zZWVtcyB0 aGF0IERhbmllbCBzYXkgdGhhdCBvbmx5IG9wdGlvbiBBIHdvcmtzLg0KPj4NCj4+DQo+PkltYWdp bmUgdGhlIGZvbGxvd2luZyB0b3BvbG9neToNCj4+DQo+PistLS0tLSsgICstLS0tLSsgICstLS0t LSsgICstLS0tLSsNCj4+fCBDRTEgfC0tfCBQRTEgfC0tfCBQRTIgfC0tfCBDRTIgfA0KPj4rLS0t LS0rICArLS0tLS0rICArLS0tLS0rICArLS0tLS0rDQo+PiAgICAgICAgICAgIHwgICAgICAgIHwN Cj4+Ky0tLS0tKyAgKy0tLS0tKyAgKy0tLS0tKyAgKy0tLS0tKw0KPj58IENFMyB8LS18IFBFMyB8 LS18IFBFNCB8LS18IENFNCB8DQo+PistLS0tLSsgICstLS0tLSsgICstLS0tLSsgICstLS0tLSsN Cj4+DQo+PldoZXJlOg0KPj4NCj4+U2l0ZSAgVHlwZSAgVkxBTg0KPj5DRTEgICBSb290ICBYDQo+ PkNFMiAgIExlYWYgIDINCj4+Q0UzICAgTGVhZiAgMw0KPj5DRTQgICBMZWFmICAzDQo+Pg0KPj4N Cj4+U28sIHRoZXJlIGFyZSBhIGxvdCBvZiBTUCdzIHdobyBhcmUga2VlbiBvbiB0aGUgd2F5IG1h bnkgc2VydmljZXMgY2FuDQo+PmJlIGhhbmRlZCB0byBhIGN1c3RvbWVyIG9uIGEgc2luZ2xlIFVO SSwgYnV0IGNvb3JkaW5hdGluZyBhIHNpbmdsZSBWTEFODQo+PnBlciBzZXJ2aWNlLCB3aXRoIHRo ZSBjdXN0b21lciAoTUVGIHVzZWQgdG8gY2FsbCB0aGlzIEVWUEwgd2hlbiBpdCB3YXMNCj4+bWFu eSBwb2ludCB0byBwb2ludCBzZXJ2aWNlcyB0ZXJtaW5hdGluZyBvbiBhIHNpbmdsZSBVTkkpLiAg U28sIGltYWdpbmUNCj4+dGhhdCB3ZSBoYXZlIHR3byBFVFJFRSBpbnN0YW5jZXMsIGFuZCBhbiBp bnRlcm5ldCBzZXJ2aWNlIGFsbA0KPj50ZXJtaW5hdGluZyBvbiBhIHNpbmdsZSBVTkkgY29ubmVj dGluZyB0byBDRTEuICBXZSBoYXZlIG5lZ290aWF0ZWQgVkxBTg0KPj5JRCdzIHdpdGggdGhlIGN1 c3RvbWVyLCBhbmQgdGhleSBhcmUgZXhwZWN0aW5nIHRvIHJlYWNoIENFMiB1c2luZyBWTEFODQo+ PjIsIENFMyBhbmQgQ0U0IHVzaW5nIFZMQU4gMywgYW5kIEludGVybmV0IHNlcnZpY2Ugb24gVkxB TiAxMC4gIEFzIGENCj4+ZnJhbWUgZnJvbSBDRTEgY29tZXMgaW50byBQRTEgZGVzdGluZWQgZm9y IENFMiAoc28gdGhlIGN1c3RvbWVyIGhhcw0KPj50YWdnZWQgaXQgd2l0aCBWSUQgMiksIHVzaW5n IHRoZSAyVkxBTiBtZXRob2QsIHNpbmNlIHRoaXMgaXMgY29taW5nDQo+PmZyb20gYSByb290IHNp dGUsIGRvIHdlDQo+Pg0KPj5hKSBwbGFjZSB0aGUgUm9vdCBTLVRhZyBpbiBmcm9udCBvZiBWSUQg MiwgdGhlbiBzaGlwIGl0IGFjcm9zcywgYW5kIHBvcA0KPj5vZmYgdGhlIEVUUkVFIFMtVGFnIChz b21lIFNQJ3Mgd2lzaCB0byBQb3AgdGhlIG9yaWdpbmFsIGN1c3RvbWVyIHRhZw0KPj5WSUQgMiBh cyB3ZWxsKQ0KPj4NCj4+LW9yLQ0KPj4NCj4+Yikgc3dhcCBWSUQyIGZvciB0aGUgRVRSRUUgUm9v dCBTLVRhZywgc2VuZCB0aGUgZnJhbWUgdG8gUEUyIHdoZXJlIGl0DQo+PndpbGwgcmVtb3ZlIHRo ZSBTLVRhZyAoYW5kIGVpdGhlciBwdXNoIFZJRDIgYmFjayBvbiwgb3IgbGVhdmUgaXQgb2ZmDQo+ PmRlcGVuZGluZyBvbiBTUCBwcmVmZXJlbmNlKQ0KPj4NCj4+VGhlIHJlZmVyZW5jZSB0byAnZG91 YmxlIHRhZ2dpbmcnIHdhcyB0YWxraW5nIGFib3V0IHNvbHV0aW9uIEEgYWJvdmUsDQo+PnNpbmNl IHRoZXJlIGlzIGJvdGggdGhlIHNlcnZpY2UgVklEIHRoYXQgaXMgY29vcmRpbmF0ZWQgd2l0aCB0 aGUNCj4+Y3VzdG9tZXIsIGFzIHdlbGwgYXMgdGhlIEV0cmVlIFZJRCB3aGljaCBkZXNpZ25hdGVz IHRoZSBzb3VyY2UgKHJvb3Qgb3INCj4+bGVhZikgW1tMWV1dIFNpbmNlIGR1YWwgVkxBTiBzb2x1 dGlvbiB0cmllcyB0byBpbmxpbmUgd2l0aCBJRUVFDQo+PnNvbHV0aW9uLCBpZiB0aGlzIGlzIHRo ZSB1c2UgY2FzZSwgd2Ugc3VnZ2VzdHMgdG8gZ28gd2l0aCBvcHRpb24gQiwgbm90DQo+PkEuIFNv IHBsZWFzZSBkb24ndCBkaXNjdXNzIG9wdGlvbiBBIG1vcmUuDQo+Pg0KPj5SZWdhcmRzLA0KPj5M dWN5DQo+Pg0KPj4NCj4+SG9wZSB0aGF0IGNsZWFycyBtb3JlIHRoYW4gaXQgY29uZnVzZXMsIEpv c2gNCj4+DQo+Pg0KPj4NCj4+T24gNC8yNS8xMiA0OjIyIFBNLCAiRmVkeWssIERvbmFsZCAoRG9u KSINCj4+PGRvbmFsZC5mZWR5a0BhbGNhdGVsLWx1Y2VudC5jb20+IHdyb3RlOg0KPj4NCj4+Pkhp IERhdmUNCj4+Pg0KPj4+WWVzIHRoZSBvbmx5IHBvaW50IEkgd291bGQgYWRkIGlzIER1YWwgVkxB TiBtZWFucyBPbmUgVklEIGZvciBSb290IGFuZA0KPj4+b25lIFZJRCBmb3IgTGVhZi4gTm90IHR3 byBUQUdzIGF0IGEgdGltZSBvbiB0aGUgZnJhbWUgYnV0IHR3bw0KPj4+YWxsb2NhdGVkIGZvciB0 aGUgc2VydmljZS4NCj4+Pg0KPj4+VGhlIGNvbmZ1c2luZyBwYXJ0IGlzIG5vIGRvdWJ0IHRoYXQg RHVhbCBQV0UvRHVhbCBWTEFOIGNvbXBhcmlzb24NCj4+PnRhbGtzIGFib3V0IEVuY2Fwc3VsYXRp b24gT3ZlcmhlYWQgYXMgYSBWTEFOIFRhZy4gV2hpbGUgdGhhdCBpcyB0cnVlDQo+Pj5pbiBhIFBX RSBzZW5zZSBpdCBpcyBzdGlsbCBhIHNpbmdsZSBWTEFOIFRhZyBhdCBhIHRpbWUgaW4gYSBFdGhl cm5ldA0KPj4+RS10cmVlIHNlbnNlLg0KPj4+IFRoZSBjb21wZWxsaW5nIGRyaXZlciBmb3IgRHVh bCBWTEFOIGlzIGhhdmluZyBhIEV0cmVlIHNlcnZpY2UgdGhhdA0KPj4+d29ya3MgaW4gbWFueSBl bnZpcm9ubWVudHMgYW5kIHRoZSBEVUFMIFZMQU4gKHJlYWxseSBkdWFsIFZMQU4NCj4+PmludGVy ZmFjZSBvbiBhDQo+Pj5WU0kpIHVzZXMgdGhlIHNhbWUgbWVjaGFuaXNtIChvbmUgVklEIGZvciBy b290IGFuZCBvbmUgVklEIGZvciBMZWFmIGF0DQo+Pj5hDQo+Pj50aW1lKSBhcyBzcGVjaWZpZWQg aW4gdGhlIElFRUUuIEluIGEgcHVyZSBFdGhlcm5ldCBicmlkZ2luZyB3b3JsZCB0aGUNCj4+PlZM QU4gVEFHcyBmb3IgRXRyZWUgYXJlIG5vdCB0eXBpY2FsbHkgYW4gb3ZlcmhlYWQgc2luY2UgdHJh bnNsYXRpb24gaXMNCj4+PnVzZWQuDQo+Pj4NCj4+PkRvbg0KPj4+DQo+Pj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+RnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwy dnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPj4+T2YgRGF2aWQgQWxsYW4gSQ0KPj4+ U2VudDogV2VkbmVzZGF5LCBBcHJpbCAyNSwgMjAxMiA1OjA1IFBNDQo+Pj5UbzogRGFuaWVsIENv aG47IGwydnBuQGlldGYub3JnDQo+Pj5TdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBw cm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+DQo+Pj5PSyBJIGZlZWwgbGlrZSBJ IGFtIGRpZ3Jlc3NpbmcgYSBmYWlyIGRpc3RhbmNlIGZyb20gdGhlIGFjdHVhbA0KPj4+cHJvYmxl bS4uLi4gQnV0IGhlcmUgZ29lczoNCj4+Pg0KPj4+U28gdGhlIHNjZW5hcmlvcyBjZW50ZXIgYXJv dW5kICJob3cgRVRSRUUgZG8geW91IHdhbnQgdG8gYmU/Ii4uLi4NCj4+Pg0KPj4+SWYgdGhlIEFD cyBhcmUgcm9vdC9sZWFmLCB0aGVuIGlmIHRoZXkgYXJlIFAyUCAoc2luZ2xlIGV0aGVybmV0IGVu ZA0KPj4+c3RhdGlvbiBhdHRhY2hlZCB0byBlYWNoIEFDKSB0aGlzIGlzIG1vb3QuIEVUUkVFIHNl bWFudGljcyBhcmUNCj4+PmVuZm9yY2VkIGJ5IHRoZSAyVklEIGRvbWFpbiBpbiB0aGUgY2VudGVy IG9mIHRoZSBleGFtcGxlLiBJZiB5b3UNCj4+PmFzc3VtZWQgbm9kZXMgQSZCIGluIHRoZSBleGFt cGxlIHdlcmUgTDJWUE4gUEVzLCB0aGUgdGFnZ2luZyBhbmQgdGhlDQo+Pj5QVyB0YWcgaW1wb3Np dGlvbiBhbGwgaGFwcGVuZWQgYXQgdGhlIHNhbWUgcG9pbnQgaW4gdGhlIG5ldHdvcmsuDQo+Pj4N Cj4+PklmIHRoZXkgYXJlIG5vdCBzaW1wbGUgUDJQIGFsbCB0aGUgd2F5IHRvIGVuZCBzeXN0ZW1z IGFuZCB0aGUNCj4+Pm9iamVjdGl2ZSBpcyB0byBhdm9pZCBicmlkZ2luZyBiZXR3ZWVuIGxlYWYg InNpdGVzIiBidXQgYWxsb3dpbmcNCj4+PmludHJhLWxlYWYtc2l0ZSBjb25uZWN0aXZpdHkgdGhl biB0aGUgbGVhdmVzIGNhbiBiZSBMQU5zIGJ1dCB0aGUgcm9vdA0KPj4+aXMgbm90LCBzdWNoIHRo YXQgSSBjYW5ub3QgYnJpZGdlIHRocm91Z2ggdGhlIHJvb3QuIEJ1dCBhbGwgaG9zdHMgYXQgYQ0K Pj4+Z2l2ZW4gbGVhZiBzaXRlIGNhbiBzZWUgZWFjaCBvdGhlci4gU28gcm9vdCBFdGhlcm5ldCBl bmQgc3lzdGVtcyBhcmUNCj4+PmRpcmVjdGx5IGF0dGFjaGVkIG9yIHR3byBWSURzIGFyZSB1c2Vk IGluIHRoZSByb290IHNpdGUuDQo+Pj4NCj4+PklmIHRoZSBvYmplY3RpdmUgaXMgdGhhdCB0aGVy ZSBhcmUgbXVsdGlwbGUgZXRoZXJuZXQgYXR0YWNoZWQgZW5kDQo+Pj5zdGF0aW9ucyBhdCBib3Ro IHRoZSBsZWFmIGFuZCByb290IHNpdGVzLCBhbmQgdGhlIG9iamVjdGl2ZSBpcyB0bw0KPj4+ZW5m b3JjZQ0KPj4+TDIgaXNvbGF0aW9uIGV2ZXJ5d2hlcmUgdGhlbiBJIG5lZWQgdHdvIFZJRHMgZXh0 ZW5kZWQgdG8gdGhlIGVuZA0KPj4+c3lzdGVtIGF0dGFjaGVtZW50IHBvaW50IGluIHRoZSBsb2Nh bCBMQU5zIGJ5IHdoYXRldmVyIG1lYW5zLi4uLg0KPj4+DQo+Pj5BbmQgSSBkbyBub3Qgc2VlIGFk ZGluZyBWTEFOcyBpbiBhbnkgcGFydGljdWxhciBzcG90LCBzaW1wbHkgc2VsZWN0aW9uDQo+Pj5v ZiB0aGUgVklEIGFuZCBhc3NvY2lhdGVkIHNlbWFudGljcyB3aGVyZSBWSURzIGFyZSB0cmFuc2xh dGVkLiBUaGUNCj4+PmFjdHVhbCBwb2ludCBvZiBTLXRhZyBpbXBvc2l0aW9uIGNvdWxkIGJlIGEg UEUsIG9yIGNsb3VkIGJlIGEgTklEL0NMRQ0KPj4+b24gdGhlIGN1c3RvbWVyIHByZW0gKG1vcmUg bGlrZWx5IHNjZW5hcmlvIGhlcmUgdG8gZXh0ZW5kIE9BTSBkZW1hcmMNCj4+PnRvIHRoZSBwcmVt KSwgb3Igc29tZSBzd2l0Y2ggaW4gYSBSQU4gZG93bnN0cmVhbSBvZiB0aGUgTVBMUyBQRS4uLg0K Pj4+YmxhaCBibGFoIGJsYWguIEFuZCBpZiBFVFJFRSBpcyBleHRlbmRlZCBpbnRvIGEgY3VzdG9t ZXIgc2l0ZSBMQU4gYW5kDQo+Pj5vdXRzaWRlIG9mIHRoZSBwcm92aWRlciBkb21haW4sIHRoZW4g dHdvIEMtdGFncyB3b3VsZCBoYXZlIHRvIGJlIHVzZWQNCj4+PnRoYXQgbWFwcGVkIHRvIFMtdGFn cyBhdCB0aGUgUEJOIGJvdW5kYXJ5Li4uDQo+Pj4NCj4+Pk1ha2Ugc2Vuc2U/DQo+Pj5EYXZlDQo+ Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBEYW5pZWwgQ29obiBb bWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbV0NCj4+PlNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjUs IDIwMTIgNDozOSBQTQ0KPj4+VG86IERhdmlkIEFsbGFuIEk7IGwydnBuQGlldGYub3JnDQo+Pj5T dWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNv bHV0aW9uPw0KPj4+DQo+Pj5EYXZlLCBidXQgdGhlIEFDcyBhcmUgcm9vdC9sZWFmICh0aGF0J3Mg d2hhdCB0aGUgd2hvbGUgdnBscyBldHJlZSBpcw0KPj4+YWJvdXQgLSBzZWUgdGhlIHJlcXQgZHJh ZnQpLCBzbyBwZXIgdGhlIDJ2bGFuIGRyYWZ0IHRoZSByb290L2xlYWYgdmxhbg0KPj4+bXVzdCBi ZSBhZGRlZC4NCj4+Pg0KPj4+VGh1bWIgdHlwZWQgLSBwbGVhc2UgYmUgdG9sZXJhbnQNCj4+Pg0K Pj4+RGF2aWQgQWxsYW4gSSA8ZGF2aWQuaS5hbGxhbkBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPj4+ DQo+Pj5ISSBEYW5pZWw6DQo+Pj4NCj4+PkluIHRoZSBleGFtcGxlIHByb3ZpZGVkLA0KPj4+DQo+ Pj4iaW5ncmVzcyBWTEFOIElEIDwtPiBFdHJlZSBSb290L0xlYWYgVklEIDwtPiBFZ3Jlc3MgVklE Ig0KPj4+ICAgICAgICAgICAgICAgICAgQSAgICAgICAgICAgICAgICAgICAgICAgQg0KPj4+DQo+ Pj50aGUgc2VydmljZSBpcyBub3QgRVRSRUUgaW4gdGhlIGRvbWFpbnMgb2YgdGhlIGluZ3Jlc3Mg YW5kIGVncmVzcyBWSUQuDQo+Pj5JdCBpcyBFTEFOLiBTTyB0aGVyZSBpcyBubyByb290L2xlYWYg YXR0cmlidXRlIHRvIHNob3ZlbCBhcm91bmQuIEl0DQo+Pj53b3VsZCByZXF1aXJlIHR3byBWSURz IGluIGVhY2ggZG9tYWluIGlmIHRoZSBFVFJFRSBzZW1hbnRpY3Mgd2VyZSB0bw0KPj4+YmUgdGVs ZXNjb3BlZCBFMkUuDQo+Pj4NCj4+Pk90aGVyd2lzZSBpdCBpcyBhIHByb3Zpc2lvbmluZyBvZiB0 aGUgVklEIHRyYW5zbGF0aW9uIHRhYmxlcyBhdCB0aGUNCj4+PmludGVybWVkaWF0ZSBub2RlcyAo QSZCIHRoYXQgSSd2ZSBhZGRlZCB0byB0aGUgcGljdHVyZSkgdGhhdCB3b3VsZA0KPj4+ZGV0ZXJt aW5lIHRoZSBWSUQgdmFsdWVzIHVzZWQgaW4gZWFjaCBkb21haW4uIE9yIGluIHRoZSBleGFtcGxl IGFib3ZlLA0KPj4+d2hhdCB0aGUgaW5ncmVzcywgRXRyZWUgYW5kIGVncmVzcyBWSUQgdmFsdWVz IHdlcmUuDQo+Pj4NCj4+PkNoZWVycw0KPj4+RGF2ZQ0KPj4+DQo+Pj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4+RnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBu LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPj4+T2YgRGFuaWVsIENvaG4NCj4+PlNlbnQ6 IFdlZG5lc2RheSwgQXByaWwgMjUsIDIwMTIgMzo0NiBQTQ0KPj4+VG86IEx1Y3kgeW9uZzsgUm9n ZXJzLCBKb3NoOyBTaGFocmFtIERhdmFyaTsgTGl6aG9uZyBKaW47DQo+Pj5sMnZwbkBpZXRmLm9y ZzsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20NCj4+PkNjOiB5dXF1bi5jYW9AZ21h aWwuY29tDQo+Pj5TdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0 aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+DQo+Pj5BbmQgdG8gdGhpcyBJIGFza2VkIGhvdyB0aGlz IG1hcHBpbmcgd29ya3MgLSBob3cgZG9lcyB0aGUgZWdyZXNzIHBlDQo+Pj5yZWNvdmVyIHRoZSBp bmdyZXNzIHZpZCB3aGVuIGl0IGdldHMgdGhlIGZyYW1lIHRhZ2dlZCB3aXRoIG9ubHkgdGhlDQo+ Pj5yb290L2xlYWYgdmlkPyBIb3cgY2FuIHlvdSBjb252ZXkgdGhlIGluZ3Jlc3MgdmlkIHBsdXMg dGhlIHJvb3QvbGVhZg0KPj4+YXR0cmlidXRlIGluIHRoZSBzYW1lIG51bWJlciBvZiBiaXRzPw0K Pj4+V2hhdCBhbSBJIG1pc3Npbmc/DQo+Pj4NCj4+PkRhbmllbA0KPj4+DQo+Pj5UaHVtYiB0eXBl ZCAtIHBsZWFzZSBiZSB0b2xlcmFudA0KPj4+DQo+Pj5MdWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3 ZWkuY29tPiB3cm90ZToNCj4+Pg0KPj4+RGFuaWVsLA0KPj4+DQo+Pj5EYXZpZCBBbGxlbiBhbHJl YWR5IGV4cGxhaW5lZCB0aGUgc29sdXRpb24uDQo+Pj4NCj4+PkZyb20gRGF2aWQ6DQo+Pj5pbmdy ZXNzIFZMQU4gSUQgPC0+IEV0cmVlIFJvb3QvTGVhZiBWSUQgPC0+IEVncmVzcyBWSUQuDQo+Pj4N Cj4+PkluZ3Jlc3MgVklEIGRvZXMgbm90IGhhdmUgdG8gZXF1YWwgRWdyZXNzIFZJRCBidXQgcmVn YXJkbGVzcyB0aGVyZSBpcw0KPj4+b25seSBldmVyIG9uZSBWSUQgb24gYSBmcmFtZSBhdCBhIHRp bWUuDQo+Pj4NCj4+Pi1lbmQNCj4+Pg0KPj4+VGhpcyB3b3JrcyB3aGVuIGN1c3RvbWVyIG1ha2Vz IGluZ3Jlc3MgVkxBTiBJRCBub3QgZXF1YWwgdG8gb3IgZXF1YWwNCj4+PnRvIGVncmVzcyBWTEFO IElELg0KPj4+DQo+Pj5SZWdhcmRzLA0KPj4+THVjeQ0KPj4+DQo+Pj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4+RnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBu LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPj4+T2YgRGFuaWVsIENvaG4NCj4+PlNlbnQ6 IFdlZG5lc2RheSwgQXByaWwgMjUsIDIwMTIgMTE6MzkgQU0NCj4+PlRvOiBMdWN5IHlvbmc7IFJv Z2VycywgSm9zaDsgU2hhaHJhbSBEYXZhcmk7IExpemhvbmcgSmluOw0KPj4+bDJ2cG5AaWV0Zi5v cmc7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQo+Pj5DYzogeXVxdW4uY2FvQGdt YWlsLmNvbQ0KPj4+U3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8g dGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4+Pg0KPj4+SGkgTHVjeSwNCj4+Pg0KPj4+VGhlIHNjZW5h cmlvIHdlIGFyZSBkaXNjdXNzaW5nIGlzIG5vdCB0aGUgRS1UcmVlIEUtTk5JLCBidXQgYSBnZW5l cmFsDQo+Pj5zY2VuYXJpbyB3aGVyZSBmcmFtZXMgYXJyaXZpbmcgYXQgdGhlIHJvb3Qgb3IgbGVh ZiBBQyAgYXJlIGFscmVhZHkNCj4+PmRvdWJsZSB0YWdnZWQuIEluIHRoaXMgY2FzZSwgdGhlIGR1 YWwgdmxhbiBzb2x1dGlvbiBjYW5ub3QgcHJlc2VydmUNCj4+PnRoZSB2bGFucyB3aXRob3V0IGFk ZGluZyBhIHRoaXJkIG9uZSwgY2FuIGl0Pw0KPj4+DQo+Pj5NYXliZSBTaGFocmFtIGNhbiBhZGQg ZGV0YWlscyBvbiB0aGUgc2NlbmFyaW8gaGUgaGFkIGluIG1pbmQNCj4+Pg0KPj4+VGh1bWIgdHlw ZWQgLSBwbGVhc2UgYmUgdG9sZXJhbnQNCj4+Pg0KPj4+THVjeSB5b25nIDxsdWN5LnlvbmdAaHVh d2VpLmNvbT4gd3JvdGU6DQo+Pj4NCj4+PkRhbmllbCwNCj4+Pg0KPj4+TUVGIGhhcyBTLVZMQU4g cHJlc2VydmF0aW9uIGF0dHJpYnV0ZSBmb3IgRU5OSSBvbmx5IGJlY2F1c2UgdGhlcmUgaXMNCj4+ Pm5vIHMtdmxhbiBhdCBVTkkuIFdoZW4gYW4gTUVOIGNvbm5lY3RzIHRvIG11bHRpcGxlIEVOTkkg aW50ZXJmYWNlcywNCj4+PlMtVkFMTiBwcmVzZXJ2YXRpb24gYXR0cmlidXRlIGlzIHVzZWQuIEl0 IGFwcGxpZXMgdG8gRS1UcmVlIGFzIHdlbGwuDQo+Pj4NCj4+PlJlZ2FyZHMsDQo+Pj5MdWN5DQo+ Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBsMnZwbi1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+Pj5P ZiBEYW5pZWwgQ29obg0KPj4+U2VudDogVHVlc2RheSwgQXByaWwgMjQsIDIwMTIgMjoxMiBBTQ0K Pj4+VG86IEx1Y3kgeW9uZzsgUm9nZXJzLCBKb3NoOyBTaGFocmFtIERhdmFyaTsgTGl6aG9uZyBK aW47DQo+Pj5sMnZwbkBpZXRmLm9yZzsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20N Cj4+PkNjOiB5dXF1bi5jYW9AZ21haWwuY29tDQo+Pj5TdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBv ZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+DQo+Pj5MdWN5LA0K Pj4+DQo+Pj5ldmVuIGlmIHRoZSBjdXJyZW50IE1FRiBmcmFtZXdvcmsgZG9lc24ndCByZXF1aXJl IHMtdmxhbiBwcmVzZXJ2YXRpb24sDQo+Pj5JIGJlbGlldmUgaXQncyB0byB0aGUgaW5kdXN0cnkn cyBiZW5lZml0IHRvIGFkb3B0IGEgc29sdXRpb24gdGhhdCBpcw0KPj4+bm90IGNvbnN0cmFpbmVk IHRvIGEgc3BlY2lmaWMgZW5uaSBtb2RlbCB0aGF0LCBsaWtlIGFsbCB0aGluZ3MNCj4+Pm5ldHdv cmtpbmcsIGlzIGxpa2VseSB0byBldm9sdmUuIEVzcGVjaWFsbHkgd2hlbiBzdWNoIGEgc29sdXRp b24gaXMNCj4+PmF2YWlsYWJsZS4NCj4+Pg0KPj4+RGFuaWVsDQo+Pj4NCj4+PlRodW1iIHR5cGVk IC0gcGxlYXNlIGJlIHRvbGVyYW50DQo+Pj4NCj4+Pkx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdl aS5jb20+IHdyb3RlOg0KPj4+DQo+Pj5EYW5pZWwsDQo+Pj4NCj4+Pk1FRiBoYXMgd29ya2VkIGlu IEVOTkkgaW50ZXJmYWNlIGZvciBhIGxvbmcgdGltZSB3aXRoIG1hbnkgc2VydmljZQ0KPj4+cHJv dmlkZXJzJyBpbnB1dHMuIEl0IGhhZCBhIGZhaXIgcmVhc29uIHRvIGFzc3VtZSBTLVZMQU4gb3Zl ciBFTk5JIGJ5DQo+Pj50aGVuLiBJdCBtYXkgb3BlbiBCLVZMQU4gZm9yIHRoZSBmdXR1cmUuIEl0 IGlzIGJldHRlciBmb3IgdXMgbm90IHRvDQo+Pj5kaXNjdXNzICBhIGZ1dHVyZSBmcmFtZXdvcmsg aGVyZSwgYmVjYXVzZSBpdCB3aWxsIGxlYWQgdXMgdG8gbm93aGVyZS4NCj4+PkhlcmUsIHdlIHdh bnQgdG8gZXh0ZW5kIFZQTFMgaW4gc3VwcG9ydGluZyBFLVRyZWUuDQo+Pj4NCj4+PkJlc3QgUmVn YXJkcywNCj4+Pkx1Y3kNCj4+Pg0KPj4+RnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPj4+T2YgRGFuaWVsIENvaG4N Cj4+PlNlbnQ6IFN1bmRheSwgQXByaWwgMjIsIDIwMTIgNzozNCBBTQ0KPj4+VG86IFJvZ2Vycywg Sm9zaDsgU2hhaHJhbSBEYXZhcmk7IExpemhvbmcgSmluOyBsMnZwbkBpZXRmLm9yZzsNCj4+PkFs ZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQo+Pj5DYzogeXVxdW4uY2FvQGdtYWlsLmNv bQ0KPj4+U3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUt VHJlZSBzb2x1dGlvbj8NCj4+Pg0KPj4+U2hhaHJhbSBhbmQgYWxsLA0KPj4+DQo+Pj5UaGlzIHF1 ZXN0aW9uIGFscmVhZHkgY2FtZSB1cCBpbiBvdXIgZGlzY3Vzc2lvbnMgLSBpcyBpdCBzYWZlIHRv DQo+Pj5hc3N1bWUgdGhhdCB0aGUgVkxBTiB0YWdzIGF0IHRoZSBFLU5OSSB3aWxsIGFsd2F5cyBi ZSBhY2NvcmRpbmcgdG8gdGhlDQo+Pj5jdXJyZW50IE1FRiBtb2RlbD8gT3Igc2hvdWxkIHdlIHRy eSB0byBiZSBhcyB0cmFuc3BhcmVudCBhcyBwb3NzaWJsZQ0KPj4+dG8gdXNlciBWTEFOIGVuY2Fw c3VsYXRpb24gYXQgdGhlIEUtTk5JLCB0byBhY2NvbW1vZGF0ZSBmdXR1cmUNCj4+PmZyYW1ld29y a3M/DQo+Pj5JIGJlbGlldmUgdGhhdCBhbnkgYXBwcm9hY2ggdGhhdCBsb29rcyBhdCB1c2VyIHBh eWxvYWQgKGluIHRoaXMgY2FzZQ0KPj4+VkxBTg0KPj4+dGFnKSB0byBzaWduYWwgVlBMUyBpbmZv cm1hdGlvbiAoaW4gdGhpcyBjYXNlIHJvb3QvbGVhZiBvcmlnaW4pIGlzDQo+Pj5uZWNlc3Nhcmls eSB0aWVkIHRvIHNwZWNpZmljIGFzc3VtcHRpb25zIG9uIHVzZXIgcGF5bG9hZCBlbmNhcHN1bGF0 aW9uDQo+Pj4oaW4gdGhpcyBjYXNlLCB0aGF0IFMtVkxBTiB0YWcgaXMgImF2YWlsYWJsZSIgdG8g ZW5jb2RlIHJvb3QvbGVhZikuIEkNCj4+PmRvbid0IHRoaW5rIHRoaXMgaXMgYSBmdXR1cmUtcHJv b2YgYXNzdW1wdGlvbiwgaXQncyB2ZXJ5IGxpa2VseSB0aGF0DQo+Pj5vdGhlciBuZXR3b3JrIG1v ZGVscyB3aWxsIGNvbWUgdXAgdGhhdCByZXF1aXJlIFMtVkxBTiBwcmVzZXJ2YXRpb24sDQo+Pj53 aGljaCBpbiB0aGUgMi1WTEFOIGFwcHJvYWNoIHdvdWxkIG5lY2Vzc2l0YXRlIGFkZGluZyBhIHRo aXJkIFZMQU4tSUQuDQo+Pj4NCj4+PkRhbmllbA0KPj4+DQo+Pj5Gcm9tOiBTaGFocmFtIERhdmFy aSA8ZGF2YXJpQGJyb2FkY29tLmNvbTxtYWlsdG86ZGF2YXJpQGJyb2FkY29tLmNvbT4+DQo+Pj5U bzogTGl6aG9uZyBKaW4gPGxpemhvLmppbkBnbWFpbC5jb208bWFpbHRvOmxpemhvLmppbkBnbWFp bC5jb20+PiwNCj4+PiJsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+Ig0KPj4+ PGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4+LA0KPj4+IkFsZXhhbmRlci5W YWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl Lg0KPj4+Y29tDQo+Pj4+DQo+Pj4iDQo+Pj48QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuDQo+Pj5jb20NCj4+Pj4NCj4+ Pj4NCj4+PkNjOiAieXVxdW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNv bT4iDQo+Pj48eXVxdW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbT4+ DQo+Pj5TdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1U cmVlIHNvbHV0aW9uPw0KPj4+DQo+Pj5IaSwNCj4+Pg0KPj4+SSBhbHNvIGhhdmUgYSBxdWVzdGlv biByZWdhcmRpbmcgMi1WTEFOLiBXaGF0IGlmIHRoZSBjdXN0b21lciB0cmFmZmljDQo+Pj5hbHJl YWR5IGhhcyBhbiBTLVZMQU4/IERvIHdlIG5lZWQgYSAzcmQgVkxBTiB0byBpZGVudGlmeSB0aGUg TC9SPw0KPj4+DQo+Pj5UaHgNCj4+PlNoYWhyYW0NCj4+Pg0KPj4+RnJvbTogbDJ2cG4tYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZz4NCj4+PlttYWlsdG86bDJ2 cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExpemhvbmcgSmluDQo+Pj5TZW50OiBG cmlkYXksIEFwcmlsIDIwLCAyMDEyIDk6MzggQU0NCj4+PlRvOiBsMnZwbkBpZXRmLm9yZzxtYWls dG86bDJ2cG5AaWV0Zi5vcmc+Ow0KPj4+QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208 bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuYw0KPj4+b20+DQo+Pj5DYzogeXVx dW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbT4NCj4+PlN1YmplY3Q6 IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/ DQo+Pj4NCj4+PkhpLCBhbGwsDQo+Pj5UaGUgZGlmZmVyZW5jZSBiZXR3ZWVuIDItVkxBTiBhbmQg Q1cgYXBwcm9hY2ggaXMgd2hvIHdpbGwgcHJvdmlkZSB0aGUNCj4+PlIvTCBpbmZvcm1hdGlvbiwg Y3VzdG9tZXIgcGF5bG9hZCBvciBQVz8gVGhlIGN1c3RvbWVyIHBheWxvYWQgd2lsbCBiZQ0KPj4+ YWx3YXlzIG1vZGlmaWVkIHRvIGNhcnJ5IFIvTCBpbmZvcm1hdGlvbiBpbiAyLVZMQU4gYXBwcm9h Y2gsIHdoaWxlIFBXDQo+Pj53aXRoIENXIHdpbGwgY2FycnkgUi9MIGluZm9ybWF0aW9uIGZvciBD VyBhcHByb2FjaC4NCj4+PkkgaGF2ZSBhIHF1ZXN0aW9uIHdpdGggdGhlIDItVkxBTiBhcHByb2Fj aCBpbiBILVZQTFMgd2hlcmUgSC1WUExTIGlzDQo+Pj5hY2Nlc3NlZCBieSBWUFdTIGFzIGRlc2Ny aWJlZCBpbiBSRkM0NjcyIHNlY3Rpb24gMTAuMS4zLiBJZiBWUFdTIGlzDQo+Pj51c2VkIHRvIGFj Y2VzcyBILVZQTFMsIGhvdyBjb3VsZCB0aGUgUEUgb24gVlBXUyBzaWRlIGFkZHMgVkxBTiB0bw0K Pj4+aW5kaWNhdGUgUi9MIGluZm9ybWF0aW9uPw0KPj4+DQo+Pj5UaGFua3MNCj4+PkxpemhvbmcN Cj4+Pg0KPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4NCj4+Pj4gTWVz c2FnZTogMg0KPj4+PiBEYXRlOiBUaHUsIDE5IEFwciAyMDEyIDA0OjM4OjM2ICswMDAwDQo+Pj4+ IEZyb206IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+Pj4+IDxBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS4NCj4+Pj4gY29t Pj4NCj4+Pj4gVG86ICJSb2dlcnMsIEpvc2giDQo+Pj4+PGpvc2gucm9nZXJzQHR3Y2FibGUuY29t PG1haWx0bzpqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbT4+LCBMdWN5IHlvbmcNCj4+Pj4gICAgICAg IDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiwgRGFu aWVsDQo+Pj4+Q29obiA8RGFuaWVsQ0BvcmNraXQuY29tPG1haWx0bzpEYW5pZWxDQG9yY2tpdC5j b20+PiwgU2FtIENhbw0KPj4+PiAgICAgICAgPHl1cXVuLmNhb0BnbWFpbC5jb208bWFpbHRvOnl1 cXVuLmNhb0BnbWFpbC5jb20+Pg0KPj4+PiBDYzogImwydnBuQGlldGYub3JnPG1haWx0bzpsMnZw bkBpZXRmLm9yZz4iDQo+Pj4+IDxsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+ Pg0KPj4+PiBTdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUg RS1UcmVlIHNvbHV0aW9uPw0KPj4+PiBNZXNzYWdlLUlEOg0KPj4+Pg0KPj4+PiA8RjkzMzY1NzE3 MzFBREU0MkE1Mzk3RkM4MzFDRUFBMDIwMzQxOTJARlJJRFdQUE1CMDAyLmVjaXRlbGUuY29tPG1h aQ0KPj4+PiBsdA0KPj4+PiBvOkY5MzM2NTcxNzMxQURFNDJBNTM5N0ZDODMxQ0VBQTAyMDM0MTky QEZSSURXUFBNQjAwMi5lY2l0ZWxlLmNvbT4+DQo+Pj4+IENvbnRlbnQtVHlwZTogdGV4dC9wbGFp bjsgY2hhcnNldD0idXMtYXNjaWkiDQo+Pj4+DQo+Pj4+IEhpIGFsbCwNCj4+Pj4gSSBmdWxseSB1 bmRlcnN0YW5kIHRoYXQgdGhhdCB3aGF0IEkgYW0gZ29pbmcgdG8gc2F5IGlzIG5vdCB2ZXJ5DQo+ Pj4+cG9wdWxhciwgYnV0Og0KPj4+Pg0KPj4+PiBJTU8gb25lIG9mIHRoZSBhZHZhbnRhZ2VzIG9m IHRoZSBDVy1iYXNlZCBzb2x1dGlvbiBpcyB0aGF0IGl0IGlzDQo+Pj4+b3J0aG9nb25hbCB0byB1 c2FnZSAob3Igbm9uLXVzYWdlKSBvZiBQMk1QIFBXcyBmb3IgZWZmZWN0aXZlIGRlbGl2ZXJ5DQo+ Pj4+b2YgQlVOIHRyYWZmaWMuDQo+Pj4+DQo+Pj4+IEFub3RoZXIgYWR2YW50YWdlIGlzIHByZXNl cnZhdGlvbiBvZiBmdWxsIG1lc2ggb2YgUDJQIFBXcyBpbiBhIFZQTFMsDQo+Pj4+YW5kLCBpbiBh IG1vcmUgZ2VuZXJpYyB3YXksIGxvY2FsaXphdGlvbiBvZiBlZmZlY3RzIG9mIGNoYW5nZXMgaW4g dGhlDQo+Pj4+UEUgY29uZmlndXJhdGlvbi4NCj4+Pj4NCj4+Pj4gSW4gcGFydGljdWxhciwgYWRk aW5nIGEgTGVhZiBBQyB0byBhIFBFIHRoYXQgcHJldmlvdXNseSBoYXMgYmVlbg0KPj4+Pm9ubHkg c3VwcG9ydGluZyBSb290IEFDcyAob3IgdmljZSB2ZXJzYSksIHJlbW92YWwgb2YgdGhlIGxhc3Qg TGVhZiBvcg0KPj4+Pmxhc3QgUm9vdCBBQyBmcm9tIGEgUEUgdGhhdCBwcmV2aW91c2x5IGhhcyBi ZWVuIHN1cHBvcnRpbmcgYSBtaXggZXRjLg0KPj4+PmFmZmVjdCBvbmx5IHRoZSBQRSB3aGVyZSB0 aGlzIG9wZXJhdGlvbiBoYXBwZW5zIGFuZCBub3QgdGhlIHJlc3Qgb2YNCj4+Pj50aGUgUEVzLg0K Pj4+Pg0KPj4+PiBBcyBmb3IgdGhlIG5lZWQgZm9yIEhXIGNoYW5nZXMgdGhhdCBoYXZlIGJlZW4g bWVudGlvbmVkIGFzIGEgbWFpbg0KPj4+PmRpc2FkdmFudGFnZSBvZiB0aGUgQ1ctYmFzZWQgYXBw cm9hY2ggLSBJIGJlbGlldmUgaXQgc3Ryb25nbHkgZGVwZW5kcw0KPj4+Pm9uIHNwZWNpZmljIGlt cGxlbWVudGF0aW9ucy4gQW5kIHNvbWUgY2hhbmdlcyBpbiB0aGUgZm9yd2FyZGluZw0KPj4+PnBy b2Nlc3MgYXJlIHJlcXVpcmVkIGluIGFueSBzb2x1dGlvbi4NCj4+Pj4NCj4+Pj4gTXkgMmMsDQo+ Pj4+ICAgICBTYXNoYQ0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IEZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc+DQo+Pj4+IFtsMnZwbi1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnPl0gb24gYmVoYWxmIG9mDQo+Pj4+IFJv Z2VycywgSm9zaA0KPj4+PiBbam9zaC5yb2dlcnNAdHdjYWJsZS5jb208bWFpbHRvOmpvc2gucm9n ZXJzQHR3Y2FibGUuY29tPl0NCj4+Pj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxOCwgMjAxMiA5 OjU3IFBNDQo+Pj4+IFRvOiBMdWN5IHlvbmc7IERhbmllbCBDb2huOyBTYW0gQ2FvDQo+Pj4+IENj OiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+DQo+Pj4+IFN1YmplY3Q6IFJl OiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+ Pj4+DQo+Pj4+IEFnYWluLCB0aGUgUDJNUCBzaXR1YXRpb24gdGhyb3dzIG1lLiAgSXMgdGhpcyBz b21ldGhpbmcgdGhhdCBpcyB1c2VkDQo+Pj4+IGNvbW1vbmx5Pw0KPj4+Pg0KPj4+PiBJJ20gdW5k ZXIgdGhlIGltcHJlc3Npb24gdGhhdCBhZGRpbmcgUDJNUCB0byBhbnkgbW9kZWwgcmVzdWx0cyBp biBhDQo+Pj4+IG1vcmUgY29tcGxleCBtb2RlbC4gIFdldGhlciBvdXRzaWRlIHMtdGFnIGlzIHVz ZWQgdG8gZGlmZmVyZW50aWF0ZSwNCj4+Pj4gb3IgZGVkaWNhdGVkIHB3J3MgYXJlIHVzZWQgZm9y IHRoZSBzYW1lIHB1cnBvc2UsIGl0IHNlZW1zIGJvdGgNCj4+Pj4gYmVjb21lIG1vcmUgY29tcGxl eC4NCj4+Pj4NCj4+Pj4gR2lsZSdzIGNvbXBhcmlzb24gc2xpZGUgc3RpbGwgY29uY2lzZWx5IGNh cHR1cmVzIHRoZSBkaWZmZXJlbmNlcw0KPj4+PmJldHdlZW4gdGhlc2UgbWV0aG9kcywgaW4gbXkg b3Bpbmlvbi4gIEkgaGF2ZW4ndCBzZWVuIGFueSBuZXcgaWRlYXMNCj4+Pj5vciAgdGhvdWdodHMg YnJvdWdodCB0byB0aGUgZ3JvdXAgaW4gdGhlIHBhc3Qgd2VlayBvciB0d28gb24gdGhlDQo+Pj4+ c3ViamVjdC4NCj4+Pj4gSSB3b3VsZCBoYXRlIGZvciBib3RoIHByb3Bvc2VkIG1ldGhvZHMgdG8g ZGllIG9uIHRoZSB2aW5lIGJlY2F1c2Ugd2UNCj4+Pj5jb3VsZG4ndCBkZWNpZGUgYmV0d2VlbiB0 d28gbWV0aG9kcyB0aGF0IGhhdmUgbm90aGluZyBpbmhlcmVudGx5DQo+Pj4+d3Jvbmcgd2l0aCBl aXRoZXIuDQo+Pj4+DQo+Pj4+IC1Kb3NoDQo+Pj4+DQo+Pj4+DQo+Pj4+IE9uIDQvMTgvMTIgMTo1 MyBQTSwgIkx1Y3kgeW9uZyINCj4+Pj48bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3ku eW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+Pj4+DQo+Pj4+PlNlbmQgdGhpcyBhZ2Fpbi4NCj4+ Pj4+DQo+Pj4+PlR3byBQVyBhcHByb2FjaCBjYW4gYmUgY29tcGxleCB0b28gaWYgdGhlIFZQTFMg aW5zdGFuY2UgZm9yIEUtVHJlZQ0KPj4+Pj51c2VzIFAyUCBQVyBmb3IgdW5pY2FzdCB0cmFmZmlj IGFuZCBQMk1QIFBXIGZvciBicm9hZGNhc3QgYW5kDQo+Pj4+PnVua25vd24gdW5pY2FzdCB0cmFm ZmljLCBhbmQgc29tZSBQMk1QIFBXcyBmb3IgbXVsdGljYXN0IHRyYWZmaWMuIEl0DQo+Pj4+Pm1h eSBkb3VibGUgYWxsIG9mIHRoZW0uDQo+Pj4+Pg0KPj4+Pj5MdWN5DQo+Pj4+Pg0KPj4+Pj4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj5Gcm9tOiBEYW5pZWwgQ29obg0KPj4+Pj5bbWFp bHRvOkRhbmllbENAb3Jja2l0LmNvbTxtYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tPl0NCj4+Pj4+ U2VudDogV2VkbmVzZGF5LCBBcHJpbCAxOCwgMjAxMiAxOjQyIFBNDQo+Pj4+PlRvOiBMdWN5IHlv bmc7IFJvZ2VycywgSm9zaDsgU2FtIENhbw0KPj4+Pj5DYzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRv OmwydnBuQGlldGYub3JnPg0KPj4+Pj5TdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBw cm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+Pj4NCj4+Pj4+SSB0aGluayB0aGUg Zmlyc3Qgb3B0aW9uIGl0cyB0aGUgbmF0dXJhbCB3YXkgdG8gZ28uIEhvdyBpcyB0aGUNCj4+Pj4+ cHJvY2Vzc2luZyBpbiB0aGlzIGNhc2UgbW9yZSBjb21wbGV4Pw0KPj4+Pj4NCj4+Pj4+VGh1bWIg dHlwZWQgLSBwbGVhc2UgYmUgdG9sZXJhbnQNCj4+Pj4+DQo+Pj4+Pkx1Y3kgeW9uZyA8bHVjeS55 b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+Pj4+ Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PlNuaXBwZWQuLg0KPj4+Pj4NCj4+Pj4+TXVsdGktUFcgLSBP biBpbmdyZXNzIFBFLCBmcmFtZSBpcyBwbGFjZWQgb250byBlaXRoZXIgYSBMZWFmLW9ubHkNCj4+ Pj4+UDJNUCBQVyAoZm9yIHRyYWZmaWMgY29taW5nIGZyb20gYSBsZWFmIEFDKSwgb3Igb250byBh IFJvb3QvTGVhZg0KPj4+Pj5QMk1QIFBXIChmb3IgdHJhZmZpYyBjb21pbmcgZnJvbSBhIHJvb3Qg QUMpIFtbTFldXSBOb3QgdGhhdCBzaW1wbGUuDQo+Pj4+PllvdSBjb25zdHJ1Y3QgZWl0aGVyIHR3 byBQMk1QIFBXcyB0byBhbGwgb3RoZXIgUEVzIGFuZCBsZXQgZWdyZXNzIFBFDQo+Pj4+PnBlcmZv cm1pbmcgZmlsdGVyaW5nLCBvciBjb25zdHJ1Y3Qgb25lIFAyTVAgUFcgdG8gbGVhZi1vbmx5IFBF cyBhbmQNCj4+Pj4+dHdvIFAyTVAgUFdzIHRvIHJvb3QgYW5kIGxlYWYgUEVzIGFuZCBsZXQgaW5n cmVzcyBQRSBwZXJmb3JtDQo+Pj4+PmZvcndhcmRpbmcgYW5kIGZpbHRlcmluZy4gQm90aCBtYWtl IG5vZGUgcHJvY2VzcyBjb21wbGV4Lg0KPj4+Pj4NCj4+Pj4+W1tMWV1dIFZQTFMgaXMgYnVpbHQg d2l0aCB0aGUgbWVjaGFuaXNtIHV0aWxpemluZyBQMlAgYW5kIFAyTVAgUFcNCj4+Pj4+Zm9yIGRl bGl2ZXJpbmcgdGhlIGZyYW1lcyB0byByZW1vdGUgUEVzLiBXZSBzaG91bGQgdXRpbGl6ZSB0aGVt IHdpdGgNCj4+Pj4+dGhlIG1pbmltaXplZCBjaGFuZ2VzLiBEdWFsIFZMQU4gc29sdXRpb24gaXMg c2ltcGxlciB0aGFuIER1YWwgUFcuDQo+Pj4+Pg0KPj4+Pj5SZWdhcmRzLA0KPj4+Pj5MdWN5DQo+ Pj4+Pg0KPj4+Pj4NCj4+Pj4+SSBzZWUgaG93IDJWTEFOIGlzIHNpbXBsZXIgd2hlbiBQMk1QIFBX J3MgYXJlIGludm9sdmVkLCBJIHRoaW5rLiAgSQ0KPj4+Pj5oYXZlbid0IGhhZCBhbnkgZmlyc3Qg aGFuZCBleHBlcmllbmNlIHdpdGggUDJNUCBQVydzLCBob3dldmVyLCBzbw0KPj4+Pj5kb24ndCBm ZWVsIHRlcnJpYmx5IHN0cm9uZyBhYm91dCB0aGlzIG9iamVjdGlvbi4gIElzIHRoaXMgYSByZWFs DQo+Pj4+PnByb2JsZW0gZm9yIG90aGVycyAobm93IG9yIGluIHRoZSBmdXR1cmUpLCBvciBpcyB0 aGlzIG9iamVjdGlvbiBpbg0KPj4+Pj50aGUgd2VlZHM/DQo+Pj4+Pg0KPj4+Pj5JJ20gbm90IHN1 cmUgdGhlICdhZGRpdGlvbmFsIGNvbXBsZXhpdHknIGlzIG5vdGFibGUsIG9yIGV2ZW4gcmVsZXZh bnQuDQo+Pj4+PkkgZW5jb3VyYWdlIG90aGVycyB0byBzcGVhayB1cCBpZiB0aGV5IGRpc2FncmVl LCBhcyBQMk1QIFBXIGlzIG9ubHkNCj4+Pj4+Y29uY2VwdHVhbCB0byBtZSwgYW5kIEkgYW0gdW5m YW1pbGlhciB3aXRoIHJlYWwtbGlmZSB1c2UgY2FzZXMgZm9yIGl0Lg0KPj4+Pj4NCj4+Pj4+VGhh bmtzLA0KPj4+Pj5Kb3NoDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pk9uIDQvMTgvMTIgMTA6 MzAgQU0sICJMdWN5IHlvbmciDQo+Pj4+PjxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVj eS55b25nQGh1YXdlaS5jb20+PiB3cm90ZToNCj4+Pj4+DQo+Pj4+Pj5QbGVhc2Ugc2VlIGlubGlu ZS4NCj4+Pj4+Pg0KPj4+Pj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+PkZyb206 IFNhbSBDYW8NCj4+Pj4+PlttYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86eXVxdW4u Y2FvQGdtYWlsLmNvbT5dDQo+Pj4+Pj5TZW50OiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiA3OjE0 IEFNDQo+Pj4+Pj5UbzogJ0RhbmllbCBDb2huJzsgTHVjeSB5b25nOyAnUm9nZXJzLCBKb3NoJzsg J0hlbmRlcmlja3gsIFdpbQ0KPj4+Pj4+KFdpbSknOyBnaWxlcy5oZXJvbkBnbWFpbC5jb208bWFp bHRvOmdpbGVzLmhlcm9uQGdtYWlsLmNvbT47DQo+Pj4+Pj5zaW1vbi5kZWxvcmRAZ21haWwuY29t PG1haWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPjsNCj4+Pj4+PkFsZXhhbmRlci5WYWluc2h0 ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLg0KPj4+ Pj4+Y29tPg0KPj4+Pj4+Q2M6IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz47 DQo+Pj4+Pj5WbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPG1haWx0bzpWbGFkaW1pci5LbGVp bmVyQGVjaXRlbGUuY29tPjsNCj4+Pj4+PkFuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPG1haWx0 bzpBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbT47DQo+Pj4+Pj5JZGFuLkthc3BpdEBlY2l0ZWxl LmNvbTxtYWlsdG86SWRhbi5LYXNwaXRAZWNpdGVsZS5jb20+Ow0KPj4+Pj4+TWlzaGFlbC5XZXhs ZXJAZWNpdGVsZS5jb208bWFpbHRvOk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPjsNCj4+Pj4+ PlJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPG1haWx0bzpSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbT4N Cj4+Pj4+PlN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBF LVRyZWUgc29sdXRpb24/DQo+Pj4+Pj4NCj4+Pj4+PlllcywgMiBwd3MgYXJlIG9ubHkgbmVlZGVk IGJldHdlZW4gcGVzIHdpdGggYm90aCByb290IGFuZCBsZWFmIGFjcw0KPj4+Pj4+YWZ0ZXIgaW1w cm92aW5nIER1YWwtUFcgYXBwcm9hY2guIElmIGNvbnNpZGVyIFAyTVAsIER1YWwtUFcNCj4+Pj4+ PmFwcHJvYWNoIHNldHVwIDIgUDJNUCBQV3MgaWYgbmVlZC4gVGhlcmUgaXMgbm8gZGlmZmVyZW5j ZSBiZXR3ZWVuDQo+Pj4+Pj5QMk1QIG9yIG5vcm1hbCBQVyBzZXR1cC4gQnV0LCBjYW4gTGVhZi1B Q3MgYmUgYm91bmQgdG8gUm9vdCBQRSBvZg0KPj4+Pj4+UDJNUCBQVz8NCj4+Pj4+Pg0KPj4+Pj4+ W1tMWV1dIE5vLCBpdCBtYWtlcyBjb21wbGV4IGluIHNldHRpbmcgdXAgUDJNUCBQVy4gU2hvdWxk IGEgUEUgd2l0aA0KPj4+Pj4+Ym90aCByb290IGFuZCBsZWFmIEFDcyBzZXQgdXAgdHdvIG9yIG9u ZSBQMk1QIFBXIHRvIG90aGVyIFBFcyAoc29tZQ0KPj4+Pj4+UEUgaGF2ZSBib3RoIHJvb3QgYW5k IGxlYWYgQUMgYW5kIHNvbWUgb25seSBoYXZlIGxlYWYgQUNzKT8NCj4+Pj4+PlJlZ2FyZHMsDQo+ Pj4+Pj5MdWN5DQo+Pj4+Pj4NCj4+Pj4+PlJlZ2FyZHMsDQo+Pj4+Pj4NCj4+Pj4+Pll1cXVuIChT YW0pIENhbw0KPj4+Pj4+RS1tYWlsOiBZdXF1bi5jYW9AZ21haWwuY29tPG1haWx0bzpZdXF1bi5j YW9AZ21haWwuY29tPg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4+Pj5Gcm9tOiBEYW5pZWwgQ29obg0KPj4+Pj4+W21haWx0bzpEYW5pZWxDQG9y Y2tpdC5jb208bWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbT5dDQo+Pj4+Pj5TZW50OiBUdWVzZGF5 LCBBcHJpbCAxNywgMjAxMiA0OjU2IFBNDQo+Pj4+Pj5UbzogTHVjeSB5b25nOyBSb2dlcnMsIEpv c2g7IEhlbmRlcmlja3gsIFdpbSAoV2ltKTsNCj4+Pj4+PmdpbGVzLmhlcm9uQGdtYWlsLmNvbTxt YWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tPjsNCj4+Pj4+PnNpbW9uLmRlbG9yZEBnbWFpbC5j b208bWFpbHRvOnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+Ow0KPj4+Pj4+QWxleGFuZGVyLlZhaW5z aHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuDQo+ Pj4+Pj5jb20+OyBTYW0gQ2FvDQo+Pj4+Pj5DYzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBu QGlldGYub3JnPjsNCj4+Pj4+PlZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZs YWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb20+Ow0KPj4+Pj4+QW5kcmV3LlNlcmdlZXZAZWNpdGVs ZS5jb208bWFpbHRvOkFuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPjsNCj4+Pj4+PklkYW4uS2Fz cGl0QGVjaXRlbGUuY29tPG1haWx0bzpJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbT47DQo+Pj4+Pj5N aXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbTxtYWlsdG86TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5j b20+Ow0KPj4+Pj4+Um90ZW0uQ29oZW5AZWNpdGVsZS5jb208bWFpbHRvOlJvdGVtLkNvaGVuQGVj aXRlbGUuY29tPg0KPj4+Pj4+U3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNo ZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4+Pj4+Pg0KPj4+Pj4+QWRkaW5nIFNhbSAoYXMg bDJ2cG5AIGlzIGhvbGRpbmcgbWVzc2FnZXMpDQo+Pj4+Pj4NCj4+Pj4+PkRDDQo+Pj4+Pj4NCj4+ Pj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj5Gcm9tOiBMdWN5IHlvbmcNCj4+ Pj4+PlttYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWku Y29tPl0NCj4+Pj4+PlNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE3LCAyMDEyIDEyOjM5IEFNDQo+Pj4+ Pj5UbzogRGFuaWVsIENvaG47IFJvZ2VycywgSm9zaDsgSGVuZGVyaWNreCwgV2ltIChXaW0pOw0K Pj4+Pj4+Z2lsZXMuaGVyb25AZ21haWwuY29tPG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+ Ow0KPj4+Pj4+c2ltb24uZGVsb3JkQGdtYWlsLmNvbTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWls LmNvbT47DQo+Pj4+Pj5BbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxl eGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS4NCj4+Pj4+PmNvbT4NCj4+Pj4+PkNjOiBsMnZwbkBp ZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+Ow0KPj4+Pj4+VmxhZGltaXIuS2xlaW5lckBl Y2l0ZWxlLmNvbTxtYWlsdG86VmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbT47DQo+Pj4+Pj5B bmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5j b20+Ow0KPj4+Pj4+SWRhbi5LYXNwaXRAZWNpdGVsZS5jb208bWFpbHRvOklkYW4uS2FzcGl0QGVj aXRlbGUuY29tPjsNCj4+Pj4+Pk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPG1haWx0bzpNaXNo YWVsLldleGxlckBlY2l0ZWxlLmNvbT47DQo+Pj4+Pj5Sb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbTxt YWlsdG86Um90ZW0uQ29oZW5AZWNpdGVsZS5jb20+DQo+Pj4+Pj5TdWJqZWN0OiBSRTogVGhlIHN0 YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+Pj4+DQo+ Pj4+Pj4NCj4+Pj4+PlNuaXBwZWQsDQo+Pj4+Pj4NCj4+Pj4+PkFzIHdlIGRpc2N1c3NlZCBleHRl bnNpdmVseSBpbiB0aGUgbGlzdCwgYW5kIGFzIHJlZmxlY3RlZCBpbiBnaWxlcw0KPj4+Pj4+c2xp ZGUsIDIgcHdzIGFyZSBvbmx5IG5lZWRlZCBiZXR3ZWVuIHBlcyB3aXRoIGJvdGggcm9vdCBhbmQg bGVhZg0KPj4+Pj4+YWNzLCB3aGljaCB3aWxsIHR5cGljYWxseSBiZSBhIHNtYWxsIG1pbm9yaXR5 Lg0KPj4+Pj4+W1tMWV1dIERvbid0IGtub3cgaWYgdGhlIGFzc3VtcHRpb24gaXMgdHJ1ZS4gRXZl biBpdCBpcyB0aGUgY2FzZSwNCj4+Pj4+PmJvdGggYXBwcm9hY2hlcyBjYW4gYmVuZWZpdCBmcm9t IGl0LiBJIHdhcyBvZmYgZm9yIGEgd2hpbGUgYW5kDQo+Pj4+Pj5jYXB0dXJlcyBzb21lIGRpc2N1 c3Npb25zIG5vdy4NCj4+Pj4+Pg0KPj4+Pj4+QWxzbyBhcyBwZXIgZ2lsZXMgc2xpZGUsIGR1YWwg dmxhbiBjYW4gaGF2ZSBzY2FsYWJpbGl0eSBpc3N1ZXMgZHVlDQo+Pj4+Pj50byBhZGRpdGlvbmFs IGxvb2t1cCBhbmQgZG91YmxlIHVzZSBvZiB2bGFucyBpbiBpbnRlcm5hbCBlbXVsYXRlZA0KPj4+ Pj4+bGFuIGludGVyZmFjZS4gQWxzbyB0aGVyZSBhcmUgcG90ZW50aWFsIGJhY2t3YXJkIGNvbXBh dGliaWxpdHkNCj4+Pj4+Pmlzc3VlcyB3aXRoIHNpbGljb24gdGhhdCBkb2Vzbid0IHN1cHBvcnQg dmxhbiBtYXBwaW5nLg0KPj4+Pj4+W1tMWV1dIEkgd2FzIG5vdCBpbiBJRVRGODMgbWVldGluZyBh bmQgd2FpdCBvbiB0aGUgbWVldGluZyBtaW51dGVzLg0KPj4+Pj4+SSBhbSBub3QgY2xlYXIgb24g YWxsIHRoZSBpc3N1ZXMuIENvdWxkIHlvdSBiZSBtb3JlIHNwZWNpZmljPyBBcyBJDQo+Pj4+Pj5t ZW50aW9uZWQgaW4gYmVsb3csIHR3byBQVyBhcHByb2FjaCBtYWtlcyBWUExTIHRyYW5zcG9ydA0K Pj4+Pj4+Y29uc3RydWN0aW9uIGFuZCBwYWNrZXQgZm9yd2FyZGluZyBtb3JlIGNvbXBsZXgsIEkg Y2FuIHNlZQ0KPj4+Pj4+cG90ZW50aWFsIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXNzdWVzIHdp dGggMiBQVyBzb2x1dGlvbi4NCj4+Pj4+Pg0KPj4+Pj4+UmVnYXJkcywNCj4+Pj4+Pkx1Y3kNCj4+ Pj4+Pg0KPj4+Pj4+UmVnYXJkcywNCj4+Pj4+Pg0KPj4+Pj4+RGFuaWVsDQo+Pj4+Pj4NCj4+Pj4+ PlRodW1iIHR5cGVkIC0gcGxlYXNlIGJlIHRvbGVyYW50DQo+Pj4+Pj4NCj4+Pj4+Pkx1Y3kgeW9u ZyA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3Jv dGU6DQo+Pj4+Pj4NCj4+Pj4+PkluIG15IG1pbmQsIHRoZSBWTEFOIGFwcHJvYWNoIG1lYW5zIGR1 YWwgdmxhbiBtZXRob2QuDQo+Pj4+Pj4NCj4+Pj4+PlRoZSBtYWluIGNvbmNlcm4gZm9yIENXIGFw cHJvYWNoIGlzIGhhcmR3YXJlIHN1cHBvcnQuDQo+Pj4+Pj4NCj4+Pj4+PlR3byBQVyBhcHByb2Fj aCBjYW4gYmUgY29tcGxleCB0b28gaWYgdGhlIFZQTFMgaW5zdGFuY2UgZm9yIEUtVHJlZQ0KPj4+ Pj4+dXNlcyBQMlAgUFcgZm9yIHVuaWNhc3QgdHJhZmZpYyBhbmQgUDJNUCBQVyBmb3IgYnJvYWRj YXN0IGFuZA0KPj4+Pj4+dW5rbm93biB1bmljYXN0IHRyYWZmaWMsIGFuZCBzb21lIFAyTVAgUFdz IGZvciBtdWx0aWNhc3QgdHJhZmZpYy4NCj4+Pj4+Pkl0IG1heSBkb3VibGUgYWxsIG9mIHRoZW0u DQo+Pj4+Pj4NCj4+Pj4+PkUtdHJlZSBpcyBhbiBFdGhlcm5ldCBzZXJ2aWNlIGFuZCB0aGVyZSBp cyBhbHJlYWR5IFZMQU4gYmFzZWQNCj4+Pj4+PnNvbHV0aW9uIGluIElFRUUsIGNhbiB3ZSBqdXN0 IHV0aWxpemUgaXQgd2l0aG91dCBjb21wbGljYXRpbmcgVlBMUw0KPj4+Pj4+dHJhbnNwb3J0IGNv bnN0cnVjdGlvbj8gVGhpcyBhbHNvIG1ha2VzIGludGVyd29ya2luZyB3aXRoIEV0aCBvbmx5DQo+ Pj4+Pj5uZXR3b3JrIGVhc2llci4NCj4+Pj4+Pg0KPj4+Pj4+Q2hlZXJzLA0KPj4+Pj4+THVjeQ0K Pj4+Pj4+DQo+Pj4+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+RnJvbTogUm9n ZXJzLCBKb3NoDQo+Pj4+Pj5bbWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29tPG1haWx0bzpq b3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbT5dDQo+Pj4+Pj5TZW50OiBNb25kYXksIEFwcmlsIDE2LCAy MDEyIDg6MzUgQU0NCj4+Pj4+PlRvOiBMdWN5IHlvbmc7IEhlbmRlcmlja3gsIFdpbSAoV2ltKTsN Cj4+Pj4+PidnaWxlcy5oZXJvbkBnbWFpbC5jb208bWFpbHRvOmdpbGVzLmhlcm9uQGdtYWlsLmNv bT4nOw0KPj4+Pj4+J3NpbW9uLmRlbG9yZEBnbWFpbC5jb208bWFpbHRvOnNpbW9uLmRlbG9yZEBn bWFpbC5jb20+JzsNCj4+Pj4+PidBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWls dG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZQ0KPj4+Pj4+Lg0KPj4+Pj4+Yw0KPj4+Pj4+ b20+Jw0KPj4+Pj4+Q2M6ICdsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+JzsN Cj4+Pj4+PidWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPG1haWx0bzpWbGFkaW1pci5LbGVp bmVyQGVjaXRlbGUuY29tPicNCj4+Pj4+PjsgJ0FuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPG1h aWx0bzpBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbT4nOw0KPj4+Pj4+J0lkYW4uS2FzcGl0QGVj aXRlbGUuY29tPG1haWx0bzpJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbT4nOw0KPj4+Pj4+J01pc2hh ZWwuV2V4bGVyQGVjaXRlbGUuY29tPG1haWx0bzpNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT4n Ow0KPj4+Pj4+J1JvdGVtLkNvaGVuQGVjaXRlbGUuY29tPG1haWx0bzpSb3RlbS5Db2hlbkBlY2l0 ZWxlLmNvbT4nDQo+Pj4+Pj5TdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hl cyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+Pj4+DQo+Pj4+Pj5JIGJlbGlldmUgdGhlIGlu aXRpYWwgcXVlc3Rpb24gd2FzIGluIHJlZ2FyZCB0byB0aGUgQ1cgbWV0aG9kLiAgQXJlDQo+Pj4+ Pj55b3Ugc2F5aW5nIHRoYXQgeW91IG5vIGxvbmdlciBhcmUgaW50ZXJlc3RlZCBpbiB0aGF0IG1l dGhvZCBpbg0KPj4+Pj4+cHJlZmVyZW5jZSBvZiB0aGUgZHVhbCB2bGFuIG1ldGhvZD8NCj4+Pj4+ Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pkx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb208 bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+ Pj4+QWdyZWUgd2l0aCBXaW0uIFZMQU4gYXBwcm9hY2ggaXMgdGhlIGJlc3Qgc29sdXRpb24gZm9y IEUtVHJlZS4NCj4+Pj4+Pg0KPj4+Pj4+THVjeQ0KPj4+Pj4+DQo+Pj4+Pj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+RnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 bDJ2cG4tYm91bmNlc0BpZXRmLm9yZz4NCj4+Pj4+PlttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZz5dIE9uDQo+Pj4+Pj5CZWhhbGYgT2Yg SGVuZGVyaWNreCwgV2ltIChXaW0pDQo+Pj4+Pj5TZW50OiBUaHVyc2RheSwgQXByaWwgMTIsIDIw MTIgMjowMyBBTQ0KPj4+Pj4+VG86ICdnaWxlcy5oZXJvbkBnbWFpbC5jb208bWFpbHRvOmdpbGVz Lmhlcm9uQGdtYWlsLmNvbT4nOw0KPj4+Pj4+J3NpbW9uLmRlbG9yZEBnbWFpbC5jb208bWFpbHRv OnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+JzsNCj4+Pj4+PidBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZQ0KPj4+Pj4+Lg0K Pj4+Pj4+Yw0KPj4+Pj4+b20+Jw0KPj4+Pj4+Q2M6ICdsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2 cG5AaWV0Zi5vcmc+JzsNCj4+Pj4+PidWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPG1haWx0 bzpWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPicNCj4+Pj4+PjsgJ0FuZHJldy5TZXJnZWV2 QGVjaXRlbGUuY29tPG1haWx0bzpBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbT4nOw0KPj4+Pj4+ J0lkYW4uS2FzcGl0QGVjaXRlbGUuY29tPG1haWx0bzpJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbT4n Ow0KPj4+Pj4+J01pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPG1haWx0bzpNaXNoYWVsLldleGxl ckBlY2l0ZWxlLmNvbT4nOw0KPj4+Pj4+J1JvdGVtLkNvaGVuQGVjaXRlbGUuY29tPG1haWx0bzpS b3RlbS5Db2hlbkBlY2l0ZWxlLmNvbT4nDQo+Pj4+Pj5TdWJqZWN0OiBSZTogVGhlIHN0YXR1cyBv ZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+Pj4+DQo+Pj4+Pj5U aGUgdmxhbiBhcHByb2FjaCBpcyBzdXBlcmlvciBhcyBpdCBhbHNvIHdvcmtzIGZvciBldGggb25s eQ0KPj4+Pj4+bmV0d29ya3MsIGV0Yy4gT24gdG9wIHNvbWUgdmVuZG9ycyBpbmRpY2F0ZSBodyBp c3N1ZXMgd2l0aCB0aGUgY3cNCj4+Pj4+PmFwcHJvYWNoLiBBcyBzdWNoIHdlIGhhdmUgZHJvcHBl ZCBtb3JlIG9yIGxlc3MgdGhlIGN3IGFwcHJvYWNoLg0KPj4+Pj4+DQo+Pj4+Pj5DaGVlcnMsDQo+ Pj4+Pj5XaW0NCj4+Pj4+Pl9fX19fX19fX19fX19fX19fDQo+Pj4+Pj5zZW50IGZyb20gYmxhY2ti ZXJyeQ0KPj4+Pj4+DQo+Pj4+Pj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+Pj4+Pj5G cm9tOiBHaWxlcyBIZXJvbg0KPj4+Pj4+W21haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb208bWFp bHRvOmdpbGVzLmhlcm9uQGdtYWlsLmNvbT5dDQo+Pj4+Pj5TZW50OiBUaHVyc2RheSwgQXByaWwg MTIsIDIwMTIgMDg6MjIgQU0NCj4+Pj4+PlRvOiBTaW1vbiBEZWxvcmQNCj4+Pj4+PjxzaW1vbi5k ZWxvcmRAZ21haWwuY29tPG1haWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPj47IEFsZXhhbmRl cg0KPj4+Pj4+VmFpbnNodGVpbg0KPj4+Pj4+PEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUu Y29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZQ0KPj4+Pj4+bGUNCj4+Pj4+Pi5j b20+Pg0KPj4+Pj4+Q2M6IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4NCj4+ Pj4+PjxsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+PjsgVmxhZGltaXIgS2xl aW5lcg0KPj4+Pj4+PFZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWly LktsZWluZXJAZWNpdGVsZS5jb20+Pg0KPj4+Pj4+Ow0KPj4+Pj4+QW5kcmV3IFNlcmdlZXYNCj4+ Pj4+PjxBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3LlNlcmdlZXZAZWNp dGVsZS5jb20+PjsNCj4+Pj4+PklkYW4gS2FzcGl0DQo+Pj4+Pj48SWRhbi5LYXNwaXRAZWNpdGVs ZS5jb208bWFpbHRvOklkYW4uS2FzcGl0QGVjaXRlbGUuY29tPj47DQo+Pj4+Pj5NaXNoYWVsIFdl eGxlcg0KPj4+Pj4+PE1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPG1haWx0bzpNaXNoYWVsLldl eGxlckBlY2l0ZWxlLmNvbT4+Ow0KPj4+Pj4+Um90ZW0gQ29oZW4NCj4+Pj4+PjxSb3RlbS5Db2hl bkBlY2l0ZWxlLmNvbTxtYWlsdG86Um90ZW0uQ29oZW5AZWNpdGVsZS5jb20+Pg0KPj4+Pj4+U3Vi amVjdDogUmU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1 dGlvbj8NCj4+Pj4+Pg0KPj4+Pj4+U29ycnkgLSB0aGUgImFub255bW91cyBwcmVzZW50YXRpb24i IHdhcyBtaW5lLiAgSSBzaG91bGQgcG9zc2libHkNCj4+Pj4+PmhhdmUgcHV0IGluIGEgdGhpcmQg Y29sdW1uIG9uIHRoZSBDVyBhcHByb2FjaC4gIEFuZCBob3BlZnVsbHkgdGhlDQo+Pj4+Pj5taW51 dGVzIHdpbGwgYmUgcG9zdGVkIHNvb24uDQo+Pj4+Pj4NCj4+Pj4+PldlIGhhZCB2YXJpb3VzIGRp c2N1c3Npb25zLCBhcyBTaW1vbiBzdGF0ZWQsIGFuZCBjb25zZW5zdXMgc2VlbWVkDQo+Pj4+Pj50 byBiZSBmb3JtaW5nIGFyb3VuZCB0aGUgdHdvIGFsdGVybmF0aXZlcyBvZiB0d28gUFdFcyBvciB0 d28gVkxBTnMuDQo+Pj4+Pj5JIGJlbGlldmUgdGhyZWUgb2YgdGhlIGF1dGhvcnMgb2YgdGhlIENX IGFwcHJvYWNoIGFyZSBhbHNvIGF1dGhvcnMNCj4+Pj4+Pm9mIHRoZSB0d28gVkxBTiBhcHByb2Fj aCBhbmQgb25lIGlzIGFsc28gYW4gYXV0aG9yIG9mIHRoZSB0d28gUFdFDQo+Pj4+Pj5hcHByb2Fj aC4gU28gcGVyaGFwcyBpdCdzIGJlc3QgdG8gbGV0IHRob3NlIGZvdXIgaW5kaXZpZHVhbHMgc2F5 DQo+Pj4+Pj53aGljaCBhcHByb2FjaCB0aGV5IHByZWZlciBhbmQgd2h5Pw0KPj4+Pj4+DQo+Pj4+ Pj5HaWxlcw0KPj4+Pj4+DQo+Pj4+Pj5PbiAxMC8wNC8yMDEyIDAwOjQ1LCAiU2ltb24gRGVsb3Jk Ig0KPj4+Pj4+PHNpbW9uLmRlbG9yZEBnbWFpbC5jb208bWFpbHRvOnNpbW9uLmRlbG9yZEBnbWFp bC5jb20+PiB3cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+PiBIaSBBbGV4YW5kZXIsDQo+Pj4+Pj4+DQo+ Pj4+Pj4+IFlvdSBhcmUgcmlnaHQsIG5vIGRpc2N1c3Npb24gb24gdGhlIFdHIG1haWxpbmcgbGlz dCByZWNlbnRseSwgYnV0DQo+Pj4+Pj4+IHRoZXJlIGhhdmUgYmVlbiBzdWJzdGFudGlhbCBkaXNj dXNzaW9ucyBhbW9uZyB0aGUgYXV0aG9ycyBvZg0KPj4+Pj4+PiB2YXJpb3VzIHNvbHV0aW9uIGRy YWZ0cyBvZmYgdGhlIG1haWxpbmcgbGlzdC4gQXMgZmFyIGFzIEkga25vdywNCj4+Pj4+Pj4gbm8g Y29uc2Vuc3VzIHlldCBiZWZvcmUgaWV0ZjgzLCBub3Qgc3VyZSB0aGUgcHJvZ3Jlc3MgaW4gdGhl DQo+Pj4+Pj4+IFBhcmlzIFdHIG1lZXRpbmcuIEkgdGhpbmsgdGhlIENXIGFwcHJvYWNoIGhhcyBu b3QgYmVlbiByZWplY3RlZA0KPj4+Pj4+PiBieSB0aGUgV0cgeWV0LCBvciB0aGUgV0cgaGFzIG5v dCB5ZXQgZGVjaWRlZCBvbiB3aGljaCBvbmUgdG8gYWRvcHQuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFNp bW9uDQo+Pj4+Pj4+DQo+Pj4+Pj4+IDIwMTIvNC84IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+Pj4+ Pj4+IDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZh aW5zaHRlaW5AZWNpDQo+Pj4+Pj4+IHRlDQo+Pj4+Pj4+IGxlLmNvbT4+DQo+Pj4+Pj4+DQo+Pj4+ Pj4+PiAgSGkgYWxsLA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFVuZm9ydHVuYXRlbHkgSSBoYXZlIG5v dCBiZWVuIGFibGUgdG8gYXR0ZW5kIHRoZSBQYXJpcyBJRVRGLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ IEhvd2V2ZXIsIGxvb2tpbmcgdXAgdGhlIEwyVlBOIHByb2NlZWRpbmdzLCBJJ3ZlIGZvdW5kIGEg c2hvcnQNCj4+Pj4+Pj4+IGFub255bW91cyBwcmVzZW50YXRpb24gY2FsbGVkICJFLVRyZWUgVXBk YXRlIiAgKA0KPj4+Pj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84My9zbGlk ZXMvc2xpZGVzLTgzLWwydnBuLTEucHB0eCkuDQo+Pj4+Pj4+PiBUaGlzIHByZXNlbnRhdGlvbiBk aXNjdXNzZXMgdGhlIGRpZmZlcmVuY2VzIG9mIHRoZSBFLVRyZWUNCj4+Pj4+Pj4+IGFwcHJvYWNo ZXMgYmFzZWQgb24gZGVkaWNhdGVkIFZMQU5zIChhcyBpbg0KPj4+Pj4+Pj4gaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jYW8tbDJ2cG4tdnBscy1ldHJlZS8/aW5jbA0KPj4+ Pj4+Pj4gdWQNCj4+Pj4+Pj4+IGVfdA0KPj4+Pj4+Pj4gZXh0PTEpIGFuZCBtdWx0aXBsZSBQV3Mg YmV0d2VlbiB0aGUgUEVzIChhcyBpbg0KPj4+Pj4+Pj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1yYW0tbDJ2cG4tZXRyZWUtbXVsdGlwbGUtcA0KPj4+Pj4+Pj4gdy8NCj4+ Pj4+Pj4+ID9pbg0KPj4+Pj4+Pj4gY2x1ZGVfdGUNCj4+Pj4+Pj4+IHh0PTEpDQo+Pj4+Pj4+PiBh bmQgY29tcGxldGVseSBpZ25vcmVzIHRoZSBzb2x1dGlvbiBiYXNlZCBvbiB1c2FnZSBvZiB0aGUg Q1cgaW4NCj4+Pj4+Pj4+IHRoZSBQV3MgY29ubmVjdGluZyB0aGUgUEVzIChhcyBpbg0KPj4+Pj4+ Pj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rZXktbDJ2cG4tdnBscy1l dHJlZS8/aW5jbA0KPj4+Pj4+Pj4gdWQNCj4+Pj4+Pj4+IGVfdA0KPj4+Pj4+Pj4gZXh0PTENCj4+ Pj4+Pj4+ICkuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaGUgTWlu dXRlcyBvZiB0aGUgUGFyaXMgTDJWUE4gc2Vzc2lvbiBhcmUgbm90IHlldCBhdmFpbGFibGUsDQo+ Pj4+Pj4+PiBidXQgSSB3b25kZXIgd2hldGhlciB0aGUgV0cgaGFzIHRha2VuIGEgZGVjaXNpb24g dG8gcmVqZWN0IHRoZQ0KPj4+Pj4+Pj4gYXBwcm9hY2ggYmFzZWQgb24gdGhlIENXIHVzYWdlPyBJ IGRvIG5vdCByZW1lbWJlciBhbnkgcmVjZW50DQo+Pj4+Pj4+PiBkaXNjdXNzaW9uIG9mIHRoaXMg dG9waWMgb24gdGhlIFdHIG1haWxpbmcgbGlzdC4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4NCj4+Pj4+Pj4+IFJlZ2FyZHMsIGFuZCBsb3RzIG9mIHRoYW5rcyBpbiBhZHZhbmNlLA0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+IFNhc2hhDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQg Zm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQNCj4+Pj4+Pj4+IGNvbnRhaW5zIGluZm9ybWF0aW9u IHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlDQo+Pj4+Pj4+PiBwcm9wcmll dGFyeSB0byBFQ0kNCj4+Pj4+Pg0KPj4+Pj4+Pj4gVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZQ0KPj4+Pj4+Pj4gaW5mb3JtIHVz IGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsDQo+ Pj4+Pj4+PiBhbmQgYWxsIGNvcGllcyB0aGVyZW9mLg0KPj4+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+ DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj5UaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lcg0KPj4+Pj4+Q2FibGUgcHJvcHJp ZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwNCj4+ Pj4+Pm9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJs ZS4gVGhpcyBFLW1haWwNCj4+Pj4+PmlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0 aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2gNCj4+Pj4+Pml0IGlzIGFkZHJlc3NlZC4N Cj4+Pj4+PklmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1h aWwsIHlvdSBhcmUNCj4+Pj4+PmhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9u LCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yDQo+Pj4+Pj5hY3Rpb24gdGFrZW4gaW4gcmVsYXRp b24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzDQo+Pj4+Pj5FLW1h aWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2 ZQ0KPj4+Pj4+cmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBpbW1lZGlhdGVseQ0KPj4+Pj4+YW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3Jp Z2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZA0KPj4+Pj4+YW55IHByaW50b3V0 Lg0KPj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+VGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUNCj4+Pj4+cHJvcHJpZXRh cnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3INCj4+ Pj4+c3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBU aGlzIEUtbWFpbCBpcw0KPj4+Pj5pbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0DQo+Pj4+PmlzIGFkZHJlc3NlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwNCj4+Pj4+eW91 IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9u LA0KPj4+Pj5jb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRl bnRzIG9mIGFuZA0KPj4+Pj5hdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBw cm9oaWJpdGVkIGFuZCBtYXkgYmUNCj4+Pj4+dW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5DQo+Pj4+PnRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueQ0KPj4+ Pj5jb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo+Pj4+DQo+Pj4+DQo+Pj4+ IFRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUg V2FybmVyIENhYmxlDQo+Pj4+cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZp bGVnZWQsIGNvbmZpZGVudGlhbCwgb3INCj4+Pj5zdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdp bmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzDQo+Pj4+aW50ZW5kZWQgc29s ZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBp cw0KPj4+PmFkZHJlc3NlZC4NCj4+Pj5JZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieQ0KPj4+Pm5vdGlmaWVkIHRoYXQgYW55 IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uDQo+Pj4+dGFr ZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlz IEUtbWFpbA0KPj4+PmlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcw0KPj4+PkUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseQ0KPj4+PmRlbGV0ZSB0 aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQu DQo+Pj4+IFRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQg b25seSBhbmQgY29udGFpbnMNCj4+Pj5pbmZvcm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJQUwg YW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kNCj4+Pj5UZWxlY29tLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlDQo+Pj4+aW5m b3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdp bmFsIGFuZA0KPj4+PmFsbCBjb3BpZXMgdGhlcmVvZi4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+DQo+Pj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IEwydnBuIG1haWxpbmcgbGlz dA0KPj4+PiBMMnZwbkBpZXRmLm9yZzxtYWlsdG86TDJ2cG5AaWV0Zi5vcmc+DQo+Pj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDJ2cG4NCj4+Pj4NCj4+Pj4NCj4+Pj4g RW5kIG9mIEwydnBuIERpZ2VzdCwgVm9sIDk1LCBJc3N1ZSAyNQ0KPj4+PiAqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKg0KPj4NCj4+DQo+PlRoaXMgRS1tYWlsIGFuZCBhbnkgb2Yg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlDQo+PnByb3ByaWV0 YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1 YmplY3QNCj4+dG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhp cyBFLW1haWwgaXMgaW50ZW5kZWQNCj4+c29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcw0KPj5hZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdQ0KPj5hcmUgaGVyZWJ5 IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywg b3INCj4+YWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0 YWNobWVudHMgdG8gdGhpcw0KPj5FLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5 IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZA0KPj50aGlzIEUtbWFpbCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZA0KPj5wZXJtYW5lbnRs eSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55 DQo+PnByaW50b3V0Lg0KPg0KPg0KPlRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlDQo+cHJvcHJpZXRhcnkgaW5mb3JtYXRp b24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0bw0KPmNv cHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGlu dGVuZGVkIHNvbGVseQ0KPmZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0 byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdQ0KPmFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQNCj50aGF0IGFu eSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBp bg0KPnJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBF LW1haWwgaXMgc3RyaWN0bHkNCj5wcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluDQo+ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZQ0KPm9yaWdpbmFs IGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0KDQoNClRoaXMg RS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVy IENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25m aWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5l ciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVy ZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWlu Zywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0 YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJl IHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUg dGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0 Lg0K From david.i.allan@ericsson.com Thu Apr 26 09:18:15 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C3F21E811D for ; Thu, 26 Apr 2012 09:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 tsIcQ5OZYtFU for ; Thu, 26 Apr 2012 09:18:14 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id DD88221E810A for ; Thu, 26 Apr 2012 09:18:13 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3QGI9YS012743; Thu, 26 Apr 2012 11:18:10 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.69]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 26 Apr 2012 12:18:04 -0400 From: David Allan I To: "Rogers, Josh" , Lucy yong , "Fedyk, Donald (Don)" , Daniel Cohn , "l2vpn@ietf.org" Date: Thu, 26 Apr 2012 12:18:02 -0400 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0jxcb6Tv97zwm+Q6qF7xP4dBizVwAAK3igAABc2sA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD52324EF4C2@EUSAACMS0703.eamcs.ericsson.se> References: <2691CE0099834E4A9C5044EEC662BB9D3264C406@dfweml505-mbx> 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_60C093A41B5E45409A19D42CF7786DFD52324EF4C2EUSAACMS0703e_" MIME-Version: 1.0 X-BeenThere: l2vpn@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, 26 Apr 2012 16:18:15 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD52324EF4C2EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI Josh: My reference to a C-tag is a customer administered tag with ethertype 0x8= 100. My reference to an S-tag is a provider administered tag with ethertype 0x8= 8a8. My supposition is the customer needs to advise the provider of what C-tag t= hey want mapped to which service if they subscribe to multiple tagged servi= ces, otherwise no tag information needs to be shared, all customer traffic = is mapped to a common service . The provider translates the work order to an S-tag value to infer from eith= er the port or the C-tag and configures the customer facing PB accordingly. Dave -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Thursday, April 26, 2012 12:01 PM To: Lucy yong; David Allan I; Fedyk, Donald (Don); Daniel Cohn; l2vpn@ietf.= org Subject: Re: The status of the approaches to the E-Tree solution? Lucy, I'm not sure that is true. I think you're having the same trouble I had, I= was considering the tag the customer applies to their egress traffic as a = 'inside S-Tag', but others have stated they would consider this a 'C-Tag', = even though it is used on the SP's network (to distinguish service on the U= NI) You'll note in my most recently explanation of the two scenarios, I in= tentionally avoided referring to this ambiguous tag as either an S-Tag or C= -Tag. Dave, can you clarify 'C-Tag' in your statement? When you say: > For 'a', a C-tagged frame simply has the s-tag inserted.... Do you mean that the SP pushes the S-tag on in front of the coordinated tag= the customer uses to ensure traffic enters the correct service? Or do you= mean something else entirely? Wait... I thought we agreed to not discuss this 'A' method any longer, as i= t leads to some horrible black hole of inconsequential tangents? -Josh --_000_60C093A41B5E45409A19D42CF7786DFD52324EF4C2EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
HI=20 Josh:
 
My reference to a C-tag is a customer= =20 administered  tag with=20  ethertype 0x8100.
My reference to an S-tag i= s a=20 provider administered  tag with= =20 ethertype 0x88a8.
 =
My supposition is the cust= omer needs=20 to advise the provider of what C-tag they want mapped to which service if t= hey=20 subscribe to multiple tagged services, otherwise no tag information needs t= o be=20 shared, all customer traffic is mapped to a common  service .
 =
The provider transla= tes the=20 work order to an S-tag value to infer from either the port or the C-tag and= =20 configures the customer facing PB accordingly.
 =
 =
Dave



-----Original Message-----
From: Rogers, Josh= =20 [mailto:josh.rogers@twcable.com]
Sent:= =20 Thursday, April 26, 2012 12:01 PM
To: Lucy yong; David Allan I; Fedyk, D= onald=20 (Don); Daniel Cohn; l2vpn@ietf.org
Subject: Re: The status of the approa= ches=20 to the E-Tree solution?

Lucy,

I'm not sure that is true. = ; I=20 think you're having the same trouble I had, I was considering the tag the=20 customer applies to their egress traffic as a 'inside S-Tag', but others ha= ve=20 stated they would consider this a 'C-Tag', even though it is used on the SP= 's=20 network (to distinguish service on the UNI)  You'll note in my most=20 recently explanation of the two scenarios, I intentionally avoided referrin= g to=20 this ambiguous tag as either an S-Tag or C-Tag.

Dave, can you clarif= y=20 'C-Tag' in your statement?  When you say:

> For 'a', a C-tag= ged=20 frame simply has the s-tag inserted....

Do you mean that the SP push= es=20 the S-tag on in front of the coordinated tag the customer uses to ensure tr= affic=20 enters the correct service?  Or do you mean something else=20 entirely?

Wait… I thought we agreed to not discuss this 'A' me= thod any=20 longer, as it leads to some horrible black hole of inconsequential=20 tangents?

-Josh


 <snipped.to end>

 
=

--_000_60C093A41B5E45409A19D42CF7786DFD52324EF4C2EUSAACMS0703e_-- From giles.heron@gmail.com Fri Apr 27 05:57:01 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F1621F85BE for ; Fri, 27 Apr 2012 05:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAXoTl94zYwO for ; Fri, 27 Apr 2012 05:57:01 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC2E821F85AE for ; Fri, 27 Apr 2012 05:57:00 -0700 (PDT) Received: by werb10 with SMTP id b10so519606wer.31 for ; Fri, 27 Apr 2012 05:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:mime-version:content-type:content-transfer-encoding; bh=y7yvx4TQ9S/Q0W1VchnzvDxfYBkiYArvYfDG1ojfz2k=; b=pn1gowQXANq+2XEnMnFoNOnsiW230eMmbKJu/49IpSG5UJckgx/du3S1idDdafmTye MApJiefPwBmUKZTm+lfwElY6bU9oKWpL+anYChZlVnLItEOvzgnWwEQmQXxqOCat6i+z 9FRrp/6ZpM+VtbYfG+7r59sOGHcdqePhYcJIBZNNuRGmn9h4oeBtRH/ARd8YVg0e0lT+ sqe6RKeZxADKEGexvCW1e9TxqRGZzm7sJnO6rjHwkaox9X6xw8aJYsdbvxmdudY0XNPv 7gBCfKwp1E93W3BfeIasZX6Gj3FOAZmi1DO1g+YzF3aSQHk0KDQVZzqN7hMDBVx/BHAb K5Aw== Received: by 10.180.83.38 with SMTP id n6mr5850590wiy.4.1335531419738; Fri, 27 Apr 2012 05:56:59 -0700 (PDT) Received: from [10.147.56.203] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id k6sm4438533wie.9.2012.04.27.05.56.58 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Apr 2012 05:56:58 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 27 Apr 2012 13:57:19 +0100 Subject: Interest in IS-IS VPLS From: Giles Heron To: Message-ID: Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHug== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-BeenThere: l2vpn@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, 27 Apr 2012 12:57:01 -0000 Hi, At the IETF meeting in Paris I took an action (as noted in the minutes) to poll the WG to see if there was any interest (other than by the authors of course) in progressing the IS-IS VPLS draft. Would you please respond to this email indicating whether or not you have interest in seeing this draft progress, ideally giving reasoning for your position. It'd be especially interesting to see responses from service providers of course. If there are no (or very few) responses to this email then Nabil and I will probably interpret that as meaning there's insufficient interest to progress. Of course it may just mean that you all missed this email in the deluge of debate on E-Tree ;) Giles From josh.rogers@twcable.com Fri Apr 27 07:44:20 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3EB21F8684 for ; Fri, 27 Apr 2012 07:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.656 X-Spam-Level: X-Spam-Status: No, score=-0.656 tagged_above=-999 required=5 tests=[AWL=0.807, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 oAlG5sT1kCgf for ; Fri, 27 Apr 2012 07:44:19 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9496821F85E6 for ; Fri, 27 Apr 2012 07:44:19 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,491,1330923600"; d="scan'208";a="373465429" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 27 Apr 2012 10:44:06 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Fri, 27 Apr 2012 10:44:18 -0400 From: "Rogers, Josh" To: Giles Heron , "l2vpn@ietf.org" Date: Fri, 27 Apr 2012 10:44:16 -0400 Subject: Re: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0khDlESzEQnIcMTGmVwA/iWvf9Gg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: l2vpn@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, 27 Apr 2012 14:44:20 -0000 I am not interested. I prefer already available methods of doing Layer 2 VPN (intentionally avoiding the term VPLS here), and don't see or appreciate any benefits that an ISIS version might offer. -Josh On 4/27/12 7:57 AM, "Giles Heron" wrote: >Hi, > >At the IETF meeting in Paris I took an action (as noted in the minutes) to >poll the WG to see if there was any interest (other than by the authors of >course) in progressing the IS-IS VPLS draft. > >Would you please respond to this email indicating whether or not you have >interest in seeing this draft progress, ideally giving reasoning for your >position. It'd be especially interesting to see responses from service >providers of course. > >If there are no (or very few) responses to this email then Nabil and I >will >probably interpret that as meaning there's insufficient interest to >progress. Of course it may just mean that you all missed this email in >the >deluge of debate on E-Tree ;) > >Giles > > This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From prvs=346489e926=edwin.mallette@bhnis.com Fri Apr 27 11:31:20 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D6F21F8615 for ; Fri, 27 Apr 2012 11:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 aviHmnZt2Tgi for ; Fri, 27 Apr 2012 11:31:19 -0700 (PDT) Received: from mx2.mybrighthouse.com (MX3.mybrighthouse.com [209.16.122.105]) by ietfa.amsl.com (Postfix) with ESMTP id 0B47F21F8598 for ; Fri, 27 Apr 2012 11:31:18 -0700 (PDT) Received: from pps.filterd (mx3 [127.0.0.1]) by mx3.mybrighthouse.com (8.14.3/8.14.3) with SMTP id q3RIU5P9011528; Fri, 27 Apr 2012 14:31:17 -0400 Received: from cnedcex2.corp.local ([10.225.5.12]) by mx3.mybrighthouse.com with ESMTP id 14g05708v7-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Apr 2012 14:31:17 -0400 Received: from CNEDCEX3.corp.local ([fe80::ac6f:a581:866a:5f86]) by CNEDCEX2.corp.local ([::1]) with mapi id 14.02.0298.004; Fri, 27 Apr 2012 14:30:44 -0400 From: "Mallette, Edwin J." To: "Rogers, Josh" , Giles Heron , "l2vpn@ietf.org" Subject: Re: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAMHfkA///8NIA= Date: Fri, 27 Apr 2012 18:30:44 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.225.1.248] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1203120001 definitions=main-1204270215 X-BeenThere: l2vpn@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, 27 Apr 2012 18:31:20 -0000 I'm also not interested in seeing the ISIS-VPLS draft progress. My rationale for this is very similar to the reasons Josh listed below. Regards, Ed On 4/27/12 4:44 PM, "Rogers, Josh" wrote: >I am not interested. I prefer already available methods of doing Layer 2 >VPN (intentionally avoiding the term VPLS here), and don't see or >appreciate any benefits that an ISIS version might offer. > >-Josh > > >On 4/27/12 7:57 AM, "Giles Heron" wrote: > >>Hi, >> >>At the IETF meeting in Paris I took an action (as noted in the minutes) >>to >>poll the WG to see if there was any interest (other than by the authors >>of >>course) in progressing the IS-IS VPLS draft. >> >>Would you please respond to this email indicating whether or not you have >>interest in seeing this draft progress, ideally giving reasoning for your >>position. It'd be especially interesting to see responses from service >>providers of course. >> >>If there are no (or very few) responses to this email then Nabil and I >>will >>probably interpret that as meaning there's insufficient interest to >>progress. Of course it may just mean that you all missed this email in >>the >>deluge of debate on E-Tree ;) >> >>Giles >> >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. ________________________________ CONFIDENTIALITY NOTICE: This e-mail may contain information that is privile= ged, confidential or otherwise protected from disclosure. If you are not th= e intended recipient of this e-mail, please notify the sender immediately b= y return e-mail, purge it and do not disseminate or copy it. From lucy.yong@huawei.com Fri Apr 27 11:44:35 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A498121F8714 for ; Fri, 27 Apr 2012 11:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] 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 zhD5nzKWqufM for ; Fri, 27 Apr 2012 11:44:35 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C5E0A21F86F7 for ; Fri, 27 Apr 2012 11:44:34 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFI55227; Fri, 27 Apr 2012 14:44:34 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 27 Apr 2012 11:43:16 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Fri, 27 Apr 2012 11:43:21 -0700 From: Lucy yong To: Giles Heron , "l2vpn@ietf.org" Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQ Date: Fri, 27 Apr 2012 18:43:21 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> 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.158.113] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@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, 27 Apr 2012 18:44:35 -0000 Hi Giles, It seems that the IS-IS VPLS provides the solution for a scalable data cent= er network as mentioned in the draft. I am not sure it is proper to weight = service providers more on this. I can see if a service provider already dep= loyed existing VPLS, the gain from IS-IS VPLS is less than the cost on upgr= ading all the edge devices to support the solution.=20 However, for data center network, IS-IS VPLS could be a useful solution. It= simplifies current VPLS mechanism, provides a good scalability, and requir= es IP only function on core switches.=20 A vendor provides devices for both service provider network and data center= network, the solution brings a synergy in leveraging VPLS solution into DC= .=20 Thus, I like to see this work moving forward. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of G= iles Heron Sent: Friday, April 27, 2012 7:57 AM To: l2vpn@ietf.org Subject: Interest in IS-IS VPLS Hi, At the IETF meeting in Paris I took an action (as noted in the minutes) to poll the WG to see if there was any interest (other than by the authors of course) in progressing the IS-IS VPLS draft. Would you please respond to this email indicating whether or not you have interest in seeing this draft progress, ideally giving reasoning for your position. It'd be especially interesting to see responses from service providers of course. If there are no (or very few) responses to this email then Nabil and I will probably interpret that as meaning there's insufficient interest to progress. Of course it may just mean that you all missed this email in the deluge of debate on E-Tree ;) Giles From gregory.mirsky@ericsson.com Fri Apr 27 12:01:55 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D30621F8783 for ; Fri, 27 Apr 2012 12:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.085 X-Spam-Level: X-Spam-Status: No, score=-6.085 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, J_CHICKENPOX_22=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 6Q547cqf-pUH for ; Fri, 27 Apr 2012 12:01:54 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id D76DB21F855B for ; Fri, 27 Apr 2012 12:01:53 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3RJ1ERT015225; Fri, 27 Apr 2012 14:01:49 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.10]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 27 Apr 2012 15:01:46 -0400 From: Gregory Mirsky To: Lucy yong , Giles Heron , "l2vpn@ietf.org" Date: Fri, 27 Apr 2012 15:01:44 -0400 Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQAALQiZA= Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> 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-BeenThere: l2vpn@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, 27 Apr 2012 19:01:55 -0000 Hi Lucy, et.al, If we think that IS-IS VPLS might be applicable only to data centers then p= erhaps l2vpn WG is not the proper WG but NVO3 might be the one. Regards, Greg -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of L= ucy yong Sent: Friday, April 27, 2012 11:43 AM To: Giles Heron; l2vpn@ietf.org Subject: RE: Interest in IS-IS VPLS Hi Giles, It seems that the IS-IS VPLS provides the solution for a scalable data cent= er network as mentioned in the draft. I am not sure it is proper to weight = service providers more on this. I can see if a service provider already dep= loyed existing VPLS, the gain from IS-IS VPLS is less than the cost on upgr= ading all the edge devices to support the solution.=20 However, for data center network, IS-IS VPLS could be a useful solution. It= simplifies current VPLS mechanism, provides a good scalability, and requir= es IP only function on core switches.=20 A vendor provides devices for both service provider network and data center= network, the solution brings a synergy in leveraging VPLS solution into DC= .=20 Thus, I like to see this work moving forward. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of G= iles Heron Sent: Friday, April 27, 2012 7:57 AM To: l2vpn@ietf.org Subject: Interest in IS-IS VPLS Hi, At the IETF meeting in Paris I took an action (as noted in the minutes) to = poll the WG to see if there was any interest (other than by the authors of course) in progressing the IS-IS VPLS draft. Would you please respond to this email indicating whether or not you have i= nterest in seeing this draft progress, ideally giving reasoning for your po= sition. It'd be especially interesting to see responses from service provi= ders of course. If there are no (or very few) responses to this email then Nabil and I will= probably interpret that as meaning there's insufficient interest to progre= ss. Of course it may just mean that you all missed this email in the delug= e of debate on E-Tree ;) Giles From lucy.yong@huawei.com Fri Apr 27 12:15:28 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3080221F866B for ; Fri, 27 Apr 2012 12:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, J_CHICKENPOX_22=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 EiDy7j8tEKfT for ; Fri, 27 Apr 2012 12:15:27 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4D81E21F85E6 for ; Fri, 27 Apr 2012 12:15:22 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFQ56704; Fri, 27 Apr 2012 15:15:22 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 27 Apr 2012 12:12:58 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Fri, 27 Apr 2012 12:12:22 -0700 From: Lucy yong To: Gregory Mirsky , Giles Heron , "l2vpn@ietf.org" Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQAALQiZAAAE+UYA== Date: Fri, 27 Apr 2012 19:12:51 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264C845@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> 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.158.113] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@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, 27 Apr 2012 19:15:28 -0000 It should inform NV03 for sure. But the solution is for L2VPN, so should be= long to this WG. Lucy -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]=20 Sent: Friday, April 27, 2012 2:02 PM To: Lucy yong; Giles Heron; l2vpn@ietf.org Subject: RE: Interest in IS-IS VPLS Hi Lucy, et.al, If we think that IS-IS VPLS might be applicable only to data centers then p= erhaps l2vpn WG is not the proper WG but NVO3 might be the one. Regards, Greg -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of L= ucy yong Sent: Friday, April 27, 2012 11:43 AM To: Giles Heron; l2vpn@ietf.org Subject: RE: Interest in IS-IS VPLS Hi Giles, It seems that the IS-IS VPLS provides the solution for a scalable data cent= er network as mentioned in the draft. I am not sure it is proper to weight = service providers more on this. I can see if a service provider already dep= loyed existing VPLS, the gain from IS-IS VPLS is less than the cost on upgr= ading all the edge devices to support the solution.=20 However, for data center network, IS-IS VPLS could be a useful solution. It= simplifies current VPLS mechanism, provides a good scalability, and requir= es IP only function on core switches.=20 A vendor provides devices for both service provider network and data center= network, the solution brings a synergy in leveraging VPLS solution into DC= .=20 Thus, I like to see this work moving forward. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of G= iles Heron Sent: Friday, April 27, 2012 7:57 AM To: l2vpn@ietf.org Subject: Interest in IS-IS VPLS Hi, At the IETF meeting in Paris I took an action (as noted in the minutes) to = poll the WG to see if there was any interest (other than by the authors of course) in progressing the IS-IS VPLS draft. Would you please respond to this email indicating whether or not you have i= nterest in seeing this draft progress, ideally giving reasoning for your po= sition. It'd be especially interesting to see responses from service provi= ders of course. If there are no (or very few) responses to this email then Nabil and I will= probably interpret that as meaning there's insufficient interest to progre= ss. Of course it may just mean that you all missed this email in the delug= e of debate on E-Tree ;) Giles From yuqun.cao@gmail.com Fri Apr 27 19:32:10 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B762A11E80A4 for ; Fri, 27 Apr 2012 19:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.982 X-Spam-Level: X-Spam-Status: No, score=-2.982 tagged_above=-999 required=5 tests=[AWL=0.617, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMmfE2cQzwFh for ; Fri, 27 Apr 2012 19:32:09 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFA011E808E for ; Fri, 27 Apr 2012 19:32:09 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so1636660pbb.31 for ; Fri, 27 Apr 2012 19:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=9CI0yS5h/tEzJhsTBgMo0XFzZAQGu+eWyvaxn7PGc6k=; b=tK9UZRZwo2oetPF0QHW+TIJ7s6wgKziwdTTWJTCPbz7wHcRfFDh9yv0mMaHEfTZVOX rBwwBsJE5wY2zKD6lvUFrYZ3c46mfWBsgLoxN6/RUljLZ85Wwr9dCKo49FExPKODrEDw 65n5WBlPnuOkFyuzJ/uM1fGZtXFOvxgP9cp/RZ3DS8ahWPMFkkgcH2lvLFtn7i9HYWo5 8F0KAIZUKaHmWOcuKv4ovNvj5ufJDAbsYcdhKGyBGbbc3fmToC5n0QrhgzxtdAPbWjIT GWMQEwAz5pHjmojs1fT2FVOmfv76Mq1Oghi4tndFr57TF4Se8EE4Ejhq0xKh16VltPpe ScAA== Received: by 10.68.131.5 with SMTP id oi5mr1923429pbb.70.1335580329085; Fri, 27 Apr 2012 19:32:09 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id ot5sm8218320pbb.26.2012.04.27.19.32.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Apr 2012 19:32:07 -0700 (PDT) From: "Sam Cao" To: References: Subject: RE: L2vpn Digest, Vol 95, Issue 112 Date: Sat, 28 Apr 2012 10:32:18 +0800 Message-ID: <68C486307AA44B559DCFEC63822715B5@R01842> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: thread-index: Ac0kp/3PU4t1TJ96RQqfuZNx9t2KGQAPG0+g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: l2vpn@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: Sat, 28 Apr 2012 02:32:10 -0000 Hi all, I am not interested in this draft because the existing L2VPN solution also can deploy light-weight VPLS. In addition, we don't see the implied shortages while deploying L2VPN mentioned in "IS-IS VPLS" draft in data center. I also don't see any benefits that an IS-IS version might offer. Thanks, Sam -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of l2vpn-request@ietf.org Sent: Saturday, April 28, 2012 3:00 AM To: l2vpn@ietf.org Subject: L2vpn Digest, Vol 95, Issue 112 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/l2vpn Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send L2vpn mailing list submissions to l2vpn@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/l2vpn or, via email, send a message with subject or body 'help' to l2vpn-request@ietf.org You can reach the person managing the list at l2vpn-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of L2vpn digest..." Today's Topics: 1. Interest in IS-IS VPLS (Giles Heron) 2. Re: Interest in IS-IS VPLS (Rogers, Josh) 3. Re: Interest in IS-IS VPLS (Mallette, Edwin J.) 4. RE: Interest in IS-IS VPLS (Lucy yong) ---------------------------------------------------------------------- Message: 1 Date: Fri, 27 Apr 2012 13:57:19 +0100 From: Giles Heron To: Subject: Interest in IS-IS VPLS Message-ID: Content-Type: text/plain; charset="US-ASCII" Hi, At the IETF meeting in Paris I took an action (as noted in the minutes) to poll the WG to see if there was any interest (other than by the authors of course) in progressing the IS-IS VPLS draft. Would you please respond to this email indicating whether or not you have interest in seeing this draft progress, ideally giving reasoning for your position. It'd be especially interesting to see responses from service providers of course. If there are no (or very few) responses to this email then Nabil and I will probably interpret that as meaning there's insufficient interest to progress. Of course it may just mean that you all missed this email in the deluge of debate on E-Tree ;) Giles ------------------------------ Message: 2 Date: Fri, 27 Apr 2012 10:44:16 -0400 From: "Rogers, Josh" To: Giles Heron , "l2vpn@ietf.org" Subject: Re: Interest in IS-IS VPLS Message-ID: Content-Type: text/plain; charset="us-ascii" I am not interested. I prefer already available methods of doing Layer 2 VPN (intentionally avoiding the term VPLS here), and don't see or appreciate any benefits that an ISIS version might offer. -Josh On 4/27/12 7:57 AM, "Giles Heron" wrote: >Hi, > >At the IETF meeting in Paris I took an action (as noted in the minutes) to >poll the WG to see if there was any interest (other than by the authors of >course) in progressing the IS-IS VPLS draft. > >Would you please respond to this email indicating whether or not you have >interest in seeing this draft progress, ideally giving reasoning for your >position. It'd be especially interesting to see responses from service >providers of course. > >If there are no (or very few) responses to this email then Nabil and I >will >probably interpret that as meaning there's insufficient interest to >progress. Of course it may just mean that you all missed this email in >the >deluge of debate on E-Tree ;) > >Giles > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ------------------------------ Message: 3 Date: Fri, 27 Apr 2012 18:30:44 +0000 From: "Mallette, Edwin J." To: "Rogers, Josh" , Giles Heron , "l2vpn@ietf.org" Subject: Re: Interest in IS-IS VPLS Message-ID: Content-Type: text/plain; charset="us-ascii" I'm also not interested in seeing the ISIS-VPLS draft progress. My rationale for this is very similar to the reasons Josh listed below. Regards, Ed On 4/27/12 4:44 PM, "Rogers, Josh" wrote: >I am not interested. I prefer already available methods of doing Layer 2 >VPN (intentionally avoiding the term VPLS here), and don't see or >appreciate any benefits that an ISIS version might offer. > >-Josh > > >On 4/27/12 7:57 AM, "Giles Heron" wrote: > >>Hi, >> >>At the IETF meeting in Paris I took an action (as noted in the minutes) >>to >>poll the WG to see if there was any interest (other than by the authors >>of >>course) in progressing the IS-IS VPLS draft. >> >>Would you please respond to this email indicating whether or not you have >>interest in seeing this draft progress, ideally giving reasoning for your >>position. It'd be especially interesting to see responses from service >>providers of course. >> >>If there are no (or very few) responses to this email then Nabil and I >>will >>probably interpret that as meaning there's insufficient interest to >>progress. Of course it may just mean that you all missed this email in >>the >>deluge of debate on E-Tree ;) >> >>Giles >> >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. ________________________________ CONFIDENTIALITY NOTICE: This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient of this e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it. ------------------------------ Message: 4 Date: Fri, 27 Apr 2012 18:43:21 +0000 From: Lucy yong To: Giles Heron , "l2vpn@ietf.org" Subject: RE: Interest in IS-IS VPLS Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> Content-Type: text/plain; charset="us-ascii" Hi Giles, It seems that the IS-IS VPLS provides the solution for a scalable data center network as mentioned in the draft. I am not sure it is proper to weight service providers more on this. I can see if a service provider already deployed existing VPLS, the gain from IS-IS VPLS is less than the cost on upgrading all the edge devices to support the solution. However, for data center network, IS-IS VPLS could be a useful solution. It simplifies current VPLS mechanism, provides a good scalability, and requires IP only function on core switches. A vendor provides devices for both service provider network and data center network, the solution brings a synergy in leveraging VPLS solution into DC. Thus, I like to see this work moving forward. Regards, Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Giles Heron Sent: Friday, April 27, 2012 7:57 AM To: l2vpn@ietf.org Subject: Interest in IS-IS VPLS Hi, At the IETF meeting in Paris I took an action (as noted in the minutes) to poll the WG to see if there was any interest (other than by the authors of course) in progressing the IS-IS VPLS draft. Would you please respond to this email indicating whether or not you have interest in seeing this draft progress, ideally giving reasoning for your position. It'd be especially interesting to see responses from service providers of course. If there are no (or very few) responses to this email then Nabil and I will probably interpret that as meaning there's insufficient interest to progress. Of course it may just mean that you all missed this email in the deluge of debate on E-Tree ;) Giles ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 112 ************************************** From jie.dong@huawei.com Fri Apr 27 19:36:11 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4F711E80A4 for ; Fri, 27 Apr 2012 19:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_00=-2.599] 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 jc8Cg8gW2ocS for ; Fri, 27 Apr 2012 19:36:10 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACAA11E8099 for ; Fri, 27 Apr 2012 19:36:10 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFI78573; Fri, 27 Apr 2012 22:36:10 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 27 Apr 2012 19:35:14 -0700 Received: from SZXEML426-HUB.china.huawei.com (10.72.61.34) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 27 Apr 2012 19:35:22 -0700 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.72]) by szxeml426-hub.china.huawei.com ([10.72.61.34]) with mapi id 14.01.0323.003; Sat, 28 Apr 2012 10:35:15 +0800 From: Jie Dong To: Giles Heron , "l2vpn@ietf.org" Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAcKmBg Date: Sat, 28 Apr 2012 02:35:14 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927247B716C@szxeml504-mbx.china.huawei.com> References: 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.108.4.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@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: Sat, 28 Apr 2012 02:36:11 -0000 According to the discussions in NVO3, there is no conclusion yet about whic= h solution would be used for data center VPN. IS-IS VPLS provides one choic= e for data center VPN. At this stage maybe it would be better to have multi= ple alternatives and see which one NVO3 will choose.=20 Thus I'm interested to see this move on.=20 Best regards, Jie > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > Giles Heron > Sent: Friday, April 27, 2012 8:57 PM > To: l2vpn@ietf.org > Subject: Interest in IS-IS VPLS >=20 > Hi, >=20 > At the IETF meeting in Paris I took an action (as noted in the minutes) t= o > poll the WG to see if there was any interest (other than by the authors o= f > course) in progressing the IS-IS VPLS draft. >=20 > Would you please respond to this email indicating whether or not you have > interest in seeing this draft progress, ideally giving reasoning for your > position. It'd be especially interesting to see responses from service > providers of course. >=20 > If there are no (or very few) responses to this email then Nabil and I wi= ll > probably interpret that as meaning there's insufficient interest to > progress. Of course it may just mean that you all missed this email in t= he > deluge of debate on E-Tree ;) >=20 > Giles >=20 From xuxiaohu@huawei.com Fri Apr 27 20:19:42 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFFE21E8034 for ; Fri, 27 Apr 2012 20:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.312 X-Spam-Level: * X-Spam-Status: No, score=1.312 tagged_above=-999 required=5 tests=[AWL=-0.631, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 rlOY6LAXotiw for ; Fri, 27 Apr 2012 20:19:41 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 669B921E8019 for ; Fri, 27 Apr 2012 20:19:41 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFI80653; Fri, 27 Apr 2012 23:19:41 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 27 Apr 2012 20:18:21 -0700 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 27 Apr 2012 20:17:57 -0700 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.252]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.003; Sat, 28 Apr 2012 11:18:22 +0800 From: Xuxiaohu To: "Rogers, Josh" , Giles Heron , "l2vpn@ietf.org" Subject: re: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHuv//l8UA//6pP7A= Date: Sat, 28 Apr 2012 03:18:21 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F1713D@szxeml525-mbx.china.huawei.com> References: 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.108.4.99] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@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: Sat, 28 Apr 2012 03:19:42 -0000 QXMgZm9yIHdoZXRoZXIgb3Igbm90IHRoZSBhbHJlYWR5IGF2YWlsYWJsZSBMMlZQTiBtZXRob2Rz IGFyZSBzdWl0YWJsZSBmb3IgYWxsIGRhdGEgY2VudGVyIG5ldHdvcmtzLCBpdCdzIGFuIGVuZGxl c3MgZGViYXRlIGluIE5WbzMgdGlsbCBub3cgYW5kIGl0IHdvdWxkIGJlIGhhcmQgdG8gcmVhY2gg YSByb3VnaCBjb25zZW5zdXMgdW50aWwgdGhlIE5WbzMgcmVxdWlyZW1lbnQgZHJhZnRzIGFyZSBh cHByb3ZlZC4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1ICANCg0KLS0tLS3Tyrz+1K28/i0tLS0t DQq3orz+yMs6IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGll dGYub3JnXSC0+rHtIFJvZ2VycywgSm9zaA0Kt6LLzcqxvOQ6IDIwMTLE6jTUwjI3yNUgMjI6NDQN CsrVvP7IyzogR2lsZXMgSGVyb247IGwydnBuQGlldGYub3JnDQrW98ziOiBSZTogSW50ZXJlc3Qg aW4gSVMtSVMgVlBMUw0KDQpJIGFtIG5vdCBpbnRlcmVzdGVkLiAgSSBwcmVmZXIgYWxyZWFkeSBh dmFpbGFibGUgbWV0aG9kcyBvZiBkb2luZyBMYXllciAyDQpWUE4gKGludGVudGlvbmFsbHkgYXZv aWRpbmcgdGhlIHRlcm0gVlBMUyBoZXJlKSwgYW5kIGRvbid0IHNlZSBvcg0KYXBwcmVjaWF0ZSBh bnkgYmVuZWZpdHMgdGhhdCBhbiBJU0lTIHZlcnNpb24gbWlnaHQgb2ZmZXIuDQoNCi1Kb3NoDQoN Cg0KT24gNC8yNy8xMiA3OjU3IEFNLCAiR2lsZXMgSGVyb24iIDxnaWxlcy5oZXJvbkBnbWFpbC5j b20+IHdyb3RlOg0KDQo+SGksDQo+DQo+QXQgdGhlIElFVEYgbWVldGluZyBpbiBQYXJpcyBJIHRv b2sgYW4gYWN0aW9uIChhcyBub3RlZCBpbiB0aGUgbWludXRlcykgdG8NCj5wb2xsIHRoZSBXRyB0 byBzZWUgaWYgdGhlcmUgd2FzIGFueSBpbnRlcmVzdCAob3RoZXIgdGhhbiBieSB0aGUgYXV0aG9y cyBvZg0KPmNvdXJzZSkgaW4gcHJvZ3Jlc3NpbmcgdGhlIElTLUlTIFZQTFMgZHJhZnQuDQo+DQo+ V291bGQgeW91IHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgaW5kaWNhdGluZyB3aGV0aGVy IG9yIG5vdCB5b3UgaGF2ZQ0KPmludGVyZXN0IGluIHNlZWluZyB0aGlzIGRyYWZ0IHByb2dyZXNz LCBpZGVhbGx5IGdpdmluZyByZWFzb25pbmcgZm9yIHlvdXINCj5wb3NpdGlvbi4gIEl0J2QgYmUg ZXNwZWNpYWxseSBpbnRlcmVzdGluZyB0byBzZWUgcmVzcG9uc2VzIGZyb20gc2VydmljZQ0KPnBy b3ZpZGVycyBvZiBjb3Vyc2UuDQo+DQo+SWYgdGhlcmUgYXJlIG5vIChvciB2ZXJ5IGZldykgcmVz cG9uc2VzIHRvIHRoaXMgZW1haWwgdGhlbiBOYWJpbCBhbmQgSQ0KPndpbGwNCj5wcm9iYWJseSBp bnRlcnByZXQgdGhhdCBhcyBtZWFuaW5nIHRoZXJlJ3MgaW5zdWZmaWNpZW50IGludGVyZXN0IHRv DQo+cHJvZ3Jlc3MuICBPZiBjb3Vyc2UgaXQgbWF5IGp1c3QgbWVhbiB0aGF0IHlvdSBhbGwgbWlz c2VkIHRoaXMgZW1haWwgaW4NCj50aGUNCj5kZWx1Z2Ugb2YgZGViYXRlIG9uIEUtVHJlZSA7KQ0K Pg0KPkdpbGVzDQo+DQo+DQoNCg0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24s IHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmln aHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRl ZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNo IGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBv ZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5h dGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24g dG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRo aXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= From mach.chen@huawei.com Sat Apr 28 03:06:24 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7355A21F85D8 for ; Sat, 28 Apr 2012 03:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] 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 lbNXxn+A5DSu for ; Sat, 28 Apr 2012 03:06:23 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0E98121F85D0 for ; Sat, 28 Apr 2012 03:06:22 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFQ98062; Sat, 28 Apr 2012 06:06:21 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 28 Apr 2012 03:04:30 -0700 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 28 Apr 2012 03:04:38 -0700 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.144]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Sat, 28 Apr 2012 18:04:29 +0800 From: Mach Chen To: Lucy yong , Giles Heron , "l2vpn@ietf.org" Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVA= Date: Sat, 28 Apr 2012 10:04:29 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@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: Sat, 28 Apr 2012 10:06:24 -0000 Fully agree with lucy here. In addition, since the ISIS VPLS leverages a uniform protocol(ISIS) for sig= naling and auto discovery, it would greatly simplify the deployment and mai= ntenance, especially for the DC networks that have already deployed ISIS fo= r IP routing. So I'd like to see the draft moving forward. Best regards, Mach > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Lucy yong > Sent: Saturday, April 28, 2012 2:43 AM > To: Giles Heron; l2vpn@ietf.org > Subject: RE: Interest in IS-IS VPLS >=20 > Hi Giles, >=20 > It seems that the IS-IS VPLS provides the solution for a scalable data ce= nter > network as mentioned in the draft. I am not sure it is proper to weight > service providers more on this. I can see if a service provider already > deployed existing VPLS, the gain from IS-IS VPLS is less than the cost on > upgrading all the edge devices to support the solution. >=20 > However, for data center network, IS-IS VPLS could be a useful solution. = It > simplifies current VPLS mechanism, provides a good scalability, and > requires IP only function on core switches. >=20 > A vendor provides devices for both service provider network and data > center network, the solution brings a synergy in leveraging VPLS solution > into DC. >=20 > Thus, I like to see this work moving forward. >=20 > Regards, > Lucy >=20 >=20 >=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Giles Heron > Sent: Friday, April 27, 2012 7:57 AM > To: l2vpn@ietf.org > Subject: Interest in IS-IS VPLS >=20 > Hi, >=20 > At the IETF meeting in Paris I took an action (as noted in the minutes) t= o > poll the WG to see if there was any interest (other than by the authors o= f > course) in progressing the IS-IS VPLS draft. >=20 > Would you please respond to this email indicating whether or not you > have > interest in seeing this draft progress, ideally giving reasoning for your > position. It'd be especially interesting to see responses from service > providers of course. >=20 > If there are no (or very few) responses to this email then Nabil and I wi= ll > probably interpret that as meaning there's insufficient interest to > progress. Of course it may just mean that you all missed this email in t= he > deluge of debate on E-Tree ;) >=20 > Giles >=20 From Alexander.Vainshtein@ecitele.com Sun Apr 29 05:24:52 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3537021F8531 for ; Sun, 29 Apr 2012 05:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.845 X-Spam-Level: X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, 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 dSUj+EwGVKXf for ; Sun, 29 Apr 2012 05:24:51 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3A23D21F849A for ; Sun, 29 Apr 2012 05:24:50 -0700 (PDT) Received: from [85.158.143.99:24515] by server-3.bemta-4.messagelabs.com id 84/DD-05853-2133D9F4; Sun, 29 Apr 2012 12:24:50 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1335702289!24836857!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.7; banners=-,-,- Received: (qmail 2839 invoked from network); 29 Apr 2012 12:24:49 -0000 Received: from unknown (HELO fridlpvsb005.ecitele.com) (168.87.1.157) by server-13.tower-216.messagelabs.com with SMTP; 29 Apr 2012 12:24:49 -0000 X-AuditID: a8571406-b7fe86d0000037a2-41-4f9d330c4c2e Received: from FRIDWPPCH002.ecitele.com (fridwppch002.ecitele.com [10.1.16.53]) by fridlpvsb005.ecitele.com (Symantec Messaging Gateway) with SMTP id 3D.EB.14242.C033D9F4; Sun, 29 Apr 2012 14:24:44 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.130]) by FRIDWPPCH002.ecitele.com ([10.1.16.53]) with mapi id 14.01.0339.001; Sun, 29 Apr 2012 14:24:48 +0200 From: Alexander Vainshtein To: Mach Chen , Lucy yong , Giles Heron , "l2vpn@ietf.org" Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAAPs1mUA== Date: Sun, 29 Apr 2012 12:24:47 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.213.93] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2WTa0gUURTHuzvj7PiYGnfVvS49tulBaMqaKdtjpYJEg9jsJRRl4+xtd2h3 dptZRfvSpiElFUYPasuea9hL0yCNwnBLS/3QyyCMDcosUoSS3pE046QZzaffved//ufce8+Q mO4VYSR5wYdEgXUxRBQeBSYYU2LSq23mz6EES1/bMWDp/RLSWhp+nCMsj67ql+A5NwNhbc7u e4MROcHgd80qbIMfLGYFweNjfchkRxJnZVaJfDHLlTIm3m5l0hiT18VyyI0En5VhvV4k2Jms KNN/32JZxgsmJHAeOy84rEzuGluKxZKxICWNyVrr5CUTSnGzvMvkRpLEOpBJ3lF6F+xb6jDn 94pDWm9TYsmTllbgB4P6ShBJQno+HPiyO0LlBPjoZT1RCaJIHd0N4HDPqz+LGgBb9r4YURG0 FTZeDhMKx9FVAPZdyFBYT8+AL8pbcHV/Jrxzqh9TeRkcag8ChXF6Fqw5X6FRmKJXwsaaNq3C OvomgDVlPoUj6fUwUHlxxAfIHX3tvDKix2gD7HlzWqN2SsPg7YeYyvHwfe+w3Bsp8zTYWJ6p yufCM7eGCJWT4YWzA5haNhZ2HH+Dq6mJsLX2OV4FEgLjKgTGpQfGpQfGpZ8B+CUAt4q83eUt lgrN5oxUxPE+5EKpnMfdCORBqc2PI5qBvyo1BGgSMDEU7T5p00WwxVKpOwQSSQ0TT0UnVdt0 Ews99lInKzkLxCIXkkIAkhgTRyUbZDllZ0t3INEzGrLId3gQM0ZzHuVZfQXpZvM/C8ZA1a/O sulohzxr2xDyInE0dTJJMpDKmSdXjBWRA5Vs5V2+v2ENGalUjpErJykaSvKybol3qPFOMIt8 +7j5GdDhgkdARgOVqIhoReQsEsZ8+oFBPqueWqREY+TZG3Pol801srkmN6CYy//CWMjoB7s6 B9YdmT1U7f185104/de1c+ufLl0R3sMM5P+sILvA4eD2hdOxffSPQX/Exxv9G8XsSWsCNkvX 425d3ZzMY9rrB/Im383blH5i55Om7I7O+98OLqn8er2NQOGjceZ2vZh/fFpZ4eYHBwbPb9/f wNWHcrN746dyH/rqVrye8ql3Ob+cwSUnm5aEiRL7G+Aueh30AwAA X-BeenThere: l2vpn@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: Sun, 29 Apr 2012 12:24:52 -0000 Dear colleagues, I would like to remind you that the original message from Giles says: It'd be especially interesting to see responses from service providers of c= ourse. So far I've seen just two messages for SPs in this thread, and both have sta= ted "I am not interested". With this in mind, IMHO and FWIW it premature to discuss details, technical= or procedural, at this stage. My 2c, Sasha > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Mach Chen > Sent: Saturday, April 28, 2012 1:04 PM > To: Lucy yong; Giles Heron; l2vpn@ietf.org > Subject: RE: Interest in IS-IS VPLS > > Fully agree with lucy here. > > In addition, since the ISIS VPLS leverages a uniform protocol(ISIS) for > signaling and auto discovery, it would greatly simplify the deployment and > maintenance, especially for the DC networks that have already deployed > ISIS for IP routing. So I'd like to see the draft moving forward. > > Best regards, > Mach > > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > > Of Lucy yong > > Sent: Saturday, April 28, 2012 2:43 AM > > To: Giles Heron; l2vpn@ietf.org > > Subject: RE: Interest in IS-IS VPLS > > > > Hi Giles, > > > > It seems that the IS-IS VPLS provides the solution for a scalable data c= enter > > network as mentioned in the draft. I am not sure it is proper to weight > > service providers more on this. I can see if a service provider already > > deployed existing VPLS, the gain from IS-IS VPLS is less than the cost o= n > > upgrading all the edge devices to support the solution. > > > > However, for data center network, IS-IS VPLS could be a useful solution.= It > > simplifies current VPLS mechanism, provides a good scalability, and > > requires IP only function on core switches. > > > > A vendor provides devices for both service provider network and data > > center network, the solution brings a synergy in leveraging VPLS solutio= n > > into DC. > > > > Thus, I like to see this work moving forward. > > > > Regards, > > Lucy > > > > > > > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > > Of Giles Heron > > Sent: Friday, April 27, 2012 7:57 AM > > To: l2vpn@ietf.org > > Subject: Interest in IS-IS VPLS > > > > Hi, > > > > At the IETF meeting in Paris I took an action (as noted in the minutes)= to > > poll the WG to see if there was any interest (other than by the authors= of > > course) in progressing the IS-IS VPLS draft. > > > > Would you please respond to this email indicating whether or not you > > have > > interest in seeing this draft progress, ideally giving reasoning for you= r > > position. It'd be especially interesting to see responses from service > > providers of course. > > > > If there are no (or very few) responses to this email then Nabil and I w= ill > > probably interpret that as meaning there's insufficient interest to > > progress. Of course it may just mean that you all missed this email in= the > > deluge of debate on E-Tree ;) > > > > Giles > > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From DanielC@orckit.com Mon Apr 30 04:36:09 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212F621F84AE for ; Mon, 30 Apr 2012 04:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HS_INDEX_PARAM=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 tOMTexP6oDkX for ; Mon, 30 Apr 2012 04:36:07 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id F0CF121F844F for ; Mon, 30 Apr 2012 04:36:05 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: The status of the approaches to the E-Tree solution? Date: Mon, 30 Apr 2012 14:38:06 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130777C8D9@tlvmail1> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D3264C1A2@dfweml505-mbx> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: Ac0fJQNWe/4Txq0Y50G6N17p5MncdwBXtrWAADjtXEAAIMJ4IABEiWPQAAFgqVoABMXRAAABv/gYAAArZUAAAWnjjAAAAsVAAOg3GVA= References: <172e01cd2322$b1efdc43$05280101@corrigent.com> <2691CE0099834E4A9C5044EEC662BB9D3264C1A2@dfweml505-mbx> From: "Daniel Cohn" To: "Lucy yong" , "Rogers, Josh" , "Shahram Davari" , "Lizhong Jin" , , Cc: yuqun.cao@gmail.com X-BeenThere: l2vpn@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, 30 Apr 2012 11:36:09 -0000 SGkgTHVjeSwNCg0KV2hlbiB5b3Ugd3JpdGUgIlBFIGtub3dzIHdoaWNoIFMtVkxBTiBJRCBpcyB1 c2VkIG9uIGFuIEFDIiwgeW91IGFzc3VtZSB0aGVyZSBpcyBvbmx5IG9uZSBTLVZMQU4gSUQgdXNl ZCBvbiB0aGUgQUMuIFRoaXMgaXMgbm90IHRydWUgaW4gdGhlIGdlbmVyYWwgY2FzZSwgeW91IG1h eSBnZXQgZGlmZmVyZW50IFMtVkxBTiBJRHMgaW4gdGhlIHNhbWUgQUMgaWYgdGhlIEFDIGlzIGNv bm5lY3RlZCB0byBhbiBJRUVFIExBTiB0aGF0IGRvdWJsZS10YWdzIHRoZSBmcmFtZXMgKHRoZSBz Y2VuYXJpbyB3ZSB3ZXJlIGRpc2N1c3NpbmcpLg0KDQpSZWdhcmRzLA0KDQpEYW5pZWwNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEx1Y3kgeW9uZyBbbWFpbHRvOmx1Y3kueW9u Z0BodWF3ZWkuY29tXSANClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAyNiwgMjAxMiAxMjowMCBBTQ0K VG86IERhbmllbCBDb2huOyBSb2dlcnMsIEpvc2g7IFNoYWhyYW0gRGF2YXJpOyBMaXpob25nIEpp bjsgbDJ2cG5AaWV0Zi5vcmc7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQpDYzog eXVxdW4uY2FvQGdtYWlsLmNvbQ0KU3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJv YWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCg0KVGhlIGN1cnJlbnQgVkxBTiBkcmFmdCBk b2VzIG5vdCBhc3N1bWUgZG91YmxlIHRhZyBmcmFtZSBhdCBBQy4gSWYgd2UgaGF2ZSB0byBjb25z aWRlciB0aGlzIGNhc2UsIHRoZSBzb2x1dGlvbiB3YXMgZGlzY3Vzc2VkIGluIHRoZSBlLW1haWwu IEkgc2hvdWxkIHVzZSBsb2NhbCB0cmFuc2xhdGlvbiBpbnN0ZWFkIG9mIG1hcHBpbmcgaW4gcHJl dmlvdXMgZS1tYWlsLCB3aGljaCBtYWtlcyBpdCBtb3JlIGNsZWFyLiBJbiB0aGlzIGNhc2UsIFBF IGtub3dzIHdoaWNoIFMtVkxBTiBJRCBpcyB1c2VkIG9uIGFuIEFDLCBzbyBQRSBpbnNlcnRzIHRo ZSBzYW1lIFMtVkxBTiBJRCBvbiB0aGUgZnJhbWVzIGdvaW5nIHRvd2FyZCB0byB0aGUgQUMuIFRo aXMgaXMgdGhlIHBhcnQgeW91IG1pc3NlZC4NCg0KTHVjeQ0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogRGFuaWVsIENvaG4gW21haWx0bzpEYW5pZWxDQG9yY2tpdC5jb21dIA0K U2VudDogV2VkbmVzZGF5LCBBcHJpbCAyNSwgMjAxMiAzOjMxIFBNDQpUbzogTHVjeSB5b25nOyBS b2dlcnMsIEpvc2g7IFNoYWhyYW0gRGF2YXJpOyBMaXpob25nIEppbjsgbDJ2cG5AaWV0Zi5vcmc7 IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQpDYzogeXVxdW4uY2FvQGdtYWlsLmNv bQ0KU3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJl ZSBzb2x1dGlvbj8NCg0KTHVjeSwgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHlvdSBtZWFuIGJ5ICJv YmV5IHRoZSBydWxlIGZpcnN0Ii4NClNheSB5b3UgZ2V0IGEgZnJhbWUgd2l0aCBkb3VibGUgdGFn IGF0IGEgbGVhZiBhYy4gQWNjb3JkaW5nIHRvIHRoZSAyIHZsYW4gZHJhZnQsIHlvdSBtdXN0IGFk ZCB0aGUgbGVhZiB2bGFuIGJlZm9yZSBmb3J3YXJkaW5nIHRoZSBmcmFtZSB0byB0aGUgbXBscywg b3RoZXJ3aXNlIHRoZSBlZ3Jlc3MgcGUgd29uJ3Qga25vdyBpdCBjYW4gb25seSBmb3J3YXJkIHRo ZSBmcmFtZSBvdmVyIHJvb3QgYWNzLiBJZiB5b3UgcmVtb3ZlIHRoZSBvdXRlciB0YWcgb24gaW5n cmVzcywgaG93IGNhbiB5b3UgcmVjb3ZlciBpdCBvbiBlZ3Jlc3M/IElmIHlvdSBkb24ndCByZW1v dmUgaXQsIHlvdSBnZXQgYSAzLWRlZXAgc3RhY2suDQoNCkRhbmllbA0KDQpUaHVtYiB0eXBlZCAt IHBsZWFzZSBiZSB0b2xlcmFudA0KDQpMdWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPiB3 cm90ZToNCg0KTG9jYWwgbWFwcGluZyBpcyBzdWZmaWNpZW50IGZvciB0aGlzLiBJZiBhIGN1c3Rv bWVyIHdpc2ggYm90aCBpbmdyZXNzIFZMQU4gSUQgYW5kIGVncmVzcyBWTEFOIElEIGFyZSB0aGUg c2FtZSwgaXQgb2JleXMgdGhlIHJ1bGUgZmlyc3QsIHRoZW4gbG9jYWwgdHJhbnNsYXRlIGluIE1Q TFMgd2lsbCB3b3JrIHBlcmZlY3RseS4NCkx1Y3kNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IERhbmllbCBDb2huIFttYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tXSANClNlbnQ6 IFdlZG5lc2RheSwgQXByaWwgMjUsIDIwMTIgMjo0NiBQTQ0KVG86IEx1Y3kgeW9uZzsgUm9nZXJz LCBKb3NoOyBTaGFocmFtIERhdmFyaTsgTGl6aG9uZyBKaW47IGwydnBuQGlldGYub3JnOyBBbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KQ2M6IHl1cXVuLmNhb0BnbWFpbC5jb20NClN1 YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29s dXRpb24/DQoNCkFuZCB0byB0aGlzIEkgYXNrZWQgaG93IHRoaXMgbWFwcGluZyB3b3JrcyAtIGhv dyBkb2VzIHRoZSBlZ3Jlc3MgcGUgcmVjb3ZlciB0aGUgaW5ncmVzcyB2aWQgd2hlbiBpdCBnZXRz IHRoZSBmcmFtZSB0YWdnZWQgd2l0aCBvbmx5IHRoZSByb290L2xlYWYgdmlkPyBIb3cgY2FuIHlv dSBjb252ZXkgdGhlIGluZ3Jlc3MgdmlkIHBsdXMgdGhlIHJvb3QvbGVhZiBhdHRyaWJ1dGUgaW4g dGhlIHNhbWUgbnVtYmVyIG9mIGJpdHM/DQpXaGF0IGFtIEkgbWlzc2luZz8NCg0KRGFuaWVsDQoN ClRodW1iIHR5cGVkIC0gcGxlYXNlIGJlIHRvbGVyYW50DQoNCkx1Y3kgeW9uZyA8bHVjeS55b25n QGh1YXdlaS5jb20+IHdyb3RlOg0KDQpEYW5pZWwsDQoNCkRhdmlkIEFsbGVuIGFscmVhZHkgZXhw bGFpbmVkIHRoZSBzb2x1dGlvbi4gDQoNCkZyb20gRGF2aWQ6DQppbmdyZXNzIFZMQU4gSUQgPC0+ IEV0cmVlIFJvb3QvTGVhZiBWSUQgPC0+IEVncmVzcyBWSUQuDQoNCkluZ3Jlc3MgVklEIGRvZXMg bm90IGhhdmUgdG8gZXF1YWwgRWdyZXNzIFZJRCBidXQgcmVnYXJkbGVzcyB0aGVyZSBpcyBvbmx5 IGV2ZXIgb25lIFZJRCBvbiBhIGZyYW1lIGF0IGEgdGltZS4NCg0KLWVuZA0KDQpUaGlzIHdvcmtz IHdoZW4gY3VzdG9tZXIgbWFrZXMgaW5ncmVzcyBWTEFOIElEIG5vdCBlcXVhbCB0byBvciBlcXVh bCB0byBlZ3Jlc3MgVkxBTiBJRC4NCg0KUmVnYXJkcywNCkx1Y3kNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGFuaWVsIENvaG4NClNlbnQ6IFdlZG5lc2Rh eSwgQXByaWwgMjUsIDIwMTIgMTE6MzkgQU0NClRvOiBMdWN5IHlvbmc7IFJvZ2VycywgSm9zaDsg U2hhaHJhbSBEYXZhcmk7IExpemhvbmcgSmluOyBsMnZwbkBpZXRmLm9yZzsgQWxleGFuZGVyLlZh aW5zaHRlaW5AZWNpdGVsZS5jb20NCkNjOiB5dXF1bi5jYW9AZ21haWwuY29tDQpTdWJqZWN0OiBS RTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0K DQpIaSBMdWN5LA0KDQpUaGUgc2NlbmFyaW8gd2UgYXJlIGRpc2N1c3NpbmcgaXMgbm90IHRoZSBF LVRyZWUgRS1OTkksIGJ1dCBhIGdlbmVyYWwgc2NlbmFyaW8gd2hlcmUgZnJhbWVzIGFycml2aW5n IGF0IHRoZSByb290IG9yIGxlYWYgQUMgIGFyZSBhbHJlYWR5IGRvdWJsZSB0YWdnZWQuIEluIHRo aXMgY2FzZSwgdGhlIGR1YWwgdmxhbiBzb2x1dGlvbiBjYW5ub3QgcHJlc2VydmUgdGhlIHZsYW5z IHdpdGhvdXQgYWRkaW5nIGEgdGhpcmQgb25lLCBjYW4gaXQ/DQoNCk1heWJlIFNoYWhyYW0gY2Fu IGFkZCBkZXRhaWxzIG9uIHRoZSBzY2VuYXJpbyBoZSBoYWQgaW4gbWluZA0KDQpUaHVtYiB0eXBl ZCAtIHBsZWFzZSBiZSB0b2xlcmFudA0KDQpMdWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3ZWkuY29t PiB3cm90ZToNCg0KRGFuaWVsLA0KDQpNRUYgaGFzIFMtVkxBTiBwcmVzZXJ2YXRpb24gYXR0cmli dXRlIGZvciBFTk5JIG9ubHkgYmVjYXVzZSB0aGVyZSBpcyBubyBzLXZsYW4gYXQgVU5JLiBXaGVu IGFuIE1FTiBjb25uZWN0cyB0byBtdWx0aXBsZSBFTk5JIGludGVyZmFjZXMsIFMtVkFMTiBwcmVz ZXJ2YXRpb24gYXR0cmlidXRlIGlzIHVzZWQuIEl0IGFwcGxpZXMgdG8gRS1UcmVlIGFzIHdlbGwu DQoNClJlZ2FyZHMsDQpMdWN5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBs MnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIERhbmllbCBDb2huDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAyNCwgMjAxMiAyOjEy IEFNDQpUbzogTHVjeSB5b25nOyBSb2dlcnMsIEpvc2g7IFNoYWhyYW0gRGF2YXJpOyBMaXpob25n IEppbjsgbDJ2cG5AaWV0Zi5vcmc7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQpD YzogeXVxdW4uY2FvQGdtYWlsLmNvbQ0KU3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFw cHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCg0KTHVjeSwNCg0KZXZlbiBpZiB0aGUg Y3VycmVudCBNRUYgZnJhbWV3b3JrIGRvZXNuJ3QgcmVxdWlyZSBzLXZsYW4gcHJlc2VydmF0aW9u LCBJIGJlbGlldmUgaXQncyB0byB0aGUgaW5kdXN0cnkncyBiZW5lZml0IHRvIGFkb3B0IGEgc29s dXRpb24gdGhhdCBpcyBub3QgY29uc3RyYWluZWQgdG8gYSBzcGVjaWZpYyBlbm5pIG1vZGVsIHRo YXQsIGxpa2UgYWxsIHRoaW5ncyBuZXR3b3JraW5nLCBpcyBsaWtlbHkgdG8gZXZvbHZlLiBFc3Bl Y2lhbGx5IHdoZW4gc3VjaCBhIHNvbHV0aW9uIGlzIGF2YWlsYWJsZS4NCg0KRGFuaWVsDQoNClRo dW1iIHR5cGVkIC0gcGxlYXNlIGJlIHRvbGVyYW50DQoNCkx1Y3kgeW9uZyA8bHVjeS55b25nQGh1 YXdlaS5jb20+IHdyb3RlOg0KDQpEYW5pZWwsDQoNCk1FRiBoYXMgd29ya2VkIGluIEVOTkkgaW50 ZXJmYWNlIGZvciBhIGxvbmcgdGltZSB3aXRoIG1hbnkgc2VydmljZSBwcm92aWRlcnMnIGlucHV0 cy4gSXQgaGFkIGEgZmFpciByZWFzb24gdG8gYXNzdW1lIFMtVkxBTiBvdmVyIEVOTkkgYnkgdGhl bi4gSXQgbWF5IG9wZW4gQi1WTEFOIGZvciB0aGUgZnV0dXJlLiBJdCBpcyBiZXR0ZXIgZm9yIHVz IG5vdCB0byBkaXNjdXNzICBhIGZ1dHVyZSBmcmFtZXdvcmsgaGVyZSwgYmVjYXVzZSBpdCB3aWxs IGxlYWQgdXMgdG8gbm93aGVyZS4gSGVyZSwgd2Ugd2FudCB0byBleHRlbmQgVlBMUyBpbiBzdXBw b3J0aW5nIEUtVHJlZS4NCg0KQmVzdCBSZWdhcmRzLA0KTHVjeQ0KDQpGcm9tOiBsMnZwbi1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IERhbmllbCBDb2huDQpTZW50OiBTdW5kYXksIEFwcmlsIDIyLCAyMDEyIDc6MzQgQU0NClRvOiBS b2dlcnMsIEpvc2g7IFNoYWhyYW0gRGF2YXJpOyBMaXpob25nIEppbjsgbDJ2cG5AaWV0Zi5vcmc7 IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQpDYzogeXVxdW4uY2FvQGdtYWlsLmNv bQ0KU3ViamVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJl ZSBzb2x1dGlvbj8NCg0KU2hhaHJhbSBhbmQgYWxsLA0KDQpUaGlzIHF1ZXN0aW9uIGFscmVhZHkg Y2FtZSB1cCBpbiBvdXIgZGlzY3Vzc2lvbnMgLSBpcyBpdCBzYWZlIHRvIGFzc3VtZSB0aGF0IHRo ZSBWTEFOIHRhZ3MgYXQgdGhlIEUtTk5JIHdpbGwgYWx3YXlzIGJlIGFjY29yZGluZyB0byB0aGUg Y3VycmVudCBNRUYgbW9kZWw/IE9yIHNob3VsZCB3ZSB0cnkgdG8gYmUgYXMgdHJhbnNwYXJlbnQg YXMgcG9zc2libGUgdG8gdXNlciBWTEFOIGVuY2Fwc3VsYXRpb24gYXQgdGhlIEUtTk5JLCB0byBh Y2NvbW1vZGF0ZSBmdXR1cmUgZnJhbWV3b3Jrcz8NCkkgYmVsaWV2ZSB0aGF0IGFueSBhcHByb2Fj aCB0aGF0IGxvb2tzIGF0IHVzZXIgcGF5bG9hZCAoaW4gdGhpcyBjYXNlIFZMQU4gdGFnKSB0byBz aWduYWwgVlBMUyBpbmZvcm1hdGlvbiAoaW4gdGhpcyBjYXNlIHJvb3QvbGVhZiBvcmlnaW4pIGlz IG5lY2Vzc2FyaWx5IHRpZWQgdG8gc3BlY2lmaWMgYXNzdW1wdGlvbnMgb24gdXNlciBwYXlsb2Fk IGVuY2Fwc3VsYXRpb24gKGluIHRoaXMgY2FzZSwgdGhhdCBTLVZMQU4gdGFnIGlzICJhdmFpbGFi bGUiIHRvIGVuY29kZSByb290L2xlYWYpLiBJIGRvbid0IHRoaW5rIHRoaXMgaXMgYSBmdXR1cmUt cHJvb2YgYXNzdW1wdGlvbiwgaXQncyB2ZXJ5IGxpa2VseSB0aGF0IG90aGVyIG5ldHdvcmsgbW9k ZWxzIHdpbGwgY29tZSB1cCB0aGF0IHJlcXVpcmUgUy1WTEFOIHByZXNlcnZhdGlvbiwgd2hpY2gg aW4gdGhlIDItVkxBTiBhcHByb2FjaCB3b3VsZCBuZWNlc3NpdGF0ZSBhZGRpbmcgYSB0aGlyZCBW TEFOLUlELg0KDQpEYW5pZWwNCg0KRnJvbTogU2hhaHJhbSBEYXZhcmkgPGRhdmFyaUBicm9hZGNv bS5jb208bWFpbHRvOmRhdmFyaUBicm9hZGNvbS5jb20+Pg0KVG86IExpemhvbmcgSmluIDxsaXpo by5qaW5AZ21haWwuY29tPG1haWx0bzpsaXpoby5qaW5AZ21haWwuY29tPj4sICJsMnZwbkBpZXRm Lm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+IiA8bDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBu QGlldGYub3JnPj4sICJBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxl eGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+IiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNp dGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPj4NCkNjOiAi eXVxdW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbT4iIDx5dXF1bi5j YW9AZ21haWwuY29tPG1haWx0bzp5dXF1bi5jYW9AZ21haWwuY29tPj4NClN1YmplY3Q6IFJFOiBU aGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQoNCkhp LA0KDQpJIGFsc28gaGF2ZSBhIHF1ZXN0aW9uIHJlZ2FyZGluZyAyLVZMQU4uIFdoYXQgaWYgdGhl IGN1c3RvbWVyIHRyYWZmaWMgYWxyZWFkeSBoYXMgYW4gUy1WTEFOPyBEbyB3ZSBuZWVkIGEgM3Jk IFZMQU4gdG8gaWRlbnRpZnkgdGhlIEwvUj8NCg0KVGh4DQpTaGFocmFtDQoNCkZyb206IGwydnBu LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86 bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExpemhvbmcgSmluDQpTZW50OiBG cmlkYXksIEFwcmlsIDIwLCAyMDEyIDk6MzggQU0NClRvOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86 bDJ2cG5AaWV0Zi5vcmc+OyBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86 QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQpDYzogeXVxdW4uY2FvQGdtYWlsLmNv bTxtYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbT4NClN1YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9m IHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQoNCkhpLCBhbGwsDQpUaGUg ZGlmZmVyZW5jZSBiZXR3ZWVuIDItVkxBTiBhbmQgQ1cgYXBwcm9hY2ggaXMgd2hvIHdpbGwgcHJv dmlkZSB0aGUgUi9MIGluZm9ybWF0aW9uLCBjdXN0b21lciBwYXlsb2FkIG9yIFBXPyBUaGUgY3Vz dG9tZXIgcGF5bG9hZCB3aWxsIGJlIGFsd2F5cyBtb2RpZmllZCB0byBjYXJyeSBSL0wgaW5mb3Jt YXRpb24gaW4gMi1WTEFOIGFwcHJvYWNoLCB3aGlsZSBQVyB3aXRoIENXIHdpbGwgY2FycnkgUi9M IGluZm9ybWF0aW9uIGZvciBDVyBhcHByb2FjaC4NCkkgaGF2ZSBhIHF1ZXN0aW9uIHdpdGggdGhl IDItVkxBTiBhcHByb2FjaCBpbiBILVZQTFMgd2hlcmUgSC1WUExTIGlzIGFjY2Vzc2VkIGJ5IFZQ V1MgYXMgZGVzY3JpYmVkIGluIFJGQzQ2NzIgc2VjdGlvbiAxMC4xLjMuIElmIFZQV1MgaXMgdXNl ZCB0byBhY2Nlc3MgSC1WUExTLCBob3cgY291bGQgdGhlIFBFIG9uIFZQV1Mgc2lkZSBhZGRzIFZM QU4gdG8gaW5kaWNhdGUgUi9MIGluZm9ybWF0aW9uPw0KDQpUaGFua3MNCkxpemhvbmcNCg0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4gTWVzc2FnZTogMg0KPiBEYXRlOiBU aHUsIDE5IEFwciAyMDEyIDA0OjM4OjM2ICswMDAwDQo+IEZyb206IEFsZXhhbmRlciBWYWluc2h0 ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZh aW5zaHRlaW5AZWNpdGVsZS5jb20+Pg0KPiBUbzogIlJvZ2VycywgSm9zaCIgPGpvc2gucm9nZXJz QHR3Y2FibGUuY29tPG1haWx0bzpqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbT4+LCBMdWN5IHlvbmcN Cj4gICAgICAgIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5j b20+PiwgRGFuaWVsIENvaG4gPERhbmllbENAb3Jja2l0LmNvbTxtYWlsdG86RGFuaWVsQ0BvcmNr aXQuY29tPj4sIFNhbSBDYW8NCj4gICAgICAgIDx5dXF1bi5jYW9AZ21haWwuY29tPG1haWx0bzp5 dXF1bi5jYW9AZ21haWwuY29tPj4NCj4gQ2M6ICJsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5A aWV0Zi5vcmc+IiA8bDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPj4NCj4gU3Vi amVjdDogUkU6IFRoZSBzdGF0dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1 dGlvbj8NCj4gTWVzc2FnZS1JRDoNCj4gICAgICAgIDxGOTMzNjU3MTczMUFERTQyQTUzOTdGQzgz MUNFQUEwMjAzNDE5MkBGUklEV1BQTUIwMDIuZWNpdGVsZS5jb208bWFpbHRvOkY5MzM2NTcxNzMx QURFNDJBNTM5N0ZDODMxQ0VBQTAyMDM0MTkyQEZSSURXUFBNQjAwMi5lY2l0ZWxlLmNvbT4+DQo+ IENvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXMtYXNjaWkiDQo+DQo+IEhpIGFs bCwNCj4gSSBmdWxseSB1bmRlcnN0YW5kIHRoYXQgdGhhdCB3aGF0IEkgYW0gZ29pbmcgdG8gc2F5 IGlzIG5vdCB2ZXJ5IHBvcHVsYXIsIGJ1dDoNCj4NCj4gSU1PIG9uZSBvZiB0aGUgYWR2YW50YWdl cyBvZiB0aGUgQ1ctYmFzZWQgc29sdXRpb24gaXMgdGhhdCBpdCBpcyBvcnRob2dvbmFsIHRvIHVz YWdlIChvciBub24tdXNhZ2UpIG9mIFAyTVAgUFdzIGZvciBlZmZlY3RpdmUgZGVsaXZlcnkgb2Yg QlVOIHRyYWZmaWMuDQo+DQo+IEFub3RoZXIgYWR2YW50YWdlIGlzIHByZXNlcnZhdGlvbiBvZiBm dWxsIG1lc2ggb2YgUDJQIFBXcyBpbiBhIFZQTFMsIGFuZCwgaW4gYSBtb3JlIGdlbmVyaWMgd2F5 LCBsb2NhbGl6YXRpb24gb2YgZWZmZWN0cyBvZiBjaGFuZ2VzIGluIHRoZSBQRSBjb25maWd1cmF0 aW9uLg0KPg0KPiBJbiBwYXJ0aWN1bGFyLCBhZGRpbmcgYSBMZWFmIEFDIHRvIGEgUEUgdGhhdCBw cmV2aW91c2x5IGhhcyBiZWVuIG9ubHkgc3VwcG9ydGluZyBSb290IEFDcyAob3IgdmljZSB2ZXJz YSksIHJlbW92YWwgb2YgdGhlIGxhc3QgTGVhZiBvciBsYXN0IFJvb3QgQUMgZnJvbSBhIFBFIHRo YXQgcHJldmlvdXNseSBoYXMgYmVlbiBzdXBwb3J0aW5nIGEgbWl4IGV0Yy4gYWZmZWN0IG9ubHkg dGhlIFBFIHdoZXJlIHRoaXMgb3BlcmF0aW9uIGhhcHBlbnMgYW5kIG5vdCB0aGUgcmVzdCBvZiB0 aGUgUEVzLg0KPg0KPiBBcyBmb3IgdGhlIG5lZWQgZm9yIEhXIGNoYW5nZXMgdGhhdCBoYXZlIGJl ZW4gbWVudGlvbmVkIGFzIGEgbWFpbiBkaXNhZHZhbnRhZ2Ugb2YgdGhlIENXLWJhc2VkIGFwcHJv YWNoIC0gSSBiZWxpZXZlIGl0IHN0cm9uZ2x5IGRlcGVuZHMgb24gc3BlY2lmaWMgaW1wbGVtZW50 YXRpb25zLiBBbmQgc29tZSBjaGFuZ2VzIGluIHRoZSBmb3J3YXJkaW5nIHByb2Nlc3MgYXJlIHJl cXVpcmVkIGluIGFueSBzb2x1dGlvbi4NCj4NCj4gTXkgMmMsDQo+ICAgICBTYXNoYQ0KPg0KPg0K Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZyb206IGwy dnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc+IFtsMnZw bi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnPl0gb24gYmVo YWxmIG9mIFJvZ2VycywgSm9zaCBbam9zaC5yb2dlcnNAdHdjYWJsZS5jb208bWFpbHRvOmpvc2gu cm9nZXJzQHR3Y2FibGUuY29tPl0NCj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxOCwgMjAxMiA5 OjU3IFBNDQo+IFRvOiBMdWN5IHlvbmc7IERhbmllbCBDb2huOyBTYW0gQ2FvDQo+IENjOiBsMnZw bkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBUaGUgc3Rh dHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRpb24/DQo+DQo+IEFnYWlu LCB0aGUgUDJNUCBzaXR1YXRpb24gdGhyb3dzIG1lLiAgSXMgdGhpcyBzb21ldGhpbmcgdGhhdCBp cyB1c2VkDQo+IGNvbW1vbmx5Pw0KPg0KPiBJJ20gdW5kZXIgdGhlIGltcHJlc3Npb24gdGhhdCBh ZGRpbmcgUDJNUCB0byBhbnkgbW9kZWwgcmVzdWx0cyBpbiBhIG1vcmUNCj4gY29tcGxleCBtb2Rl bC4gIFdldGhlciBvdXRzaWRlIHMtdGFnIGlzIHVzZWQgdG8gZGlmZmVyZW50aWF0ZSwgb3INCj4g ZGVkaWNhdGVkIHB3J3MgYXJlIHVzZWQgZm9yIHRoZSBzYW1lIHB1cnBvc2UsIGl0IHNlZW1zIGJv dGggYmVjb21lIG1vcmUNCj4gY29tcGxleC4NCj4NCj4gR2lsZSdzIGNvbXBhcmlzb24gc2xpZGUg c3RpbGwgY29uY2lzZWx5IGNhcHR1cmVzIHRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVuDQo+IHRoZXNl IG1ldGhvZHMsIGluIG15IG9waW5pb24uICBJIGhhdmVuJ3Qgc2VlbiBhbnkgbmV3IGlkZWFzIG9y IHRob3VnaHRzDQo+IGJyb3VnaHQgdG8gdGhlIGdyb3VwIGluIHRoZSBwYXN0IHdlZWsgb3IgdHdv IG9uIHRoZSBzdWJqZWN0LiAgSSB3b3VsZCBoYXRlDQo+IGZvciBib3RoIHByb3Bvc2VkIG1ldGhv ZHMgdG8gZGllIG9uIHRoZSB2aW5lIGJlY2F1c2Ugd2UgY291bGRuJ3QgZGVjaWRlDQo+IGJldHdl ZW4gdHdvIG1ldGhvZHMgdGhhdCBoYXZlIG5vdGhpbmcgaW5oZXJlbnRseSB3cm9uZyB3aXRoIGVp dGhlci4NCj4NCj4gLUpvc2gNCj4NCj4NCj4gT24gNC8xOC8xMiAxOjUzIFBNLCAiTHVjeSB5b25n IiA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3Jv dGU6DQo+DQo+PlNlbmQgdGhpcyBhZ2Fpbi4NCj4+DQo+PlR3byBQVyBhcHByb2FjaCBjYW4gYmUg Y29tcGxleCB0b28gaWYgdGhlIFZQTFMgaW5zdGFuY2UgZm9yIEUtVHJlZSB1c2VzDQo+PlAyUCBQ VyBmb3IgdW5pY2FzdCB0cmFmZmljIGFuZCBQMk1QIFBXIGZvciBicm9hZGNhc3QgYW5kIHVua25v d24NCj4+dW5pY2FzdCB0cmFmZmljLCBhbmQgc29tZSBQMk1QIFBXcyBmb3IgbXVsdGljYXN0IHRy YWZmaWMuIEl0IG1heSBkb3VibGUNCj4+YWxsIG9mIHRoZW0uDQo+Pg0KPj5MdWN5DQo+Pg0KPj4t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiBEYW5pZWwgQ29obiBbbWFpbHRvOkRh bmllbENAb3Jja2l0LmNvbTxtYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tPl0NCj4+U2VudDogV2Vk bmVzZGF5LCBBcHJpbCAxOCwgMjAxMiAxOjQyIFBNDQo+PlRvOiBMdWN5IHlvbmc7IFJvZ2Vycywg Sm9zaDsgU2FtIENhbw0KPj5DYzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3Jn Pg0KPj5TdWJqZWN0OiBSRTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1U cmVlIHNvbHV0aW9uPw0KPj4NCj4+SSB0aGluayB0aGUgZmlyc3Qgb3B0aW9uIGl0cyB0aGUgbmF0 dXJhbCB3YXkgdG8gZ28uIEhvdyBpcyB0aGUgcHJvY2Vzc2luZw0KPj5pbiB0aGlzIGNhc2UgbW9y ZSBjb21wbGV4Pw0KPj4NCj4+VGh1bWIgdHlwZWQgLSBwbGVhc2UgYmUgdG9sZXJhbnQNCj4+DQo+ Pkx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWku Y29tPj4gd3JvdGU6DQo+Pg0KPj4NCj4+DQo+PlNuaXBwZWQuLg0KPj4NCj4+TXVsdGktUFcgLSBP biBpbmdyZXNzIFBFLCBmcmFtZSBpcyBwbGFjZWQgb250byBlaXRoZXIgYSBMZWFmLW9ubHkgUDJN UCBQVw0KPj4oZm9yIHRyYWZmaWMgY29taW5nIGZyb20gYSBsZWFmIEFDKSwgb3Igb250byBhIFJv b3QvTGVhZiBQMk1QIFBXIChmb3INCj4+dHJhZmZpYyBjb21pbmcgZnJvbSBhIHJvb3QgQUMpDQo+ PltbTFldXSBOb3QgdGhhdCBzaW1wbGUuIFlvdSBjb25zdHJ1Y3QgZWl0aGVyIHR3byBQMk1QIFBX cyB0byBhbGwgb3RoZXINCj4+UEVzIGFuZCBsZXQgZWdyZXNzIFBFIHBlcmZvcm1pbmcgZmlsdGVy aW5nLCBvciBjb25zdHJ1Y3Qgb25lIFAyTVAgUFcgdG8NCj4+bGVhZi1vbmx5IFBFcyBhbmQgdHdv IFAyTVAgUFdzIHRvIHJvb3QgYW5kIGxlYWYgUEVzIGFuZCBsZXQgaW5ncmVzcyBQRQ0KPj5wZXJm b3JtIGZvcndhcmRpbmcgYW5kIGZpbHRlcmluZy4gQm90aCBtYWtlIG5vZGUgcHJvY2VzcyBjb21w bGV4Lg0KPj4NCj4+W1tMWV1dIFZQTFMgaXMgYnVpbHQgd2l0aCB0aGUgbWVjaGFuaXNtIHV0aWxp emluZyBQMlAgYW5kIFAyTVAgUFcgZm9yDQo+PmRlbGl2ZXJpbmcgdGhlIGZyYW1lcyB0byByZW1v dGUgUEVzLiBXZSBzaG91bGQgdXRpbGl6ZSB0aGVtIHdpdGggdGhlDQo+Pm1pbmltaXplZCBjaGFu Z2VzLiBEdWFsIFZMQU4gc29sdXRpb24gaXMgc2ltcGxlciB0aGFuIER1YWwgUFcuDQo+Pg0KPj5S ZWdhcmRzLA0KPj5MdWN5DQo+Pg0KPj4NCj4+SSBzZWUgaG93IDJWTEFOIGlzIHNpbXBsZXIgd2hl biBQMk1QIFBXJ3MgYXJlIGludm9sdmVkLCBJIHRoaW5rLiAgSQ0KPj5oYXZlbid0IGhhZCBhbnkg Zmlyc3QgaGFuZCBleHBlcmllbmNlIHdpdGggUDJNUCBQVydzLCBob3dldmVyLCBzbyBkb24ndA0K Pj5mZWVsIHRlcnJpYmx5IHN0cm9uZyBhYm91dCB0aGlzIG9iamVjdGlvbi4gIElzIHRoaXMgYSBy ZWFsIHByb2JsZW0gZm9yDQo+Pm90aGVycyAobm93IG9yIGluIHRoZSBmdXR1cmUpLCBvciBpcyB0 aGlzIG9iamVjdGlvbiBpbiB0aGUgd2VlZHM/DQo+Pg0KPj5JJ20gbm90IHN1cmUgdGhlICdhZGRp dGlvbmFsIGNvbXBsZXhpdHknIGlzIG5vdGFibGUsIG9yIGV2ZW4gcmVsZXZhbnQuICBJDQo+PmVu Y291cmFnZSBvdGhlcnMgdG8gc3BlYWsgdXAgaWYgdGhleSBkaXNhZ3JlZSwgYXMgUDJNUCBQVyBp cyBvbmx5DQo+PmNvbmNlcHR1YWwgdG8gbWUsIGFuZCBJIGFtIHVuZmFtaWxpYXIgd2l0aCByZWFs LWxpZmUgdXNlIGNhc2VzIGZvciBpdC4NCj4+DQo+PlRoYW5rcywNCj4+Sm9zaA0KPj4NCj4+DQo+ Pg0KPj5PbiA0LzE4LzEyIDEwOjMwIEFNLCAiTHVjeSB5b25nIiA8bHVjeS55b25nQGh1YXdlaS5j b208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+Pg0KPj4+UGxlYXNlIHNl ZSBpbmxpbmUuDQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBT YW0gQ2FvIFttYWlsdG86eXVxdW4uY2FvQGdtYWlsLmNvbTxtYWlsdG86eXVxdW4uY2FvQGdtYWls LmNvbT5dDQo+Pj5TZW50OiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiA3OjE0IEFNDQo+Pj5Ubzog J0RhbmllbCBDb2huJzsgTHVjeSB5b25nOyAnUm9nZXJzLCBKb3NoJzsgJ0hlbmRlcmlja3gsIFdp bSAoV2ltKSc7DQo+Pj5naWxlcy5oZXJvbkBnbWFpbC5jb208bWFpbHRvOmdpbGVzLmhlcm9uQGdt YWlsLmNvbT47IHNpbW9uLmRlbG9yZEBnbWFpbC5jb208bWFpbHRvOnNpbW9uLmRlbG9yZEBnbWFp bC5jb20+Ow0KPj4+QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPg0KPj4+Q2M6IGwydnBuQGlldGYub3JnPG1haWx0 bzpsMnZwbkBpZXRmLm9yZz47IFZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZs YWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb20+Ow0KPj4+QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5j b208bWFpbHRvOkFuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPjsgSWRhbi5LYXNwaXRAZWNpdGVs ZS5jb208bWFpbHRvOklkYW4uS2FzcGl0QGVjaXRlbGUuY29tPjsNCj4+Pk1pc2hhZWwuV2V4bGVy QGVjaXRlbGUuY29tPG1haWx0bzpNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT47IFJvdGVtLkNv aGVuQGVjaXRlbGUuY29tPG1haWx0bzpSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbT4NCj4+PlN1Ympl Y3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRp b24/DQo+Pj4NCj4+PlllcywgMiBwd3MgYXJlIG9ubHkgbmVlZGVkIGJldHdlZW4gcGVzIHdpdGgg Ym90aCByb290IGFuZCBsZWFmIGFjcyBhZnRlcg0KPj4+aW1wcm92aW5nIER1YWwtUFcgYXBwcm9h Y2guIElmIGNvbnNpZGVyIFAyTVAsIER1YWwtUFcgYXBwcm9hY2ggc2V0dXAgMg0KPj4+UDJNUA0K Pj4+UFdzIGlmIG5lZWQuIFRoZXJlIGlzIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBQMk1QIG9yIG5v cm1hbCBQVyBzZXR1cC4gQnV0LA0KPj4+Y2FuIExlYWYtQUNzIGJlIGJvdW5kIHRvIFJvb3QgUEUg b2YgUDJNUCBQVz8NCj4+Pg0KPj4+W1tMWV1dIE5vLCBpdCBtYWtlcyBjb21wbGV4IGluIHNldHRp bmcgdXAgUDJNUCBQVy4gU2hvdWxkIGEgUEUgd2l0aCBib3RoDQo+Pj5yb290IGFuZCBsZWFmIEFD cyBzZXQgdXAgdHdvIG9yIG9uZSBQMk1QIFBXIHRvIG90aGVyIFBFcyAoc29tZSBQRSBoYXZlDQo+ Pj5ib3RoIHJvb3QgYW5kIGxlYWYgQUMgYW5kIHNvbWUgb25seSBoYXZlIGxlYWYgQUNzKT8NCj4+ PlJlZ2FyZHMsDQo+Pj5MdWN5DQo+Pj4NCj4+PlJlZ2FyZHMsDQo+Pj4NCj4+Pll1cXVuIChTYW0p IENhbw0KPj4+RS1tYWlsOiBZdXF1bi5jYW9AZ21haWwuY29tPG1haWx0bzpZdXF1bi5jYW9AZ21h aWwuY29tPg0KPj4+DQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9t OiBEYW5pZWwgQ29obiBbbWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbTxtYWlsdG86RGFuaWVsQ0Bv cmNraXQuY29tPl0NCj4+PlNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE3LCAyMDEyIDQ6NTYgUE0NCj4+ PlRvOiBMdWN5IHlvbmc7IFJvZ2VycywgSm9zaDsgSGVuZGVyaWNreCwgV2ltIChXaW0pOw0KPj4+ Z2lsZXMuaGVyb25AZ21haWwuY29tPG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+Ow0KPj4+ c2ltb24uZGVsb3JkQGdtYWlsLmNvbTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT47IEFs ZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbT47IFNhbSBDYW8NCj4+PkNjOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2 cG5AaWV0Zi5vcmc+OyBWbGFkaW1pci5LbGVpbmVyQGVjaXRlbGUuY29tPG1haWx0bzpWbGFkaW1p ci5LbGVpbmVyQGVjaXRlbGUuY29tPjsNCj4+PkFuZHJldy5TZXJnZWV2QGVjaXRlbGUuY29tPG1h aWx0bzpBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbT47IElkYW4uS2FzcGl0QGVjaXRlbGUuY29t PG1haWx0bzpJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbT47DQo+Pj5NaXNoYWVsLldleGxlckBlY2l0 ZWxlLmNvbTxtYWlsdG86TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb20+OyBSb3RlbS5Db2hlbkBl Y2l0ZWxlLmNvbTxtYWlsdG86Um90ZW0uQ29oZW5AZWNpdGVsZS5jb20+DQo+Pj5TdWJqZWN0OiBS RTogVGhlIHN0YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0K Pj4+DQo+Pj5BZGRpbmcgU2FtIChhcyBsMnZwbkAgaXMgaG9sZGluZyBtZXNzYWdlcykNCj4+Pg0K Pj4+REMNCj4+Pg0KPj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IEx1Y3kg eW9uZyBbbWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2Vp LmNvbT5dDQo+Pj5TZW50OiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiAxMjozOSBBTQ0KPj4+VG86 IERhbmllbCBDb2huOyBSb2dlcnMsIEpvc2g7IEhlbmRlcmlja3gsIFdpbSAoV2ltKTsNCj4+Pmdp bGVzLmhlcm9uQGdtYWlsLmNvbTxtYWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tPjsgc2ltb24u ZGVsb3JkQGdtYWlsLmNvbTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT47DQo+Pj5BbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb20+DQo+Pj5DYzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3Jn PjsgVmxhZGltaXIuS2xlaW5lckBlY2l0ZWxlLmNvbTxtYWlsdG86VmxhZGltaXIuS2xlaW5lckBl Y2l0ZWxlLmNvbT47DQo+Pj5BbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWlsdG86QW5kcmV3 LlNlcmdlZXZAZWNpdGVsZS5jb20+OyBJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbTxtYWlsdG86SWRh bi5LYXNwaXRAZWNpdGVsZS5jb20+Ow0KPj4+TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb208bWFp bHRvOk1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPjsgUm90ZW0uQ29oZW5AZWNpdGVsZS5jb208 bWFpbHRvOlJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPg0KPj4+U3ViamVjdDogUkU6IFRoZSBzdGF0 dXMgb2YgdGhlIGFwcHJvYWNoZXMgdG8gdGhlIEUtVHJlZSBzb2x1dGlvbj8NCj4+Pg0KPj4+DQo+ Pj5TbmlwcGVkLA0KPj4+DQo+Pj5BcyB3ZSBkaXNjdXNzZWQgZXh0ZW5zaXZlbHkgaW4gdGhlIGxp c3QsIGFuZCBhcyByZWZsZWN0ZWQgaW4gZ2lsZXMNCj4+PnNsaWRlLCAyIHB3cyBhcmUgb25seSBu ZWVkZWQgYmV0d2VlbiBwZXMgd2l0aCBib3RoIHJvb3QgYW5kIGxlYWYgYWNzLA0KPj4+d2hpY2gg d2lsbCB0eXBpY2FsbHkgYmUgYSBzbWFsbCBtaW5vcml0eS4NCj4+PltbTFldXSBEb24ndCBrbm93 IGlmIHRoZSBhc3N1bXB0aW9uIGlzIHRydWUuIEV2ZW4gaXQgaXMgdGhlIGNhc2UsIGJvdGgNCj4+ PmFwcHJvYWNoZXMgY2FuIGJlbmVmaXQgZnJvbSBpdC4gSSB3YXMgb2ZmIGZvciBhIHdoaWxlIGFu ZCBjYXB0dXJlcyBzb21lDQo+Pj5kaXNjdXNzaW9ucyBub3cuDQo+Pj4NCj4+PkFsc28gYXMgcGVy IGdpbGVzIHNsaWRlLCBkdWFsIHZsYW4gY2FuIGhhdmUgc2NhbGFiaWxpdHkgaXNzdWVzIGR1ZSB0 bw0KPj4+YWRkaXRpb25hbCBsb29rdXAgYW5kIGRvdWJsZSB1c2Ugb2YgdmxhbnMgaW4gaW50ZXJu YWwgZW11bGF0ZWQgbGFuDQo+Pj5pbnRlcmZhY2UuIEFsc28gdGhlcmUgYXJlIHBvdGVudGlhbCBi YWNrd2FyZCBjb21wYXRpYmlsaXR5IGlzc3VlcyB3aXRoDQo+Pj5zaWxpY29uIHRoYXQgZG9lc24n dCBzdXBwb3J0IHZsYW4gbWFwcGluZy4NCj4+PltbTFldXSBJIHdhcyBub3QgaW4gSUVURjgzIG1l ZXRpbmcgYW5kIHdhaXQgb24gdGhlIG1lZXRpbmcgbWludXRlcy4gSSBhbQ0KPj4+bm90IGNsZWFy IG9uIGFsbCB0aGUgaXNzdWVzLiBDb3VsZCB5b3UgYmUgbW9yZSBzcGVjaWZpYz8gQXMgSSBtZW50 aW9uZWQNCj4+PmluIGJlbG93LCB0d28gUFcgYXBwcm9hY2ggbWFrZXMgVlBMUyB0cmFuc3BvcnQg Y29uc3RydWN0aW9uIGFuZCBwYWNrZXQNCj4+PmZvcndhcmRpbmcgbW9yZSBjb21wbGV4LCBJIGNh biBzZWUgcG90ZW50aWFsIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkNCj4+Pmlzc3VlcyB3aXRoIDIg UFcgc29sdXRpb24uDQo+Pj4NCj4+PlJlZ2FyZHMsDQo+Pj5MdWN5DQo+Pj4NCj4+PlJlZ2FyZHMs DQo+Pj4NCj4+PkRhbmllbA0KPj4+DQo+Pj5UaHVtYiB0eXBlZCAtIHBsZWFzZSBiZSB0b2xlcmFu dA0KPj4+DQo+Pj5MdWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5Lnlv bmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KPj4+DQo+Pj5JbiBteSBtaW5kLCB0aGUgVkxBTiBhcHBy b2FjaCBtZWFucyBkdWFsIHZsYW4gbWV0aG9kLg0KPj4+DQo+Pj5UaGUgbWFpbiBjb25jZXJuIGZv ciBDVyBhcHByb2FjaCBpcyBoYXJkd2FyZSBzdXBwb3J0Lg0KPj4+DQo+Pj5Ud28gUFcgYXBwcm9h Y2ggY2FuIGJlIGNvbXBsZXggdG9vIGlmIHRoZSBWUExTIGluc3RhbmNlIGZvciBFLVRyZWUgdXNl cw0KPj4+UDJQIFBXIGZvciB1bmljYXN0IHRyYWZmaWMgYW5kIFAyTVAgUFcgZm9yIGJyb2FkY2Fz dCBhbmQgdW5rbm93biB1bmljYXN0DQo+Pj50cmFmZmljLCBhbmQgc29tZSBQMk1QIFBXcyBmb3Ig bXVsdGljYXN0IHRyYWZmaWMuIEl0IG1heSBkb3VibGUgYWxsIG9mDQo+Pj50aGVtLg0KPj4+DQo+ Pj5FLXRyZWUgaXMgYW4gRXRoZXJuZXQgc2VydmljZSBhbmQgdGhlcmUgaXMgYWxyZWFkeSBWTEFO IGJhc2VkIHNvbHV0aW9uDQo+Pj5pbiBJRUVFLCBjYW4gd2UganVzdCB1dGlsaXplIGl0IHdpdGhv dXQgY29tcGxpY2F0aW5nIFZQTFMgdHJhbnNwb3J0DQo+Pj5jb25zdHJ1Y3Rpb24/IFRoaXMgYWxz byBtYWtlcyBpbnRlcndvcmtpbmcgd2l0aCBFdGggb25seSBuZXR3b3JrIGVhc2llci4NCj4+Pg0K Pj4+Q2hlZXJzLA0KPj4+THVjeQ0KPj4+DQo+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4+RnJvbTogUm9nZXJzLCBKb3NoIFttYWlsdG86am9zaC5yb2dlcnNAdHdjYWJsZS5jb208bWFp bHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29tPl0NCj4+PlNlbnQ6IE1vbmRheSwgQXByaWwgMTYs IDIwMTIgODozNSBBTQ0KPj4+VG86IEx1Y3kgeW9uZzsgSGVuZGVyaWNreCwgV2ltIChXaW0pOyAn Z2lsZXMuaGVyb25AZ21haWwuY29tPG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+JzsNCj4+ PidzaW1vbi5kZWxvcmRAZ21haWwuY29tPG1haWx0bzpzaW1vbi5kZWxvcmRAZ21haWwuY29tPic7 ICdBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5z aHRlaW5AZWNpdGVsZS5jb20+Jw0KPj4+Q2M6ICdsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5A aWV0Zi5vcmc+JzsgJ1ZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWly LktsZWluZXJAZWNpdGVsZS5jb20+JzsNCj4+PidBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxt YWlsdG86QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb20+JzsgJ0lkYW4uS2FzcGl0QGVjaXRlbGUu Y29tPG1haWx0bzpJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbT4nOw0KPj4+J01pc2hhZWwuV2V4bGVy QGVjaXRlbGUuY29tPG1haWx0bzpNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT4nOyAnUm90ZW0u Q29oZW5AZWNpdGVsZS5jb208bWFpbHRvOlJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPicNCj4+PlN1 YmplY3Q6IFJFOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29s dXRpb24/DQo+Pj4NCj4+PkkgYmVsaWV2ZSB0aGUgaW5pdGlhbCBxdWVzdGlvbiB3YXMgaW4gcmVn YXJkIHRvIHRoZSBDVyBtZXRob2QuICBBcmUgeW91DQo+Pj5zYXlpbmcgdGhhdCB5b3Ugbm8gbG9u Z2VyIGFyZSBpbnRlcmVzdGVkIGluIHRoYXQgbWV0aG9kIGluIHByZWZlcmVuY2Ugb2YNCj4+PnRo ZSBkdWFsIHZsYW4gbWV0aG9kPw0KPj4+DQo+Pj4NCj4+Pg0KPj4+THVjeSB5b25nIDxsdWN5Lnlv bmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiB3cm90ZToNCj4+Pg0K Pj4+DQo+Pj5BZ3JlZSB3aXRoIFdpbS4gVkxBTiBhcHByb2FjaCBpcyB0aGUgYmVzdCBzb2x1dGlv biBmb3IgRS1UcmVlLg0KPj4+DQo+Pj5MdWN5DQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj5Gcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpsMnZwbi1ib3Vu Y2VzQGlldGYub3JnPiBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBu LWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYNCj4+Pk9mIEhlbmRlcmlja3gsIFdpbSAoV2lt KQ0KPj4+U2VudDogVGh1cnNkYXksIEFwcmlsIDEyLCAyMDEyIDI6MDMgQU0NCj4+PlRvOiAnZ2ls ZXMuaGVyb25AZ21haWwuY29tPG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5jb20+JzsgJ3NpbW9u LmRlbG9yZEBnbWFpbC5jb208bWFpbHRvOnNpbW9uLmRlbG9yZEBnbWFpbC5jb20+JzsNCj4+PidB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRl aW5AZWNpdGVsZS5jb20+Jw0KPj4+Q2M6ICdsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0 Zi5vcmc+JzsgJ1ZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLkts ZWluZXJAZWNpdGVsZS5jb20+JzsNCj4+PidBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWls dG86QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb20+JzsgJ0lkYW4uS2FzcGl0QGVjaXRlbGUuY29t PG1haWx0bzpJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbT4nOw0KPj4+J01pc2hhZWwuV2V4bGVyQGVj aXRlbGUuY29tPG1haWx0bzpNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT4nOyAnUm90ZW0uQ29o ZW5AZWNpdGVsZS5jb208bWFpbHRvOlJvdGVtLkNvaGVuQGVjaXRlbGUuY29tPicNCj4+PlN1Ympl Y3Q6IFJlOiBUaGUgc3RhdHVzIG9mIHRoZSBhcHByb2FjaGVzIHRvIHRoZSBFLVRyZWUgc29sdXRp b24/DQo+Pj4NCj4+PlRoZSB2bGFuIGFwcHJvYWNoIGlzIHN1cGVyaW9yIGFzIGl0IGFsc28gd29y a3MgZm9yIGV0aCBvbmx5IG5ldHdvcmtzLA0KPj4+ZXRjLiBPbiB0b3Agc29tZSB2ZW5kb3JzIGlu ZGljYXRlIGh3IGlzc3VlcyB3aXRoIHRoZSBjdyBhcHByb2FjaC4gQXMNCj4+PnN1Y2ggd2UgaGF2 ZSBkcm9wcGVkIG1vcmUgb3IgbGVzcyB0aGUgY3cgYXBwcm9hY2guDQo+Pj4NCj4+PkNoZWVycywN Cj4+PldpbQ0KPj4+X19fX19fX19fX19fX19fX18NCj4+PnNlbnQgZnJvbSBibGFja2JlcnJ5DQo+ Pj4NCj4+Pi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4+PkZyb206IEdpbGVzIEhlcm9u IFttYWlsdG86Z2lsZXMuaGVyb25AZ21haWwuY29tPG1haWx0bzpnaWxlcy5oZXJvbkBnbWFpbC5j b20+XQ0KPj4+U2VudDogVGh1cnNkYXksIEFwcmlsIDEyLCAyMDEyIDA4OjIyIEFNDQo+Pj5Ubzog U2ltb24gRGVsb3JkIDxzaW1vbi5kZWxvcmRAZ21haWwuY29tPG1haWx0bzpzaW1vbi5kZWxvcmRA Z21haWwuY29tPj47IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+Pj48QWxleGFuZGVyLlZhaW5zaHRl aW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPj4N Cj4+PkNjOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+IDxsMnZwbkBpZXRm Lm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+PjsgVmxhZGltaXIgS2xlaW5lcg0KPj4+PFZsYWRp bWlyLktsZWluZXJAZWNpdGVsZS5jb208bWFpbHRvOlZsYWRpbWlyLktsZWluZXJAZWNpdGVsZS5j b20+PjsgQW5kcmV3IFNlcmdlZXYNCj4+PjxBbmRyZXcuU2VyZ2VldkBlY2l0ZWxlLmNvbTxtYWls dG86QW5kcmV3LlNlcmdlZXZAZWNpdGVsZS5jb20+PjsgSWRhbiBLYXNwaXQgPElkYW4uS2FzcGl0 QGVjaXRlbGUuY29tPG1haWx0bzpJZGFuLkthc3BpdEBlY2l0ZWxlLmNvbT4+Ow0KPj4+TWlzaGFl bCBXZXhsZXIgPE1pc2hhZWwuV2V4bGVyQGVjaXRlbGUuY29tPG1haWx0bzpNaXNoYWVsLldleGxl ckBlY2l0ZWxlLmNvbT4+OyBSb3RlbSBDb2hlbg0KPj4+PFJvdGVtLkNvaGVuQGVjaXRlbGUuY29t PG1haWx0bzpSb3RlbS5Db2hlbkBlY2l0ZWxlLmNvbT4+DQo+Pj5TdWJqZWN0OiBSZTogVGhlIHN0 YXR1cyBvZiB0aGUgYXBwcm9hY2hlcyB0byB0aGUgRS1UcmVlIHNvbHV0aW9uPw0KPj4+DQo+Pj5T b3JyeSAtIHRoZSAiYW5vbnltb3VzIHByZXNlbnRhdGlvbiIgd2FzIG1pbmUuICBJIHNob3VsZCBw b3NzaWJseSBoYXZlDQo+Pj5wdXQgaW4gYSB0aGlyZCBjb2x1bW4gb24gdGhlIENXIGFwcHJvYWNo LiAgQW5kIGhvcGVmdWxseSB0aGUgbWludXRlcw0KPj4+d2lsbCBiZSBwb3N0ZWQgc29vbi4NCj4+ Pg0KPj4+V2UgaGFkIHZhcmlvdXMgZGlzY3Vzc2lvbnMsIGFzIFNpbW9uIHN0YXRlZCwgYW5kIGNv bnNlbnN1cyBzZWVtZWQgdG8gYmUNCj4+PmZvcm1pbmcgYXJvdW5kIHRoZSB0d28gYWx0ZXJuYXRp dmVzIG9mIHR3byBQV0VzIG9yIHR3byBWTEFOcy4gIEkgYmVsaWV2ZQ0KPj4+dGhyZWUgb2YgdGhl IGF1dGhvcnMgb2YgdGhlIENXIGFwcHJvYWNoIGFyZSBhbHNvIGF1dGhvcnMgb2YgdGhlIHR3byBW TEFODQo+Pj5hcHByb2FjaCBhbmQgb25lIGlzIGFsc28gYW4gYXV0aG9yIG9mIHRoZSB0d28gUFdF IGFwcHJvYWNoLiBTbyBwZXJoYXBzDQo+Pj5pdCdzIGJlc3QgdG8gbGV0IHRob3NlIGZvdXIgaW5k aXZpZHVhbHMgc2F5IHdoaWNoIGFwcHJvYWNoIHRoZXkgcHJlZmVyDQo+Pj5hbmQgd2h5Pw0KPj4+ DQo+Pj5HaWxlcw0KPj4+DQo+Pj5PbiAxMC8wNC8yMDEyIDAwOjQ1LCAiU2ltb24gRGVsb3JkIiA8 c2ltb24uZGVsb3JkQGdtYWlsLmNvbTxtYWlsdG86c2ltb24uZGVsb3JkQGdtYWlsLmNvbT4+IHdy b3RlOg0KPj4+DQo+Pj4+IEhpIEFsZXhhbmRlciwNCj4+Pj4NCj4+Pj4gWW91IGFyZSByaWdodCwg bm8gZGlzY3Vzc2lvbiBvbiB0aGUgV0cgbWFpbGluZyBsaXN0IHJlY2VudGx5LCBidXQNCj4+Pj4g dGhlcmUgaGF2ZSBiZWVuIHN1YnN0YW50aWFsIGRpc2N1c3Npb25zIGFtb25nIHRoZSBhdXRob3Jz IG9mIHZhcmlvdXMNCj4+Pj4gc29sdXRpb24gZHJhZnRzIG9mZiB0aGUgbWFpbGluZyBsaXN0LiBB cyBmYXIgYXMgSSBrbm93LCBubyBjb25zZW5zdXMNCj4+Pj4geWV0IGJlZm9yZSBpZXRmODMsIG5v dCBzdXJlIHRoZSBwcm9ncmVzcyBpbiB0aGUgUGFyaXMgV0cgbWVldGluZy4gSQ0KPj4+PiB0aGlu ayB0aGUgQ1cgYXBwcm9hY2ggaGFzIG5vdCBiZWVuIHJlamVjdGVkIGJ5IHRoZSBXRyB5ZXQsIG9y IHRoZSBXRw0KPj4+PiBoYXMgbm90IHlldCBkZWNpZGVkIG9uIHdoaWNoIG9uZSB0byBhZG9wdC4N Cj4+Pj4NCj4+Pj4gU2ltb24NCj4+Pj4NCj4+Pj4gMjAxMi80LzggQWxleGFuZGVyIFZhaW5zaHRl aW4gPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFp bnNodGVpbkBlY2l0ZWxlLmNvbT4+DQo+Pj4+DQo+Pj4+PiAgSGkgYWxsLA0KPj4+Pj4NCj4+Pj4+ IFVuZm9ydHVuYXRlbHkgSSBoYXZlIG5vdCBiZWVuIGFibGUgdG8gYXR0ZW5kIHRoZSBQYXJpcyBJ RVRGLg0KPj4+Pj4NCj4+Pj4+IEhvd2V2ZXIsIGxvb2tpbmcgdXAgdGhlIEwyVlBOIHByb2NlZWRp bmdzLCBJJ3ZlIGZvdW5kIGEgc2hvcnQNCj4+Pj4+IGFub255bW91cyBwcmVzZW50YXRpb24gY2Fs bGVkICJFLVRyZWUgVXBkYXRlIiAgKA0KPj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVk aW5ncy84My9zbGlkZXMvc2xpZGVzLTgzLWwydnBuLTEucHB0eCkuDQo+Pj4+PiBUaGlzIHByZXNl bnRhdGlvbiBkaXNjdXNzZXMgdGhlIGRpZmZlcmVuY2VzIG9mIHRoZSBFLVRyZWUgYXBwcm9hY2hl cw0KPj4+Pj4gYmFzZWQgb24gZGVkaWNhdGVkIFZMQU5zIChhcyBpbg0KPj4+Pj4gaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jYW8tbDJ2cG4tdnBscy1ldHJlZS8/aW5jbHVk ZV90DQo+Pj4+PiBleHQ9MSkgYW5kIG11bHRpcGxlIFBXcyBiZXR3ZWVuIHRoZSBQRXMgKGFzIGlu DQo+Pj4+PiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJhbS1sMnZwbi1l dHJlZS1tdWx0aXBsZS1wdy8/aW4NCj4+Pj4+IGNsdWRlX3RlDQo+Pj4+PiB4dD0xKQ0KPj4+Pj4g YW5kIGNvbXBsZXRlbHkgaWdub3JlcyB0aGUgc29sdXRpb24gYmFzZWQgb24gdXNhZ2Ugb2YgdGhl IENXIGluIHRoZQ0KPj4+Pj4gUFdzIGNvbm5lY3RpbmcgdGhlIFBFcyAoYXMgaW4NCj4+Pj4+IGh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta2V5LWwydnBuLXZwbHMtZXRyZWUv P2luY2x1ZGVfdA0KPj4+Pj4gZXh0PTENCj4+Pj4+ICkuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+ Pj4+PiBUaGUgTWludXRlcyBvZiB0aGUgUGFyaXMgTDJWUE4gc2Vzc2lvbiBhcmUgbm90IHlldCBh dmFpbGFibGUsIGJ1dCBJDQo+Pj4+PiB3b25kZXIgd2hldGhlciB0aGUgV0cgaGFzIHRha2VuIGEg ZGVjaXNpb24gdG8gcmVqZWN0IHRoZSBhcHByb2FjaA0KPj4+Pj4gYmFzZWQgb24gdGhlIENXIHVz YWdlPyBJIGRvIG5vdCByZW1lbWJlciBhbnkgcmVjZW50IGRpc2N1c3Npb24gb2YNCj4+Pj4+IHRo aXMgdG9waWMgb24gdGhlIFdHIG1haWxpbmcgbGlzdC4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+ Pj4+IFJlZ2FyZHMsIGFuZCBsb3RzIG9mIHRoYW5rcyBpbiBhZHZhbmNlLA0KPj4+Pj4NCj4+Pj4+ IFNhc2hhDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFRoaXMgZS1t YWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFp bnMNCj4+Pj4+IGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5 IGJlIHByb3ByaWV0YXJ5IHRvIEVDSQ0KPj4+DQo+Pj4+PiBUZWxlY29tLiBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlDQo+Pj4+PiBpbmZvcm0g dXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwg YW5kDQo+Pj4+PiBhbGwgY29waWVzIHRoZXJlb2YuDQo+Pj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+ DQo+Pj4NCj4+PlRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIFRpbWUgV2FybmVyIENhYmxlDQo+Pj5wcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2gg aXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0DQo+Pj50byBjb3B5cmlnaHQg YmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZA0K Pj4+c29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGlj aCBpdCBpcyBhZGRyZXNzZWQuDQo+Pj5JZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieQ0KPj4+bm90aWZpZWQgdGhhdCBhbnkg ZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4NCj4+ PmluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBF LW1haWwgaXMNCj4+PnN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcw0KPj4+RS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5DQo+Pj5kZWxldGUgdGhlIG9y aWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0KPj4+ DQo+Pg0KPj4NCj4+VGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gVGltZSBXYXJuZXIgQ2FibGUNCj4+cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNo IGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0bw0KPj5jb3B5cmlnaHQg YmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBz b2xlbHkNCj4+Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNo IGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91DQo+PmFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQNCj4+dGhhdCBhbnkgZGlz c2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4NCj4+ cmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFp bCBpcyBzdHJpY3RseQ0KPj5wcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluDQo+PmVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUNCj4+b3JpZ2luYWwg YW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo+DQo+DQo+IFRo aXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2Fy bmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBj b25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdh cm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9m IHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUg aGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29w eWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQg YXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5 IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxl dGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50 b3V0Lg0KPiBUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50 IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQg d2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1h aWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYWxsIGNv cGllcyB0aGVyZW9mLg0KPg0KPg0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g TDJ2cG4gbWFpbGluZyBsaXN0DQo+IEwydnBuQGlldGYub3JnPG1haWx0bzpMMnZwbkBpZXRmLm9y Zz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sMnZwbg0KPg0KPg0K PiBFbmQgb2YgTDJ2cG4gRGlnZXN0LCBWb2wgOTUsIElzc3VlIDI1DQo+ICoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqDQo= From DanielC@orckit.com Mon Apr 30 04:38:43 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8006A21F85D9 for ; Mon, 30 Apr 2012 04:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HS_INDEX_PARAM=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 Hwic-sR1bxSr for ; Mon, 30 Apr 2012 04:38:40 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9C12F21F84B8 for ; Mon, 30 Apr 2012 04:38:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Date: Mon, 30 Apr 2012 14:40:37 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130777C8DC@tlvmail1> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D3264C3CB@dfweml505-mbx> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNI1NEe/4Txq0Y50G6N17p5Mncd5atPrZAgAYGhwA= References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3F298@SZXEML508-MBS.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D3264C3CB@dfweml505-mbx> From: "Daniel Cohn" To: "Lucy yong" , "Jiangyuanlong" , "Fedyk, Donald (Don" , "Rogers, Josh" Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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, 30 Apr 2012 11:38:43 -0000 Yuanlong, So the 2-VLAN solution, for the S-VLAN tagged port, works only when there is a single S-VID per AC? Thanks, DC -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Wednesday, April 25, 2012 9:21 PM To: Fedyk, Donald (Don; Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Don and Josh, draft-jiang-l2vpn-vpls-pe-etree-05 discussed S-VLAN access in the following way: "... For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames received from the root ACs can be translated to the root S-VLAN in the VPLS network domain. Alternatively, the PBB VPLS PE model (where an IEEE 802.1ah bridge module is embedded in the PE) as described in [PBB-VPLS] can be used, and a root B-VLAN or leaf B-VLAN can be added in this case. In a similar way, the traffic from the leaf ACs is tagged and transported on the leaf C-VLAN, S-VLAN or B-VLAN.=20 " It seems option B is in line with the 1st sentence, not sure where option A came from, but do you have any concerns with the description in the 2nd sentence? Regards, Yuanlong ---------------------------------------------------------------------- Date: Wed, 25 Apr 2012 18:52:50 -0500 From: "Fedyk, Donald (Don)" To: "Rogers, Josh" , David Allan I , Daniel Cohn , "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: =09 =09 Content-Type: text/plain; charset=3D"us-ascii" Hi Josh Is there a draft that describes solution A? Solution B is what I've seen in the IEEE. One argument is that A is adding an extra TAG that offers little value. The TAG you have labeled 2 may need to be swapped anyway. Stacking S-TAGs is why PBB was developed. Cheers, Don -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Wednesday, April 25, 2012 7:22 PM To: David Allan I; Fedyk, Donald (Don); Daniel Cohn; l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? > Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. I have to apologize, because I think I led y'all down that path (I referred to the outermost tag, the same tag that the MPLS psuedowire is using for vlan mode encamp, as the S-Tag, even though the customer is the one placing it on the frame. Same as I described below, but I either used term S-Tag incorrectly, or ambiguously. >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... So, I think this could be cleared up some still. What I was referring to is the VID that the customer is using to put frames in, the VID which they should use to ensure the frame goes into the correct ETREE instance. You drew a distinction between 'customer VID' vs 'provider VID', but since it is negotiated, I haven't really seen a distinction, which I think is what has caused all the confusion. In the two discussion points/solutions I mentioned, the first one, "A", describes both a coordinated VID which the customer should use, and the service provider uses to distinguish between services on the same UNI, as well as a second, outer, VID which is used by the SP to determine the source AC type. In my example, if you were to sniff inside the psuedowire between PE1 and PE2 to see CE2 destined traffic, wish solution A, you might see "4001:2:Payload", where 4001 designates it is from a root AC, 2 designates the ETREE instance, and Payload is the customer's traffic (which may include a C-Tag), where with solution B, you would see "4001:Payload", and VID 2 would have to be swapped for 4001 as it enters the PE2-CE2 AC, giving the customer "2:Payload" just as they sent it (alternatively SP may choose to simply drop tag entirely and provide "Payload" to customer, this can cause problems with PVST on some devices, but I still see it done occasionally) ** Note, for the example above, I'm assuming 4001 is used as a 'standard' for root sourced frames, and 4002 is used for leaf sourced frames, for the ETREE R/L tags. Have I undone the confusion, or made it worse? -Josh On 4/25/12 5:19 PM, "David Allan I" wrote: >Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. > >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" > >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... > >Cheers >Dave > > > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Wednesday, April 25, 2012 5:42 PM >To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >Dave/Daniel/Lucy/Others Debating how many tags necessary when S-Tag >preservation is desired, > > >I think you all may have gone off on a tangent here. The original >discussion was about how to deal with the situation where the S-Tag is >preserved at a handoff (either an ENNI, or Service Multiplexed UNI) > >I believe there were two suggestions, one was that you push on a 'ETREE' >tag (one of two values, for either a frame sourced from a root AC or >another for a frame from a leaf AC), and the second solution was to 'map'. > > >Imagine the following topology: > >+-----+ +-----+ +-----+ +-----+ >| CE1 |--| PE1 |--| PE2 |--| CE2 | >+-----+ +-----+ +-----+ +-----+ > | | >+-----+ +-----+ +-----+ +-----+ >| CE3 |--| PE3 |--| PE4 |--| CE4 | >+-----+ +-----+ +-----+ +-----+ > >Where: > >Site Type VLAN >CE1 Root X >CE2 Leaf 2 >CE3 Leaf 3 >CE4 Leaf 3 > > >So, there are a lot of SP's who are keen on the way many services can be >handed to a customer on a single UNI, but coordinating a single VLAN per >service, with the customer (MEF used to call this EVPL when it was many >point to point services terminating on a single UNI). So, imagine that >we have two ETREE instances, and an internet service all terminating on a >single UNI connecting to CE1. We have negotiated VLAN ID's with the >customer, and they are expecting to reach CE2 using VLAN 2, CE3 and CE4 >using VLAN 3, and Internet service on VLAN 10. As a frame from CE1 comes >into PE1 destined for CE2 (so the customer has tagged it with VID 2), >using the 2VLAN method, since this is coming from a root site, do we > >a) place the Root S-Tag in front of VID 2, then ship it across, and pop >off the ETREE S-Tag (some SP's wish to Pop the original customer tag VID >2 as well) > >-or- > >b) swap VID2 for the ETREE Root S-Tag, send the frame to PE2 where it >will remove the S-Tag (and either push VID2 back on, or leave it off >depending on SP preference) > >The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf) > > >Hope that clears more than it confuses, >Josh > > > >On 4/25/12 4:22 PM, "Fedyk, Donald (Don)" > wrote: > >>Hi Dave >> >>Yes the only point I would add is Dual VLAN means One VID for Root and >>one VID for Leaf. Not two TAGs at a time on the frame but two allocated >>for the service. >> >>The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks >>about Encapsulation Overhead as a VLAN Tag. While that is true in a PWE >>sense it is still a single VLAN Tag at a time in a Ethernet E-tree sense. >> The compelling driver for Dual VLAN is having a Etree service that >>works in many environments and the DUAL VLAN (really dual VLAN >>interface on a >>VSI) uses the same mechanism (one VID for root and one VID for Leaf at >>a >>time) as specified in the IEEE. In a pure Ethernet bridging world the >>VLAN TAGs for Etree are not typically an overhead since translation is >>used. >> >>Don >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of David Allan I >>Sent: Wednesday, April 25, 2012 5:05 PM >>To: Daniel Cohn; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>OK I feel like I am digressing a fair distance from the actual >>problem.... But here goes: >> >>So the scenarios center around "how ETREE do you want to be?".... >> >>If the ACs are root/leaf, then if they are P2P (single ethernet end >>station attached to each AC) this is moot. ETREE semantics are enforced >>by the 2VID domain in the center of the example. If you assumed nodes >>A&B in the example were L2VPN PEs, the tagging and the PW tag >>imposition all happened at the same point in the network. >> >>If they are not simple P2P all the way to end systems and the objective >>is to avoid bridging between leaf "sites" but allowing intra-leaf-site >>connectivity then the leaves can be LANs but the root is not, such that >>I cannot bridge through the root. But all hosts at a given leaf site >>can see each other. So root Ethernet end systems are directly attached >>or two VIDs are used in the root site. >> >>If the objective is that there are multiple ethernet attached end >>stations at both the leaf and root sites, and the objective is to >>enforce >>L2 isolation everywhere then I need two VIDs extended to the end system >>attachement point in the local LANs by whatever means.... >> >>And I do not see adding VLANs in any particular spot, simply selection >>of the VID and associated semantics where VIDs are translated. The >>actual point of S-tag imposition could be a PE, or cloud be a NID/CLE >>on the customer prem (more likely scenario here to extend OAM demarc to >>the prem), or some switch in a RAN downstream of the MPLS PE... blah >>blah blah. And if ETREE is extended into a customer site LAN and >>outside of the provider domain, then two C-tags would have to be used >>that mapped to S-tags at the PBN boundary... >> >>Make sense? >>Dave >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 25, 2012 4:39 PM >>To: David Allan I; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Dave, but the ACs are root/leaf (that's what the whole vpls etree is >>about - see the reqt draft), so per the 2vlan draft the root/leaf vlan >>must be added. >> >>Thumb typed - please be tolerant >> >>David Allan I wrote: >> >>HI Daniel: >> >>In the example provided, >> >>"ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" >> A B >> >>the service is not ETREE in the domains of the ingress and egress VID. >>It is ELAN. SO there is no root/leaf attribute to shovel around. It >>would require two VIDs in each domain if the ETREE semantics were to be >>telescoped E2E. >> >>Otherwise it is a provisioning of the VID translation tables at the >>intermediate nodes (A&B that I've added to the picture) that would >>determine the VID values used in each domain. Or in the example above, >>what the ingress, Etree and egress VID values were. >> >>Cheers >>Dave >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 3:46 PM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>And to this I asked how this mapping works - how does the egress pe >>recover the ingress vid when it gets the frame tagged with only the >>root/leaf vid? How can you convey the ingress vid plus the root/leaf >>attribute in the same number of bits? >>What am I missing? >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>David Allen already explained the solution. >> >>From David: >>ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. >> >>Ingress VID does not have to equal Egress VID but regardless there is >>only ever one VID on a frame at a time. >> >>-end >> >>This works when customer makes ingress VLAN ID not equal to or equal to >>egress VLAN ID. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 11:39 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Lucy, >> >>The scenario we are discussing is not the E-Tree E-NNI, but a general >>scenario where frames arriving at the root or leaf AC are already >>double tagged. In this case, the dual vlan solution cannot preserve the >>vlans without adding a third one, can it? >> >>Maybe Shahram can add details on the scenario he had in mind >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has S-VLAN preservation attribute for ENNI only because there is no >>s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN >>preservation attribute is used. It applies to E-Tree as well. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Tuesday, April 24, 2012 2:12 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Lucy, >> >>even if the current MEF framework doesn't require s-vlan preservation, >>I believe it's to the industry's benefit to adopt a solution that is >>not constrained to a specific enni model that, like all things >>networking, is likely to evolve. Especially when such a solution is >>available. >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has worked in ENNI interface for a long time with many service >>providers' inputs. It had a fair reason to assume S-VLAN over ENNI by >>then. It may open B-VLAN for the future. It is better for us not to >>discuss a future framework here, because it will lead us to nowhere. >>Here, we want to extend VPLS in supporting E-Tree. >> >>Best Regards, >>Lucy >> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Sunday, April 22, 2012 7:34 AM >>To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Shahram and all, >> >>This question already came up in our discussions - is it safe to assume >>that the VLAN tags at the E-NNI will always be according to the current >>MEF model? Or should we try to be as transparent as possible to user >>VLAN encapsulation at the E-NNI, to accommodate future frameworks? >>I believe that any approach that looks at user payload (in this case >>VLAN >>tag) to signal VPLS information (in this case root/leaf origin) is >>necessarily tied to specific assumptions on user payload encapsulation >>(in this case, that S-VLAN tag is "available" to encode root/leaf). I >>don't think this is a future-proof assumption, it's very likely that >>other network models will come up that require S-VLAN preservation, >>which in the 2-VLAN approach would necessitate adding a third VLAN-ID. >> >>Daniel >> >>From: Shahram Davari > >>To: Lizhong Jin >, >>"l2vpn@ietf.org" >>>, >>"Alexander.Vainshtein@ecitele.com>om> >>" >>>om> >>> >>Cc: "yuqun.cao@gmail.com" >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, >> >>I also have a question regarding 2-VLAN. What if the customer traffic >>already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? >> >>Thx >>Shahram >> >>From: l2vpn-bounces@ietf.org >>[mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin >>Sent: Friday, April 20, 2012 9:38 AM >>To: l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com>m> >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, all, >>The difference between 2-VLAN and CW approach is who will provide the >>R/L information, customer payload or PW? The customer payload will be >>always modified to carry R/L information in 2-VLAN approach, while PW >>with CW will carry R/L information for CW approach. >>I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is >>accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is >>used to access H-VPLS, how could the PE on VPWS side adds VLAN to >>indicate R/L information? >> >>Thanks >>Lizhong >> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Thu, 19 Apr 2012 04:38:36 +0000 >>> From: Alexander Vainshtein >>> >> com>> >>> To: "Rogers, Josh" >>>>, Lucy yong >>> >, Daniel >>>Cohn >, Sam Cao >>> > >>> Cc: "l2vpn@ietf.org" >>> > >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> Message-ID: >>> >>> >> t o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> >>> Content-Type: text/plain; charset=3D"us-ascii" >>> >>> Hi all, >>> I fully understand that that what I am going to say is not very >>>popular, but: >>> >>> IMO one of the advantages of the CW-based solution is that it is >>>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery >>>of BUN traffic. >>> >>> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>>and, in a more generic way, localization of effects of changes in the >>>PE configuration. >>> >>> In particular, adding a Leaf AC to a PE that previously has been only >>>supporting Root ACs (or vice versa), removal of the last Leaf or last >>>Root AC from a PE that previously has been supporting a mix etc. >>>affect only the PE where this operation happens and not the rest of the >>>PEs. >>> >>> As for the need for HW changes that have been mentioned as a main >>>disadvantage of the CW-based approach - I believe it strongly depends >>>on specific implementations. And some changes in the forwarding >>>process are required in any solution. >>> >>> My 2c, >>> Sasha >>> >>> >>> >>> ________________________________________ >>> From: l2vpn-bounces@ietf.org >>> [l2vpn-bounces@ietf.org] on behalf of >>> Rogers, Josh >>> [josh.rogers@twcable.com] >>> Sent: Wednesday, April 18, 2012 9:57 PM >>> To: Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: Re: The status of the approaches to the E-Tree solution? >>> >>> Again, the P2MP situation throws me. Is this something that is used >>> commonly? >>> >>> I'm under the impression that adding P2MP to any model results in a >>> more complex model. Wether outside s-tag is used to differentiate, >>> or dedicated pw's are used for the same purpose, it seems both become >>> more complex. >>> >>> Gile's comparison slide still concisely captures the differences >>>between these methods, in my opinion. I haven't seen any new ideas or >>>thoughts brought to the group in the past week or two on the subject. >>> I would hate for both proposed methods to die on the vine because we >>>couldn't decide between two methods that have nothing inherently wrong >>>with either. >>> >>> -Josh >>> >>> >>> On 4/18/12 1:53 PM, "Lucy yong" >>>> wrote: >>> >>>>Send this again. >>>> >>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>>double all of them. >>>> >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn >>>>[mailto:DanielC@orckit.com] >>>>Sent: Wednesday, April 18, 2012 1:42 PM >>>>To: Lucy yong; Rogers, Josh; Sam Cao >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>I think the first option its the natural way to go. How is the >>>>processing in this case more complex? >>>> >>>>Thumb typed - please be tolerant >>>> >>>>Lucy yong > wrote: >>>> >>>> >>>> >>>>Snipped.. >>>> >>>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only >>>>P2MP PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP >>>>PW (for traffic coming from a root AC) [[LY]] Not that simple. You >>>>construct either two P2MP PWs to all other PEs and let egress PE >>>>performing filtering, or construct one P2MP PW to leaf-only PEs and >>>>two P2MP PWs to root and leaf PEs and let ingress PE perform >>>>forwarding and filtering. Both make node process complex. >>>> >>>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>>>delivering the frames to remote PEs. We should utilize them with the >>>>minimized changes. Dual VLAN solution is simpler than Dual PW. >>>> >>>>Regards, >>>>Lucy >>>> >>>> >>>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>>>haven't had any first hand experience with P2MP PW's, however, so >>>>don't feel terribly strong about this objection. Is this a real >>>>problem for others (now or in the future), or is this objection in >>>>the weeds? >>>> >>>>I'm not sure the 'additional complexity' is notable, or even relevant. >>>>I encourage others to speak up if they disagree, as P2MP PW is only >>>>conceptual to me, and I am unfamiliar with real-life use cases for it. >>>> >>>>Thanks, >>>>Josh >>>> >>>> >>>> >>>>On 4/18/12 10:30 AM, "Lucy yong" >>>>> wrote: >>>> >>>>>Please see inline. >>>>> >>>>>-----Original Message----- >>>>>From: Sam Cao >>>>>[mailto:yuqun.cao@gmail.com] >>>>>Sent: Tuesday, April 17, 2012 7:14 AM >>>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>>>(Wim)'; giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>>>> >>>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>>>PE have both root and leaf AC and some only have leaf ACs)? >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Yuqun (Sam) Cao >>>>>E-mail: Yuqun.cao@gmail.com >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn >>>>>[mailto:DanielC@orckit.com] >>>>>Sent: Tuesday, April 17, 2012 4:56 PM >>>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com>; Sam Cao >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Adding Sam (as l2vpn@ is holding messages) >>>>> >>>>>DC >>>>> >>>>>-----Original Message----- >>>>>From: Lucy yong >>>>>[mailto:lucy.yong@huawei.com] >>>>>Sent: Tuesday, April 17, 2012 12:39 AM >>>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>> >>>>>Snipped, >>>>> >>>>>As we discussed extensively in the list, and as reflected in giles >>>>>slide, 2 pws are only needed between pes with both root and leaf >>>>>acs, which will typically be a small minority. >>>>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>>>both approaches can benefit from it. I was off for a while and >>>>>captures some discussions now. >>>>> >>>>>Also as per giles slide, dual vlan can have scalability issues due >>>>>to additional lookup and double use of vlans in internal emulated >>>>>lan interface. Also there are potential backward compatibility >>>>>issues with silicon that doesn't support vlan mapping. >>>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. >>>>>I am not clear on all the issues. Could you be more specific? As I >>>>>mentioned in below, two PW approach makes VPLS transport >>>>>construction and packet forwarding more complex, I can see potential >>>>>backward compatibility issues with 2 PW solution. >>>>> >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Daniel >>>>> >>>>>Thumb typed - please be tolerant >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>>In my mind, the VLAN approach means dual vlan method. >>>>> >>>>>The main concern for CW approach is hardware support. >>>>> >>>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and >>>>>unknown unicast traffic, and some P2MP PWs for multicast traffic. It >>>>>may double all of them. >>>>> >>>>>E-tree is an Ethernet service and there is already VLAN based >>>>>solution in IEEE, can we just utilize it without complicating VPLS >>>>>transport construction? This also makes interworking with Eth only >>>>>network easier. >>>>> >>>>>Cheers, >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: Rogers, Josh >>>>>[mailto:josh.rogers@twcable.com] >>>>>Sent: Monday, April 16, 2012 8:35 AM >>>>>To: Lucy yong; Henderickx, Wim (Wim); >>>>>'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com' ; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>I believe the initial question was in regard to the CW method. Are >>>>>you saying that you no longer are interested in that method in >>>>>preference of the dual vlan method? >>>>> >>>>> >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>> >>>>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>>>> >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: l2vpn-bounces@ietf.org >>>>>[mailto:l2vpn-bounces@ietf.org] On >>>>>Behalf Of Henderickx, Wim (Wim) >>>>>Sent: Thursday, April 12, 2012 2:03 AM >>>>>To: 'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com' ; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>The vlan approach is superior as it also works for eth only >>>>>networks, etc. On top some vendors indicate hw issues with the cw >>>>>approach. As such we have dropped more or less the cw approach. >>>>> >>>>>Cheers, >>>>>Wim >>>>>_________________ >>>>>sent from blackberry >>>>> >>>>>----- Original Message ----- >>>>>From: Giles Heron >>>>>[mailto:giles.heron@gmail.com] >>>>>Sent: Thursday, April 12, 2012 08:22 AM >>>>>To: Simon Delord >>>>>>; Alexander >>>>>Vainshtein >>>>>>>>>e >>>>>.com>> >>>>>Cc: l2vpn@ietf.org >>>>>>; Vladimir Kleiner >>>>>> ; >>>>>Andrew Sergeev >>>>>>; >>>>>Idan Kaspit >>>>>>; >>>>>Mishael Wexler >>>>>>; >>>>>Rotem Cohen >>>>>> >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>Sorry - the "anonymous presentation" was mine. I should possibly >>>>>have put in a third column on the CW approach. And hopefully the >>>>>minutes will be posted soon. >>>>> >>>>>We had various discussions, as Simon stated, and consensus seemed to >>>>>be forming around the two alternatives of two PWEs or two VLANs. I >>>>>believe three of the authors of the CW approach are also authors of >>>>>the two VLAN approach and one is also an author of the two PWE >>>>>approach. So perhaps it's best to let those four individuals say >>>>>which approach they prefer and why? >>>>> >>>>>Giles >>>>> >>>>>On 10/04/2012 00:45, "Simon Delord" >>>>>> wrote: >>>>> >>>>>> Hi Alexander, >>>>>> >>>>>> You are right, no discussion on the WG mailing list recently, but >>>>>> there have been substantial discussions among the authors of >>>>>> various solution drafts off the mailing list. As far as I know, no >>>>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>>>> meeting. I think the CW approach has not been rejected by the WG >>>>>> yet, or the WG has not yet decided on which one to adopt. >>>>>> >>>>>> Simon >>>>>> >>>>>> 2012/4/8 Alexander Vainshtein >>>>>> >>>>> e >>>>>> le.com>> >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>>>> >>>>>>> However, looking up the L2VPN proceedings, I've found a short >>>>>>> anonymous presentation called "E-Tree Update" ( >>>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>>>> This presentation discusses the differences of the E-Tree >>>>>>> approaches based on dedicated VLANs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw >>>>>>> / >>>>>>> ?in >>>>>>> clude_te >>>>>>> xt=3D1) >>>>>>> and completely ignores the solution based on usage of the CW in >>>>>>> the PWs connecting the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1 >>>>>>> ). >>>>>>> >>>>>>> >>>>>>> >>>>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>>>> I wonder whether the WG has taken a decision to reject the >>>>>>> approach based on the CW usage? I do not remember any recent >>>>>>> discussion of this topic on the WG mailing list. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, and lots of thanks in advance, >>>>>>> >>>>>>> Sasha >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This e-mail message is intended for the recipient only and >>>>>>> contains information which is CONFIDENTIAL and which may be >>>>>>> proprietary to ECI >>>>> >>>>>>> Telecom. If you have received this transmission in error, please >>>>>>> inform us by e-mail, phone or fax, and then delete the original >>>>>>> and all copies thereof. >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>>proprietary information, which is privileged, confidential, or >>>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>>intended solely for the use of the individual or entity to which it >>>>>is addressed. >>>>>If you are not the intended recipient of this E-mail, you are hereby >>>>>notified that any dissemination, distribution, copying, or action >>>>>taken in relation to the contents of and attachments to this E-mail >>>>>is strictly prohibited and may be unlawful. If you have received >>>>>this E-mail in error, please notify the sender immediately and >>>>>permanently delete the original and any copy of this E-mail and any >>>>>printout. >>>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or >>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>intended solely for the use of the individual or entity to which it >>>>is addressed. If you are not the intended recipient of this E-mail, >>>>you are hereby notified that any dissemination, distribution, >>>>copying, or action taken in relation to the contents of and >>>>attachments to this E-mail is strictly prohibited and may be >>>>unlawful. If you have received this E-mail in error, please notify >>>>the sender immediately and permanently delete the original and any >>>>copy of this E-mail and any printout. >>> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> This e-mail message is intended for the recipient only and contains >>>information which is CONFIDENTIAL and which may be proprietary to ECI >>>Telecom. If you have received this transmission in error, please >>>inform us by e-mail, phone or fax, and then delete the original and >>>all copies thereof. >>> >>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> L2vpn mailing list >>> L2vpn@ietf.org >>> https://www.ietf.org/mailman/listinfo/l2vpn >>> >>> >>> End of L2vpn Digest, Vol 95, Issue 25 >>> *********************************** > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 101 ************************************** From wim.henderickx@alcatel-lucent.com Mon Apr 30 05:27:31 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9FB21F8620 for ; Mon, 30 Apr 2012 05:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.034 X-Spam-Level: X-Spam-Status: No, score=-10.034 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HELO_EQ_FR=0.35, HS_INDEX_PARAM=0.001, 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 qvo71UMAYv8E for ; Mon, 30 Apr 2012 05:27:27 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5F04B21F8576 for ; Mon, 30 Apr 2012 05:27:26 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3UCQvqR032370 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Apr 2012 14:27:11 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 30 Apr 2012 14:27:07 +0200 From: "Henderickx, Wim (Wim)" To: Daniel Cohn , Lucy yong , Jiangyuanlong , "Fedyk, Donald (Don)" , "Rogers, Josh" Date: Mon, 30 Apr 2012 14:26:57 +0200 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNI1NEe/4Txq0Y50G6N17p5Mncd5atPrZAgAYGhwCAAA0B8A== Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D67023EBC8286@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3F298@SZXEML508-MBS.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D3264C3CB@dfweml505-mbx> <44F4E579A764584EA9BDFD07D0CA08130777C8DC@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130777C8DC@tlvmail1> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: B0lL DZKo EacA FQc4 H3bu Ir5d NeAt N+7z SvUp TgU/ YSC7 Ykyp edLD me1Q neyY nwVu; 5; ZABhAG4AaQBlAGwAYwBAAG8AcgBjAGsAaQB0AC4AYwBvAG0AOwBqAGkAYQBuAGcAeQB1AGEAbgBsAG8AbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA7AGoAbwBzAGgALgByAG8AZwBlAHIAcwBAAHQAdwBjAGEAYgBsAGUALgBjAG8AbQA7AGwAMgB2AHAAbgBAAGkAZQB0AGYALgBvAHIAZwA7AGwAdQBjAHkALgB5AG8AbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Sosha1_v1; 7; {8DD0B36A-A73F-4D39-9AF4-AC57F2751C8F}; dwBpAG0ALgBoAGUAbgBkAGUAcgBpAGMAawB4AEAAYQBsAGMAYQB0AGUAbAAtAGwAdQBjAGUAbgB0AC4AYwBvAG0A; Mon, 30 Apr 2012 12:26:57 GMT; UgBFADoAIABUAGgAZQAgAHMAdABhAHQAdQBzACAAbwBmACAAdABoAGUAIABhAHAAcAByAG8AYQBjAGgAZQBzACAAdABvACAAdABoAGUAIABFAC0AVAByAGUAZQAgAHMAbwBsAHUAdABpAG8AbgA/AA== x-cr-puzzleid: {8DD0B36A-A73F-4D39-9AF4-AC57F2751C8F} acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 30 Apr 2012 12:27:31 -0000 Daniel, as Don pointed out the 2-VLAN solution works also with multiple S-V= LANS. I am not sure why we are going in circles on this? -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= aniel Cohn Sent: maandag 30 april 2012 13:41 To: Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Yuanlong, So the 2-VLAN solution, for the S-VLAN tagged port, works only when there is a single S-VID per AC? Thanks, DC -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Wednesday, April 25, 2012 9:21 PM To: Fedyk, Donald (Don; Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Don and Josh, draft-jiang-l2vpn-vpls-pe-etree-05 discussed S-VLAN access in the following way: "... For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames received from the root ACs can be translated to the root S-VLAN in the VPLS network domain. Alternatively, the PBB VPLS PE model (where an IEEE 802.1ah bridge module is embedded in the PE) as described in [PBB-VPLS] can be used, and a root B-VLAN or leaf B-VLAN can be added in this case. In a similar way, the traffic from the leaf ACs is tagged and transported on the leaf C-VLAN, S-VLAN or B-VLAN. " It seems option B is in line with the 1st sentence, not sure where option A came from, but do you have any concerns with the description in the 2nd sentence? Regards, Yuanlong ---------------------------------------------------------------------- Date: Wed, 25 Apr 2012 18:52:50 -0500 From: "Fedyk, Donald (Don)" To: "Rogers, Josh" , David Allan I , Daniel Cohn , "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: Content-Type: text/plain; charset=3D"us-ascii" Hi Josh Is there a draft that describes solution A? Solution B is what I've seen in the IEEE. One argument is that A is adding an extra TAG that offers little value. The TAG you have labeled 2 may need to be swapped anyway. Stacking S-TAGs is why PBB was developed. Cheers, Don -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Wednesday, April 25, 2012 7:22 PM To: David Allan I; Fedyk, Donald (Don); Daniel Cohn; l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? > Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. I have to apologize, because I think I led y'all down that path (I referred to the outermost tag, the same tag that the MPLS psuedowire is using for vlan mode encamp, as the S-Tag, even though the customer is the one placing it on the frame. Same as I described below, but I either used term S-Tag incorrectly, or ambiguously. >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... So, I think this could be cleared up some still. What I was referring to is the VID that the customer is using to put frames in, the VID which they should use to ensure the frame goes into the correct ETREE instance. You drew a distinction between 'customer VID' vs 'provider VID', but since it is negotiated, I haven't really seen a distinction, which I think is what has caused all the confusion. In the two discussion points/solutions I mentioned, the first one, "A", describes both a coordinated VID which the customer should use, and the service provider uses to distinguish between services on the same UNI, as well as a second, outer, VID which is used by the SP to determine the source AC type. In my example, if you were to sniff inside the psuedowire between PE1 and PE2 to see CE2 destined traffic, wish solution A, you might see "4001:2:Payload", where 4001 designates it is from a root AC, 2 designates the ETREE instance, and Payload is the customer's traffic (which may include a C-Tag), where with solution B, you would see "4001:Payload", and VID 2 would have to be swapped for 4001 as it enters the PE2-CE2 AC, giving the customer "2:Payload" just as they sent it (alternatively SP may choose to simply drop tag entirely and provide "Payload" to customer, this can cause problems with PVST on some devices, but I still see it done occasionally) ** Note, for the example above, I'm assuming 4001 is used as a 'standard' for root sourced frames, and 4002 is used for leaf sourced frames, for the ETREE R/L tags. Have I undone the confusion, or made it worse? -Josh On 4/25/12 5:19 PM, "David Allan I" wrote: >Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. > >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" > >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... > >Cheers >Dave > > > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Wednesday, April 25, 2012 5:42 PM >To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >Dave/Daniel/Lucy/Others Debating how many tags necessary when S-Tag >preservation is desired, > > >I think you all may have gone off on a tangent here. The original >discussion was about how to deal with the situation where the S-Tag is >preserved at a handoff (either an ENNI, or Service Multiplexed UNI) > >I believe there were two suggestions, one was that you push on a 'ETREE' >tag (one of two values, for either a frame sourced from a root AC or >another for a frame from a leaf AC), and the second solution was to 'map'. > > >Imagine the following topology: > >+-----+ +-----+ +-----+ +-----+ >| CE1 |--| PE1 |--| PE2 |--| CE2 | >+-----+ +-----+ +-----+ +-----+ > | | >+-----+ +-----+ +-----+ +-----+ >| CE3 |--| PE3 |--| PE4 |--| CE4 | >+-----+ +-----+ +-----+ +-----+ > >Where: > >Site Type VLAN >CE1 Root X >CE2 Leaf 2 >CE3 Leaf 3 >CE4 Leaf 3 > > >So, there are a lot of SP's who are keen on the way many services can be >handed to a customer on a single UNI, but coordinating a single VLAN per >service, with the customer (MEF used to call this EVPL when it was many >point to point services terminating on a single UNI). So, imagine that >we have two ETREE instances, and an internet service all terminating on a >single UNI connecting to CE1. We have negotiated VLAN ID's with the >customer, and they are expecting to reach CE2 using VLAN 2, CE3 and CE4 >using VLAN 3, and Internet service on VLAN 10. As a frame from CE1 comes >into PE1 destined for CE2 (so the customer has tagged it with VID 2), >using the 2VLAN method, since this is coming from a root site, do we > >a) place the Root S-Tag in front of VID 2, then ship it across, and pop >off the ETREE S-Tag (some SP's wish to Pop the original customer tag VID >2 as well) > >-or- > >b) swap VID2 for the ETREE Root S-Tag, send the frame to PE2 where it >will remove the S-Tag (and either push VID2 back on, or leave it off >depending on SP preference) > >The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf) > > >Hope that clears more than it confuses, >Josh > > > >On 4/25/12 4:22 PM, "Fedyk, Donald (Don)" > wrote: > >>Hi Dave >> >>Yes the only point I would add is Dual VLAN means One VID for Root and >>one VID for Leaf. Not two TAGs at a time on the frame but two allocated >>for the service. >> >>The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks >>about Encapsulation Overhead as a VLAN Tag. While that is true in a PWE >>sense it is still a single VLAN Tag at a time in a Ethernet E-tree sense. >> The compelling driver for Dual VLAN is having a Etree service that >>works in many environments and the DUAL VLAN (really dual VLAN >>interface on a >>VSI) uses the same mechanism (one VID for root and one VID for Leaf at >>a >>time) as specified in the IEEE. In a pure Ethernet bridging world the >>VLAN TAGs for Etree are not typically an overhead since translation is >>used. >> >>Don >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of David Allan I >>Sent: Wednesday, April 25, 2012 5:05 PM >>To: Daniel Cohn; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>OK I feel like I am digressing a fair distance from the actual >>problem.... But here goes: >> >>So the scenarios center around "how ETREE do you want to be?".... >> >>If the ACs are root/leaf, then if they are P2P (single ethernet end >>station attached to each AC) this is moot. ETREE semantics are enforced >>by the 2VID domain in the center of the example. If you assumed nodes >>A&B in the example were L2VPN PEs, the tagging and the PW tag >>imposition all happened at the same point in the network. >> >>If they are not simple P2P all the way to end systems and the objective >>is to avoid bridging between leaf "sites" but allowing intra-leaf-site >>connectivity then the leaves can be LANs but the root is not, such that >>I cannot bridge through the root. But all hosts at a given leaf site >>can see each other. So root Ethernet end systems are directly attached >>or two VIDs are used in the root site. >> >>If the objective is that there are multiple ethernet attached end >>stations at both the leaf and root sites, and the objective is to >>enforce >>L2 isolation everywhere then I need two VIDs extended to the end system >>attachement point in the local LANs by whatever means.... >> >>And I do not see adding VLANs in any particular spot, simply selection >>of the VID and associated semantics where VIDs are translated. The >>actual point of S-tag imposition could be a PE, or cloud be a NID/CLE >>on the customer prem (more likely scenario here to extend OAM demarc to >>the prem), or some switch in a RAN downstream of the MPLS PE... blah >>blah blah. And if ETREE is extended into a customer site LAN and >>outside of the provider domain, then two C-tags would have to be used >>that mapped to S-tags at the PBN boundary... >> >>Make sense? >>Dave >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 25, 2012 4:39 PM >>To: David Allan I; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Dave, but the ACs are root/leaf (that's what the whole vpls etree is >>about - see the reqt draft), so per the 2vlan draft the root/leaf vlan >>must be added. >> >>Thumb typed - please be tolerant >> >>David Allan I wrote: >> >>HI Daniel: >> >>In the example provided, >> >>"ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" >> A B >> >>the service is not ETREE in the domains of the ingress and egress VID. >>It is ELAN. SO there is no root/leaf attribute to shovel around. It >>would require two VIDs in each domain if the ETREE semantics were to be >>telescoped E2E. >> >>Otherwise it is a provisioning of the VID translation tables at the >>intermediate nodes (A&B that I've added to the picture) that would >>determine the VID values used in each domain. Or in the example above, >>what the ingress, Etree and egress VID values were. >> >>Cheers >>Dave >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 3:46 PM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>And to this I asked how this mapping works - how does the egress pe >>recover the ingress vid when it gets the frame tagged with only the >>root/leaf vid? How can you convey the ingress vid plus the root/leaf >>attribute in the same number of bits? >>What am I missing? >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>David Allen already explained the solution. >> >>From David: >>ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. >> >>Ingress VID does not have to equal Egress VID but regardless there is >>only ever one VID on a frame at a time. >> >>-end >> >>This works when customer makes ingress VLAN ID not equal to or equal to >>egress VLAN ID. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 11:39 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Lucy, >> >>The scenario we are discussing is not the E-Tree E-NNI, but a general >>scenario where frames arriving at the root or leaf AC are already >>double tagged. In this case, the dual vlan solution cannot preserve the >>vlans without adding a third one, can it? >> >>Maybe Shahram can add details on the scenario he had in mind >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has S-VLAN preservation attribute for ENNI only because there is no >>s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN >>preservation attribute is used. It applies to E-Tree as well. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Tuesday, April 24, 2012 2:12 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Lucy, >> >>even if the current MEF framework doesn't require s-vlan preservation, >>I believe it's to the industry's benefit to adopt a solution that is >>not constrained to a specific enni model that, like all things >>networking, is likely to evolve. Especially when such a solution is >>available. >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has worked in ENNI interface for a long time with many service >>providers' inputs. It had a fair reason to assume S-VLAN over ENNI by >>then. It may open B-VLAN for the future. It is better for us not to >>discuss a future framework here, because it will lead us to nowhere. >>Here, we want to extend VPLS in supporting E-Tree. >> >>Best Regards, >>Lucy >> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Sunday, April 22, 2012 7:34 AM >>To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Shahram and all, >> >>This question already came up in our discussions - is it safe to assume >>that the VLAN tags at the E-NNI will always be according to the current >>MEF model? Or should we try to be as transparent as possible to user >>VLAN encapsulation at the E-NNI, to accommodate future frameworks? >>I believe that any approach that looks at user payload (in this case >>VLAN >>tag) to signal VPLS information (in this case root/leaf origin) is >>necessarily tied to specific assumptions on user payload encapsulation >>(in this case, that S-VLAN tag is "available" to encode root/leaf). I >>don't think this is a future-proof assumption, it's very likely that >>other network models will come up that require S-VLAN preservation, >>which in the 2-VLAN approach would necessitate adding a third VLAN-ID. >> >>Daniel >> >>From: Shahram Davari > >>To: Lizhong Jin >, >>"l2vpn@ietf.org" >>>, >>"Alexander.Vainshtein@ecitele.com>om> >>" >>>om> >>> >>Cc: "yuqun.cao@gmail.com" >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, >> >>I also have a question regarding 2-VLAN. What if the customer traffic >>already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? >> >>Thx >>Shahram >> >>From: l2vpn-bounces@ietf.org >>[mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin >>Sent: Friday, April 20, 2012 9:38 AM >>To: l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com>m> >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, all, >>The difference between 2-VLAN and CW approach is who will provide the >>R/L information, customer payload or PW? The customer payload will be >>always modified to carry R/L information in 2-VLAN approach, while PW >>with CW will carry R/L information for CW approach. >>I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is >>accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is >>used to access H-VPLS, how could the PE on VPWS side adds VLAN to >>indicate R/L information? >> >>Thanks >>Lizhong >> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Thu, 19 Apr 2012 04:38:36 +0000 >>> From: Alexander Vainshtein >>> >> com>> >>> To: "Rogers, Josh" >>>>, Lucy yong >>> >, Daniel >>>Cohn >, Sam Cao >>> > >>> Cc: "l2vpn@ietf.org" >>> > >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> Message-ID: >>> >>> >> t o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> >>> Content-Type: text/plain; charset=3D"us-ascii" >>> >>> Hi all, >>> I fully understand that that what I am going to say is not very >>>popular, but: >>> >>> IMO one of the advantages of the CW-based solution is that it is >>>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery >>>of BUN traffic. >>> >>> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>>and, in a more generic way, localization of effects of changes in the >>>PE configuration. >>> >>> In particular, adding a Leaf AC to a PE that previously has been only >>>supporting Root ACs (or vice versa), removal of the last Leaf or last >>>Root AC from a PE that previously has been supporting a mix etc. >>>affect only the PE where this operation happens and not the rest of the >>>PEs. >>> >>> As for the need for HW changes that have been mentioned as a main >>>disadvantage of the CW-based approach - I believe it strongly depends >>>on specific implementations. And some changes in the forwarding >>>process are required in any solution. >>> >>> My 2c, >>> Sasha >>> >>> >>> >>> ________________________________________ >>> From: l2vpn-bounces@ietf.org >>> [l2vpn-bounces@ietf.org] on behalf of >>> Rogers, Josh >>> [josh.rogers@twcable.com] >>> Sent: Wednesday, April 18, 2012 9:57 PM >>> To: Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: Re: The status of the approaches to the E-Tree solution? >>> >>> Again, the P2MP situation throws me. Is this something that is used >>> commonly? >>> >>> I'm under the impression that adding P2MP to any model results in a >>> more complex model. Wether outside s-tag is used to differentiate, >>> or dedicated pw's are used for the same purpose, it seems both become >>> more complex. >>> >>> Gile's comparison slide still concisely captures the differences >>>between these methods, in my opinion. I haven't seen any new ideas or >>>thoughts brought to the group in the past week or two on the subject. >>> I would hate for both proposed methods to die on the vine because we >>>couldn't decide between two methods that have nothing inherently wrong >>>with either. >>> >>> -Josh >>> >>> >>> On 4/18/12 1:53 PM, "Lucy yong" >>>> wrote: >>> >>>>Send this again. >>>> >>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>>double all of them. >>>> >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn >>>>[mailto:DanielC@orckit.com] >>>>Sent: Wednesday, April 18, 2012 1:42 PM >>>>To: Lucy yong; Rogers, Josh; Sam Cao >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>I think the first option its the natural way to go. How is the >>>>processing in this case more complex? >>>> >>>>Thumb typed - please be tolerant >>>> >>>>Lucy yong > wrote: >>>> >>>> >>>> >>>>Snipped.. >>>> >>>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only >>>>P2MP PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP >>>>PW (for traffic coming from a root AC) [[LY]] Not that simple. You >>>>construct either two P2MP PWs to all other PEs and let egress PE >>>>performing filtering, or construct one P2MP PW to leaf-only PEs and >>>>two P2MP PWs to root and leaf PEs and let ingress PE perform >>>>forwarding and filtering. Both make node process complex. >>>> >>>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>>>delivering the frames to remote PEs. We should utilize them with the >>>>minimized changes. Dual VLAN solution is simpler than Dual PW. >>>> >>>>Regards, >>>>Lucy >>>> >>>> >>>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>>>haven't had any first hand experience with P2MP PW's, however, so >>>>don't feel terribly strong about this objection. Is this a real >>>>problem for others (now or in the future), or is this objection in >>>>the weeds? >>>> >>>>I'm not sure the 'additional complexity' is notable, or even relevant. >>>>I encourage others to speak up if they disagree, as P2MP PW is only >>>>conceptual to me, and I am unfamiliar with real-life use cases for it. >>>> >>>>Thanks, >>>>Josh >>>> >>>> >>>> >>>>On 4/18/12 10:30 AM, "Lucy yong" >>>>> wrote: >>>> >>>>>Please see inline. >>>>> >>>>>-----Original Message----- >>>>>From: Sam Cao >>>>>[mailto:yuqun.cao@gmail.com] >>>>>Sent: Tuesday, April 17, 2012 7:14 AM >>>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>>>(Wim)'; giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>>>> >>>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>>>PE have both root and leaf AC and some only have leaf ACs)? >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Yuqun (Sam) Cao >>>>>E-mail: Yuqun.cao@gmail.com >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn >>>>>[mailto:DanielC@orckit.com] >>>>>Sent: Tuesday, April 17, 2012 4:56 PM >>>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com>; Sam Cao >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Adding Sam (as l2vpn@ is holding messages) >>>>> >>>>>DC >>>>> >>>>>-----Original Message----- >>>>>From: Lucy yong >>>>>[mailto:lucy.yong@huawei.com] >>>>>Sent: Tuesday, April 17, 2012 12:39 AM >>>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>> >>>>>Snipped, >>>>> >>>>>As we discussed extensively in the list, and as reflected in giles >>>>>slide, 2 pws are only needed between pes with both root and leaf >>>>>acs, which will typically be a small minority. >>>>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>>>both approaches can benefit from it. I was off for a while and >>>>>captures some discussions now. >>>>> >>>>>Also as per giles slide, dual vlan can have scalability issues due >>>>>to additional lookup and double use of vlans in internal emulated >>>>>lan interface. Also there are potential backward compatibility >>>>>issues with silicon that doesn't support vlan mapping. >>>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. >>>>>I am not clear on all the issues. Could you be more specific? As I >>>>>mentioned in below, two PW approach makes VPLS transport >>>>>construction and packet forwarding more complex, I can see potential >>>>>backward compatibility issues with 2 PW solution. >>>>> >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Daniel >>>>> >>>>>Thumb typed - please be tolerant >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>>In my mind, the VLAN approach means dual vlan method. >>>>> >>>>>The main concern for CW approach is hardware support. >>>>> >>>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and >>>>>unknown unicast traffic, and some P2MP PWs for multicast traffic. It >>>>>may double all of them. >>>>> >>>>>E-tree is an Ethernet service and there is already VLAN based >>>>>solution in IEEE, can we just utilize it without complicating VPLS >>>>>transport construction? This also makes interworking with Eth only >>>>>network easier. >>>>> >>>>>Cheers, >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: Rogers, Josh >>>>>[mailto:josh.rogers@twcable.com] >>>>>Sent: Monday, April 16, 2012 8:35 AM >>>>>To: Lucy yong; Henderickx, Wim (Wim); >>>>>'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com' ; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>I believe the initial question was in regard to the CW method. Are >>>>>you saying that you no longer are interested in that method in >>>>>preference of the dual vlan method? >>>>> >>>>> >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>> >>>>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>>>> >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: l2vpn-bounces@ietf.org >>>>>[mailto:l2vpn-bounces@ietf.org] On >>>>>Behalf Of Henderickx, Wim (Wim) >>>>>Sent: Thursday, April 12, 2012 2:03 AM >>>>>To: 'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com' ; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>The vlan approach is superior as it also works for eth only >>>>>networks, etc. On top some vendors indicate hw issues with the cw >>>>>approach. As such we have dropped more or less the cw approach. >>>>> >>>>>Cheers, >>>>>Wim >>>>>_________________ >>>>>sent from blackberry >>>>> >>>>>----- Original Message ----- >>>>>From: Giles Heron >>>>>[mailto:giles.heron@gmail.com] >>>>>Sent: Thursday, April 12, 2012 08:22 AM >>>>>To: Simon Delord >>>>>>; Alexander >>>>>Vainshtein >>>>>>>>>e >>>>>.com>> >>>>>Cc: l2vpn@ietf.org >>>>>>; Vladimir Kleiner >>>>>> ; >>>>>Andrew Sergeev >>>>>>; >>>>>Idan Kaspit >>>>>>; >>>>>Mishael Wexler >>>>>>; >>>>>Rotem Cohen >>>>>> >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>Sorry - the "anonymous presentation" was mine. I should possibly >>>>>have put in a third column on the CW approach. And hopefully the >>>>>minutes will be posted soon. >>>>> >>>>>We had various discussions, as Simon stated, and consensus seemed to >>>>>be forming around the two alternatives of two PWEs or two VLANs. I >>>>>believe three of the authors of the CW approach are also authors of >>>>>the two VLAN approach and one is also an author of the two PWE >>>>>approach. So perhaps it's best to let those four individuals say >>>>>which approach they prefer and why? >>>>> >>>>>Giles >>>>> >>>>>On 10/04/2012 00:45, "Simon Delord" >>>>>> wrote: >>>>> >>>>>> Hi Alexander, >>>>>> >>>>>> You are right, no discussion on the WG mailing list recently, but >>>>>> there have been substantial discussions among the authors of >>>>>> various solution drafts off the mailing list. As far as I know, no >>>>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>>>> meeting. I think the CW approach has not been rejected by the WG >>>>>> yet, or the WG has not yet decided on which one to adopt. >>>>>> >>>>>> Simon >>>>>> >>>>>> 2012/4/8 Alexander Vainshtein >>>>>> >>>>> e >>>>>> le.com>> >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>>>> >>>>>>> However, looking up the L2VPN proceedings, I've found a short >>>>>>> anonymous presentation called "E-Tree Update" ( >>>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>>>> This presentation discusses the differences of the E-Tree >>>>>>> approaches based on dedicated VLANs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw >>>>>>> / >>>>>>> ?in >>>>>>> clude_te >>>>>>> xt=3D1) >>>>>>> and completely ignores the solution based on usage of the CW in >>>>>>> the PWs connecting the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1 >>>>>>> ). >>>>>>> >>>>>>> >>>>>>> >>>>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>>>> I wonder whether the WG has taken a decision to reject the >>>>>>> approach based on the CW usage? I do not remember any recent >>>>>>> discussion of this topic on the WG mailing list. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, and lots of thanks in advance, >>>>>>> >>>>>>> Sasha >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This e-mail message is intended for the recipient only and >>>>>>> contains information which is CONFIDENTIAL and which may be >>>>>>> proprietary to ECI >>>>> >>>>>>> Telecom. If you have received this transmission in error, please >>>>>>> inform us by e-mail, phone or fax, and then delete the original >>>>>>> and all copies thereof. >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>>proprietary information, which is privileged, confidential, or >>>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>>intended solely for the use of the individual or entity to which it >>>>>is addressed. >>>>>If you are not the intended recipient of this E-mail, you are hereby >>>>>notified that any dissemination, distribution, copying, or action >>>>>taken in relation to the contents of and attachments to this E-mail >>>>>is strictly prohibited and may be unlawful. If you have received >>>>>this E-mail in error, please notify the sender immediately and >>>>>permanently delete the original and any copy of this E-mail and any >>>>>printout. >>>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or >>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>intended solely for the use of the individual or entity to which it >>>>is addressed. If you are not the intended recipient of this E-mail, >>>>you are hereby notified that any dissemination, distribution, >>>>copying, or action taken in relation to the contents of and >>>>attachments to this E-mail is strictly prohibited and may be >>>>unlawful. If you have received this E-mail in error, please notify >>>>the sender immediately and permanently delete the original and any >>>>copy of this E-mail and any printout. >>> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> This e-mail message is intended for the recipient only and contains >>>information which is CONFIDENTIAL and which may be proprietary to ECI >>>Telecom. If you have received this transmission in error, please >>>inform us by e-mail, phone or fax, and then delete the original and >>>all copies thereof. >>> >>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> L2vpn mailing list >>> L2vpn@ietf.org >>> https://www.ietf.org/mailman/listinfo/l2vpn >>> >>> >>> End of L2vpn Digest, Vol 95, Issue 25 >>> *********************************** > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 101 ************************************** From DanielC@orckit.com Mon Apr 30 05:32:57 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A73C21F85A5 for ; Mon, 30 Apr 2012 05:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HS_INDEX_PARAM=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 wzzxZ4n7ZmQi for ; Mon, 30 Apr 2012 05:32:54 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB4821F8595 for ; Mon, 30 Apr 2012 05:32:48 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Date: Mon, 30 Apr 2012 15:34:50 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130777C90B@tlvmail1> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D67023EBC8286@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNI1NEe/4Txq0Y50G6N17p5Mncd5atPrZAgAYGhwCAAA0B8IAAATpg References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3F298@SZXEML508-MBS.china.huawei.com><2691CE0099834E4A9C5044EEC662BB9D3264C3CB@dfweml505-mbx> <44F4E579A764584EA9BDFD07D0CA08130777C8DC@tlvmail1> <14C7F4F06DB5814AB0DE29716C4F6D67023EBC8286@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> From: "Daniel Cohn" To: "Henderickx, Wim (Wim)" , "Lucy yong" , "Jiangyuanlong" , "Fedyk, Donald (Don)" , "Rogers, Josh" Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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, 30 Apr 2012 12:32:57 -0000 Because I still didn't see an explanation on how the egress PE knows which S-VID to push when sending the frame to the AC, if the original S-VID was popped at the ingress PE. Lucy answered that the egress PE " knows which S-VLAN ID is used on an AC", which seems to assume a single S-VLAN per root/leaf AC. So I still didn't get an answer to my question.=20 Regards, DC=20 -----Original Message----- From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]=20 Sent: Monday, April 30, 2012 3:27 PM To: Daniel Cohn; Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Daniel, as Don pointed out the 2-VLAN solution works also with multiple S-VLANS. I am not sure why we are going in circles on this? -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: maandag 30 april 2012 13:41 To: Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Yuanlong, So the 2-VLAN solution, for the S-VLAN tagged port, works only when there is a single S-VID per AC? Thanks, DC -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Wednesday, April 25, 2012 9:21 PM To: Fedyk, Donald (Don; Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Don and Josh, draft-jiang-l2vpn-vpls-pe-etree-05 discussed S-VLAN access in the following way: "... For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames received from the root ACs can be translated to the root S-VLAN in the VPLS network domain. Alternatively, the PBB VPLS PE model (where an IEEE 802.1ah bridge module is embedded in the PE) as described in [PBB-VPLS] can be used, and a root B-VLAN or leaf B-VLAN can be added in this case. In a similar way, the traffic from the leaf ACs is tagged and transported on the leaf C-VLAN, S-VLAN or B-VLAN. " It seems option B is in line with the 1st sentence, not sure where option A came from, but do you have any concerns with the description in the 2nd sentence? Regards, Yuanlong ---------------------------------------------------------------------- Date: Wed, 25 Apr 2012 18:52:50 -0500 From: "Fedyk, Donald (Don)" To: "Rogers, Josh" , David Allan I , Daniel Cohn , "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: Content-Type: text/plain; charset=3D"us-ascii" Hi Josh Is there a draft that describes solution A? Solution B is what I've seen in the IEEE. One argument is that A is adding an extra TAG that offers little value. The TAG you have labeled 2 may need to be swapped anyway. Stacking S-TAGs is why PBB was developed. Cheers, Don -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Wednesday, April 25, 2012 7:22 PM To: David Allan I; Fedyk, Donald (Don); Daniel Cohn; l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? > Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. I have to apologize, because I think I led y'all down that path (I referred to the outermost tag, the same tag that the MPLS psuedowire is using for vlan mode encamp, as the S-Tag, even though the customer is the one placing it on the frame. Same as I described below, but I either used term S-Tag incorrectly, or ambiguously. >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... So, I think this could be cleared up some still. What I was referring to is the VID that the customer is using to put frames in, the VID which they should use to ensure the frame goes into the correct ETREE instance. You drew a distinction between 'customer VID' vs 'provider VID', but since it is negotiated, I haven't really seen a distinction, which I think is what has caused all the confusion. In the two discussion points/solutions I mentioned, the first one, "A", describes both a coordinated VID which the customer should use, and the service provider uses to distinguish between services on the same UNI, as well as a second, outer, VID which is used by the SP to determine the source AC type. In my example, if you were to sniff inside the psuedowire between PE1 and PE2 to see CE2 destined traffic, wish solution A, you might see "4001:2:Payload", where 4001 designates it is from a root AC, 2 designates the ETREE instance, and Payload is the customer's traffic (which may include a C-Tag), where with solution B, you would see "4001:Payload", and VID 2 would have to be swapped for 4001 as it enters the PE2-CE2 AC, giving the customer "2:Payload" just as they sent it (alternatively SP may choose to simply drop tag entirely and provide "Payload" to customer, this can cause problems with PVST on some devices, but I still see it done occasionally) ** Note, for the example above, I'm assuming 4001 is used as a 'standard' for root sourced frames, and 4002 is used for leaf sourced frames, for the ETREE R/L tags. Have I undone the confusion, or made it worse? -Josh On 4/25/12 5:19 PM, "David Allan I" wrote: >Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. > >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" > >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... > >Cheers >Dave > > > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Wednesday, April 25, 2012 5:42 PM >To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >Dave/Daniel/Lucy/Others Debating how many tags necessary when S-Tag >preservation is desired, > > >I think you all may have gone off on a tangent here. The original >discussion was about how to deal with the situation where the S-Tag is >preserved at a handoff (either an ENNI, or Service Multiplexed UNI) > >I believe there were two suggestions, one was that you push on a 'ETREE' >tag (one of two values, for either a frame sourced from a root AC or >another for a frame from a leaf AC), and the second solution was to 'map'. > > >Imagine the following topology: > >+-----+ +-----+ +-----+ +-----+ >| CE1 |--| PE1 |--| PE2 |--| CE2 | >+-----+ +-----+ +-----+ +-----+ > | | >+-----+ +-----+ +-----+ +-----+ >| CE3 |--| PE3 |--| PE4 |--| CE4 | >+-----+ +-----+ +-----+ +-----+ > >Where: > >Site Type VLAN >CE1 Root X >CE2 Leaf 2 >CE3 Leaf 3 >CE4 Leaf 3 > > >So, there are a lot of SP's who are keen on the way many services can be >handed to a customer on a single UNI, but coordinating a single VLAN per >service, with the customer (MEF used to call this EVPL when it was many >point to point services terminating on a single UNI). So, imagine that >we have two ETREE instances, and an internet service all terminating on a >single UNI connecting to CE1. We have negotiated VLAN ID's with the >customer, and they are expecting to reach CE2 using VLAN 2, CE3 and CE4 >using VLAN 3, and Internet service on VLAN 10. As a frame from CE1 comes >into PE1 destined for CE2 (so the customer has tagged it with VID 2), >using the 2VLAN method, since this is coming from a root site, do we > >a) place the Root S-Tag in front of VID 2, then ship it across, and pop >off the ETREE S-Tag (some SP's wish to Pop the original customer tag VID >2 as well) > >-or- > >b) swap VID2 for the ETREE Root S-Tag, send the frame to PE2 where it >will remove the S-Tag (and either push VID2 back on, or leave it off >depending on SP preference) > >The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf) > > >Hope that clears more than it confuses, >Josh > > > >On 4/25/12 4:22 PM, "Fedyk, Donald (Don)" > wrote: > >>Hi Dave >> >>Yes the only point I would add is Dual VLAN means One VID for Root and >>one VID for Leaf. Not two TAGs at a time on the frame but two allocated >>for the service. >> >>The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks >>about Encapsulation Overhead as a VLAN Tag. While that is true in a PWE >>sense it is still a single VLAN Tag at a time in a Ethernet E-tree sense. >> The compelling driver for Dual VLAN is having a Etree service that >>works in many environments and the DUAL VLAN (really dual VLAN >>interface on a >>VSI) uses the same mechanism (one VID for root and one VID for Leaf at >>a >>time) as specified in the IEEE. In a pure Ethernet bridging world the >>VLAN TAGs for Etree are not typically an overhead since translation is >>used. >> >>Don >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of David Allan I >>Sent: Wednesday, April 25, 2012 5:05 PM >>To: Daniel Cohn; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>OK I feel like I am digressing a fair distance from the actual >>problem.... But here goes: >> >>So the scenarios center around "how ETREE do you want to be?".... >> >>If the ACs are root/leaf, then if they are P2P (single ethernet end >>station attached to each AC) this is moot. ETREE semantics are enforced >>by the 2VID domain in the center of the example. If you assumed nodes >>A&B in the example were L2VPN PEs, the tagging and the PW tag >>imposition all happened at the same point in the network. >> >>If they are not simple P2P all the way to end systems and the objective >>is to avoid bridging between leaf "sites" but allowing intra-leaf-site >>connectivity then the leaves can be LANs but the root is not, such that >>I cannot bridge through the root. But all hosts at a given leaf site >>can see each other. So root Ethernet end systems are directly attached >>or two VIDs are used in the root site. >> >>If the objective is that there are multiple ethernet attached end >>stations at both the leaf and root sites, and the objective is to >>enforce >>L2 isolation everywhere then I need two VIDs extended to the end system >>attachement point in the local LANs by whatever means.... >> >>And I do not see adding VLANs in any particular spot, simply selection >>of the VID and associated semantics where VIDs are translated. The >>actual point of S-tag imposition could be a PE, or cloud be a NID/CLE >>on the customer prem (more likely scenario here to extend OAM demarc to >>the prem), or some switch in a RAN downstream of the MPLS PE... blah >>blah blah. And if ETREE is extended into a customer site LAN and >>outside of the provider domain, then two C-tags would have to be used >>that mapped to S-tags at the PBN boundary... >> >>Make sense? >>Dave >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 25, 2012 4:39 PM >>To: David Allan I; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Dave, but the ACs are root/leaf (that's what the whole vpls etree is >>about - see the reqt draft), so per the 2vlan draft the root/leaf vlan >>must be added. >> >>Thumb typed - please be tolerant >> >>David Allan I wrote: >> >>HI Daniel: >> >>In the example provided, >> >>"ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" >> A B >> >>the service is not ETREE in the domains of the ingress and egress VID. >>It is ELAN. SO there is no root/leaf attribute to shovel around. It >>would require two VIDs in each domain if the ETREE semantics were to be >>telescoped E2E. >> >>Otherwise it is a provisioning of the VID translation tables at the >>intermediate nodes (A&B that I've added to the picture) that would >>determine the VID values used in each domain. Or in the example above, >>what the ingress, Etree and egress VID values were. >> >>Cheers >>Dave >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 3:46 PM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>And to this I asked how this mapping works - how does the egress pe >>recover the ingress vid when it gets the frame tagged with only the >>root/leaf vid? How can you convey the ingress vid plus the root/leaf >>attribute in the same number of bits? >>What am I missing? >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>David Allen already explained the solution. >> >>From David: >>ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. >> >>Ingress VID does not have to equal Egress VID but regardless there is >>only ever one VID on a frame at a time. >> >>-end >> >>This works when customer makes ingress VLAN ID not equal to or equal to >>egress VLAN ID. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 11:39 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Lucy, >> >>The scenario we are discussing is not the E-Tree E-NNI, but a general >>scenario where frames arriving at the root or leaf AC are already >>double tagged. In this case, the dual vlan solution cannot preserve the >>vlans without adding a third one, can it? >> >>Maybe Shahram can add details on the scenario he had in mind >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has S-VLAN preservation attribute for ENNI only because there is no >>s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN >>preservation attribute is used. It applies to E-Tree as well. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Tuesday, April 24, 2012 2:12 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Lucy, >> >>even if the current MEF framework doesn't require s-vlan preservation, >>I believe it's to the industry's benefit to adopt a solution that is >>not constrained to a specific enni model that, like all things >>networking, is likely to evolve. Especially when such a solution is >>available. >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has worked in ENNI interface for a long time with many service >>providers' inputs. It had a fair reason to assume S-VLAN over ENNI by >>then. It may open B-VLAN for the future. It is better for us not to >>discuss a future framework here, because it will lead us to nowhere. >>Here, we want to extend VPLS in supporting E-Tree. >> >>Best Regards, >>Lucy >> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Sunday, April 22, 2012 7:34 AM >>To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Shahram and all, >> >>This question already came up in our discussions - is it safe to assume >>that the VLAN tags at the E-NNI will always be according to the current >>MEF model? Or should we try to be as transparent as possible to user >>VLAN encapsulation at the E-NNI, to accommodate future frameworks? >>I believe that any approach that looks at user payload (in this case >>VLAN >>tag) to signal VPLS information (in this case root/leaf origin) is >>necessarily tied to specific assumptions on user payload encapsulation >>(in this case, that S-VLAN tag is "available" to encode root/leaf). I >>don't think this is a future-proof assumption, it's very likely that >>other network models will come up that require S-VLAN preservation, >>which in the 2-VLAN approach would necessitate adding a third VLAN-ID. >> >>Daniel >> >>From: Shahram Davari > >>To: Lizhong Jin >, >>"l2vpn@ietf.org" >>>, >>"Alexander.Vainshtein@ecitele.com>om> >>" >>>om> >>> >>Cc: "yuqun.cao@gmail.com" >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, >> >>I also have a question regarding 2-VLAN. What if the customer traffic >>already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? >> >>Thx >>Shahram >> >>From: l2vpn-bounces@ietf.org >>[mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin >>Sent: Friday, April 20, 2012 9:38 AM >>To: l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com>m> >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, all, >>The difference between 2-VLAN and CW approach is who will provide the >>R/L information, customer payload or PW? The customer payload will be >>always modified to carry R/L information in 2-VLAN approach, while PW >>with CW will carry R/L information for CW approach. >>I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is >>accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is >>used to access H-VPLS, how could the PE on VPWS side adds VLAN to >>indicate R/L information? >> >>Thanks >>Lizhong >> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Thu, 19 Apr 2012 04:38:36 +0000 >>> From: Alexander Vainshtein >>> >> com>> >>> To: "Rogers, Josh" >>>>, Lucy yong >>> >, Daniel >>>Cohn >, Sam Cao >>> > >>> Cc: "l2vpn@ietf.org" >>> > >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> Message-ID: >>> >>> >> t o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> >>> Content-Type: text/plain; charset=3D"us-ascii" >>> >>> Hi all, >>> I fully understand that that what I am going to say is not very >>>popular, but: >>> >>> IMO one of the advantages of the CW-based solution is that it is >>>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery >>>of BUN traffic. >>> >>> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>>and, in a more generic way, localization of effects of changes in the >>>PE configuration. >>> >>> In particular, adding a Leaf AC to a PE that previously has been only >>>supporting Root ACs (or vice versa), removal of the last Leaf or last >>>Root AC from a PE that previously has been supporting a mix etc. >>>affect only the PE where this operation happens and not the rest of the >>>PEs. >>> >>> As for the need for HW changes that have been mentioned as a main >>>disadvantage of the CW-based approach - I believe it strongly depends >>>on specific implementations. And some changes in the forwarding >>>process are required in any solution. >>> >>> My 2c, >>> Sasha >>> >>> >>> >>> ________________________________________ >>> From: l2vpn-bounces@ietf.org >>> [l2vpn-bounces@ietf.org] on behalf of >>> Rogers, Josh >>> [josh.rogers@twcable.com] >>> Sent: Wednesday, April 18, 2012 9:57 PM >>> To: Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: Re: The status of the approaches to the E-Tree solution? >>> >>> Again, the P2MP situation throws me. Is this something that is used >>> commonly? >>> >>> I'm under the impression that adding P2MP to any model results in a >>> more complex model. Wether outside s-tag is used to differentiate, >>> or dedicated pw's are used for the same purpose, it seems both become >>> more complex. >>> >>> Gile's comparison slide still concisely captures the differences >>>between these methods, in my opinion. I haven't seen any new ideas or >>>thoughts brought to the group in the past week or two on the subject. >>> I would hate for both proposed methods to die on the vine because we >>>couldn't decide between two methods that have nothing inherently wrong >>>with either. >>> >>> -Josh >>> >>> >>> On 4/18/12 1:53 PM, "Lucy yong" >>>> wrote: >>> >>>>Send this again. >>>> >>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>>double all of them. >>>> >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn >>>>[mailto:DanielC@orckit.com] >>>>Sent: Wednesday, April 18, 2012 1:42 PM >>>>To: Lucy yong; Rogers, Josh; Sam Cao >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>I think the first option its the natural way to go. How is the >>>>processing in this case more complex? >>>> >>>>Thumb typed - please be tolerant >>>> >>>>Lucy yong > wrote: >>>> >>>> >>>> >>>>Snipped.. >>>> >>>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only >>>>P2MP PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP >>>>PW (for traffic coming from a root AC) [[LY]] Not that simple. You >>>>construct either two P2MP PWs to all other PEs and let egress PE >>>>performing filtering, or construct one P2MP PW to leaf-only PEs and >>>>two P2MP PWs to root and leaf PEs and let ingress PE perform >>>>forwarding and filtering. Both make node process complex. >>>> >>>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>>>delivering the frames to remote PEs. We should utilize them with the >>>>minimized changes. Dual VLAN solution is simpler than Dual PW. >>>> >>>>Regards, >>>>Lucy >>>> >>>> >>>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>>>haven't had any first hand experience with P2MP PW's, however, so >>>>don't feel terribly strong about this objection. Is this a real >>>>problem for others (now or in the future), or is this objection in >>>>the weeds? >>>> >>>>I'm not sure the 'additional complexity' is notable, or even relevant. >>>>I encourage others to speak up if they disagree, as P2MP PW is only >>>>conceptual to me, and I am unfamiliar with real-life use cases for it. >>>> >>>>Thanks, >>>>Josh >>>> >>>> >>>> >>>>On 4/18/12 10:30 AM, "Lucy yong" >>>>> wrote: >>>> >>>>>Please see inline. >>>>> >>>>>-----Original Message----- >>>>>From: Sam Cao >>>>>[mailto:yuqun.cao@gmail.com] >>>>>Sent: Tuesday, April 17, 2012 7:14 AM >>>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>>>(Wim)'; giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>>>> >>>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>>>PE have both root and leaf AC and some only have leaf ACs)? >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Yuqun (Sam) Cao >>>>>E-mail: Yuqun.cao@gmail.com >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn >>>>>[mailto:DanielC@orckit.com] >>>>>Sent: Tuesday, April 17, 2012 4:56 PM >>>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com>; Sam Cao >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Adding Sam (as l2vpn@ is holding messages) >>>>> >>>>>DC >>>>> >>>>>-----Original Message----- >>>>>From: Lucy yong >>>>>[mailto:lucy.yong@huawei.com] >>>>>Sent: Tuesday, April 17, 2012 12:39 AM >>>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>> >>>>>Snipped, >>>>> >>>>>As we discussed extensively in the list, and as reflected in giles >>>>>slide, 2 pws are only needed between pes with both root and leaf >>>>>acs, which will typically be a small minority. >>>>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>>>both approaches can benefit from it. I was off for a while and >>>>>captures some discussions now. >>>>> >>>>>Also as per giles slide, dual vlan can have scalability issues due >>>>>to additional lookup and double use of vlans in internal emulated >>>>>lan interface. Also there are potential backward compatibility >>>>>issues with silicon that doesn't support vlan mapping. >>>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. >>>>>I am not clear on all the issues. Could you be more specific? As I >>>>>mentioned in below, two PW approach makes VPLS transport >>>>>construction and packet forwarding more complex, I can see potential >>>>>backward compatibility issues with 2 PW solution. >>>>> >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Daniel >>>>> >>>>>Thumb typed - please be tolerant >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>>In my mind, the VLAN approach means dual vlan method. >>>>> >>>>>The main concern for CW approach is hardware support. >>>>> >>>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and >>>>>unknown unicast traffic, and some P2MP PWs for multicast traffic. It >>>>>may double all of them. >>>>> >>>>>E-tree is an Ethernet service and there is already VLAN based >>>>>solution in IEEE, can we just utilize it without complicating VPLS >>>>>transport construction? This also makes interworking with Eth only >>>>>network easier. >>>>> >>>>>Cheers, >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: Rogers, Josh >>>>>[mailto:josh.rogers@twcable.com] >>>>>Sent: Monday, April 16, 2012 8:35 AM >>>>>To: Lucy yong; Henderickx, Wim (Wim); >>>>>'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com' ; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>I believe the initial question was in regard to the CW method. Are >>>>>you saying that you no longer are interested in that method in >>>>>preference of the dual vlan method? >>>>> >>>>> >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>> >>>>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>>>> >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: l2vpn-bounces@ietf.org >>>>>[mailto:l2vpn-bounces@ietf.org] On >>>>>Behalf Of Henderickx, Wim (Wim) >>>>>Sent: Thursday, April 12, 2012 2:03 AM >>>>>To: 'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com' ; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>The vlan approach is superior as it also works for eth only >>>>>networks, etc. On top some vendors indicate hw issues with the cw >>>>>approach. As such we have dropped more or less the cw approach. >>>>> >>>>>Cheers, >>>>>Wim >>>>>_________________ >>>>>sent from blackberry >>>>> >>>>>----- Original Message ----- >>>>>From: Giles Heron >>>>>[mailto:giles.heron@gmail.com] >>>>>Sent: Thursday, April 12, 2012 08:22 AM >>>>>To: Simon Delord >>>>>>; Alexander >>>>>Vainshtein >>>>>>>>>e >>>>>.com>> >>>>>Cc: l2vpn@ietf.org >>>>>>; Vladimir Kleiner >>>>>> ; >>>>>Andrew Sergeev >>>>>>; >>>>>Idan Kaspit >>>>>>; >>>>>Mishael Wexler >>>>>>; >>>>>Rotem Cohen >>>>>> >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>Sorry - the "anonymous presentation" was mine. I should possibly >>>>>have put in a third column on the CW approach. And hopefully the >>>>>minutes will be posted soon. >>>>> >>>>>We had various discussions, as Simon stated, and consensus seemed to >>>>>be forming around the two alternatives of two PWEs or two VLANs. I >>>>>believe three of the authors of the CW approach are also authors of >>>>>the two VLAN approach and one is also an author of the two PWE >>>>>approach. So perhaps it's best to let those four individuals say >>>>>which approach they prefer and why? >>>>> >>>>>Giles >>>>> >>>>>On 10/04/2012 00:45, "Simon Delord" >>>>>> wrote: >>>>> >>>>>> Hi Alexander, >>>>>> >>>>>> You are right, no discussion on the WG mailing list recently, but >>>>>> there have been substantial discussions among the authors of >>>>>> various solution drafts off the mailing list. As far as I know, no >>>>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>>>> meeting. I think the CW approach has not been rejected by the WG >>>>>> yet, or the WG has not yet decided on which one to adopt. >>>>>> >>>>>> Simon >>>>>> >>>>>> 2012/4/8 Alexander Vainshtein >>>>>> >>>>> e >>>>>> le.com>> >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>>>> >>>>>>> However, looking up the L2VPN proceedings, I've found a short >>>>>>> anonymous presentation called "E-Tree Update" ( >>>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>>>> This presentation discusses the differences of the E-Tree >>>>>>> approaches based on dedicated VLANs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw >>>>>>> / >>>>>>> ?in >>>>>>> clude_te >>>>>>> xt=3D1) >>>>>>> and completely ignores the solution based on usage of the CW in >>>>>>> the PWs connecting the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1 >>>>>>> ). >>>>>>> >>>>>>> >>>>>>> >>>>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>>>> I wonder whether the WG has taken a decision to reject the >>>>>>> approach based on the CW usage? I do not remember any recent >>>>>>> discussion of this topic on the WG mailing list. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, and lots of thanks in advance, >>>>>>> >>>>>>> Sasha >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This e-mail message is intended for the recipient only and >>>>>>> contains information which is CONFIDENTIAL and which may be >>>>>>> proprietary to ECI >>>>> >>>>>>> Telecom. If you have received this transmission in error, please >>>>>>> inform us by e-mail, phone or fax, and then delete the original >>>>>>> and all copies thereof. >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>>proprietary information, which is privileged, confidential, or >>>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>>intended solely for the use of the individual or entity to which it >>>>>is addressed. >>>>>If you are not the intended recipient of this E-mail, you are hereby >>>>>notified that any dissemination, distribution, copying, or action >>>>>taken in relation to the contents of and attachments to this E-mail >>>>>is strictly prohibited and may be unlawful. If you have received >>>>>this E-mail in error, please notify the sender immediately and >>>>>permanently delete the original and any copy of this E-mail and any >>>>>printout. >>>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or >>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>intended solely for the use of the individual or entity to which it >>>>is addressed. If you are not the intended recipient of this E-mail, >>>>you are hereby notified that any dissemination, distribution, >>>>copying, or action taken in relation to the contents of and >>>>attachments to this E-mail is strictly prohibited and may be >>>>unlawful. If you have received this E-mail in error, please notify >>>>the sender immediately and permanently delete the original and any >>>>copy of this E-mail and any printout. >>> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> This e-mail message is intended for the recipient only and contains >>>information which is CONFIDENTIAL and which may be proprietary to ECI >>>Telecom. If you have received this transmission in error, please >>>inform us by e-mail, phone or fax, and then delete the original and >>>all copies thereof. >>> >>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> L2vpn mailing list >>> L2vpn@ietf.org >>> https://www.ietf.org/mailman/listinfo/l2vpn >>> >>> >>> End of L2vpn Digest, Vol 95, Issue 25 >>> *********************************** > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 101 ************************************** From wim.henderickx@alcatel-lucent.com Mon Apr 30 05:35:15 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAE221F85A5 for ; Mon, 30 Apr 2012 05:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.048 X-Spam-Level: X-Spam-Status: No, score=-8.048 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_00=-2.599, HELO_EQ_FR=0.35, HS_INDEX_PARAM=0.001, 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 bumwdupLkmWA for ; Mon, 30 Apr 2012 05:35:12 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id EAC0A21F861D for ; Mon, 30 Apr 2012 05:35:11 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3UCZ5X6008105 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Apr 2012 14:35:05 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 30 Apr 2012 14:35:05 +0200 From: "Henderickx, Wim (Wim)" To: Daniel Cohn , Lucy yong , Jiangyuanlong , "Fedyk, Donald (Don)" , "Rogers, Josh" Date: Mon, 30 Apr 2012 14:34:51 +0200 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNI1NEe/4Txq0Y50G6N17p5Mncd5atPrZAgAYGhwCAAA0B8IAAATpggAAAz9A= Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D67023EBC828C@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3F298@SZXEML508-MBS.china.huawei.com><2691CE0099834E4A9C5044EEC662BB9D3264C3CB@dfweml505-mbx> <44F4E579A764584EA9BDFD07D0CA08130777C8DC@tlvmail1> <14C7F4F06DB5814AB0DE29716C4F6D67023EBC8286@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130777C90B@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130777C90B@tlvmail1> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: B/Hx Q2qp SNqd S5L4 TJ68 V4iB Yleq aXQ1 dzxe gCXI gV8V kYTu qy3Q xCMK zjsG 9Nw2; 5; ZABhAG4AaQBlAGwAYwBAAG8AcgBjAGsAaQB0AC4AYwBvAG0AOwBqAGkAYQBuAGcAeQB1AGEAbgBsAG8AbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA7AGoAbwBzAGgALgByAG8AZwBlAHIAcwBAAHQAdwBjAGEAYgBsAGUALgBjAG8AbQA7AGwAMgB2AHAAbgBAAGkAZQB0AGYALgBvAHIAZwA7AGwAdQBjAHkALgB5AG8AbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Sosha1_v1; 7; {A161AE18-7654-49B7-8C76-046E2538ECEF}; dwBpAG0ALgBoAGUAbgBkAGUAcgBpAGMAawB4AEAAYQBsAGMAYQB0AGUAbAAtAGwAdQBjAGUAbgB0AC4AYwBvAG0A; Mon, 30 Apr 2012 12:34:51 GMT; UgBFADoAIABUAGgAZQAgAHMAdABhAHQAdQBzACAAbwBmACAAdABoAGUAIABhAHAAcAByAG8AYQBjAGgAZQBzACAAdABvACAAdABoAGUAIABFAC0AVAByAGUAZQAgAHMAbwBsAHUAdABpAG8AbgA/AA== x-cr-puzzleid: {A161AE18-7654-49B7-8C76-046E2538ECEF} acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 30 Apr 2012 12:35:15 -0000 The internal S-VID which is pushed is popped/replaced with the original S-V= ID. Since they have a 1:1 relationship it is straightfwd. You need a mappin= g on ingress PE of the VPLS and on the egress PE. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: maandag 30 april 2012 14:35 To: Henderickx, Wim (Wim); Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); R= ogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Because I still didn't see an explanation on how the egress PE knows which S-VID to push when sending the frame to the AC, if the original S-VID was popped at the ingress PE. Lucy answered that the egress PE " knows which S-VLAN ID is used on an AC", which seems to assume a single S-VLAN per root/leaf AC. So I still didn't get an answer to my question. Regards, DC -----Original Message----- From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Monday, April 30, 2012 3:27 PM To: Daniel Cohn; Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Daniel, as Don pointed out the 2-VLAN solution works also with multiple S-VLANS. I am not sure why we are going in circles on this? -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: maandag 30 april 2012 13:41 To: Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Yuanlong, So the 2-VLAN solution, for the S-VLAN tagged port, works only when there is a single S-VID per AC? Thanks, DC -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Wednesday, April 25, 2012 9:21 PM To: Fedyk, Donald (Don; Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Don and Josh, draft-jiang-l2vpn-vpls-pe-etree-05 discussed S-VLAN access in the following way: "... For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames received from the root ACs can be translated to the root S-VLAN in the VPLS network domain. Alternatively, the PBB VPLS PE model (where an IEEE 802.1ah bridge module is embedded in the PE) as described in [PBB-VPLS] can be used, and a root B-VLAN or leaf B-VLAN can be added in this case. In a similar way, the traffic from the leaf ACs is tagged and transported on the leaf C-VLAN, S-VLAN or B-VLAN. " It seems option B is in line with the 1st sentence, not sure where option A came from, but do you have any concerns with the description in the 2nd sentence? Regards, Yuanlong ---------------------------------------------------------------------- Date: Wed, 25 Apr 2012 18:52:50 -0500 From: "Fedyk, Donald (Don)" To: "Rogers, Josh" , David Allan I , Daniel Cohn , "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: Content-Type: text/plain; charset=3D"us-ascii" Hi Josh Is there a draft that describes solution A? Solution B is what I've seen in the IEEE. One argument is that A is adding an extra TAG that offers little value. The TAG you have labeled 2 may need to be swapped anyway. Stacking S-TAGs is why PBB was developed. Cheers, Don -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Wednesday, April 25, 2012 7:22 PM To: David Allan I; Fedyk, Donald (Don); Daniel Cohn; l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? > Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. I have to apologize, because I think I led y'all down that path (I referred to the outermost tag, the same tag that the MPLS psuedowire is using for vlan mode encamp, as the S-Tag, even though the customer is the one placing it on the frame. Same as I described below, but I either used term S-Tag incorrectly, or ambiguously. >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... So, I think this could be cleared up some still. What I was referring to is the VID that the customer is using to put frames in, the VID which they should use to ensure the frame goes into the correct ETREE instance. You drew a distinction between 'customer VID' vs 'provider VID', but since it is negotiated, I haven't really seen a distinction, which I think is what has caused all the confusion. In the two discussion points/solutions I mentioned, the first one, "A", describes both a coordinated VID which the customer should use, and the service provider uses to distinguish between services on the same UNI, as well as a second, outer, VID which is used by the SP to determine the source AC type. In my example, if you were to sniff inside the psuedowire between PE1 and PE2 to see CE2 destined traffic, wish solution A, you might see "4001:2:Payload", where 4001 designates it is from a root AC, 2 designates the ETREE instance, and Payload is the customer's traffic (which may include a C-Tag), where with solution B, you would see "4001:Payload", and VID 2 would have to be swapped for 4001 as it enters the PE2-CE2 AC, giving the customer "2:Payload" just as they sent it (alternatively SP may choose to simply drop tag entirely and provide "Payload" to customer, this can cause problems with PVST on some devices, but I still see it done occasionally) ** Note, for the example above, I'm assuming 4001 is used as a 'standard' for root sourced frames, and 4002 is used for leaf sourced frames, for the ETREE R/L tags. Have I undone the confusion, or made it worse? -Josh On 4/25/12 5:19 PM, "David Allan I" wrote: >Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. > >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" > >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... > >Cheers >Dave > > > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Wednesday, April 25, 2012 5:42 PM >To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >Dave/Daniel/Lucy/Others Debating how many tags necessary when S-Tag >preservation is desired, > > >I think you all may have gone off on a tangent here. The original >discussion was about how to deal with the situation where the S-Tag is >preserved at a handoff (either an ENNI, or Service Multiplexed UNI) > >I believe there were two suggestions, one was that you push on a 'ETREE' >tag (one of two values, for either a frame sourced from a root AC or >another for a frame from a leaf AC), and the second solution was to 'map'. > > >Imagine the following topology: > >+-----+ +-----+ +-----+ +-----+ >| CE1 |--| PE1 |--| PE2 |--| CE2 | >+-----+ +-----+ +-----+ +-----+ > | | >+-----+ +-----+ +-----+ +-----+ >| CE3 |--| PE3 |--| PE4 |--| CE4 | >+-----+ +-----+ +-----+ +-----+ > >Where: > >Site Type VLAN >CE1 Root X >CE2 Leaf 2 >CE3 Leaf 3 >CE4 Leaf 3 > > >So, there are a lot of SP's who are keen on the way many services can be >handed to a customer on a single UNI, but coordinating a single VLAN per >service, with the customer (MEF used to call this EVPL when it was many >point to point services terminating on a single UNI). So, imagine that >we have two ETREE instances, and an internet service all terminating on a >single UNI connecting to CE1. We have negotiated VLAN ID's with the >customer, and they are expecting to reach CE2 using VLAN 2, CE3 and CE4 >using VLAN 3, and Internet service on VLAN 10. As a frame from CE1 comes >into PE1 destined for CE2 (so the customer has tagged it with VID 2), >using the 2VLAN method, since this is coming from a root site, do we > >a) place the Root S-Tag in front of VID 2, then ship it across, and pop >off the ETREE S-Tag (some SP's wish to Pop the original customer tag VID >2 as well) > >-or- > >b) swap VID2 for the ETREE Root S-Tag, send the frame to PE2 where it >will remove the S-Tag (and either push VID2 back on, or leave it off >depending on SP preference) > >The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf) > > >Hope that clears more than it confuses, >Josh > > > >On 4/25/12 4:22 PM, "Fedyk, Donald (Don)" > wrote: > >>Hi Dave >> >>Yes the only point I would add is Dual VLAN means One VID for Root and >>one VID for Leaf. Not two TAGs at a time on the frame but two allocated >>for the service. >> >>The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks >>about Encapsulation Overhead as a VLAN Tag. While that is true in a PWE >>sense it is still a single VLAN Tag at a time in a Ethernet E-tree sense. >> The compelling driver for Dual VLAN is having a Etree service that >>works in many environments and the DUAL VLAN (really dual VLAN >>interface on a >>VSI) uses the same mechanism (one VID for root and one VID for Leaf at >>a >>time) as specified in the IEEE. In a pure Ethernet bridging world the >>VLAN TAGs for Etree are not typically an overhead since translation is >>used. >> >>Don >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of David Allan I >>Sent: Wednesday, April 25, 2012 5:05 PM >>To: Daniel Cohn; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>OK I feel like I am digressing a fair distance from the actual >>problem.... But here goes: >> >>So the scenarios center around "how ETREE do you want to be?".... >> >>If the ACs are root/leaf, then if they are P2P (single ethernet end >>station attached to each AC) this is moot. ETREE semantics are enforced >>by the 2VID domain in the center of the example. If you assumed nodes >>A&B in the example were L2VPN PEs, the tagging and the PW tag >>imposition all happened at the same point in the network. >> >>If they are not simple P2P all the way to end systems and the objective >>is to avoid bridging between leaf "sites" but allowing intra-leaf-site >>connectivity then the leaves can be LANs but the root is not, such that >>I cannot bridge through the root. But all hosts at a given leaf site >>can see each other. So root Ethernet end systems are directly attached >>or two VIDs are used in the root site. >> >>If the objective is that there are multiple ethernet attached end >>stations at both the leaf and root sites, and the objective is to >>enforce >>L2 isolation everywhere then I need two VIDs extended to the end system >>attachement point in the local LANs by whatever means.... >> >>And I do not see adding VLANs in any particular spot, simply selection >>of the VID and associated semantics where VIDs are translated. The >>actual point of S-tag imposition could be a PE, or cloud be a NID/CLE >>on the customer prem (more likely scenario here to extend OAM demarc to >>the prem), or some switch in a RAN downstream of the MPLS PE... blah >>blah blah. And if ETREE is extended into a customer site LAN and >>outside of the provider domain, then two C-tags would have to be used >>that mapped to S-tags at the PBN boundary... >> >>Make sense? >>Dave >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 25, 2012 4:39 PM >>To: David Allan I; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Dave, but the ACs are root/leaf (that's what the whole vpls etree is >>about - see the reqt draft), so per the 2vlan draft the root/leaf vlan >>must be added. >> >>Thumb typed - please be tolerant >> >>David Allan I wrote: >> >>HI Daniel: >> >>In the example provided, >> >>"ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" >> A B >> >>the service is not ETREE in the domains of the ingress and egress VID. >>It is ELAN. SO there is no root/leaf attribute to shovel around. It >>would require two VIDs in each domain if the ETREE semantics were to be >>telescoped E2E. >> >>Otherwise it is a provisioning of the VID translation tables at the >>intermediate nodes (A&B that I've added to the picture) that would >>determine the VID values used in each domain. Or in the example above, >>what the ingress, Etree and egress VID values were. >> >>Cheers >>Dave >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 3:46 PM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>And to this I asked how this mapping works - how does the egress pe >>recover the ingress vid when it gets the frame tagged with only the >>root/leaf vid? How can you convey the ingress vid plus the root/leaf >>attribute in the same number of bits? >>What am I missing? >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>David Allen already explained the solution. >> >>From David: >>ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. >> >>Ingress VID does not have to equal Egress VID but regardless there is >>only ever one VID on a frame at a time. >> >>-end >> >>This works when customer makes ingress VLAN ID not equal to or equal to >>egress VLAN ID. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 11:39 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Lucy, >> >>The scenario we are discussing is not the E-Tree E-NNI, but a general >>scenario where frames arriving at the root or leaf AC are already >>double tagged. In this case, the dual vlan solution cannot preserve the >>vlans without adding a third one, can it? >> >>Maybe Shahram can add details on the scenario he had in mind >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has S-VLAN preservation attribute for ENNI only because there is no >>s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN >>preservation attribute is used. It applies to E-Tree as well. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Tuesday, April 24, 2012 2:12 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Lucy, >> >>even if the current MEF framework doesn't require s-vlan preservation, >>I believe it's to the industry's benefit to adopt a solution that is >>not constrained to a specific enni model that, like all things >>networking, is likely to evolve. Especially when such a solution is >>available. >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has worked in ENNI interface for a long time with many service >>providers' inputs. It had a fair reason to assume S-VLAN over ENNI by >>then. It may open B-VLAN for the future. It is better for us not to >>discuss a future framework here, because it will lead us to nowhere. >>Here, we want to extend VPLS in supporting E-Tree. >> >>Best Regards, >>Lucy >> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Sunday, April 22, 2012 7:34 AM >>To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Shahram and all, >> >>This question already came up in our discussions - is it safe to assume >>that the VLAN tags at the E-NNI will always be according to the current >>MEF model? Or should we try to be as transparent as possible to user >>VLAN encapsulation at the E-NNI, to accommodate future frameworks? >>I believe that any approach that looks at user payload (in this case >>VLAN >>tag) to signal VPLS information (in this case root/leaf origin) is >>necessarily tied to specific assumptions on user payload encapsulation >>(in this case, that S-VLAN tag is "available" to encode root/leaf). I >>don't think this is a future-proof assumption, it's very likely that >>other network models will come up that require S-VLAN preservation, >>which in the 2-VLAN approach would necessitate adding a third VLAN-ID. >> >>Daniel >> >>From: Shahram Davari > >>To: Lizhong Jin >, >>"l2vpn@ietf.org" >>>, >>"Alexander.Vainshtein@ecitele.com>om> >>" >>>om> >>> >>Cc: "yuqun.cao@gmail.com" >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, >> >>I also have a question regarding 2-VLAN. What if the customer traffic >>already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? >> >>Thx >>Shahram >> >>From: l2vpn-bounces@ietf.org >>[mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin >>Sent: Friday, April 20, 2012 9:38 AM >>To: l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com>m> >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, all, >>The difference between 2-VLAN and CW approach is who will provide the >>R/L information, customer payload or PW? The customer payload will be >>always modified to carry R/L information in 2-VLAN approach, while PW >>with CW will carry R/L information for CW approach. >>I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is >>accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is >>used to access H-VPLS, how could the PE on VPWS side adds VLAN to >>indicate R/L information? >> >>Thanks >>Lizhong >> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Thu, 19 Apr 2012 04:38:36 +0000 >>> From: Alexander Vainshtein >>> >> com>> >>> To: "Rogers, Josh" >>>>, Lucy yong >>> >, Daniel >>>Cohn >, Sam Cao >>> > >>> Cc: "l2vpn@ietf.org" >>> > >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> Message-ID: >>> >>> >> t o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> >>> Content-Type: text/plain; charset=3D"us-ascii" >>> >>> Hi all, >>> I fully understand that that what I am going to say is not very >>>popular, but: >>> >>> IMO one of the advantages of the CW-based solution is that it is >>>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery >>>of BUN traffic. >>> >>> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>>and, in a more generic way, localization of effects of changes in the >>>PE configuration. >>> >>> In particular, adding a Leaf AC to a PE that previously has been only >>>supporting Root ACs (or vice versa), removal of the last Leaf or last >>>Root AC from a PE that previously has been supporting a mix etc. >>>affect only the PE where this operation happens and not the rest of the >>>PEs. >>> >>> As for the need for HW changes that have been mentioned as a main >>>disadvantage of the CW-based approach - I believe it strongly depends >>>on specific implementations. And some changes in the forwarding >>>process are required in any solution. >>> >>> My 2c, >>> Sasha >>> >>> >>> >>> ________________________________________ >>> From: l2vpn-bounces@ietf.org >>> [l2vpn-bounces@ietf.org] on behalf of >>> Rogers, Josh >>> [josh.rogers@twcable.com] >>> Sent: Wednesday, April 18, 2012 9:57 PM >>> To: Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: Re: The status of the approaches to the E-Tree solution? >>> >>> Again, the P2MP situation throws me. Is this something that is used >>> commonly? >>> >>> I'm under the impression that adding P2MP to any model results in a >>> more complex model. Wether outside s-tag is used to differentiate, >>> or dedicated pw's are used for the same purpose, it seems both become >>> more complex. >>> >>> Gile's comparison slide still concisely captures the differences >>>between these methods, in my opinion. I haven't seen any new ideas or >>>thoughts brought to the group in the past week or two on the subject. >>> I would hate for both proposed methods to die on the vine because we >>>couldn't decide between two methods that have nothing inherently wrong >>>with either. >>> >>> -Josh >>> >>> >>> On 4/18/12 1:53 PM, "Lucy yong" >>>> wrote: >>> >>>>Send this again. >>>> >>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>>double all of them. >>>> >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn >>>>[mailto:DanielC@orckit.com] >>>>Sent: Wednesday, April 18, 2012 1:42 PM >>>>To: Lucy yong; Rogers, Josh; Sam Cao >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>I think the first option its the natural way to go. How is the >>>>processing in this case more complex? >>>> >>>>Thumb typed - please be tolerant >>>> >>>>Lucy yong > wrote: >>>> >>>> >>>> >>>>Snipped.. >>>> >>>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only >>>>P2MP PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP >>>>PW (for traffic coming from a root AC) [[LY]] Not that simple. You >>>>construct either two P2MP PWs to all other PEs and let egress PE >>>>performing filtering, or construct one P2MP PW to leaf-only PEs and >>>>two P2MP PWs to root and leaf PEs and let ingress PE perform >>>>forwarding and filtering. Both make node process complex. >>>> >>>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>>>delivering the frames to remote PEs. We should utilize them with the >>>>minimized changes. Dual VLAN solution is simpler than Dual PW. >>>> >>>>Regards, >>>>Lucy >>>> >>>> >>>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>>>haven't had any first hand experience with P2MP PW's, however, so >>>>don't feel terribly strong about this objection. Is this a real >>>>problem for others (now or in the future), or is this objection in >>>>the weeds? >>>> >>>>I'm not sure the 'additional complexity' is notable, or even relevant. >>>>I encourage others to speak up if they disagree, as P2MP PW is only >>>>conceptual to me, and I am unfamiliar with real-life use cases for it. >>>> >>>>Thanks, >>>>Josh >>>> >>>> >>>> >>>>On 4/18/12 10:30 AM, "Lucy yong" >>>>> wrote: >>>> >>>>>Please see inline. >>>>> >>>>>-----Original Message----- >>>>>From: Sam Cao >>>>>[mailto:yuqun.cao@gmail.com] >>>>>Sent: Tuesday, April 17, 2012 7:14 AM >>>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>>>(Wim)'; giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>>>> >>>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>>>PE have both root and leaf AC and some only have leaf ACs)? >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Yuqun (Sam) Cao >>>>>E-mail: Yuqun.cao@gmail.com >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn >>>>>[mailto:DanielC@orckit.com] >>>>>Sent: Tuesday, April 17, 2012 4:56 PM >>>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com>; Sam Cao >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Adding Sam (as l2vpn@ is holding messages) >>>>> >>>>>DC >>>>> >>>>>-----Original Message----- >>>>>From: Lucy yong >>>>>[mailto:lucy.yong@huawei.com] >>>>>Sent: Tuesday, April 17, 2012 12:39 AM >>>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>> >>>>>Snipped, >>>>> >>>>>As we discussed extensively in the list, and as reflected in giles >>>>>slide, 2 pws are only needed between pes with both root and leaf >>>>>acs, which will typically be a small minority. >>>>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>>>both approaches can benefit from it. I was off for a while and >>>>>captures some discussions now. >>>>> >>>>>Also as per giles slide, dual vlan can have scalability issues due >>>>>to additional lookup and double use of vlans in internal emulated >>>>>lan interface. Also there are potential backward compatibility >>>>>issues with silicon that doesn't support vlan mapping. >>>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. >>>>>I am not clear on all the issues. Could you be more specific? As I >>>>>mentioned in below, two PW approach makes VPLS transport >>>>>construction and packet forwarding more complex, I can see potential >>>>>backward compatibility issues with 2 PW solution. >>>>> >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Daniel >>>>> >>>>>Thumb typed - please be tolerant >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>>In my mind, the VLAN approach means dual vlan method. >>>>> >>>>>The main concern for CW approach is hardware support. >>>>> >>>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and >>>>>unknown unicast traffic, and some P2MP PWs for multicast traffic. It >>>>>may double all of them. >>>>> >>>>>E-tree is an Ethernet service and there is already VLAN based >>>>>solution in IEEE, can we just utilize it without complicating VPLS >>>>>transport construction? This also makes interworking with Eth only >>>>>network easier. >>>>> >>>>>Cheers, >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: Rogers, Josh >>>>>[mailto:josh.rogers@twcable.com] >>>>>Sent: Monday, April 16, 2012 8:35 AM >>>>>To: Lucy yong; Henderickx, Wim (Wim); >>>>>'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com' ; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>I believe the initial question was in regard to the CW method. Are >>>>>you saying that you no longer are interested in that method in >>>>>preference of the dual vlan method? >>>>> >>>>> >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>> >>>>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>>>> >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: l2vpn-bounces@ietf.org >>>>>[mailto:l2vpn-bounces@ietf.org] On >>>>>Behalf Of Henderickx, Wim (Wim) >>>>>Sent: Thursday, April 12, 2012 2:03 AM >>>>>To: 'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com' ; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>The vlan approach is superior as it also works for eth only >>>>>networks, etc. On top some vendors indicate hw issues with the cw >>>>>approach. As such we have dropped more or less the cw approach. >>>>> >>>>>Cheers, >>>>>Wim >>>>>_________________ >>>>>sent from blackberry >>>>> >>>>>----- Original Message ----- >>>>>From: Giles Heron >>>>>[mailto:giles.heron@gmail.com] >>>>>Sent: Thursday, April 12, 2012 08:22 AM >>>>>To: Simon Delord >>>>>>; Alexander >>>>>Vainshtein >>>>>>>>>e >>>>>.com>> >>>>>Cc: l2vpn@ietf.org >>>>>>; Vladimir Kleiner >>>>>> ; >>>>>Andrew Sergeev >>>>>>; >>>>>Idan Kaspit >>>>>>; >>>>>Mishael Wexler >>>>>>; >>>>>Rotem Cohen >>>>>> >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>Sorry - the "anonymous presentation" was mine. I should possibly >>>>>have put in a third column on the CW approach. And hopefully the >>>>>minutes will be posted soon. >>>>> >>>>>We had various discussions, as Simon stated, and consensus seemed to >>>>>be forming around the two alternatives of two PWEs or two VLANs. I >>>>>believe three of the authors of the CW approach are also authors of >>>>>the two VLAN approach and one is also an author of the two PWE >>>>>approach. So perhaps it's best to let those four individuals say >>>>>which approach they prefer and why? >>>>> >>>>>Giles >>>>> >>>>>On 10/04/2012 00:45, "Simon Delord" >>>>>> wrote: >>>>> >>>>>> Hi Alexander, >>>>>> >>>>>> You are right, no discussion on the WG mailing list recently, but >>>>>> there have been substantial discussions among the authors of >>>>>> various solution drafts off the mailing list. As far as I know, no >>>>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>>>> meeting. I think the CW approach has not been rejected by the WG >>>>>> yet, or the WG has not yet decided on which one to adopt. >>>>>> >>>>>> Simon >>>>>> >>>>>> 2012/4/8 Alexander Vainshtein >>>>>> >>>>> e >>>>>> le.com>> >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>>>> >>>>>>> However, looking up the L2VPN proceedings, I've found a short >>>>>>> anonymous presentation called "E-Tree Update" ( >>>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>>>> This presentation discusses the differences of the E-Tree >>>>>>> approaches based on dedicated VLANs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw >>>>>>> / >>>>>>> ?in >>>>>>> clude_te >>>>>>> xt=3D1) >>>>>>> and completely ignores the solution based on usage of the CW in >>>>>>> the PWs connecting the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1 >>>>>>> ). >>>>>>> >>>>>>> >>>>>>> >>>>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>>>> I wonder whether the WG has taken a decision to reject the >>>>>>> approach based on the CW usage? I do not remember any recent >>>>>>> discussion of this topic on the WG mailing list. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, and lots of thanks in advance, >>>>>>> >>>>>>> Sasha >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This e-mail message is intended for the recipient only and >>>>>>> contains information which is CONFIDENTIAL and which may be >>>>>>> proprietary to ECI >>>>> >>>>>>> Telecom. If you have received this transmission in error, please >>>>>>> inform us by e-mail, phone or fax, and then delete the original >>>>>>> and all copies thereof. >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>>proprietary information, which is privileged, confidential, or >>>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>>intended solely for the use of the individual or entity to which it >>>>>is addressed. >>>>>If you are not the intended recipient of this E-mail, you are hereby >>>>>notified that any dissemination, distribution, copying, or action >>>>>taken in relation to the contents of and attachments to this E-mail >>>>>is strictly prohibited and may be unlawful. If you have received >>>>>this E-mail in error, please notify the sender immediately and >>>>>permanently delete the original and any copy of this E-mail and any >>>>>printout. >>>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or >>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>intended solely for the use of the individual or entity to which it >>>>is addressed. If you are not the intended recipient of this E-mail, >>>>you are hereby notified that any dissemination, distribution, >>>>copying, or action taken in relation to the contents of and >>>>attachments to this E-mail is strictly prohibited and may be >>>>unlawful. If you have received this E-mail in error, please notify >>>>the sender immediately and permanently delete the original and any >>>>copy of this E-mail and any printout. >>> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> This e-mail message is intended for the recipient only and contains >>>information which is CONFIDENTIAL and which may be proprietary to ECI >>>Telecom. If you have received this transmission in error, please >>>inform us by e-mail, phone or fax, and then delete the original and >>>all copies thereof. >>> >>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> L2vpn mailing list >>> L2vpn@ietf.org >>> https://www.ietf.org/mailman/listinfo/l2vpn >>> >>> >>> End of L2vpn Digest, Vol 95, Issue 25 >>> *********************************** > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 101 ************************************** From DanielC@orckit.com Mon Apr 30 05:49:05 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7847D21F85B5 for ; Mon, 30 Apr 2012 05:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HS_INDEX_PARAM=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 Wl0R0RbuSfVz for ; Mon, 30 Apr 2012 05:49:02 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6E23521F860E for ; Mon, 30 Apr 2012 05:49:01 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Date: Mon, 30 Apr 2012 15:51:02 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130777C912@tlvmail1> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D67023EBC828C@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNI1NEe/4Txq0Y50G6N17p5Mncd5atPrZAgAYGhwCAAA0B8IAAATpggAAAz9CAAAEdYA== References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3F298@SZXEML508-MBS.china.huawei.com><2691CE0099834E4A9C5044EEC662BB9D3264C3CB@dfweml505-mbx> <44F4E579A764584EA9BDFD07D0CA08130777C8DC@tlvmail1> <14C7F4F06DB5814AB0DE29716C4F6D67023EBC8286@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <44F4E579A764584EA9BDFD07D0CA08130777C90B@tlvmail1> <14C7F4F06DB5814AB0DE29716C4F6D67023EBC828C@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> From: "Daniel Cohn" To: "Henderickx, Wim (Wim)" , "Lucy yong" , "Jiangyuanlong" , "Fedyk, Donald (Don)" , "Rogers, Josh" Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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, 30 Apr 2012 12:49:05 -0000 Can you explain this 1:1 relationship? Assuming any S-VID value can be received at any root or leaf AC, the S-VID that replaces it at the ingress PE must be such that the egress PE can recover the original S-VID plus the root/leaf ingress AC attribute. I don't see how this can be accomplished with the same number of bits. IOW, there needs to be a 1:1 mapping between 4094 S-VIDs in the root AC plus 4094 S-VIDs in a leaf AC to 4094 internal S-VIDs. I don't see how that is accomplished. What am I missing here? DC -----Original Message----- From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]=20 Sent: Monday, April 30, 2012 3:35 PM To: Daniel Cohn; Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? The internal S-VID which is pushed is popped/replaced with the original S-VID. Since they have a 1:1 relationship it is straightfwd. You need a mapping on ingress PE of the VPLS and on the egress PE. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: maandag 30 april 2012 14:35 To: Henderickx, Wim (Wim); Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Because I still didn't see an explanation on how the egress PE knows which S-VID to push when sending the frame to the AC, if the original S-VID was popped at the ingress PE. Lucy answered that the egress PE " knows which S-VLAN ID is used on an AC", which seems to assume a single S-VLAN per root/leaf AC. So I still didn't get an answer to my question. Regards, DC -----Original Message----- From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Monday, April 30, 2012 3:27 PM To: Daniel Cohn; Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Daniel, as Don pointed out the 2-VLAN solution works also with multiple S-VLANS. I am not sure why we are going in circles on this? -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: maandag 30 april 2012 13:41 To: Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Yuanlong, So the 2-VLAN solution, for the S-VLAN tagged port, works only when there is a single S-VID per AC? Thanks, DC -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Wednesday, April 25, 2012 9:21 PM To: Fedyk, Donald (Don; Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Don and Josh, draft-jiang-l2vpn-vpls-pe-etree-05 discussed S-VLAN access in the following way: "... For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames received from the root ACs can be translated to the root S-VLAN in the VPLS network domain. Alternatively, the PBB VPLS PE model (where an IEEE 802.1ah bridge module is embedded in the PE) as described in [PBB-VPLS] can be used, and a root B-VLAN or leaf B-VLAN can be added in this case. In a similar way, the traffic from the leaf ACs is tagged and transported on the leaf C-VLAN, S-VLAN or B-VLAN. " It seems option B is in line with the 1st sentence, not sure where option A came from, but do you have any concerns with the description in the 2nd sentence? Regards, Yuanlong ---------------------------------------------------------------------- Date: Wed, 25 Apr 2012 18:52:50 -0500 From: "Fedyk, Donald (Don)" To: "Rogers, Josh" , David Allan I , Daniel Cohn , "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: Content-Type: text/plain; charset=3D"us-ascii" Hi Josh Is there a draft that describes solution A? Solution B is what I've seen in the IEEE. One argument is that A is adding an extra TAG that offers little value. The TAG you have labeled 2 may need to be swapped anyway. Stacking S-TAGs is why PBB was developed. Cheers, Don -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Wednesday, April 25, 2012 7:22 PM To: David Allan I; Fedyk, Donald (Don); Daniel Cohn; l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? > Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. I have to apologize, because I think I led y'all down that path (I referred to the outermost tag, the same tag that the MPLS psuedowire is using for vlan mode encamp, as the S-Tag, even though the customer is the one placing it on the frame. Same as I described below, but I either used term S-Tag incorrectly, or ambiguously. >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... So, I think this could be cleared up some still. What I was referring to is the VID that the customer is using to put frames in, the VID which they should use to ensure the frame goes into the correct ETREE instance. You drew a distinction between 'customer VID' vs 'provider VID', but since it is negotiated, I haven't really seen a distinction, which I think is what has caused all the confusion. In the two discussion points/solutions I mentioned, the first one, "A", describes both a coordinated VID which the customer should use, and the service provider uses to distinguish between services on the same UNI, as well as a second, outer, VID which is used by the SP to determine the source AC type. In my example, if you were to sniff inside the psuedowire between PE1 and PE2 to see CE2 destined traffic, wish solution A, you might see "4001:2:Payload", where 4001 designates it is from a root AC, 2 designates the ETREE instance, and Payload is the customer's traffic (which may include a C-Tag), where with solution B, you would see "4001:Payload", and VID 2 would have to be swapped for 4001 as it enters the PE2-CE2 AC, giving the customer "2:Payload" just as they sent it (alternatively SP may choose to simply drop tag entirely and provide "Payload" to customer, this can cause problems with PVST on some devices, but I still see it done occasionally) ** Note, for the example above, I'm assuming 4001 is used as a 'standard' for root sourced frames, and 4002 is used for leaf sourced frames, for the ETREE R/L tags. Have I undone the confusion, or made it worse? -Josh On 4/25/12 5:19 PM, "David Allan I" wrote: >Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. > >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" > >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... > >Cheers >Dave > > > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Wednesday, April 25, 2012 5:42 PM >To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >Dave/Daniel/Lucy/Others Debating how many tags necessary when S-Tag >preservation is desired, > > >I think you all may have gone off on a tangent here. The original >discussion was about how to deal with the situation where the S-Tag is >preserved at a handoff (either an ENNI, or Service Multiplexed UNI) > >I believe there were two suggestions, one was that you push on a 'ETREE' >tag (one of two values, for either a frame sourced from a root AC or >another for a frame from a leaf AC), and the second solution was to 'map'. > > >Imagine the following topology: > >+-----+ +-----+ +-----+ +-----+ >| CE1 |--| PE1 |--| PE2 |--| CE2 | >+-----+ +-----+ +-----+ +-----+ > | | >+-----+ +-----+ +-----+ +-----+ >| CE3 |--| PE3 |--| PE4 |--| CE4 | >+-----+ +-----+ +-----+ +-----+ > >Where: > >Site Type VLAN >CE1 Root X >CE2 Leaf 2 >CE3 Leaf 3 >CE4 Leaf 3 > > >So, there are a lot of SP's who are keen on the way many services can be >handed to a customer on a single UNI, but coordinating a single VLAN per >service, with the customer (MEF used to call this EVPL when it was many >point to point services terminating on a single UNI). So, imagine that >we have two ETREE instances, and an internet service all terminating on a >single UNI connecting to CE1. We have negotiated VLAN ID's with the >customer, and they are expecting to reach CE2 using VLAN 2, CE3 and CE4 >using VLAN 3, and Internet service on VLAN 10. As a frame from CE1 comes >into PE1 destined for CE2 (so the customer has tagged it with VID 2), >using the 2VLAN method, since this is coming from a root site, do we > >a) place the Root S-Tag in front of VID 2, then ship it across, and pop >off the ETREE S-Tag (some SP's wish to Pop the original customer tag VID >2 as well) > >-or- > >b) swap VID2 for the ETREE Root S-Tag, send the frame to PE2 where it >will remove the S-Tag (and either push VID2 back on, or leave it off >depending on SP preference) > >The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf) > > >Hope that clears more than it confuses, >Josh > > > >On 4/25/12 4:22 PM, "Fedyk, Donald (Don)" > wrote: > >>Hi Dave >> >>Yes the only point I would add is Dual VLAN means One VID for Root and >>one VID for Leaf. Not two TAGs at a time on the frame but two allocated >>for the service. >> >>The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks >>about Encapsulation Overhead as a VLAN Tag. While that is true in a PWE >>sense it is still a single VLAN Tag at a time in a Ethernet E-tree sense. >> The compelling driver for Dual VLAN is having a Etree service that >>works in many environments and the DUAL VLAN (really dual VLAN >>interface on a >>VSI) uses the same mechanism (one VID for root and one VID for Leaf at >>a >>time) as specified in the IEEE. In a pure Ethernet bridging world the >>VLAN TAGs for Etree are not typically an overhead since translation is >>used. >> >>Don >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of David Allan I >>Sent: Wednesday, April 25, 2012 5:05 PM >>To: Daniel Cohn; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>OK I feel like I am digressing a fair distance from the actual >>problem.... But here goes: >> >>So the scenarios center around "how ETREE do you want to be?".... >> >>If the ACs are root/leaf, then if they are P2P (single ethernet end >>station attached to each AC) this is moot. ETREE semantics are enforced >>by the 2VID domain in the center of the example. If you assumed nodes >>A&B in the example were L2VPN PEs, the tagging and the PW tag >>imposition all happened at the same point in the network. >> >>If they are not simple P2P all the way to end systems and the objective >>is to avoid bridging between leaf "sites" but allowing intra-leaf-site >>connectivity then the leaves can be LANs but the root is not, such that >>I cannot bridge through the root. But all hosts at a given leaf site >>can see each other. So root Ethernet end systems are directly attached >>or two VIDs are used in the root site. >> >>If the objective is that there are multiple ethernet attached end >>stations at both the leaf and root sites, and the objective is to >>enforce >>L2 isolation everywhere then I need two VIDs extended to the end system >>attachement point in the local LANs by whatever means.... >> >>And I do not see adding VLANs in any particular spot, simply selection >>of the VID and associated semantics where VIDs are translated. The >>actual point of S-tag imposition could be a PE, or cloud be a NID/CLE >>on the customer prem (more likely scenario here to extend OAM demarc to >>the prem), or some switch in a RAN downstream of the MPLS PE... blah >>blah blah. And if ETREE is extended into a customer site LAN and >>outside of the provider domain, then two C-tags would have to be used >>that mapped to S-tags at the PBN boundary... >> >>Make sense? >>Dave >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 25, 2012 4:39 PM >>To: David Allan I; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Dave, but the ACs are root/leaf (that's what the whole vpls etree is >>about - see the reqt draft), so per the 2vlan draft the root/leaf vlan >>must be added. >> >>Thumb typed - please be tolerant >> >>David Allan I wrote: >> >>HI Daniel: >> >>In the example provided, >> >>"ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" >> A B >> >>the service is not ETREE in the domains of the ingress and egress VID. >>It is ELAN. SO there is no root/leaf attribute to shovel around. It >>would require two VIDs in each domain if the ETREE semantics were to be >>telescoped E2E. >> >>Otherwise it is a provisioning of the VID translation tables at the >>intermediate nodes (A&B that I've added to the picture) that would >>determine the VID values used in each domain. Or in the example above, >>what the ingress, Etree and egress VID values were. >> >>Cheers >>Dave >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 3:46 PM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>And to this I asked how this mapping works - how does the egress pe >>recover the ingress vid when it gets the frame tagged with only the >>root/leaf vid? How can you convey the ingress vid plus the root/leaf >>attribute in the same number of bits? >>What am I missing? >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>David Allen already explained the solution. >> >>From David: >>ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. >> >>Ingress VID does not have to equal Egress VID but regardless there is >>only ever one VID on a frame at a time. >> >>-end >> >>This works when customer makes ingress VLAN ID not equal to or equal to >>egress VLAN ID. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 11:39 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Lucy, >> >>The scenario we are discussing is not the E-Tree E-NNI, but a general >>scenario where frames arriving at the root or leaf AC are already >>double tagged. In this case, the dual vlan solution cannot preserve the >>vlans without adding a third one, can it? >> >>Maybe Shahram can add details on the scenario he had in mind >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has S-VLAN preservation attribute for ENNI only because there is no >>s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN >>preservation attribute is used. It applies to E-Tree as well. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Tuesday, April 24, 2012 2:12 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Lucy, >> >>even if the current MEF framework doesn't require s-vlan preservation, >>I believe it's to the industry's benefit to adopt a solution that is >>not constrained to a specific enni model that, like all things >>networking, is likely to evolve. Especially when such a solution is >>available. >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has worked in ENNI interface for a long time with many service >>providers' inputs. It had a fair reason to assume S-VLAN over ENNI by >>then. It may open B-VLAN for the future. It is better for us not to >>discuss a future framework here, because it will lead us to nowhere. >>Here, we want to extend VPLS in supporting E-Tree. >> >>Best Regards, >>Lucy >> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Sunday, April 22, 2012 7:34 AM >>To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Shahram and all, >> >>This question already came up in our discussions - is it safe to assume >>that the VLAN tags at the E-NNI will always be according to the current >>MEF model? Or should we try to be as transparent as possible to user >>VLAN encapsulation at the E-NNI, to accommodate future frameworks? >>I believe that any approach that looks at user payload (in this case >>VLAN >>tag) to signal VPLS information (in this case root/leaf origin) is >>necessarily tied to specific assumptions on user payload encapsulation >>(in this case, that S-VLAN tag is "available" to encode root/leaf). I >>don't think this is a future-proof assumption, it's very likely that >>other network models will come up that require S-VLAN preservation, >>which in the 2-VLAN approach would necessitate adding a third VLAN-ID. >> >>Daniel >> >>From: Shahram Davari > >>To: Lizhong Jin >, >>"l2vpn@ietf.org" >>>, >>"Alexander.Vainshtein@ecitele.com>om> >>" >>>om> >>> >>Cc: "yuqun.cao@gmail.com" >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, >> >>I also have a question regarding 2-VLAN. What if the customer traffic >>already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? >> >>Thx >>Shahram >> >>From: l2vpn-bounces@ietf.org >>[mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin >>Sent: Friday, April 20, 2012 9:38 AM >>To: l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com>m> >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, all, >>The difference between 2-VLAN and CW approach is who will provide the >>R/L information, customer payload or PW? The customer payload will be >>always modified to carry R/L information in 2-VLAN approach, while PW >>with CW will carry R/L information for CW approach. >>I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is >>accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is >>used to access H-VPLS, how could the PE on VPWS side adds VLAN to >>indicate R/L information? >> >>Thanks >>Lizhong >> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Thu, 19 Apr 2012 04:38:36 +0000 >>> From: Alexander Vainshtein >>> >> com>> >>> To: "Rogers, Josh" >>>>, Lucy yong >>> >, Daniel >>>Cohn >, Sam Cao >>> > >>> Cc: "l2vpn@ietf.org" >>> > >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> Message-ID: >>> >>> >> t o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> >>> Content-Type: text/plain; charset=3D"us-ascii" >>> >>> Hi all, >>> I fully understand that that what I am going to say is not very >>>popular, but: >>> >>> IMO one of the advantages of the CW-based solution is that it is >>>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery >>>of BUN traffic. >>> >>> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>>and, in a more generic way, localization of effects of changes in the >>>PE configuration. >>> >>> In particular, adding a Leaf AC to a PE that previously has been only >>>supporting Root ACs (or vice versa), removal of the last Leaf or last >>>Root AC from a PE that previously has been supporting a mix etc. >>>affect only the PE where this operation happens and not the rest of the >>>PEs. >>> >>> As for the need for HW changes that have been mentioned as a main >>>disadvantage of the CW-based approach - I believe it strongly depends >>>on specific implementations. And some changes in the forwarding >>>process are required in any solution. >>> >>> My 2c, >>> Sasha >>> >>> >>> >>> ________________________________________ >>> From: l2vpn-bounces@ietf.org >>> [l2vpn-bounces@ietf.org] on behalf of >>> Rogers, Josh >>> [josh.rogers@twcable.com] >>> Sent: Wednesday, April 18, 2012 9:57 PM >>> To: Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: Re: The status of the approaches to the E-Tree solution? >>> >>> Again, the P2MP situation throws me. Is this something that is used >>> commonly? >>> >>> I'm under the impression that adding P2MP to any model results in a >>> more complex model. Wether outside s-tag is used to differentiate, >>> or dedicated pw's are used for the same purpose, it seems both become >>> more complex. >>> >>> Gile's comparison slide still concisely captures the differences >>>between these methods, in my opinion. I haven't seen any new ideas or >>>thoughts brought to the group in the past week or two on the subject. >>> I would hate for both proposed methods to die on the vine because we >>>couldn't decide between two methods that have nothing inherently wrong >>>with either. >>> >>> -Josh >>> >>> >>> On 4/18/12 1:53 PM, "Lucy yong" >>>> wrote: >>> >>>>Send this again. >>>> >>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>>double all of them. >>>> >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn >>>>[mailto:DanielC@orckit.com] >>>>Sent: Wednesday, April 18, 2012 1:42 PM >>>>To: Lucy yong; Rogers, Josh; Sam Cao >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>I think the first option its the natural way to go. How is the >>>>processing in this case more complex? >>>> >>>>Thumb typed - please be tolerant >>>> >>>>Lucy yong > wrote: >>>> >>>> >>>> >>>>Snipped.. >>>> >>>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only >>>>P2MP PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP >>>>PW (for traffic coming from a root AC) [[LY]] Not that simple. You >>>>construct either two P2MP PWs to all other PEs and let egress PE >>>>performing filtering, or construct one P2MP PW to leaf-only PEs and >>>>two P2MP PWs to root and leaf PEs and let ingress PE perform >>>>forwarding and filtering. Both make node process complex. >>>> >>>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>>>delivering the frames to remote PEs. We should utilize them with the >>>>minimized changes. Dual VLAN solution is simpler than Dual PW. >>>> >>>>Regards, >>>>Lucy >>>> >>>> >>>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>>>haven't had any first hand experience with P2MP PW's, however, so >>>>don't feel terribly strong about this objection. Is this a real >>>>problem for others (now or in the future), or is this objection in >>>>the weeds? >>>> >>>>I'm not sure the 'additional complexity' is notable, or even relevant. >>>>I encourage others to speak up if they disagree, as P2MP PW is only >>>>conceptual to me, and I am unfamiliar with real-life use cases for it. >>>> >>>>Thanks, >>>>Josh >>>> >>>> >>>> >>>>On 4/18/12 10:30 AM, "Lucy yong" >>>>> wrote: >>>> >>>>>Please see inline. >>>>> >>>>>-----Original Message----- >>>>>From: Sam Cao >>>>>[mailto:yuqun.cao@gmail.com] >>>>>Sent: Tuesday, April 17, 2012 7:14 AM >>>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>>>(Wim)'; giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>>>> >>>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>>>PE have both root and leaf AC and some only have leaf ACs)? >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Yuqun (Sam) Cao >>>>>E-mail: Yuqun.cao@gmail.com >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn >>>>>[mailto:DanielC@orckit.com] >>>>>Sent: Tuesday, April 17, 2012 4:56 PM >>>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com>; Sam Cao >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Adding Sam (as l2vpn@ is holding messages) >>>>> >>>>>DC >>>>> >>>>>-----Original Message----- >>>>>From: Lucy yong >>>>>[mailto:lucy.yong@huawei.com] >>>>>Sent: Tuesday, April 17, 2012 12:39 AM >>>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>> >>>>>Snipped, >>>>> >>>>>As we discussed extensively in the list, and as reflected in giles >>>>>slide, 2 pws are only needed between pes with both root and leaf >>>>>acs, which will typically be a small minority. >>>>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>>>both approaches can benefit from it. I was off for a while and >>>>>captures some discussions now. >>>>> >>>>>Also as per giles slide, dual vlan can have scalability issues due >>>>>to additional lookup and double use of vlans in internal emulated >>>>>lan interface. Also there are potential backward compatibility >>>>>issues with silicon that doesn't support vlan mapping. >>>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. >>>>>I am not clear on all the issues. Could you be more specific? As I >>>>>mentioned in below, two PW approach makes VPLS transport >>>>>construction and packet forwarding more complex, I can see potential >>>>>backward compatibility issues with 2 PW solution. >>>>> >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Daniel >>>>> >>>>>Thumb typed - please be tolerant >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>>In my mind, the VLAN approach means dual vlan method. >>>>> >>>>>The main concern for CW approach is hardware support. >>>>> >>>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and >>>>>unknown unicast traffic, and some P2MP PWs for multicast traffic. It >>>>>may double all of them. >>>>> >>>>>E-tree is an Ethernet service and there is already VLAN based >>>>>solution in IEEE, can we just utilize it without complicating VPLS >>>>>transport construction? This also makes interworking with Eth only >>>>>network easier. >>>>> >>>>>Cheers, >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: Rogers, Josh >>>>>[mailto:josh.rogers@twcable.com] >>>>>Sent: Monday, April 16, 2012 8:35 AM >>>>>To: Lucy yong; Henderickx, Wim (Wim); >>>>>'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com' ; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>I believe the initial question was in regard to the CW method. Are >>>>>you saying that you no longer are interested in that method in >>>>>preference of the dual vlan method? >>>>> >>>>> >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>> >>>>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>>>> >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: l2vpn-bounces@ietf.org >>>>>[mailto:l2vpn-bounces@ietf.org] On >>>>>Behalf Of Henderickx, Wim (Wim) >>>>>Sent: Thursday, April 12, 2012 2:03 AM >>>>>To: 'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com' ; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>The vlan approach is superior as it also works for eth only >>>>>networks, etc. On top some vendors indicate hw issues with the cw >>>>>approach. As such we have dropped more or less the cw approach. >>>>> >>>>>Cheers, >>>>>Wim >>>>>_________________ >>>>>sent from blackberry >>>>> >>>>>----- Original Message ----- >>>>>From: Giles Heron >>>>>[mailto:giles.heron@gmail.com] >>>>>Sent: Thursday, April 12, 2012 08:22 AM >>>>>To: Simon Delord >>>>>>; Alexander >>>>>Vainshtein >>>>>>>>>e >>>>>.com>> >>>>>Cc: l2vpn@ietf.org >>>>>>; Vladimir Kleiner >>>>>> ; >>>>>Andrew Sergeev >>>>>>; >>>>>Idan Kaspit >>>>>>; >>>>>Mishael Wexler >>>>>>; >>>>>Rotem Cohen >>>>>> >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>Sorry - the "anonymous presentation" was mine. I should possibly >>>>>have put in a third column on the CW approach. And hopefully the >>>>>minutes will be posted soon. >>>>> >>>>>We had various discussions, as Simon stated, and consensus seemed to >>>>>be forming around the two alternatives of two PWEs or two VLANs. I >>>>>believe three of the authors of the CW approach are also authors of >>>>>the two VLAN approach and one is also an author of the two PWE >>>>>approach. So perhaps it's best to let those four individuals say >>>>>which approach they prefer and why? >>>>> >>>>>Giles >>>>> >>>>>On 10/04/2012 00:45, "Simon Delord" >>>>>> wrote: >>>>> >>>>>> Hi Alexander, >>>>>> >>>>>> You are right, no discussion on the WG mailing list recently, but >>>>>> there have been substantial discussions among the authors of >>>>>> various solution drafts off the mailing list. As far as I know, no >>>>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>>>> meeting. I think the CW approach has not been rejected by the WG >>>>>> yet, or the WG has not yet decided on which one to adopt. >>>>>> >>>>>> Simon >>>>>> >>>>>> 2012/4/8 Alexander Vainshtein >>>>>> >>>>> e >>>>>> le.com>> >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>>>> >>>>>>> However, looking up the L2VPN proceedings, I've found a short >>>>>>> anonymous presentation called "E-Tree Update" ( >>>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>>>> This presentation discusses the differences of the E-Tree >>>>>>> approaches based on dedicated VLANs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw >>>>>>> / >>>>>>> ?in >>>>>>> clude_te >>>>>>> xt=3D1) >>>>>>> and completely ignores the solution based on usage of the CW in >>>>>>> the PWs connecting the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1 >>>>>>> ). >>>>>>> >>>>>>> >>>>>>> >>>>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>>>> I wonder whether the WG has taken a decision to reject the >>>>>>> approach based on the CW usage? I do not remember any recent >>>>>>> discussion of this topic on the WG mailing list. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, and lots of thanks in advance, >>>>>>> >>>>>>> Sasha >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This e-mail message is intended for the recipient only and >>>>>>> contains information which is CONFIDENTIAL and which may be >>>>>>> proprietary to ECI >>>>> >>>>>>> Telecom. If you have received this transmission in error, please >>>>>>> inform us by e-mail, phone or fax, and then delete the original >>>>>>> and all copies thereof. >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>>proprietary information, which is privileged, confidential, or >>>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>>intended solely for the use of the individual or entity to which it >>>>>is addressed. >>>>>If you are not the intended recipient of this E-mail, you are hereby >>>>>notified that any dissemination, distribution, copying, or action >>>>>taken in relation to the contents of and attachments to this E-mail >>>>>is strictly prohibited and may be unlawful. If you have received >>>>>this E-mail in error, please notify the sender immediately and >>>>>permanently delete the original and any copy of this E-mail and any >>>>>printout. >>>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or >>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>intended solely for the use of the individual or entity to which it >>>>is addressed. If you are not the intended recipient of this E-mail, >>>>you are hereby notified that any dissemination, distribution, >>>>copying, or action taken in relation to the contents of and >>>>attachments to this E-mail is strictly prohibited and may be >>>>unlawful. If you have received this E-mail in error, please notify >>>>the sender immediately and permanently delete the original and any >>>>copy of this E-mail and any printout. >>> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> This e-mail message is intended for the recipient only and contains >>>information which is CONFIDENTIAL and which may be proprietary to ECI >>>Telecom. If you have received this transmission in error, please >>>inform us by e-mail, phone or fax, and then delete the original and >>>all copies thereof. >>> >>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> L2vpn mailing list >>> L2vpn@ietf.org >>> https://www.ietf.org/mailman/listinfo/l2vpn >>> >>> >>> End of L2vpn Digest, Vol 95, Issue 25 >>> *********************************** > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 101 ************************************** From wim.henderickx@alcatel-lucent.com Mon Apr 30 05:54:29 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B699021F8575 for ; Mon, 30 Apr 2012 05:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.936 X-Spam-Level: X-Spam-Status: No, score=-9.936 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, HELO_EQ_FR=0.35, HS_INDEX_PARAM=0.001, 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 9f0NYZgU0N+p for ; Mon, 30 Apr 2012 05:54:26 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 21DA521F850C for ; Mon, 30 Apr 2012 05:54:25 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3UCsJsq005290 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Apr 2012 14:54:19 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 30 Apr 2012 14:54:19 +0200 From: "Henderickx, Wim (Wim)" To: "'DanielC@orckit.com'" , "'lucy.yong@huawei.com'" , "'jiangyuanlong@huawei.com'" , "Fedyk, Donald (Don)" , "'josh.rogers@twcable.com'" Date: Mon, 30 Apr 2012 14:54:18 +0200 Subject: Re: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNI1NEe/4Txq0Y50G6N17p5Mncd5atPrZAgAYGhwCAAA0B8IAAATpggAAAz9CAAAEdYIAABKrk Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D67023ECB0FE3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130777C912@tlvmail1> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "'l2vpn@ietf.org'" X-BeenThere: l2vpn@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, 30 Apr 2012 12:54:29 -0000 The procedure halfs the s-vid space since you need 1 for root and one for l= eaf. If this is not enough pbb solves the issue. This is how ieee proposes = this to work afaik. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, April 30, 2012 02:51 PM To: Henderickx, Wim (Wim); Lucy yong ; Jiangyuanlong = ; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Can you explain this 1:1 relationship? Assuming any S-VID value can be received at any root or leaf AC, the S-VID that replaces it at the ingress PE must be such that the egress PE can recover the original S-VID plus the root/leaf ingress AC attribute. I don't see how this can be accomplished with the same number of bits. IOW, there needs to be a 1:1 mapping between 4094 S-VIDs in the root AC plus 4094 S-VIDs in a leaf AC to 4094 internal S-VIDs. I don't see how that is accomplished. What am I missing here? DC -----Original Message----- From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Monday, April 30, 2012 3:35 PM To: Daniel Cohn; Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? The internal S-VID which is pushed is popped/replaced with the original S-VID. Since they have a 1:1 relationship it is straightfwd. You need a mapping on ingress PE of the VPLS and on the egress PE. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: maandag 30 april 2012 14:35 To: Henderickx, Wim (Wim); Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Because I still didn't see an explanation on how the egress PE knows which S-VID to push when sending the frame to the AC, if the original S-VID was popped at the ingress PE. Lucy answered that the egress PE " knows which S-VLAN ID is used on an AC", which seems to assume a single S-VLAN per root/leaf AC. So I still didn't get an answer to my question. Regards, DC -----Original Message----- From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Monday, April 30, 2012 3:27 PM To: Daniel Cohn; Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Daniel, as Don pointed out the 2-VLAN solution works also with multiple S-VLANS. I am not sure why we are going in circles on this? -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: maandag 30 april 2012 13:41 To: Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Yuanlong, So the 2-VLAN solution, for the S-VLAN tagged port, works only when there is a single S-VID per AC? Thanks, DC -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Wednesday, April 25, 2012 9:21 PM To: Fedyk, Donald (Don; Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Don and Josh, draft-jiang-l2vpn-vpls-pe-etree-05 discussed S-VLAN access in the following way: "... For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames received from the root ACs can be translated to the root S-VLAN in the VPLS network domain. Alternatively, the PBB VPLS PE model (where an IEEE 802.1ah bridge module is embedded in the PE) as described in [PBB-VPLS] can be used, and a root B-VLAN or leaf B-VLAN can be added in this case. In a similar way, the traffic from the leaf ACs is tagged and transported on the leaf C-VLAN, S-VLAN or B-VLAN. " It seems option B is in line with the 1st sentence, not sure where option A came from, but do you have any concerns with the description in the 2nd sentence? Regards, Yuanlong ---------------------------------------------------------------------- Date: Wed, 25 Apr 2012 18:52:50 -0500 From: "Fedyk, Donald (Don)" To: "Rogers, Josh" , David Allan I , Daniel Cohn , "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: Content-Type: text/plain; charset=3D"us-ascii" Hi Josh Is there a draft that describes solution A? Solution B is what I've seen in the IEEE. One argument is that A is adding an extra TAG that offers little value. The TAG you have labeled 2 may need to be swapped anyway. Stacking S-TAGs is why PBB was developed. Cheers, Don -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Wednesday, April 25, 2012 7:22 PM To: David Allan I; Fedyk, Donald (Don); Daniel Cohn; l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? > Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. I have to apologize, because I think I led y'all down that path (I referred to the outermost tag, the same tag that the MPLS psuedowire is using for vlan mode encamp, as the S-Tag, even though the customer is the one placing it on the frame. Same as I described below, but I either used term S-Tag incorrectly, or ambiguously. >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... So, I think this could be cleared up some still. What I was referring to is the VID that the customer is using to put frames in, the VID which they should use to ensure the frame goes into the correct ETREE instance. You drew a distinction between 'customer VID' vs 'provider VID', but since it is negotiated, I haven't really seen a distinction, which I think is what has caused all the confusion. In the two discussion points/solutions I mentioned, the first one, "A", describes both a coordinated VID which the customer should use, and the service provider uses to distinguish between services on the same UNI, as well as a second, outer, VID which is used by the SP to determine the source AC type. In my example, if you were to sniff inside the psuedowire between PE1 and PE2 to see CE2 destined traffic, wish solution A, you might see "4001:2:Payload", where 4001 designates it is from a root AC, 2 designates the ETREE instance, and Payload is the customer's traffic (which may include a C-Tag), where with solution B, you would see "4001:Payload", and VID 2 would have to be swapped for 4001 as it enters the PE2-CE2 AC, giving the customer "2:Payload" just as they sent it (alternatively SP may choose to simply drop tag entirely and provide "Payload" to customer, this can cause problems with PVST on some devices, but I still see it done occasionally) ** Note, for the example above, I'm assuming 4001 is used as a 'standard' for root sourced frames, and 4002 is used for leaf sourced frames, for the ETREE R/L tags. Have I undone the confusion, or made it worse? -Josh On 4/25/12 5:19 PM, "David Allan I" wrote: >Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. > >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" > >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... > >Cheers >Dave > > > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Wednesday, April 25, 2012 5:42 PM >To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >Dave/Daniel/Lucy/Others Debating how many tags necessary when S-Tag >preservation is desired, > > >I think you all may have gone off on a tangent here. The original >discussion was about how to deal with the situation where the S-Tag is >preserved at a handoff (either an ENNI, or Service Multiplexed UNI) > >I believe there were two suggestions, one was that you push on a 'ETREE' >tag (one of two values, for either a frame sourced from a root AC or >another for a frame from a leaf AC), and the second solution was to 'map'. > > >Imagine the following topology: > >+-----+ +-----+ +-----+ +-----+ >| CE1 |--| PE1 |--| PE2 |--| CE2 | >+-----+ +-----+ +-----+ +-----+ > | | >+-----+ +-----+ +-----+ +-----+ >| CE3 |--| PE3 |--| PE4 |--| CE4 | >+-----+ +-----+ +-----+ +-----+ > >Where: > >Site Type VLAN >CE1 Root X >CE2 Leaf 2 >CE3 Leaf 3 >CE4 Leaf 3 > > >So, there are a lot of SP's who are keen on the way many services can be >handed to a customer on a single UNI, but coordinating a single VLAN per >service, with the customer (MEF used to call this EVPL when it was many >point to point services terminating on a single UNI). So, imagine that >we have two ETREE instances, and an internet service all terminating on a >single UNI connecting to CE1. We have negotiated VLAN ID's with the >customer, and they are expecting to reach CE2 using VLAN 2, CE3 and CE4 >using VLAN 3, and Internet service on VLAN 10. As a frame from CE1 comes >into PE1 destined for CE2 (so the customer has tagged it with VID 2), >using the 2VLAN method, since this is coming from a root site, do we > >a) place the Root S-Tag in front of VID 2, then ship it across, and pop >off the ETREE S-Tag (some SP's wish to Pop the original customer tag VID >2 as well) > >-or- > >b) swap VID2 for the ETREE Root S-Tag, send the frame to PE2 where it >will remove the S-Tag (and either push VID2 back on, or leave it off >depending on SP preference) > >The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf) > > >Hope that clears more than it confuses, >Josh > > > >On 4/25/12 4:22 PM, "Fedyk, Donald (Don)" > wrote: > >>Hi Dave >> >>Yes the only point I would add is Dual VLAN means One VID for Root and >>one VID for Leaf. Not two TAGs at a time on the frame but two allocated >>for the service. >> >>The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks >>about Encapsulation Overhead as a VLAN Tag. While that is true in a PWE >>sense it is still a single VLAN Tag at a time in a Ethernet E-tree sense. >> The compelling driver for Dual VLAN is having a Etree service that >>works in many environments and the DUAL VLAN (really dual VLAN >>interface on a >>VSI) uses the same mechanism (one VID for root and one VID for Leaf at >>a >>time) as specified in the IEEE. In a pure Ethernet bridging world the >>VLAN TAGs for Etree are not typically an overhead since translation is >>used. >> >>Don >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of David Allan I >>Sent: Wednesday, April 25, 2012 5:05 PM >>To: Daniel Cohn; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>OK I feel like I am digressing a fair distance from the actual >>problem.... But here goes: >> >>So the scenarios center around "how ETREE do you want to be?".... >> >>If the ACs are root/leaf, then if they are P2P (single ethernet end >>station attached to each AC) this is moot. ETREE semantics are enforced >>by the 2VID domain in the center of the example. If you assumed nodes >>A&B in the example were L2VPN PEs, the tagging and the PW tag >>imposition all happened at the same point in the network. >> >>If they are not simple P2P all the way to end systems and the objective >>is to avoid bridging between leaf "sites" but allowing intra-leaf-site >>connectivity then the leaves can be LANs but the root is not, such that >>I cannot bridge through the root. But all hosts at a given leaf site >>can see each other. So root Ethernet end systems are directly attached >>or two VIDs are used in the root site. >> >>If the objective is that there are multiple ethernet attached end >>stations at both the leaf and root sites, and the objective is to >>enforce >>L2 isolation everywhere then I need two VIDs extended to the end system >>attachement point in the local LANs by whatever means.... >> >>And I do not see adding VLANs in any particular spot, simply selection >>of the VID and associated semantics where VIDs are translated. The >>actual point of S-tag imposition could be a PE, or cloud be a NID/CLE >>on the customer prem (more likely scenario here to extend OAM demarc to >>the prem), or some switch in a RAN downstream of the MPLS PE... blah >>blah blah. And if ETREE is extended into a customer site LAN and >>outside of the provider domain, then two C-tags would have to be used >>that mapped to S-tags at the PBN boundary... >> >>Make sense? >>Dave >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 25, 2012 4:39 PM >>To: David Allan I; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Dave, but the ACs are root/leaf (that's what the whole vpls etree is >>about - see the reqt draft), so per the 2vlan draft the root/leaf vlan >>must be added. >> >>Thumb typed - please be tolerant >> >>David Allan I wrote: >> >>HI Daniel: >> >>In the example provided, >> >>"ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" >> A B >> >>the service is not ETREE in the domains of the ingress and egress VID. >>It is ELAN. SO there is no root/leaf attribute to shovel around. It >>would require two VIDs in each domain if the ETREE semantics were to be >>telescoped E2E. >> >>Otherwise it is a provisioning of the VID translation tables at the >>intermediate nodes (A&B that I've added to the picture) that would >>determine the VID values used in each domain. Or in the example above, >>what the ingress, Etree and egress VID values were. >> >>Cheers >>Dave >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 3:46 PM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>And to this I asked how this mapping works - how does the egress pe >>recover the ingress vid when it gets the frame tagged with only the >>root/leaf vid? How can you convey the ingress vid plus the root/leaf >>attribute in the same number of bits? >>What am I missing? >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>David Allen already explained the solution. >> >>From David: >>ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. >> >>Ingress VID does not have to equal Egress VID but regardless there is >>only ever one VID on a frame at a time. >> >>-end >> >>This works when customer makes ingress VLAN ID not equal to or equal to >>egress VLAN ID. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 11:39 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Lucy, >> >>The scenario we are discussing is not the E-Tree E-NNI, but a general >>scenario where frames arriving at the root or leaf AC are already >>double tagged. In this case, the dual vlan solution cannot preserve the >>vlans without adding a third one, can it? >> >>Maybe Shahram can add details on the scenario he had in mind >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has S-VLAN preservation attribute for ENNI only because there is no >>s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN >>preservation attribute is used. It applies to E-Tree as well. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Tuesday, April 24, 2012 2:12 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Lucy, >> >>even if the current MEF framework doesn't require s-vlan preservation, >>I believe it's to the industry's benefit to adopt a solution that is >>not constrained to a specific enni model that, like all things >>networking, is likely to evolve. Especially when such a solution is >>available. >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has worked in ENNI interface for a long time with many service >>providers' inputs. It had a fair reason to assume S-VLAN over ENNI by >>then. It may open B-VLAN for the future. It is better for us not to >>discuss a future framework here, because it will lead us to nowhere. >>Here, we want to extend VPLS in supporting E-Tree. >> >>Best Regards, >>Lucy >> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Sunday, April 22, 2012 7:34 AM >>To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Shahram and all, >> >>This question already came up in our discussions - is it safe to assume >>that the VLAN tags at the E-NNI will always be according to the current >>MEF model? Or should we try to be as transparent as possible to user >>VLAN encapsulation at the E-NNI, to accommodate future frameworks? >>I believe that any approach that looks at user payload (in this case >>VLAN >>tag) to signal VPLS information (in this case root/leaf origin) is >>necessarily tied to specific assumptions on user payload encapsulation >>(in this case, that S-VLAN tag is "available" to encode root/leaf). I >>don't think this is a future-proof assumption, it's very likely that >>other network models will come up that require S-VLAN preservation, >>which in the 2-VLAN approach would necessitate adding a third VLAN-ID. >> >>Daniel >> >>From: Shahram Davari > >>To: Lizhong Jin >, >>"l2vpn@ietf.org" >>>, >>"Alexander.Vainshtein@ecitele.com>om> >>" >>>om> >>> >>Cc: "yuqun.cao@gmail.com" >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, >> >>I also have a question regarding 2-VLAN. What if the customer traffic >>already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? >> >>Thx >>Shahram >> >>From: l2vpn-bounces@ietf.org >>[mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin >>Sent: Friday, April 20, 2012 9:38 AM >>To: l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com>m> >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, all, >>The difference between 2-VLAN and CW approach is who will provide the >>R/L information, customer payload or PW? The customer payload will be >>always modified to carry R/L information in 2-VLAN approach, while PW >>with CW will carry R/L information for CW approach. >>I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is >>accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is >>used to access H-VPLS, how could the PE on VPWS side adds VLAN to >>indicate R/L information? >> >>Thanks >>Lizhong >> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Thu, 19 Apr 2012 04:38:36 +0000 >>> From: Alexander Vainshtein >>> >> com>> >>> To: "Rogers, Josh" >>>>, Lucy yong >>> >, Daniel >>>Cohn >, Sam Cao >>> > >>> Cc: "l2vpn@ietf.org" >>> > >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> Message-ID: >>> >>> >> t o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> >>> Content-Type: text/plain; charset=3D"us-ascii" >>> >>> Hi all, >>> I fully understand that that what I am going to say is not very >>>popular, but: >>> >>> IMO one of the advantages of the CW-based solution is that it is >>>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery >>>of BUN traffic. >>> >>> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>>and, in a more generic way, localization of effects of changes in the >>>PE configuration. >>> >>> In particular, adding a Leaf AC to a PE that previously has been only >>>supporting Root ACs (or vice versa), removal of the last Leaf or last >>>Root AC from a PE that previously has been supporting a mix etc. >>>affect only the PE where this operation happens and not the rest of the >>>PEs. >>> >>> As for the need for HW changes that have been mentioned as a main >>>disadvantage of the CW-based approach - I believe it strongly depends >>>on specific implementations. And some changes in the forwarding >>>process are required in any solution. >>> >>> My 2c, >>> Sasha >>> >>> >>> >>> ________________________________________ >>> From: l2vpn-bounces@ietf.org >>> [l2vpn-bounces@ietf.org] on behalf of >>> Rogers, Josh >>> [josh.rogers@twcable.com] >>> Sent: Wednesday, April 18, 2012 9:57 PM >>> To: Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: Re: The status of the approaches to the E-Tree solution? >>> >>> Again, the P2MP situation throws me. Is this something that is used >>> commonly? >>> >>> I'm under the impression that adding P2MP to any model results in a >>> more complex model. Wether outside s-tag is used to differentiate, >>> or dedicated pw's are used for the same purpose, it seems both become >>> more complex. >>> >>> Gile's comparison slide still concisely captures the differences >>>between these methods, in my opinion. I haven't seen any new ideas or >>>thoughts brought to the group in the past week or two on the subject. >>> I would hate for both proposed methods to die on the vine because we >>>couldn't decide between two methods that have nothing inherently wrong >>>with either. >>> >>> -Josh >>> >>> >>> On 4/18/12 1:53 PM, "Lucy yong" >>>> wrote: >>> >>>>Send this again. >>>> >>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>>double all of them. >>>> >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn >>>>[mailto:DanielC@orckit.com] >>>>Sent: Wednesday, April 18, 2012 1:42 PM >>>>To: Lucy yong; Rogers, Josh; Sam Cao >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>I think the first option its the natural way to go. How is the >>>>processing in this case more complex? >>>> >>>>Thumb typed - please be tolerant >>>> >>>>Lucy yong > wrote: >>>> >>>> >>>> >>>>Snipped.. >>>> >>>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only >>>>P2MP PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP >>>>PW (for traffic coming from a root AC) [[LY]] Not that simple. You >>>>construct either two P2MP PWs to all other PEs and let egress PE >>>>performing filtering, or construct one P2MP PW to leaf-only PEs and >>>>two P2MP PWs to root and leaf PEs and let ingress PE perform >>>>forwarding and filtering. Both make node process complex. >>>> >>>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>>>delivering the frames to remote PEs. We should utilize them with the >>>>minimized changes. Dual VLAN solution is simpler than Dual PW. >>>> >>>>Regards, >>>>Lucy >>>> >>>> >>>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>>>haven't had any first hand experience with P2MP PW's, however, so >>>>don't feel terribly strong about this objection. Is this a real >>>>problem for others (now or in the future), or is this objection in >>>>the weeds? >>>> >>>>I'm not sure the 'additional complexity' is notable, or even relevant. >>>>I encourage others to speak up if they disagree, as P2MP PW is only >>>>conceptual to me, and I am unfamiliar with real-life use cases for it. >>>> >>>>Thanks, >>>>Josh >>>> >>>> >>>> >>>>On 4/18/12 10:30 AM, "Lucy yong" >>>>> wrote: >>>> >>>>>Please see inline. >>>>> >>>>>-----Original Message----- >>>>>From: Sam Cao >>>>>[mailto:yuqun.cao@gmail.com] >>>>>Sent: Tuesday, April 17, 2012 7:14 AM >>>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>>>(Wim)'; giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>>>> >>>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>>>PE have both root and leaf AC and some only have leaf ACs)? >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Yuqun (Sam) Cao >>>>>E-mail: Yuqun.cao@gmail.com >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn >>>>>[mailto:DanielC@orckit.com] >>>>>Sent: Tuesday, April 17, 2012 4:56 PM >>>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com>; Sam Cao >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Adding Sam (as l2vpn@ is holding messages) >>>>> >>>>>DC >>>>> >>>>>-----Original Message----- >>>>>From: Lucy yong >>>>>[mailto:lucy.yong@huawei.com] >>>>>Sent: Tuesday, April 17, 2012 12:39 AM >>>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>> >>>>>Snipped, >>>>> >>>>>As we discussed extensively in the list, and as reflected in giles >>>>>slide, 2 pws are only needed between pes with both root and leaf >>>>>acs, which will typically be a small minority. >>>>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>>>both approaches can benefit from it. I was off for a while and >>>>>captures some discussions now. >>>>> >>>>>Also as per giles slide, dual vlan can have scalability issues due >>>>>to additional lookup and double use of vlans in internal emulated >>>>>lan interface. Also there are potential backward compatibility >>>>>issues with silicon that doesn't support vlan mapping. >>>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. >>>>>I am not clear on all the issues. Could you be more specific? As I >>>>>mentioned in below, two PW approach makes VPLS transport >>>>>construction and packet forwarding more complex, I can see potential >>>>>backward compatibility issues with 2 PW solution. >>>>> >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Daniel >>>>> >>>>>Thumb typed - please be tolerant >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>>In my mind, the VLAN approach means dual vlan method. >>>>> >>>>>The main concern for CW approach is hardware support. >>>>> >>>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and >>>>>unknown unicast traffic, and some P2MP PWs for multicast traffic. It >>>>>may double all of them. >>>>> >>>>>E-tree is an Ethernet service and there is already VLAN based >>>>>solution in IEEE, can we just utilize it without complicating VPLS >>>>>transport construction? This also makes interworking with Eth only >>>>>network easier. >>>>> >>>>>Cheers, >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: Rogers, Josh >>>>>[mailto:josh.rogers@twcable.com] >>>>>Sent: Monday, April 16, 2012 8:35 AM >>>>>To: Lucy yong; Henderickx, Wim (Wim); >>>>>'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com' ; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>I believe the initial question was in regard to the CW method. Are >>>>>you saying that you no longer are interested in that method in >>>>>preference of the dual vlan method? >>>>> >>>>> >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>> >>>>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>>>> >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: l2vpn-bounces@ietf.org >>>>>[mailto:l2vpn-bounces@ietf.org] On >>>>>Behalf Of Henderickx, Wim (Wim) >>>>>Sent: Thursday, April 12, 2012 2:03 AM >>>>>To: 'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com' ; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>The vlan approach is superior as it also works for eth only >>>>>networks, etc. On top some vendors indicate hw issues with the cw >>>>>approach. As such we have dropped more or less the cw approach. >>>>> >>>>>Cheers, >>>>>Wim >>>>>_________________ >>>>>sent from blackberry >>>>> >>>>>----- Original Message ----- >>>>>From: Giles Heron >>>>>[mailto:giles.heron@gmail.com] >>>>>Sent: Thursday, April 12, 2012 08:22 AM >>>>>To: Simon Delord >>>>>>; Alexander >>>>>Vainshtein >>>>>>>>>e >>>>>.com>> >>>>>Cc: l2vpn@ietf.org >>>>>>; Vladimir Kleiner >>>>>> ; >>>>>Andrew Sergeev >>>>>>; >>>>>Idan Kaspit >>>>>>; >>>>>Mishael Wexler >>>>>>; >>>>>Rotem Cohen >>>>>> >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>Sorry - the "anonymous presentation" was mine. I should possibly >>>>>have put in a third column on the CW approach. And hopefully the >>>>>minutes will be posted soon. >>>>> >>>>>We had various discussions, as Simon stated, and consensus seemed to >>>>>be forming around the two alternatives of two PWEs or two VLANs. I >>>>>believe three of the authors of the CW approach are also authors of >>>>>the two VLAN approach and one is also an author of the two PWE >>>>>approach. So perhaps it's best to let those four individuals say >>>>>which approach they prefer and why? >>>>> >>>>>Giles >>>>> >>>>>On 10/04/2012 00:45, "Simon Delord" >>>>>> wrote: >>>>> >>>>>> Hi Alexander, >>>>>> >>>>>> You are right, no discussion on the WG mailing list recently, but >>>>>> there have been substantial discussions among the authors of >>>>>> various solution drafts off the mailing list. As far as I know, no >>>>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>>>> meeting. I think the CW approach has not been rejected by the WG >>>>>> yet, or the WG has not yet decided on which one to adopt. >>>>>> >>>>>> Simon >>>>>> >>>>>> 2012/4/8 Alexander Vainshtein >>>>>> >>>>> e >>>>>> le.com>> >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>>>> >>>>>>> However, looking up the L2VPN proceedings, I've found a short >>>>>>> anonymous presentation called "E-Tree Update" ( >>>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>>>> This presentation discusses the differences of the E-Tree >>>>>>> approaches based on dedicated VLANs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw >>>>>>> / >>>>>>> ?in >>>>>>> clude_te >>>>>>> xt=3D1) >>>>>>> and completely ignores the solution based on usage of the CW in >>>>>>> the PWs connecting the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1 >>>>>>> ). >>>>>>> >>>>>>> >>>>>>> >>>>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>>>> I wonder whether the WG has taken a decision to reject the >>>>>>> approach based on the CW usage? I do not remember any recent >>>>>>> discussion of this topic on the WG mailing list. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, and lots of thanks in advance, >>>>>>> >>>>>>> Sasha >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This e-mail message is intended for the recipient only and >>>>>>> contains information which is CONFIDENTIAL and which may be >>>>>>> proprietary to ECI >>>>> >>>>>>> Telecom. If you have received this transmission in error, please >>>>>>> inform us by e-mail, phone or fax, and then delete the original >>>>>>> and all copies thereof. >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>>proprietary information, which is privileged, confidential, or >>>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>>intended solely for the use of the individual or entity to which it >>>>>is addressed. >>>>>If you are not the intended recipient of this E-mail, you are hereby >>>>>notified that any dissemination, distribution, copying, or action >>>>>taken in relation to the contents of and attachments to this E-mail >>>>>is strictly prohibited and may be unlawful. If you have received >>>>>this E-mail in error, please notify the sender immediately and >>>>>permanently delete the original and any copy of this E-mail and any >>>>>printout. >>>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or >>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>intended solely for the use of the individual or entity to which it >>>>is addressed. If you are not the intended recipient of this E-mail, >>>>you are hereby notified that any dissemination, distribution, >>>>copying, or action taken in relation to the contents of and >>>>attachments to this E-mail is strictly prohibited and may be >>>>unlawful. If you have received this E-mail in error, please notify >>>>the sender immediately and permanently delete the original and any >>>>copy of this E-mail and any printout. >>> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> This e-mail message is intended for the recipient only and contains >>>information which is CONFIDENTIAL and which may be proprietary to ECI >>>Telecom. If you have received this transmission in error, please >>>inform us by e-mail, phone or fax, and then delete the original and >>>all copies thereof. >>> >>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> L2vpn mailing list >>> L2vpn@ietf.org >>> https://www.ietf.org/mailman/listinfo/l2vpn >>> >>> >>> End of L2vpn Digest, Vol 95, Issue 25 >>> *********************************** > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 101 ************************************** From jdrake@juniper.net Mon Apr 30 06:13:05 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1720021F863F for ; Mon, 30 Apr 2012 06:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 PaeUr9n92mvk for ; Mon, 30 Apr 2012 06:13:04 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1CE21F8637 for ; Mon, 30 Apr 2012 06:13:04 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKT56P3MbwD/H4UmaI0RmyLQTNko7zBlIC@postini.com; Mon, 30 Apr 2012 06:13:04 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 30 Apr 2012 06:12:04 -0700 From: John E Drake To: Mach Chen , Lucy yong , Giles Heron , "l2vpn@ietf.org" Date: Mon, 30 Apr 2012 06:12:02 -0700 Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAAcwK+MA== Message-ID: <5E893DB832F57341992548CDBB333163A56EEDE9C5@EMBX01-HQ.jnpr.net> References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> 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-BeenThere: l2vpn@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, 30 Apr 2012 13:13:05 -0000 We already have TRILL and SPB. Why is yet another IS-IS variant necessary,= particularly one that is so completely under-specified?=20 Sent from my iPhone > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Mach Chen > Sent: Saturday, April 28, 2012 3:04 AM > To: Lucy yong; Giles Heron; l2vpn@ietf.org > Subject: RE: Interest in IS-IS VPLS >=20 > Fully agree with lucy here. >=20 > In addition, since the ISIS VPLS leverages a uniform protocol(ISIS) for > signaling and auto discovery, it would greatly simplify the deployment > and maintenance, especially for the DC networks that have already > deployed ISIS for IP routing. So I'd like to see the draft moving > forward. >=20 > Best regards, > Mach >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > > Of Lucy yong > > Sent: Saturday, April 28, 2012 2:43 AM > > To: Giles Heron; l2vpn@ietf.org > > Subject: RE: Interest in IS-IS VPLS > > > > Hi Giles, > > > > It seems that the IS-IS VPLS provides the solution for a scalable > data > > center network as mentioned in the draft. I am not sure it is proper > > to weight service providers more on this. I can see if a service > > provider already deployed existing VPLS, the gain from IS-IS VPLS is > > less than the cost on upgrading all the edge devices to support the > solution. > > > > However, for data center network, IS-IS VPLS could be a useful > > solution. It simplifies current VPLS mechanism, provides a good > > scalability, and requires IP only function on core switches. > > > > A vendor provides devices for both service provider network and data > > center network, the solution brings a synergy in leveraging VPLS > > solution into DC. > > > > Thus, I like to see this work moving forward. > > > > Regards, > > Lucy > > > > > > > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > > Of Giles Heron > > Sent: Friday, April 27, 2012 7:57 AM > > To: l2vpn@ietf.org > > Subject: Interest in IS-IS VPLS > > > > Hi, > > > > At the IETF meeting in Paris I took an action (as noted in the > > minutes) to poll the WG to see if there was any interest (other than > > by the authors of > > course) in progressing the IS-IS VPLS draft. > > > > Would you please respond to this email indicating whether or not you > > have interest in seeing this draft progress, ideally giving reasoning > > for your position. It'd be especially interesting to see responses > > from service providers of course. > > > > If there are no (or very few) responses to this email then Nabil and > I > > will probably interpret that as meaning there's insufficient interest > > to progress. Of course it may just mean that you all missed this > > email in the deluge of debate on E-Tree ;) > > > > Giles > > From josh.rogers@twcable.com Mon Apr 30 07:20:21 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4473921F8634 for ; Mon, 30 Apr 2012 07:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.209 X-Spam-Level: X-Spam-Status: No, score=-0.209 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HS_INDEX_PARAM=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 I11eRE+rWGco for ; Mon, 30 Apr 2012 07:20:18 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id B46CC21F8630 for ; Mon, 30 Apr 2012 07:20:17 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,504,1330923600"; d="scan'208";a="357796123" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 30 Apr 2012 10:19:20 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Mon, 30 Apr 2012 10:20:03 -0400 From: "Rogers, Josh" To: Daniel Cohn , "Henderickx, Wim (Wim)" , Lucy yong , Jiangyuanlong , "Fedyk, Donald (Don)" Date: Mon, 30 Apr 2012 10:20:02 -0400 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNI1NEe/4Txq0Y50G6N17p5Mncd5atPrZAgAYGhwCAAA0B8IAAATpggAAAz9CAAAEdYIAAHJ8C Message-ID: 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 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 30 Apr 2012 14:20:21 -0000 The mapping would be manual in the configuration of each PE. Daniel Cohn wrote: Can you explain this 1:1 relationship? Assuming any S-VID value can be received at any root or leaf AC, the S-VID that replaces it at the ingress PE must be such that the egress PE can recover the original S-VID plus the root/leaf ingress AC attribute. I don't see how this can be accomplished with the same number of bits. IOW, there needs to be a 1:1 mapping between 4094 S-VIDs in the root AC plus 4094 S-VIDs in a leaf AC to 4094 internal S-VIDs. I don't see how that is accomplished. What am I missing here? DC -----Original Message----- From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Monday, April 30, 2012 3:35 PM To: Daniel Cohn; Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? The internal S-VID which is pushed is popped/replaced with the original S-VID. Since they have a 1:1 relationship it is straightfwd. You need a mapping on ingress PE of the VPLS and on the egress PE. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: maandag 30 april 2012 14:35 To: Henderickx, Wim (Wim); Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Because I still didn't see an explanation on how the egress PE knows which S-VID to push when sending the frame to the AC, if the original S-VID was popped at the ingress PE. Lucy answered that the egress PE " knows which S-VLAN ID is used on an AC", which seems to assume a single S-VLAN per root/leaf AC. So I still didn't get an answer to my question. Regards, DC -----Original Message----- From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Monday, April 30, 2012 3:27 PM To: Daniel Cohn; Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Daniel, as Don pointed out the 2-VLAN solution works also with multiple S-VLANS. I am not sure why we are going in circles on this? -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: maandag 30 april 2012 13:41 To: Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Yuanlong, So the 2-VLAN solution, for the S-VLAN tagged port, works only when there is a single S-VID per AC? Thanks, DC -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Wednesday, April 25, 2012 9:21 PM To: Fedyk, Donald (Don; Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Don and Josh, draft-jiang-l2vpn-vpls-pe-etree-05 discussed S-VLAN access in the following way: "... For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames received from the root ACs can be translated to the root S-VLAN in the VPLS network domain. Alternatively, the PBB VPLS PE model (where an IEEE 802.1ah bridge module is embedded in the PE) as described in [PBB-VPLS] can be used, and a root B-VLAN or leaf B-VLAN can be added in this case. In a similar way, the traffic from the leaf ACs is tagged and transported on the leaf C-VLAN, S-VLAN or B-VLAN. " It seems option B is in line with the 1st sentence, not sure where option A came from, but do you have any concerns with the description in the 2nd sentence? Regards, Yuanlong ---------------------------------------------------------------------- Date: Wed, 25 Apr 2012 18:52:50 -0500 From: "Fedyk, Donald (Don)" To: "Rogers, Josh" , David Allan I , Daniel Cohn , "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: Content-Type: text/plain; charset=3D"us-ascii" Hi Josh Is there a draft that describes solution A? Solution B is what I've seen in the IEEE. One argument is that A is adding an extra TAG that offers little value. The TAG you have labeled 2 may need to be swapped anyway. Stacking S-TAGs is why PBB was developed. Cheers, Don -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Wednesday, April 25, 2012 7:22 PM To: David Allan I; Fedyk, Donald (Don); Daniel Cohn; l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? > Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. I have to apologize, because I think I led y'all down that path (I referred to the outermost tag, the same tag that the MPLS psuedowire is using for vlan mode encamp, as the S-Tag, even though the customer is the one placing it on the frame. Same as I described below, but I either used term S-Tag incorrectly, or ambiguously. >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... So, I think this could be cleared up some still. What I was referring to is the VID that the customer is using to put frames in, the VID which they should use to ensure the frame goes into the correct ETREE instance. You drew a distinction between 'customer VID' vs 'provider VID', but since it is negotiated, I haven't really seen a distinction, which I think is what has caused all the confusion. In the two discussion points/solutions I mentioned, the first one, "A", describes both a coordinated VID which the customer should use, and the service provider uses to distinguish between services on the same UNI, as well as a second, outer, VID which is used by the SP to determine the source AC type. In my example, if you were to sniff inside the psuedowire between PE1 and PE2 to see CE2 destined traffic, wish solution A, you might see "4001:2:Payload", where 4001 designates it is from a root AC, 2 designates the ETREE instance, and Payload is the customer's traffic (which may include a C-Tag), where with solution B, you would see "4001:Payload", and VID 2 would have to be swapped for 4001 as it enters the PE2-CE2 AC, giving the customer "2:Payload" just as they sent it (alternatively SP may choose to simply drop tag entirely and provide "Payload" to customer, this can cause problems with PVST on some devices, but I still see it done occasionally) ** Note, for the example above, I'm assuming 4001 is used as a 'standard' for root sourced frames, and 4002 is used for leaf sourced frames, for the ETREE R/L tags. Have I undone the confusion, or made it worse? -Josh On 4/25/12 5:19 PM, "David Allan I" wrote: >Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. > >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" > >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... > >Cheers >Dave > > > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Wednesday, April 25, 2012 5:42 PM >To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >Dave/Daniel/Lucy/Others Debating how many tags necessary when S-Tag >preservation is desired, > > >I think you all may have gone off on a tangent here. The original >discussion was about how to deal with the situation where the S-Tag is >preserved at a handoff (either an ENNI, or Service Multiplexed UNI) > >I believe there were two suggestions, one was that you push on a 'ETREE' >tag (one of two values, for either a frame sourced from a root AC or >another for a frame from a leaf AC), and the second solution was to 'map'. > > >Imagine the following topology: > >+-----+ +-----+ +-----+ +-----+ >| CE1 |--| PE1 |--| PE2 |--| CE2 | >+-----+ +-----+ +-----+ +-----+ > | | >+-----+ +-----+ +-----+ +-----+ >| CE3 |--| PE3 |--| PE4 |--| CE4 | >+-----+ +-----+ +-----+ +-----+ > >Where: > >Site Type VLAN >CE1 Root X >CE2 Leaf 2 >CE3 Leaf 3 >CE4 Leaf 3 > > >So, there are a lot of SP's who are keen on the way many services can be >handed to a customer on a single UNI, but coordinating a single VLAN per >service, with the customer (MEF used to call this EVPL when it was many >point to point services terminating on a single UNI). So, imagine that >we have two ETREE instances, and an internet service all terminating on a >single UNI connecting to CE1. We have negotiated VLAN ID's with the >customer, and they are expecting to reach CE2 using VLAN 2, CE3 and CE4 >using VLAN 3, and Internet service on VLAN 10. As a frame from CE1 comes >into PE1 destined for CE2 (so the customer has tagged it with VID 2), >using the 2VLAN method, since this is coming from a root site, do we > >a) place the Root S-Tag in front of VID 2, then ship it across, and pop >off the ETREE S-Tag (some SP's wish to Pop the original customer tag VID >2 as well) > >-or- > >b) swap VID2 for the ETREE Root S-Tag, send the frame to PE2 where it >will remove the S-Tag (and either push VID2 back on, or leave it off >depending on SP preference) > >The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf) > > >Hope that clears more than it confuses, >Josh > > > >On 4/25/12 4:22 PM, "Fedyk, Donald (Don)" > wrote: > >>Hi Dave >> >>Yes the only point I would add is Dual VLAN means One VID for Root and >>one VID for Leaf. Not two TAGs at a time on the frame but two allocated >>for the service. >> >>The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks >>about Encapsulation Overhead as a VLAN Tag. While that is true in a PWE >>sense it is still a single VLAN Tag at a time in a Ethernet E-tree sense. >> The compelling driver for Dual VLAN is having a Etree service that >>works in many environments and the DUAL VLAN (really dual VLAN >>interface on a >>VSI) uses the same mechanism (one VID for root and one VID for Leaf at >>a >>time) as specified in the IEEE. In a pure Ethernet bridging world the >>VLAN TAGs for Etree are not typically an overhead since translation is >>used. >> >>Don >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of David Allan I >>Sent: Wednesday, April 25, 2012 5:05 PM >>To: Daniel Cohn; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>OK I feel like I am digressing a fair distance from the actual >>problem.... But here goes: >> >>So the scenarios center around "how ETREE do you want to be?".... >> >>If the ACs are root/leaf, then if they are P2P (single ethernet end >>station attached to each AC) this is moot. ETREE semantics are enforced >>by the 2VID domain in the center of the example. If you assumed nodes >>A&B in the example were L2VPN PEs, the tagging and the PW tag >>imposition all happened at the same point in the network. >> >>If they are not simple P2P all the way to end systems and the objective >>is to avoid bridging between leaf "sites" but allowing intra-leaf-site >>connectivity then the leaves can be LANs but the root is not, such that >>I cannot bridge through the root. But all hosts at a given leaf site >>can see each other. So root Ethernet end systems are directly attached >>or two VIDs are used in the root site. >> >>If the objective is that there are multiple ethernet attached end >>stations at both the leaf and root sites, and the objective is to >>enforce >>L2 isolation everywhere then I need two VIDs extended to the end system >>attachement point in the local LANs by whatever means.... >> >>And I do not see adding VLANs in any particular spot, simply selection >>of the VID and associated semantics where VIDs are translated. The >>actual point of S-tag imposition could be a PE, or cloud be a NID/CLE >>on the customer prem (more likely scenario here to extend OAM demarc to >>the prem), or some switch in a RAN downstream of the MPLS PE... blah >>blah blah. And if ETREE is extended into a customer site LAN and >>outside of the provider domain, then two C-tags would have to be used >>that mapped to S-tags at the PBN boundary... >> >>Make sense? >>Dave >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 25, 2012 4:39 PM >>To: David Allan I; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Dave, but the ACs are root/leaf (that's what the whole vpls etree is >>about - see the reqt draft), so per the 2vlan draft the root/leaf vlan >>must be added. >> >>Thumb typed - please be tolerant >> >>David Allan I wrote: >> >>HI Daniel: >> >>In the example provided, >> >>"ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" >> A B >> >>the service is not ETREE in the domains of the ingress and egress VID. >>It is ELAN. SO there is no root/leaf attribute to shovel around. It >>would require two VIDs in each domain if the ETREE semantics were to be >>telescoped E2E. >> >>Otherwise it is a provisioning of the VID translation tables at the >>intermediate nodes (A&B that I've added to the picture) that would >>determine the VID values used in each domain. Or in the example above, >>what the ingress, Etree and egress VID values were. >> >>Cheers >>Dave >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 3:46 PM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>And to this I asked how this mapping works - how does the egress pe >>recover the ingress vid when it gets the frame tagged with only the >>root/leaf vid? How can you convey the ingress vid plus the root/leaf >>attribute in the same number of bits? >>What am I missing? >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>David Allen already explained the solution. >> >>From David: >>ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. >> >>Ingress VID does not have to equal Egress VID but regardless there is >>only ever one VID on a frame at a time. >> >>-end >> >>This works when customer makes ingress VLAN ID not equal to or equal to >>egress VLAN ID. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 11:39 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Lucy, >> >>The scenario we are discussing is not the E-Tree E-NNI, but a general >>scenario where frames arriving at the root or leaf AC are already >>double tagged. In this case, the dual vlan solution cannot preserve the >>vlans without adding a third one, can it? >> >>Maybe Shahram can add details on the scenario he had in mind >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has S-VLAN preservation attribute for ENNI only because there is no >>s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN >>preservation attribute is used. It applies to E-Tree as well. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Tuesday, April 24, 2012 2:12 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Lucy, >> >>even if the current MEF framework doesn't require s-vlan preservation, >>I believe it's to the industry's benefit to adopt a solution that is >>not constrained to a specific enni model that, like all things >>networking, is likely to evolve. Especially when such a solution is >>available. >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has worked in ENNI interface for a long time with many service >>providers' inputs. It had a fair reason to assume S-VLAN over ENNI by >>then. It may open B-VLAN for the future. It is better for us not to >>discuss a future framework here, because it will lead us to nowhere. >>Here, we want to extend VPLS in supporting E-Tree. >> >>Best Regards, >>Lucy >> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Sunday, April 22, 2012 7:34 AM >>To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Shahram and all, >> >>This question already came up in our discussions - is it safe to assume >>that the VLAN tags at the E-NNI will always be according to the current >>MEF model? Or should we try to be as transparent as possible to user >>VLAN encapsulation at the E-NNI, to accommodate future frameworks? >>I believe that any approach that looks at user payload (in this case >>VLAN >>tag) to signal VPLS information (in this case root/leaf origin) is >>necessarily tied to specific assumptions on user payload encapsulation >>(in this case, that S-VLAN tag is "available" to encode root/leaf). I >>don't think this is a future-proof assumption, it's very likely that >>other network models will come up that require S-VLAN preservation, >>which in the 2-VLAN approach would necessitate adding a third VLAN-ID. >> >>Daniel >> >>From: Shahram Davari > >>To: Lizhong Jin >, >>"l2vpn@ietf.org" >>>, >>"Alexander.Vainshtein@ecitele.com>om> >>" >>>om> >>> >>Cc: "yuqun.cao@gmail.com" >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, >> >>I also have a question regarding 2-VLAN. What if the customer traffic >>already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? >> >>Thx >>Shahram >> >>From: l2vpn-bounces@ietf.org >>[mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin >>Sent: Friday, April 20, 2012 9:38 AM >>To: l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com>m> >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, all, >>The difference between 2-VLAN and CW approach is who will provide the >>R/L information, customer payload or PW? The customer payload will be >>always modified to carry R/L information in 2-VLAN approach, while PW >>with CW will carry R/L information for CW approach. >>I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is >>accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is >>used to access H-VPLS, how could the PE on VPWS side adds VLAN to >>indicate R/L information? >> >>Thanks >>Lizhong >> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Thu, 19 Apr 2012 04:38:36 +0000 >>> From: Alexander Vainshtein >>> >> com>> >>> To: "Rogers, Josh" >>>>, Lucy yong >>> >, Daniel >>>Cohn >, Sam Cao >>> > >>> Cc: "l2vpn@ietf.org" >>> > >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> Message-ID: >>> >>> >> t o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> >>> Content-Type: text/plain; charset=3D"us-ascii" >>> >>> Hi all, >>> I fully understand that that what I am going to say is not very >>>popular, but: >>> >>> IMO one of the advantages of the CW-based solution is that it is >>>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery >>>of BUN traffic. >>> >>> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>>and, in a more generic way, localization of effects of changes in the >>>PE configuration. >>> >>> In particular, adding a Leaf AC to a PE that previously has been only >>>supporting Root ACs (or vice versa), removal of the last Leaf or last >>>Root AC from a PE that previously has been supporting a mix etc. >>>affect only the PE where this operation happens and not the rest of the >>>PEs. >>> >>> As for the need for HW changes that have been mentioned as a main >>>disadvantage of the CW-based approach - I believe it strongly depends >>>on specific implementations. And some changes in the forwarding >>>process are required in any solution. >>> >>> My 2c, >>> Sasha >>> >>> >>> >>> ________________________________________ >>> From: l2vpn-bounces@ietf.org >>> [l2vpn-bounces@ietf.org] on behalf of >>> Rogers, Josh >>> [josh.rogers@twcable.com] >>> Sent: Wednesday, April 18, 2012 9:57 PM >>> To: Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: Re: The status of the approaches to the E-Tree solution? >>> >>> Again, the P2MP situation throws me. Is this something that is used >>> commonly? >>> >>> I'm under the impression that adding P2MP to any model results in a >>> more complex model. Wether outside s-tag is used to differentiate, >>> or dedicated pw's are used for the same purpose, it seems both become >>> more complex. >>> >>> Gile's comparison slide still concisely captures the differences >>>between these methods, in my opinion. I haven't seen any new ideas or >>>thoughts brought to the group in the past week or two on the subject. >>> I would hate for both proposed methods to die on the vine because we >>>couldn't decide between two methods that have nothing inherently wrong >>>with either. >>> >>> -Josh >>> >>> >>> On 4/18/12 1:53 PM, "Lucy yong" >>>> wrote: >>> >>>>Send this again. >>>> >>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>>double all of them. >>>> >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn >>>>[mailto:DanielC@orckit.com] >>>>Sent: Wednesday, April 18, 2012 1:42 PM >>>>To: Lucy yong; Rogers, Josh; Sam Cao >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>I think the first option its the natural way to go. How is the >>>>processing in this case more complex? >>>> >>>>Thumb typed - please be tolerant >>>> >>>>Lucy yong > wrote: >>>> >>>> >>>> >>>>Snipped.. >>>> >>>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only >>>>P2MP PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP >>>>PW (for traffic coming from a root AC) [[LY]] Not that simple. You >>>>construct either two P2MP PWs to all other PEs and let egress PE >>>>performing filtering, or construct one P2MP PW to leaf-only PEs and >>>>two P2MP PWs to root and leaf PEs and let ingress PE perform >>>>forwarding and filtering. Both make node process complex. >>>> >>>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>>>delivering the frames to remote PEs. We should utilize them with the >>>>minimized changes. Dual VLAN solution is simpler than Dual PW. >>>> >>>>Regards, >>>>Lucy >>>> >>>> >>>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>>>haven't had any first hand experience with P2MP PW's, however, so >>>>don't feel terribly strong about this objection. Is this a real >>>>problem for others (now or in the future), or is this objection in >>>>the weeds? >>>> >>>>I'm not sure the 'additional complexity' is notable, or even relevant. >>>>I encourage others to speak up if they disagree, as P2MP PW is only >>>>conceptual to me, and I am unfamiliar with real-life use cases for it. >>>> >>>>Thanks, >>>>Josh >>>> >>>> >>>> >>>>On 4/18/12 10:30 AM, "Lucy yong" >>>>> wrote: >>>> >>>>>Please see inline. >>>>> >>>>>-----Original Message----- >>>>>From: Sam Cao >>>>>[mailto:yuqun.cao@gmail.com] >>>>>Sent: Tuesday, April 17, 2012 7:14 AM >>>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>>>(Wim)'; giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>>>> >>>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>>>PE have both root and leaf AC and some only have leaf ACs)? >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Yuqun (Sam) Cao >>>>>E-mail: Yuqun.cao@gmail.com >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn >>>>>[mailto:DanielC@orckit.com] >>>>>Sent: Tuesday, April 17, 2012 4:56 PM >>>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com>; Sam Cao >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Adding Sam (as l2vpn@ is holding messages) >>>>> >>>>>DC >>>>> >>>>>-----Original Message----- >>>>>From: Lucy yong >>>>>[mailto:lucy.yong@huawei.com] >>>>>Sent: Tuesday, April 17, 2012 12:39 AM >>>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>> >>>>>Snipped, >>>>> >>>>>As we discussed extensively in the list, and as reflected in giles >>>>>slide, 2 pws are only needed between pes with both root and leaf >>>>>acs, which will typically be a small minority. >>>>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>>>both approaches can benefit from it. I was off for a while and >>>>>captures some discussions now. >>>>> >>>>>Also as per giles slide, dual vlan can have scalability issues due >>>>>to additional lookup and double use of vlans in internal emulated >>>>>lan interface. Also there are potential backward compatibility >>>>>issues with silicon that doesn't support vlan mapping. >>>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. >>>>>I am not clear on all the issues. Could you be more specific? As I >>>>>mentioned in below, two PW approach makes VPLS transport >>>>>construction and packet forwarding more complex, I can see potential >>>>>backward compatibility issues with 2 PW solution. >>>>> >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Daniel >>>>> >>>>>Thumb typed - please be tolerant >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>>In my mind, the VLAN approach means dual vlan method. >>>>> >>>>>The main concern for CW approach is hardware support. >>>>> >>>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and >>>>>unknown unicast traffic, and some P2MP PWs for multicast traffic. It >>>>>may double all of them. >>>>> >>>>>E-tree is an Ethernet service and there is already VLAN based >>>>>solution in IEEE, can we just utilize it without complicating VPLS >>>>>transport construction? This also makes interworking with Eth only >>>>>network easier. >>>>> >>>>>Cheers, >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: Rogers, Josh >>>>>[mailto:josh.rogers@twcable.com] >>>>>Sent: Monday, April 16, 2012 8:35 AM >>>>>To: Lucy yong; Henderickx, Wim (Wim); >>>>>'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com' ; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>I believe the initial question was in regard to the CW method. Are >>>>>you saying that you no longer are interested in that method in >>>>>preference of the dual vlan method? >>>>> >>>>> >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>> >>>>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>>>> >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: l2vpn-bounces@ietf.org >>>>>[mailto:l2vpn-bounces@ietf.org] On >>>>>Behalf Of Henderickx, Wim (Wim) >>>>>Sent: Thursday, April 12, 2012 2:03 AM >>>>>To: 'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com' ; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>The vlan approach is superior as it also works for eth only >>>>>networks, etc. On top some vendors indicate hw issues with the cw >>>>>approach. As such we have dropped more or less the cw approach. >>>>> >>>>>Cheers, >>>>>Wim >>>>>_________________ >>>>>sent from blackberry >>>>> >>>>>----- Original Message ----- >>>>>From: Giles Heron >>>>>[mailto:giles.heron@gmail.com] >>>>>Sent: Thursday, April 12, 2012 08:22 AM >>>>>To: Simon Delord >>>>>>; Alexander >>>>>Vainshtein >>>>>>>>>e >>>>>.com>> >>>>>Cc: l2vpn@ietf.org >>>>>>; Vladimir Kleiner >>>>>> ; >>>>>Andrew Sergeev >>>>>>; >>>>>Idan Kaspit >>>>>>; >>>>>Mishael Wexler >>>>>>; >>>>>Rotem Cohen >>>>>> >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>Sorry - the "anonymous presentation" was mine. I should possibly >>>>>have put in a third column on the CW approach. And hopefully the >>>>>minutes will be posted soon. >>>>> >>>>>We had various discussions, as Simon stated, and consensus seemed to >>>>>be forming around the two alternatives of two PWEs or two VLANs. I >>>>>believe three of the authors of the CW approach are also authors of >>>>>the two VLAN approach and one is also an author of the two PWE >>>>>approach. So perhaps it's best to let those four individuals say >>>>>which approach they prefer and why? >>>>> >>>>>Giles >>>>> >>>>>On 10/04/2012 00:45, "Simon Delord" >>>>>> wrote: >>>>> >>>>>> Hi Alexander, >>>>>> >>>>>> You are right, no discussion on the WG mailing list recently, but >>>>>> there have been substantial discussions among the authors of >>>>>> various solution drafts off the mailing list. As far as I know, no >>>>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>>>> meeting. I think the CW approach has not been rejected by the WG >>>>>> yet, or the WG has not yet decided on which one to adopt. >>>>>> >>>>>> Simon >>>>>> >>>>>> 2012/4/8 Alexander Vainshtein >>>>>> >>>>> e >>>>>> le.com>> >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>>>> >>>>>>> However, looking up the L2VPN proceedings, I've found a short >>>>>>> anonymous presentation called "E-Tree Update" ( >>>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>>>> This presentation discusses the differences of the E-Tree >>>>>>> approaches based on dedicated VLANs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw >>>>>>> / >>>>>>> ?in >>>>>>> clude_te >>>>>>> xt=3D1) >>>>>>> and completely ignores the solution based on usage of the CW in >>>>>>> the PWs connecting the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1 >>>>>>> ). >>>>>>> >>>>>>> >>>>>>> >>>>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>>>> I wonder whether the WG has taken a decision to reject the >>>>>>> approach based on the CW usage? I do not remember any recent >>>>>>> discussion of this topic on the WG mailing list. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, and lots of thanks in advance, >>>>>>> >>>>>>> Sasha >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This e-mail message is intended for the recipient only and >>>>>>> contains information which is CONFIDENTIAL and which may be >>>>>>> proprietary to ECI >>>>> >>>>>>> Telecom. If you have received this transmission in error, please >>>>>>> inform us by e-mail, phone or fax, and then delete the original >>>>>>> and all copies thereof. >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>>proprietary information, which is privileged, confidential, or >>>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>>intended solely for the use of the individual or entity to which it >>>>>is addressed. >>>>>If you are not the intended recipient of this E-mail, you are hereby >>>>>notified that any dissemination, distribution, copying, or action >>>>>taken in relation to the contents of and attachments to this E-mail >>>>>is strictly prohibited and may be unlawful. If you have received >>>>>this E-mail in error, please notify the sender immediately and >>>>>permanently delete the original and any copy of this E-mail and any >>>>>printout. >>>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or >>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>intended solely for the use of the individual or entity to which it >>>>is addressed. If you are not the intended recipient of this E-mail, >>>>you are hereby notified that any dissemination, distribution, >>>>copying, or action taken in relation to the contents of and >>>>attachments to this E-mail is strictly prohibited and may be >>>>unlawful. If you have received this E-mail in error, please notify >>>>the sender immediately and permanently delete the original and any >>>>copy of this E-mail and any printout. >>> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> This e-mail message is intended for the recipient only and contains >>>information which is CONFIDENTIAL and which may be proprietary to ECI >>>Telecom. If you have received this transmission in error, please >>>inform us by e-mail, phone or fax, and then delete the original and >>>all copies thereof. >>> >>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> L2vpn mailing list >>> L2vpn@ietf.org >>> https://www.ietf.org/mailman/listinfo/l2vpn >>> >>> >>> End of L2vpn Digest, Vol 95, Issue 25 >>> *********************************** > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 101 ************************************** This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From donald.fedyk@alcatel-lucent.com Mon Apr 30 07:21:30 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1B421F863F for ; Mon, 30 Apr 2012 07:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.098 X-Spam-Level: X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 dm16P2InB5HN for ; Mon, 30 Apr 2012 07:21:26 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id A0F7421F8633 for ; Mon, 30 Apr 2012 07:21:26 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q3UEKjXQ011238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Apr 2012 09:20:45 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q3UEKieR003784 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Apr 2012 09:20:44 -0500 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.144]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Mon, 30 Apr 2012 09:20:44 -0500 From: "Fedyk, Donald (Don)" To: "Henderickx, Wim (Wim)" , "'DanielC@orckit.com'" , "'lucy.yong@huawei.com'" , "'jiangyuanlong@huawei.com'" , "'josh.rogers@twcable.com'" Date: Mon, 30 Apr 2012 09:20:32 -0500 Subject: RE: The status of the approaches to the E-Tree solution? Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNI1NEe/4Txq0Y50G6N17p5Mncd5atPrZAgAYGhwCAAA0B8IAAATpggAAAz9CAAAEdYIAABKrkgAAO+lA= Message-ID: References: <44F4E579A764584EA9BDFD07D0CA08130777C912@tlvmail1> <14C7F4F06DB5814AB0DE29716C4F6D67023ECB0FE3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D67023ECB0FE3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {17B4B879-50A5-40A7-BBBB-A23A242CAF6F} x-cr-hashedpuzzle: AyCa BM+d CMbK EZFw GeZo H+N1 Izko OZ4+ PhEM f87d kYBf mgbO rItq wYZa xcnK xxQ6; 5; ZABhAG4AaQBlAGwAYwBAAG8AcgBjAGsAaQB0AC4AYwBvAG0AOwBqAGkAYQBuAGcAeQB1AGEAbgBsAG8AbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA7AGoAbwBzAGgALgByAG8AZwBlAHIAcwBAAHQAdwBjAGEAYgBsAGUALgBjAG8AbQA7AGwAMgB2AHAAbgBAAGkAZQB0AGYALgBvAHIAZwA7AGwAdQBjAHkALgB5AG8AbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Sosha1_v1; 7; {17B4B879-50A5-40A7-BBBB-A23A242CAF6F}; ZABvAG4AYQBsAGQALgBmAGUAZAB5AGsAQABhAGwAYwBhAHQAZQBsAC0AbAB1AGMAZQBuAHQALgBjAG8AbQA=; Mon, 30 Apr 2012 14:20:32 GMT; UgBFADoAIABUAGgAZQAgAHMAdABhAHQAdQBzACAAbwBmACAAdABoAGUAIABhAHAAcAByAG8AYQBjAGgAZQBzACAAdABvACAAdABoAGUAIABFAC0AVAByAGUAZQAgAHMAbwBsAHUAdABpAG8AbgA/AA== acceptlanguage: en-US 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.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "'l2vpn@ietf.org'" X-BeenThere: l2vpn@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, 30 Apr 2012 14:21:30 -0000 Hi Dan Let me try to explain. I think you are mixing the case 1) where there is a single core Etree and m= ultiple S-VLANs multiplex on that tree with the case 2) where there are mul= tiple core E-Trees one per S-VLAN. In case 1) You need to encapsulate. You encapsulate based on local context = of Root or Leaf. The Core Etree though is the superset of the all the mult= iplexed E-Trees and would need to push on Ingress (in some form) the S-VID = and Pop on egress (in some form) the S-VID. You can use a single Root S-VID= (or other encapsulation ) and Single Leaf S-VID (or other encapsulation ) i= n the core. In case 2) You have a dedicated E-Tree per S-VLAN. On Ingress you translate= based on local context of root or leaf but the mapping is 1:1 and on egres= s you translate back with 1:1. There are multiple S-VIDs per leaf and root = as Wim points out the S-VID space is halved. Both cases use local service context to determine root /leaf behavior. The frame format differs in the two cases. (Data overhead varies) But the biggest difference in the two cases is whether or not you can prune= the encapsulated tree within the core or only on the edge. If the core is= transparent (can't internally prune) then the dedicated Etree case 2) is m= ore efficient. If the core can do some form of DPI or other then Case 1 ca= n also be data efficient. By data efficient I mean not sending frames to Edges only to be dumped. Thi= s matters because root to leaf data is often multicast. In the IEEE the S-VLAN and PBB forms are both case 2) 1:1 mapping on the e= dge (S-VID <-> S-VID(Root/Leaf) or S-VID<->I-SID (Root/Leaf)) from a servic= e perspective. But PBB case also encapsulates with an outer single B-VLAN = and in certain implementations can be made to be data efficient (for exampl= e with SPB). Hope that clears it up, Don -----Original Message----- From: Henderickx, Wim (Wim) Sent: Monday, April 30, 2012 8:54 AM To: 'DanielC@orckit.com'; 'lucy.yong@huawei.com'; 'jiangyuanlong@huawei.com= '; Fedyk, Donald (Don); 'josh.rogers@twcable.com' Cc: 'l2vpn@ietf.org' Subject: Re: The status of the approaches to the E-Tree solution? The procedure halfs the s-vid space since you need 1 for root and one for l= eaf. If this is not enough pbb solves the issue. This is how ieee proposes = this to work afaik. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, April 30, 2012 02:51 PM To: Henderickx, Wim (Wim); Lucy yong ; Jiangyuanlong = ; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Can you explain this 1:1 relationship? Assuming any S-VID value can be received at any root or leaf AC, the S-VID that replaces it at the ingress PE must be such that the egress PE can recover the original S-VID plus the root/leaf ingress AC attribute. I don't see how this can be accomplished with the same number of bits. IOW, there needs to be a 1:1 mapping between 4094 S-VIDs in the root AC plus 4094 S-VIDs in a leaf AC to 4094 internal S-VIDs. I don't see how that is accomplished. What am I missing here? DC -----Original Message----- From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Monday, April 30, 2012 3:35 PM To: Daniel Cohn; Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? The internal S-VID which is pushed is popped/replaced with the original S-VID. Since they have a 1:1 relationship it is straightfwd. You need a mapping on ingress PE of the VPLS and on the egress PE. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: maandag 30 april 2012 14:35 To: Henderickx, Wim (Wim); Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Because I still didn't see an explanation on how the egress PE knows which S-VID to push when sending the frame to the AC, if the original S-VID was popped at the ingress PE. Lucy answered that the egress PE " knows which S-VLAN ID is used on an AC", which seems to assume a single S-VLAN per root/leaf AC. So I still didn't get an answer to my question. Regards, DC -----Original Message----- From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Monday, April 30, 2012 3:27 PM To: Daniel Cohn; Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Daniel, as Don pointed out the 2-VLAN solution works also with multiple S-VLANS. I am not sure why we are going in circles on this? -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: maandag 30 april 2012 13:41 To: Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Yuanlong, So the 2-VLAN solution, for the S-VLAN tagged port, works only when there is a single S-VID per AC? Thanks, DC -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Wednesday, April 25, 2012 9:21 PM To: Fedyk, Donald (Don; Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Don and Josh, draft-jiang-l2vpn-vpls-pe-etree-05 discussed S-VLAN access in the following way: "... For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames received from the root ACs can be translated to the root S-VLAN in the VPLS network domain. Alternatively, the PBB VPLS PE model (where an IEEE 802.1ah bridge module is embedded in the PE) as described in [PBB-VPLS] can be used, and a root B-VLAN or leaf B-VLAN can be added in this case. In a similar way, the traffic from the leaf ACs is tagged and transported on the leaf C-VLAN, S-VLAN or B-VLAN. " It seems option B is in line with the 1st sentence, not sure where option A came from, but do you have any concerns with the description in the 2nd sentence? Regards, Yuanlong ---------------------------------------------------------------------- Date: Wed, 25 Apr 2012 18:52:50 -0500 From: "Fedyk, Donald (Don)" To: "Rogers, Josh" , David Allan I , Daniel Cohn , "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: Content-Type: text/plain; charset=3D"us-ascii" Hi Josh Is there a draft that describes solution A? Solution B is what I've seen in the IEEE. One argument is that A is adding an extra TAG that offers little value. The TAG you have labeled 2 may need to be swapped anyway. Stacking S-TAGs is why PBB was developed. Cheers, Don -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Wednesday, April 25, 2012 7:22 PM To: David Allan I; Fedyk, Donald (Don); Daniel Cohn; l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? > Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. I have to apologize, because I think I led y'all down that path (I referred to the outermost tag, the same tag that the MPLS psuedowire is using for vlan mode encamp, as the S-Tag, even though the customer is the one placing it on the frame. Same as I described below, but I either used term S-Tag incorrectly, or ambiguously. >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... So, I think this could be cleared up some still. What I was referring to is the VID that the customer is using to put frames in, the VID which they should use to ensure the frame goes into the correct ETREE instance. You drew a distinction between 'customer VID' vs 'provider VID', but since it is negotiated, I haven't really seen a distinction, which I think is what has caused all the confusion. In the two discussion points/solutions I mentioned, the first one, "A", describes both a coordinated VID which the customer should use, and the service provider uses to distinguish between services on the same UNI, as well as a second, outer, VID which is used by the SP to determine the source AC type. In my example, if you were to sniff inside the psuedowire between PE1 and PE2 to see CE2 destined traffic, wish solution A, you might see "4001:2:Payload", where 4001 designates it is from a root AC, 2 designates the ETREE instance, and Payload is the customer's traffic (which may include a C-Tag), where with solution B, you would see "4001:Payload", and VID 2 would have to be swapped for 4001 as it enters the PE2-CE2 AC, giving the customer "2:Payload" just as they sent it (alternatively SP may choose to simply drop tag entirely and provide "Payload" to customer, this can cause problems with PVST on some devices, but I still see it done occasionally) ** Note, for the example above, I'm assuming 4001 is used as a 'standard' for root sourced frames, and 4002 is used for leaf sourced frames, for the ETREE R/L tags. Have I undone the confusion, or made it worse? -Josh On 4/25/12 5:19 PM, "David Allan I" wrote: >Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. > >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" > >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... > >Cheers >Dave > > > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Wednesday, April 25, 2012 5:42 PM >To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >Dave/Daniel/Lucy/Others Debating how many tags necessary when S-Tag >preservation is desired, > > >I think you all may have gone off on a tangent here. The original >discussion was about how to deal with the situation where the S-Tag is >preserved at a handoff (either an ENNI, or Service Multiplexed UNI) > >I believe there were two suggestions, one was that you push on a 'ETREE' >tag (one of two values, for either a frame sourced from a root AC or >another for a frame from a leaf AC), and the second solution was to 'map'. > > >Imagine the following topology: > >+-----+ +-----+ +-----+ +-----+ >| CE1 |--| PE1 |--| PE2 |--| CE2 | >+-----+ +-----+ +-----+ +-----+ > | | >+-----+ +-----+ +-----+ +-----+ >| CE3 |--| PE3 |--| PE4 |--| CE4 | >+-----+ +-----+ +-----+ +-----+ > >Where: > >Site Type VLAN >CE1 Root X >CE2 Leaf 2 >CE3 Leaf 3 >CE4 Leaf 3 > > >So, there are a lot of SP's who are keen on the way many services can be >handed to a customer on a single UNI, but coordinating a single VLAN per >service, with the customer (MEF used to call this EVPL when it was many >point to point services terminating on a single UNI). So, imagine that >we have two ETREE instances, and an internet service all terminating on a >single UNI connecting to CE1. We have negotiated VLAN ID's with the >customer, and they are expecting to reach CE2 using VLAN 2, CE3 and CE4 >using VLAN 3, and Internet service on VLAN 10. As a frame from CE1 comes >into PE1 destined for CE2 (so the customer has tagged it with VID 2), >using the 2VLAN method, since this is coming from a root site, do we > >a) place the Root S-Tag in front of VID 2, then ship it across, and pop >off the ETREE S-Tag (some SP's wish to Pop the original customer tag VID >2 as well) > >-or- > >b) swap VID2 for the ETREE Root S-Tag, send the frame to PE2 where it >will remove the S-Tag (and either push VID2 back on, or leave it off >depending on SP preference) > >The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf) > > >Hope that clears more than it confuses, >Josh > > > >On 4/25/12 4:22 PM, "Fedyk, Donald (Don)" > wrote: > >>Hi Dave >> >>Yes the only point I would add is Dual VLAN means One VID for Root and >>one VID for Leaf. Not two TAGs at a time on the frame but two allocated >>for the service. >> >>The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks >>about Encapsulation Overhead as a VLAN Tag. While that is true in a PWE >>sense it is still a single VLAN Tag at a time in a Ethernet E-tree sense. >> The compelling driver for Dual VLAN is having a Etree service that >>works in many environments and the DUAL VLAN (really dual VLAN >>interface on a >>VSI) uses the same mechanism (one VID for root and one VID for Leaf at >>a >>time) as specified in the IEEE. In a pure Ethernet bridging world the >>VLAN TAGs for Etree are not typically an overhead since translation is >>used. >> >>Don >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of David Allan I >>Sent: Wednesday, April 25, 2012 5:05 PM >>To: Daniel Cohn; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>OK I feel like I am digressing a fair distance from the actual >>problem.... But here goes: >> >>So the scenarios center around "how ETREE do you want to be?".... >> >>If the ACs are root/leaf, then if they are P2P (single ethernet end >>station attached to each AC) this is moot. ETREE semantics are enforced >>by the 2VID domain in the center of the example. If you assumed nodes >>A&B in the example were L2VPN PEs, the tagging and the PW tag >>imposition all happened at the same point in the network. >> >>If they are not simple P2P all the way to end systems and the objective >>is to avoid bridging between leaf "sites" but allowing intra-leaf-site >>connectivity then the leaves can be LANs but the root is not, such that >>I cannot bridge through the root. But all hosts at a given leaf site >>can see each other. So root Ethernet end systems are directly attached >>or two VIDs are used in the root site. >> >>If the objective is that there are multiple ethernet attached end >>stations at both the leaf and root sites, and the objective is to >>enforce >>L2 isolation everywhere then I need two VIDs extended to the end system >>attachement point in the local LANs by whatever means.... >> >>And I do not see adding VLANs in any particular spot, simply selection >>of the VID and associated semantics where VIDs are translated. The >>actual point of S-tag imposition could be a PE, or cloud be a NID/CLE >>on the customer prem (more likely scenario here to extend OAM demarc to >>the prem), or some switch in a RAN downstream of the MPLS PE... blah >>blah blah. And if ETREE is extended into a customer site LAN and >>outside of the provider domain, then two C-tags would have to be used >>that mapped to S-tags at the PBN boundary... >> >>Make sense? >>Dave >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 25, 2012 4:39 PM >>To: David Allan I; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Dave, but the ACs are root/leaf (that's what the whole vpls etree is >>about - see the reqt draft), so per the 2vlan draft the root/leaf vlan >>must be added. >> >>Thumb typed - please be tolerant >> >>David Allan I wrote: >> >>HI Daniel: >> >>In the example provided, >> >>"ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" >> A B >> >>the service is not ETREE in the domains of the ingress and egress VID. >>It is ELAN. SO there is no root/leaf attribute to shovel around. It >>would require two VIDs in each domain if the ETREE semantics were to be >>telescoped E2E. >> >>Otherwise it is a provisioning of the VID translation tables at the >>intermediate nodes (A&B that I've added to the picture) that would >>determine the VID values used in each domain. Or in the example above, >>what the ingress, Etree and egress VID values were. >> >>Cheers >>Dave >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 3:46 PM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>And to this I asked how this mapping works - how does the egress pe >>recover the ingress vid when it gets the frame tagged with only the >>root/leaf vid? How can you convey the ingress vid plus the root/leaf >>attribute in the same number of bits? >>What am I missing? >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>David Allen already explained the solution. >> >>From David: >>ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. >> >>Ingress VID does not have to equal Egress VID but regardless there is >>only ever one VID on a frame at a time. >> >>-end >> >>This works when customer makes ingress VLAN ID not equal to or equal to >>egress VLAN ID. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 11:39 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Lucy, >> >>The scenario we are discussing is not the E-Tree E-NNI, but a general >>scenario where frames arriving at the root or leaf AC are already >>double tagged. In this case, the dual vlan solution cannot preserve the >>vlans without adding a third one, can it? >> >>Maybe Shahram can add details on the scenario he had in mind >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has S-VLAN preservation attribute for ENNI only because there is no >>s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN >>preservation attribute is used. It applies to E-Tree as well. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Tuesday, April 24, 2012 2:12 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Lucy, >> >>even if the current MEF framework doesn't require s-vlan preservation, >>I believe it's to the industry's benefit to adopt a solution that is >>not constrained to a specific enni model that, like all things >>networking, is likely to evolve. Especially when such a solution is >>available. >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has worked in ENNI interface for a long time with many service >>providers' inputs. It had a fair reason to assume S-VLAN over ENNI by >>then. It may open B-VLAN for the future. It is better for us not to >>discuss a future framework here, because it will lead us to nowhere. >>Here, we want to extend VPLS in supporting E-Tree. >> >>Best Regards, >>Lucy >> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Sunday, April 22, 2012 7:34 AM >>To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Shahram and all, >> >>This question already came up in our discussions - is it safe to assume >>that the VLAN tags at the E-NNI will always be according to the current >>MEF model? Or should we try to be as transparent as possible to user >>VLAN encapsulation at the E-NNI, to accommodate future frameworks? >>I believe that any approach that looks at user payload (in this case >>VLAN >>tag) to signal VPLS information (in this case root/leaf origin) is >>necessarily tied to specific assumptions on user payload encapsulation >>(in this case, that S-VLAN tag is "available" to encode root/leaf). I >>don't think this is a future-proof assumption, it's very likely that >>other network models will come up that require S-VLAN preservation, >>which in the 2-VLAN approach would necessitate adding a third VLAN-ID. >> >>Daniel >> >>From: Shahram Davari > >>To: Lizhong Jin >, >>"l2vpn@ietf.org" >>>, >>"Alexander.Vainshtein@ecitele.com>om> >>" >>>om> >>> >>Cc: "yuqun.cao@gmail.com" >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, >> >>I also have a question regarding 2-VLAN. What if the customer traffic >>already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? >> >>Thx >>Shahram >> >>From: l2vpn-bounces@ietf.org >>[mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin >>Sent: Friday, April 20, 2012 9:38 AM >>To: l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com>m> >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, all, >>The difference between 2-VLAN and CW approach is who will provide the >>R/L information, customer payload or PW? The customer payload will be >>always modified to carry R/L information in 2-VLAN approach, while PW >>with CW will carry R/L information for CW approach. >>I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is >>accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is >>used to access H-VPLS, how could the PE on VPWS side adds VLAN to >>indicate R/L information? >> >>Thanks >>Lizhong >> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Thu, 19 Apr 2012 04:38:36 +0000 >>> From: Alexander Vainshtein >>> >> com>> >>> To: "Rogers, Josh" >>>>, Lucy yong >>> >, Daniel >>>Cohn >, Sam Cao >>> > >>> Cc: "l2vpn@ietf.org" >>> > >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> Message-ID: >>> >>> >> t o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> >>> Content-Type: text/plain; charset=3D"us-ascii" >>> >>> Hi all, >>> I fully understand that that what I am going to say is not very >>>popular, but: >>> >>> IMO one of the advantages of the CW-based solution is that it is >>>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery >>>of BUN traffic. >>> >>> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>>and, in a more generic way, localization of effects of changes in the >>>PE configuration. >>> >>> In particular, adding a Leaf AC to a PE that previously has been only >>>supporting Root ACs (or vice versa), removal of the last Leaf or last >>>Root AC from a PE that previously has been supporting a mix etc. >>>affect only the PE where this operation happens and not the rest of the >>>PEs. >>> >>> As for the need for HW changes that have been mentioned as a main >>>disadvantage of the CW-based approach - I believe it strongly depends >>>on specific implementations. And some changes in the forwarding >>>process are required in any solution. >>> >>> My 2c, >>> Sasha >>> >>> >>> >>> ________________________________________ >>> From: l2vpn-bounces@ietf.org >>> [l2vpn-bounces@ietf.org] on behalf of >>> Rogers, Josh >>> [josh.rogers@twcable.com] >>> Sent: Wednesday, April 18, 2012 9:57 PM >>> To: Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: Re: The status of the approaches to the E-Tree solution? >>> >>> Again, the P2MP situation throws me. Is this something that is used >>> commonly? >>> >>> I'm under the impression that adding P2MP to any model results in a >>> more complex model. Wether outside s-tag is used to differentiate, >>> or dedicated pw's are used for the same purpose, it seems both become >>> more complex. >>> >>> Gile's comparison slide still concisely captures the differences >>>between these methods, in my opinion. I haven't seen any new ideas or >>>thoughts brought to the group in the past week or two on the subject. >>> I would hate for both proposed methods to die on the vine because we >>>couldn't decide between two methods that have nothing inherently wrong >>>with either. >>> >>> -Josh >>> >>> >>> On 4/18/12 1:53 PM, "Lucy yong" >>>> wrote: >>> >>>>Send this again. >>>> >>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>>double all of them. >>>> >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn >>>>[mailto:DanielC@orckit.com] >>>>Sent: Wednesday, April 18, 2012 1:42 PM >>>>To: Lucy yong; Rogers, Josh; Sam Cao >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>I think the first option its the natural way to go. How is the >>>>processing in this case more complex? >>>> >>>>Thumb typed - please be tolerant >>>> >>>>Lucy yong > wrote: >>>> >>>> >>>> >>>>Snipped.. >>>> >>>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only >>>>P2MP PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP >>>>PW (for traffic coming from a root AC) [[LY]] Not that simple. You >>>>construct either two P2MP PWs to all other PEs and let egress PE >>>>performing filtering, or construct one P2MP PW to leaf-only PEs and >>>>two P2MP PWs to root and leaf PEs and let ingress PE perform >>>>forwarding and filtering. Both make node process complex. >>>> >>>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>>>delivering the frames to remote PEs. We should utilize them with the >>>>minimized changes. Dual VLAN solution is simpler than Dual PW. >>>> >>>>Regards, >>>>Lucy >>>> >>>> >>>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>>>haven't had any first hand experience with P2MP PW's, however, so >>>>don't feel terribly strong about this objection. Is this a real >>>>problem for others (now or in the future), or is this objection in >>>>the weeds? >>>> >>>>I'm not sure the 'additional complexity' is notable, or even relevant. >>>>I encourage others to speak up if they disagree, as P2MP PW is only >>>>conceptual to me, and I am unfamiliar with real-life use cases for it. >>>> >>>>Thanks, >>>>Josh >>>> >>>> >>>> >>>>On 4/18/12 10:30 AM, "Lucy yong" >>>>> wrote: >>>> >>>>>Please see inline. >>>>> >>>>>-----Original Message----- >>>>>From: Sam Cao >>>>>[mailto:yuqun.cao@gmail.com] >>>>>Sent: Tuesday, April 17, 2012 7:14 AM >>>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>>>(Wim)'; giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>>>> >>>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>>>PE have both root and leaf AC and some only have leaf ACs)? >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Yuqun (Sam) Cao >>>>>E-mail: Yuqun.cao@gmail.com >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn >>>>>[mailto:DanielC@orckit.com] >>>>>Sent: Tuesday, April 17, 2012 4:56 PM >>>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com>; Sam Cao >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Adding Sam (as l2vpn@ is holding messages) >>>>> >>>>>DC >>>>> >>>>>-----Original Message----- >>>>>From: Lucy yong >>>>>[mailto:lucy.yong@huawei.com] >>>>>Sent: Tuesday, April 17, 2012 12:39 AM >>>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>> >>>>>Snipped, >>>>> >>>>>As we discussed extensively in the list, and as reflected in giles >>>>>slide, 2 pws are only needed between pes with both root and leaf >>>>>acs, which will typically be a small minority. >>>>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>>>both approaches can benefit from it. I was off for a while and >>>>>captures some discussions now. >>>>> >>>>>Also as per giles slide, dual vlan can have scalability issues due >>>>>to additional lookup and double use of vlans in internal emulated >>>>>lan interface. Also there are potential backward compatibility >>>>>issues with silicon that doesn't support vlan mapping. >>>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. >>>>>I am not clear on all the issues. Could you be more specific? As I >>>>>mentioned in below, two PW approach makes VPLS transport >>>>>construction and packet forwarding more complex, I can see potential >>>>>backward compatibility issues with 2 PW solution. >>>>> >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Daniel >>>>> >>>>>Thumb typed - please be tolerant >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>>In my mind, the VLAN approach means dual vlan method. >>>>> >>>>>The main concern for CW approach is hardware support. >>>>> >>>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and >>>>>unknown unicast traffic, and some P2MP PWs for multicast traffic. It >>>>>may double all of them. >>>>> >>>>>E-tree is an Ethernet service and there is already VLAN based >>>>>solution in IEEE, can we just utilize it without complicating VPLS >>>>>transport construction? This also makes interworking with Eth only >>>>>network easier. >>>>> >>>>>Cheers, >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: Rogers, Josh >>>>>[mailto:josh.rogers@twcable.com] >>>>>Sent: Monday, April 16, 2012 8:35 AM >>>>>To: Lucy yong; Henderickx, Wim (Wim); >>>>>'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com' ; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>I believe the initial question was in regard to the CW method. Are >>>>>you saying that you no longer are interested in that method in >>>>>preference of the dual vlan method? >>>>> >>>>> >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>> >>>>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>>>> >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: l2vpn-bounces@ietf.org >>>>>[mailto:l2vpn-bounces@ietf.org] On >>>>>Behalf Of Henderickx, Wim (Wim) >>>>>Sent: Thursday, April 12, 2012 2:03 AM >>>>>To: 'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com' ; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>The vlan approach is superior as it also works for eth only >>>>>networks, etc. On top some vendors indicate hw issues with the cw >>>>>approach. As such we have dropped more or less the cw approach. >>>>> >>>>>Cheers, >>>>>Wim >>>>>_________________ >>>>>sent from blackberry >>>>> >>>>>----- Original Message ----- >>>>>From: Giles Heron >>>>>[mailto:giles.heron@gmail.com] >>>>>Sent: Thursday, April 12, 2012 08:22 AM >>>>>To: Simon Delord >>>>>>; Alexander >>>>>Vainshtein >>>>>>>>>e >>>>>.com>> >>>>>Cc: l2vpn@ietf.org >>>>>>; Vladimir Kleiner >>>>>> ; >>>>>Andrew Sergeev >>>>>>; >>>>>Idan Kaspit >>>>>>; >>>>>Mishael Wexler >>>>>>; >>>>>Rotem Cohen >>>>>> >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>Sorry - the "anonymous presentation" was mine. I should possibly >>>>>have put in a third column on the CW approach. And hopefully the >>>>>minutes will be posted soon. >>>>> >>>>>We had various discussions, as Simon stated, and consensus seemed to >>>>>be forming around the two alternatives of two PWEs or two VLANs. I >>>>>believe three of the authors of the CW approach are also authors of >>>>>the two VLAN approach and one is also an author of the two PWE >>>>>approach. So perhaps it's best to let those four individuals say >>>>>which approach they prefer and why? >>>>> >>>>>Giles >>>>> >>>>>On 10/04/2012 00:45, "Simon Delord" >>>>>> wrote: >>>>> >>>>>> Hi Alexander, >>>>>> >>>>>> You are right, no discussion on the WG mailing list recently, but >>>>>> there have been substantial discussions among the authors of >>>>>> various solution drafts off the mailing list. As far as I know, no >>>>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>>>> meeting. I think the CW approach has not been rejected by the WG >>>>>> yet, or the WG has not yet decided on which one to adopt. >>>>>> >>>>>> Simon >>>>>> >>>>>> 2012/4/8 Alexander Vainshtein >>>>>> >>>>> e >>>>>> le.com>> >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>>>> >>>>>>> However, looking up the L2VPN proceedings, I've found a short >>>>>>> anonymous presentation called "E-Tree Update" ( >>>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>>>> This presentation discusses the differences of the E-Tree >>>>>>> approaches based on dedicated VLANs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw >>>>>>> / >>>>>>> ?in >>>>>>> clude_te >>>>>>> xt=3D1) >>>>>>> and completely ignores the solution based on usage of the CW in >>>>>>> the PWs connecting the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1 >>>>>>> ). >>>>>>> >>>>>>> >>>>>>> >>>>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>>>> I wonder whether the WG has taken a decision to reject the >>>>>>> approach based on the CW usage? I do not remember any recent >>>>>>> discussion of this topic on the WG mailing list. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, and lots of thanks in advance, >>>>>>> >>>>>>> Sasha >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This e-mail message is intended for the recipient only and >>>>>>> contains information which is CONFIDENTIAL and which may be >>>>>>> proprietary to ECI >>>>> >>>>>>> Telecom. If you have received this transmission in error, please >>>>>>> inform us by e-mail, phone or fax, and then delete the original >>>>>>> and all copies thereof. >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>>proprietary information, which is privileged, confidential, or >>>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>>intended solely for the use of the individual or entity to which it >>>>>is addressed. >>>>>If you are not the intended recipient of this E-mail, you are hereby >>>>>notified that any dissemination, distribution, copying, or action >>>>>taken in relation to the contents of and attachments to this E-mail >>>>>is strictly prohibited and may be unlawful. If you have received >>>>>this E-mail in error, please notify the sender immediately and >>>>>permanently delete the original and any copy of this E-mail and any >>>>>printout. >>>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or >>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>intended solely for the use of the individual or entity to which it >>>>is addressed. If you are not the intended recipient of this E-mail, >>>>you are hereby notified that any dissemination, distribution, >>>>copying, or action taken in relation to the contents of and >>>>attachments to this E-mail is strictly prohibited and may be >>>>unlawful. If you have received this E-mail in error, please notify >>>>the sender immediately and permanently delete the original and any >>>>copy of this E-mail and any printout. >>> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> This e-mail message is intended for the recipient only and contains >>>information which is CONFIDENTIAL and which may be proprietary to ECI >>>Telecom. If you have received this transmission in error, please >>>inform us by e-mail, phone or fax, and then delete the original and >>>all copies thereof. >>> >>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> L2vpn mailing list >>> L2vpn@ietf.org >>> https://www.ietf.org/mailman/listinfo/l2vpn >>> >>> >>> End of L2vpn Digest, Vol 95, Issue 25 >>> *********************************** > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 101 ************************************** From DanielC@orckit.com Mon Apr 30 07:32:19 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F6021F84D6 for ; Mon, 30 Apr 2012 07:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HS_INDEX_PARAM=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 Y26j7uj3zn4G for ; Mon, 30 Apr 2012 07:32:14 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA4521F845C for ; Mon, 30 Apr 2012 07:32:13 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: The status of the approaches to the E-Tree solution? Date: Mon, 30 Apr 2012 17:34:13 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130777C944@tlvmail1> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The status of the approaches to the E-Tree solution? Thread-Index: AQHNI1NEe/4Txq0Y50G6N17p5Mncd5atPrZAgAYGhwCAAA0B8IAAATpggAAAz9CAAAEdYIAABKrkgAAO+lCAAAwQgA== References: <44F4E579A764584EA9BDFD07D0CA08130777C912@tlvmail1> <14C7F4F06DB5814AB0DE29716C4F6D67023ECB0FE3@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> From: "Daniel Cohn" To: "Fedyk, Donald (Don)" , "Henderickx, Wim (Wim)" , , , Cc: l2vpn@ietf.org X-BeenThere: l2vpn@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, 30 Apr 2012 14:32:19 -0000 Hi Don, I was referring all the time to case 1). And Wim's e-mail clarified the mapping solution when he wrote that the S-VID space is reduced in half. Which confirms that S-VID preservation in the 2-VLAN solution is only supported with additional requirements - either constraining the S-VIDs supported to a reduced subset, or by using PBB (not sure I understand how PBB overcomes the previous limitation but let's leave it for another thread). Thanks, DC -----Original Message----- From: Fedyk, Donald (Don) [mailto:donald.fedyk@alcatel-lucent.com]=20 Sent: Monday, April 30, 2012 5:21 PM To: Henderickx, Wim (Wim); Daniel Cohn; 'lucy.yong@huawei.com'; 'jiangyuanlong@huawei.com'; 'josh.rogers@twcable.com' Cc: 'l2vpn@ietf.org' Subject: RE: The status of the approaches to the E-Tree solution? Hi Dan Let me try to explain. I think you are mixing the case 1) where there is a single core Etree and multiple S-VLANs multiplex on that tree with the case 2) where there are multiple core E-Trees one per S-VLAN. In case 1) You need to encapsulate. You encapsulate based on local context of Root or Leaf. The Core Etree though is the superset of the all the multiplexed E-Trees and would need to push on Ingress (in some form) the S-VID and Pop on egress (in some form) the S-VID. You can use a single Root S-VID(or other encapsulation ) and Single Leaf S-VID (or other encapsulation ) in the core. In case 2) You have a dedicated E-Tree per S-VLAN. On Ingress you translate based on local context of root or leaf but the mapping is 1:1 and on egress you translate back with 1:1. There are multiple S-VIDs per leaf and root as Wim points out the S-VID space is halved. Both cases use local service context to determine root /leaf behavior. The frame format differs in the two cases. (Data overhead varies) But the biggest difference in the two cases is whether or not you can prune the encapsulated tree within the core or only on the edge. If the core is transparent (can't internally prune) then the dedicated Etree case 2) is more efficient. If the core can do some form of DPI or other then Case 1 can also be data efficient. By data efficient I mean not sending frames to Edges only to be dumped. This matters because root to leaf data is often multicast. In the IEEE the S-VLAN and PBB forms are both case 2) 1:1 mapping on the edge (S-VID <-> S-VID(Root/Leaf) or S-VID<->I-SID (Root/Leaf)) from a service perspective. But PBB case also encapsulates with an outer single B-VLAN and in certain implementations can be made to be data efficient (for example with SPB). Hope that clears it up, Don -----Original Message----- From: Henderickx, Wim (Wim) Sent: Monday, April 30, 2012 8:54 AM To: 'DanielC@orckit.com'; 'lucy.yong@huawei.com'; 'jiangyuanlong@huawei.com'; Fedyk, Donald (Don); 'josh.rogers@twcable.com' Cc: 'l2vpn@ietf.org' Subject: Re: The status of the approaches to the E-Tree solution? The procedure halfs the s-vid space since you need 1 for root and one for leaf. If this is not enough pbb solves the issue. This is how ieee proposes this to work afaik. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, April 30, 2012 02:51 PM To: Henderickx, Wim (Wim); Lucy yong ; Jiangyuanlong ; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Can you explain this 1:1 relationship? Assuming any S-VID value can be received at any root or leaf AC, the S-VID that replaces it at the ingress PE must be such that the egress PE can recover the original S-VID plus the root/leaf ingress AC attribute. I don't see how this can be accomplished with the same number of bits. IOW, there needs to be a 1:1 mapping between 4094 S-VIDs in the root AC plus 4094 S-VIDs in a leaf AC to 4094 internal S-VIDs. I don't see how that is accomplished. What am I missing here? DC -----Original Message----- From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Monday, April 30, 2012 3:35 PM To: Daniel Cohn; Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? The internal S-VID which is pushed is popped/replaced with the original S-VID. Since they have a 1:1 relationship it is straightfwd. You need a mapping on ingress PE of the VPLS and on the egress PE. -----Original Message----- From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: maandag 30 april 2012 14:35 To: Henderickx, Wim (Wim); Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Because I still didn't see an explanation on how the egress PE knows which S-VID to push when sending the frame to the AC, if the original S-VID was popped at the ingress PE. Lucy answered that the egress PE " knows which S-VLAN ID is used on an AC", which seems to assume a single S-VLAN per root/leaf AC. So I still didn't get an answer to my question. Regards, DC -----Original Message----- From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Monday, April 30, 2012 3:27 PM To: Daniel Cohn; Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Daniel, as Don pointed out the 2-VLAN solution works also with multiple S-VLANS. I am not sure why we are going in circles on this? -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: maandag 30 april 2012 13:41 To: Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Yuanlong, So the 2-VLAN solution, for the S-VLAN tagged port, works only when there is a single S-VID per AC? Thanks, DC -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Wednesday, April 25, 2012 9:21 PM To: Fedyk, Donald (Don; Rogers, Josh Cc: l2vpn@ietf.org Subject: RE: The status of the approaches to the E-Tree solution? Hi Don and Josh, draft-jiang-l2vpn-vpls-pe-etree-05 discussed S-VLAN access in the following way: "... For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames received from the root ACs can be translated to the root S-VLAN in the VPLS network domain. Alternatively, the PBB VPLS PE model (where an IEEE 802.1ah bridge module is embedded in the PE) as described in [PBB-VPLS] can be used, and a root B-VLAN or leaf B-VLAN can be added in this case. In a similar way, the traffic from the leaf ACs is tagged and transported on the leaf C-VLAN, S-VLAN or B-VLAN. " It seems option B is in line with the 1st sentence, not sure where option A came from, but do you have any concerns with the description in the 2nd sentence? Regards, Yuanlong ---------------------------------------------------------------------- Date: Wed, 25 Apr 2012 18:52:50 -0500 From: "Fedyk, Donald (Don)" To: "Rogers, Josh" , David Allan I , Daniel Cohn , "l2vpn@ietf.org" Subject: RE: The status of the approaches to the E-Tree solution? Message-ID: Content-Type: text/plain; charset=3D"us-ascii" Hi Josh Is there a draft that describes solution A? Solution B is what I've seen in the IEEE. One argument is that A is adding an extra TAG that offers little value. The TAG you have labeled 2 may need to be swapped anyway. Stacking S-TAGs is why PBB was developed. Cheers, Don -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Wednesday, April 25, 2012 7:22 PM To: David Allan I; Fedyk, Donald (Don); Daniel Cohn; l2vpn@ietf.org Subject: Re: The status of the approaches to the E-Tree solution? > Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. I have to apologize, because I think I led y'all down that path (I referred to the outermost tag, the same tag that the MPLS psuedowire is using for vlan mode encamp, as the S-Tag, even though the customer is the one placing it on the frame. Same as I described below, but I either used term S-Tag incorrectly, or ambiguously. >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... So, I think this could be cleared up some still. What I was referring to is the VID that the customer is using to put frames in, the VID which they should use to ensure the frame goes into the correct ETREE instance. You drew a distinction between 'customer VID' vs 'provider VID', but since it is negotiated, I haven't really seen a distinction, which I think is what has caused all the confusion. In the two discussion points/solutions I mentioned, the first one, "A", describes both a coordinated VID which the customer should use, and the service provider uses to distinguish between services on the same UNI, as well as a second, outer, VID which is used by the SP to determine the source AC type. In my example, if you were to sniff inside the psuedowire between PE1 and PE2 to see CE2 destined traffic, wish solution A, you might see "4001:2:Payload", where 4001 designates it is from a root AC, 2 designates the ETREE instance, and Payload is the customer's traffic (which may include a C-Tag), where with solution B, you would see "4001:Payload", and VID 2 would have to be swapped for 4001 as it enters the PE2-CE2 AC, giving the customer "2:Payload" just as they sent it (alternatively SP may choose to simply drop tag entirely and provide "Payload" to customer, this can cause problems with PVST on some devices, but I still see it done occasionally) ** Note, for the example above, I'm assuming 4001 is used as a 'standard' for root sourced frames, and 4002 is used for leaf sourced frames, for the ETREE R/L tags. Have I undone the confusion, or made it worse? -Josh On 4/25/12 5:19 PM, "David Allan I" wrote: >Yes, if the discussion was options on preserving CUSTOMER tag >information, we did march off on a tangent. > >Now I hate to be pedantic but when you wrote: >"The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf)" > >I presume you meant "the customer VID is coordinated with the provider", >"Not the service VID that is coordinated with the customer". The customer >tag infers the ETREE instance for a VID based UNI. And the customer does >not need to know the provider ETREE VIDs....the provider needs to know >what tags the customer wants mapped to specific provider services.... > >Cheers >Dave > > > > >-----Original Message----- >From: Rogers, Josh [mailto:josh.rogers@twcable.com] >Sent: Wednesday, April 25, 2012 5:42 PM >To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; l2vpn@ietf.org >Subject: Re: The status of the approaches to the E-Tree solution? > >Dave/Daniel/Lucy/Others Debating how many tags necessary when S-Tag >preservation is desired, > > >I think you all may have gone off on a tangent here. The original >discussion was about how to deal with the situation where the S-Tag is >preserved at a handoff (either an ENNI, or Service Multiplexed UNI) > >I believe there were two suggestions, one was that you push on a 'ETREE' >tag (one of two values, for either a frame sourced from a root AC or >another for a frame from a leaf AC), and the second solution was to 'map'. > > >Imagine the following topology: > >+-----+ +-----+ +-----+ +-----+ >| CE1 |--| PE1 |--| PE2 |--| CE2 | >+-----+ +-----+ +-----+ +-----+ > | | >+-----+ +-----+ +-----+ +-----+ >| CE3 |--| PE3 |--| PE4 |--| CE4 | >+-----+ +-----+ +-----+ +-----+ > >Where: > >Site Type VLAN >CE1 Root X >CE2 Leaf 2 >CE3 Leaf 3 >CE4 Leaf 3 > > >So, there are a lot of SP's who are keen on the way many services can be >handed to a customer on a single UNI, but coordinating a single VLAN per >service, with the customer (MEF used to call this EVPL when it was many >point to point services terminating on a single UNI). So, imagine that >we have two ETREE instances, and an internet service all terminating on a >single UNI connecting to CE1. We have negotiated VLAN ID's with the >customer, and they are expecting to reach CE2 using VLAN 2, CE3 and CE4 >using VLAN 3, and Internet service on VLAN 10. As a frame from CE1 comes >into PE1 destined for CE2 (so the customer has tagged it with VID 2), >using the 2VLAN method, since this is coming from a root site, do we > >a) place the Root S-Tag in front of VID 2, then ship it across, and pop >off the ETREE S-Tag (some SP's wish to Pop the original customer tag VID >2 as well) > >-or- > >b) swap VID2 for the ETREE Root S-Tag, send the frame to PE2 where it >will remove the S-Tag (and either push VID2 back on, or leave it off >depending on SP preference) > >The reference to 'double tagging' was talking about solution A above, >since there is both the service VID that is coordinated with the >customer, as well as the Etree VID which designates the source (root or >leaf) > > >Hope that clears more than it confuses, >Josh > > > >On 4/25/12 4:22 PM, "Fedyk, Donald (Don)" > wrote: > >>Hi Dave >> >>Yes the only point I would add is Dual VLAN means One VID for Root and >>one VID for Leaf. Not two TAGs at a time on the frame but two allocated >>for the service. >> >>The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks >>about Encapsulation Overhead as a VLAN Tag. While that is true in a PWE >>sense it is still a single VLAN Tag at a time in a Ethernet E-tree sense. >> The compelling driver for Dual VLAN is having a Etree service that >>works in many environments and the DUAL VLAN (really dual VLAN >>interface on a >>VSI) uses the same mechanism (one VID for root and one VID for Leaf at >>a >>time) as specified in the IEEE. In a pure Ethernet bridging world the >>VLAN TAGs for Etree are not typically an overhead since translation is >>used. >> >>Don >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of David Allan I >>Sent: Wednesday, April 25, 2012 5:05 PM >>To: Daniel Cohn; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>OK I feel like I am digressing a fair distance from the actual >>problem.... But here goes: >> >>So the scenarios center around "how ETREE do you want to be?".... >> >>If the ACs are root/leaf, then if they are P2P (single ethernet end >>station attached to each AC) this is moot. ETREE semantics are enforced >>by the 2VID domain in the center of the example. If you assumed nodes >>A&B in the example were L2VPN PEs, the tagging and the PW tag >>imposition all happened at the same point in the network. >> >>If they are not simple P2P all the way to end systems and the objective >>is to avoid bridging between leaf "sites" but allowing intra-leaf-site >>connectivity then the leaves can be LANs but the root is not, such that >>I cannot bridge through the root. But all hosts at a given leaf site >>can see each other. So root Ethernet end systems are directly attached >>or two VIDs are used in the root site. >> >>If the objective is that there are multiple ethernet attached end >>stations at both the leaf and root sites, and the objective is to >>enforce >>L2 isolation everywhere then I need two VIDs extended to the end system >>attachement point in the local LANs by whatever means.... >> >>And I do not see adding VLANs in any particular spot, simply selection >>of the VID and associated semantics where VIDs are translated. The >>actual point of S-tag imposition could be a PE, or cloud be a NID/CLE >>on the customer prem (more likely scenario here to extend OAM demarc to >>the prem), or some switch in a RAN downstream of the MPLS PE... blah >>blah blah. And if ETREE is extended into a customer site LAN and >>outside of the provider domain, then two C-tags would have to be used >>that mapped to S-tags at the PBN boundary... >> >>Make sense? >>Dave >> >>-----Original Message----- >>From: Daniel Cohn [mailto:DanielC@orckit.com] >>Sent: Wednesday, April 25, 2012 4:39 PM >>To: David Allan I; l2vpn@ietf.org >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Dave, but the ACs are root/leaf (that's what the whole vpls etree is >>about - see the reqt draft), so per the 2vlan draft the root/leaf vlan >>must be added. >> >>Thumb typed - please be tolerant >> >>David Allan I wrote: >> >>HI Daniel: >> >>In the example provided, >> >>"ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID" >> A B >> >>the service is not ETREE in the domains of the ingress and egress VID. >>It is ELAN. SO there is no root/leaf attribute to shovel around. It >>would require two VIDs in each domain if the ETREE semantics were to be >>telescoped E2E. >> >>Otherwise it is a provisioning of the VID translation tables at the >>intermediate nodes (A&B that I've added to the picture) that would >>determine the VID values used in each domain. Or in the example above, >>what the ingress, Etree and egress VID values were. >> >>Cheers >>Dave >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 3:46 PM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>And to this I asked how this mapping works - how does the egress pe >>recover the ingress vid when it gets the frame tagged with only the >>root/leaf vid? How can you convey the ingress vid plus the root/leaf >>attribute in the same number of bits? >>What am I missing? >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>David Allen already explained the solution. >> >>From David: >>ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID. >> >>Ingress VID does not have to equal Egress VID but regardless there is >>only ever one VID on a frame at a time. >> >>-end >> >>This works when customer makes ingress VLAN ID not equal to or equal to >>egress VLAN ID. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Wednesday, April 25, 2012 11:39 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi Lucy, >> >>The scenario we are discussing is not the E-Tree E-NNI, but a general >>scenario where frames arriving at the root or leaf AC are already >>double tagged. In this case, the dual vlan solution cannot preserve the >>vlans without adding a third one, can it? >> >>Maybe Shahram can add details on the scenario he had in mind >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has S-VLAN preservation attribute for ENNI only because there is no >>s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN >>preservation attribute is used. It applies to E-Tree as well. >> >>Regards, >>Lucy >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Tuesday, April 24, 2012 2:12 AM >>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; >>l2vpn@ietf.org; Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Lucy, >> >>even if the current MEF framework doesn't require s-vlan preservation, >>I believe it's to the industry's benefit to adopt a solution that is >>not constrained to a specific enni model that, like all things >>networking, is likely to evolve. Especially when such a solution is >>available. >> >>Daniel >> >>Thumb typed - please be tolerant >> >>Lucy yong wrote: >> >>Daniel, >> >>MEF has worked in ENNI interface for a long time with many service >>providers' inputs. It had a fair reason to assume S-VLAN over ENNI by >>then. It may open B-VLAN for the future. It is better for us not to >>discuss a future framework here, because it will lead us to nowhere. >>Here, we want to extend VPLS in supporting E-Tree. >> >>Best Regards, >>Lucy >> >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>Of Daniel Cohn >>Sent: Sunday, April 22, 2012 7:34 AM >>To: Rogers, Josh; Shahram Davari; Lizhong Jin; l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Shahram and all, >> >>This question already came up in our discussions - is it safe to assume >>that the VLAN tags at the E-NNI will always be according to the current >>MEF model? Or should we try to be as transparent as possible to user >>VLAN encapsulation at the E-NNI, to accommodate future frameworks? >>I believe that any approach that looks at user payload (in this case >>VLAN >>tag) to signal VPLS information (in this case root/leaf origin) is >>necessarily tied to specific assumptions on user payload encapsulation >>(in this case, that S-VLAN tag is "available" to encode root/leaf). I >>don't think this is a future-proof assumption, it's very likely that >>other network models will come up that require S-VLAN preservation, >>which in the 2-VLAN approach would necessitate adding a third VLAN-ID. >> >>Daniel >> >>From: Shahram Davari > >>To: Lizhong Jin >, >>"l2vpn@ietf.org" >>>, >>"Alexander.Vainshtein@ecitele.com>om> >>" >>>om> >>> >>Cc: "yuqun.cao@gmail.com" >>> >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, >> >>I also have a question regarding 2-VLAN. What if the customer traffic >>already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R? >> >>Thx >>Shahram >> >>From: l2vpn-bounces@ietf.org >>[mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin >>Sent: Friday, April 20, 2012 9:38 AM >>To: l2vpn@ietf.org; >>Alexander.Vainshtein@ecitele.com>m> >>Cc: yuqun.cao@gmail.com >>Subject: RE: The status of the approaches to the E-Tree solution? >> >>Hi, all, >>The difference between 2-VLAN and CW approach is who will provide the >>R/L information, customer payload or PW? The customer payload will be >>always modified to carry R/L information in 2-VLAN approach, while PW >>with CW will carry R/L information for CW approach. >>I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is >>accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is >>used to access H-VPLS, how could the PE on VPWS side adds VLAN to >>indicate R/L information? >> >>Thanks >>Lizhong >> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Thu, 19 Apr 2012 04:38:36 +0000 >>> From: Alexander Vainshtein >>> >> com>> >>> To: "Rogers, Josh" >>>>, Lucy yong >>> >, Daniel >>>Cohn >, Sam Cao >>> > >>> Cc: "l2vpn@ietf.org" >>> > >>> Subject: RE: The status of the approaches to the E-Tree solution? >>> Message-ID: >>> >>> >> t o:F9336571731ADE42A5397FC831CEAA02034192@FRIDWPPMB002.ecitele.com>> >>> Content-Type: text/plain; charset=3D"us-ascii" >>> >>> Hi all, >>> I fully understand that that what I am going to say is not very >>>popular, but: >>> >>> IMO one of the advantages of the CW-based solution is that it is >>>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery >>>of BUN traffic. >>> >>> Another advantage is preservation of full mesh of P2P PWs in a VPLS, >>>and, in a more generic way, localization of effects of changes in the >>>PE configuration. >>> >>> In particular, adding a Leaf AC to a PE that previously has been only >>>supporting Root ACs (or vice versa), removal of the last Leaf or last >>>Root AC from a PE that previously has been supporting a mix etc. >>>affect only the PE where this operation happens and not the rest of the >>>PEs. >>> >>> As for the need for HW changes that have been mentioned as a main >>>disadvantage of the CW-based approach - I believe it strongly depends >>>on specific implementations. And some changes in the forwarding >>>process are required in any solution. >>> >>> My 2c, >>> Sasha >>> >>> >>> >>> ________________________________________ >>> From: l2vpn-bounces@ietf.org >>> [l2vpn-bounces@ietf.org] on behalf of >>> Rogers, Josh >>> [josh.rogers@twcable.com] >>> Sent: Wednesday, April 18, 2012 9:57 PM >>> To: Lucy yong; Daniel Cohn; Sam Cao >>> Cc: l2vpn@ietf.org >>> Subject: Re: The status of the approaches to the E-Tree solution? >>> >>> Again, the P2MP situation throws me. Is this something that is used >>> commonly? >>> >>> I'm under the impression that adding P2MP to any model results in a >>> more complex model. Wether outside s-tag is used to differentiate, >>> or dedicated pw's are used for the same purpose, it seems both become >>> more complex. >>> >>> Gile's comparison slide still concisely captures the differences >>>between these methods, in my opinion. I haven't seen any new ideas or >>>thoughts brought to the group in the past week or two on the subject. >>> I would hate for both proposed methods to die on the vine because we >>>couldn't decide between two methods that have nothing inherently wrong >>>with either. >>> >>> -Josh >>> >>> >>> On 4/18/12 1:53 PM, "Lucy yong" >>>> wrote: >>> >>>>Send this again. >>>> >>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown >>>>unicast traffic, and some P2MP PWs for multicast traffic. It may >>>>double all of them. >>>> >>>>Lucy >>>> >>>>-----Original Message----- >>>>From: Daniel Cohn >>>>[mailto:DanielC@orckit.com] >>>>Sent: Wednesday, April 18, 2012 1:42 PM >>>>To: Lucy yong; Rogers, Josh; Sam Cao >>>>Cc: l2vpn@ietf.org >>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>> >>>>I think the first option its the natural way to go. How is the >>>>processing in this case more complex? >>>> >>>>Thumb typed - please be tolerant >>>> >>>>Lucy yong > wrote: >>>> >>>> >>>> >>>>Snipped.. >>>> >>>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only >>>>P2MP PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP >>>>PW (for traffic coming from a root AC) [[LY]] Not that simple. You >>>>construct either two P2MP PWs to all other PEs and let egress PE >>>>performing filtering, or construct one P2MP PW to leaf-only PEs and >>>>two P2MP PWs to root and leaf PEs and let ingress PE perform >>>>forwarding and filtering. Both make node process complex. >>>> >>>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for >>>>delivering the frames to remote PEs. We should utilize them with the >>>>minimized changes. Dual VLAN solution is simpler than Dual PW. >>>> >>>>Regards, >>>>Lucy >>>> >>>> >>>>I see how 2VLAN is simpler when P2MP PW's are involved, I think. I >>>>haven't had any first hand experience with P2MP PW's, however, so >>>>don't feel terribly strong about this objection. Is this a real >>>>problem for others (now or in the future), or is this objection in >>>>the weeds? >>>> >>>>I'm not sure the 'additional complexity' is notable, or even relevant. >>>>I encourage others to speak up if they disagree, as P2MP PW is only >>>>conceptual to me, and I am unfamiliar with real-life use cases for it. >>>> >>>>Thanks, >>>>Josh >>>> >>>> >>>> >>>>On 4/18/12 10:30 AM, "Lucy yong" >>>>> wrote: >>>> >>>>>Please see inline. >>>>> >>>>>-----Original Message----- >>>>>From: Sam Cao >>>>>[mailto:yuqun.cao@gmail.com] >>>>>Sent: Tuesday, April 17, 2012 7:14 AM >>>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim >>>>>(Wim)'; giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Yes, 2 pws are only needed between pes with both root and leaf acs >>>>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach >>>>>setup 2 P2MP PWs if need. There is no difference between P2MP or >>>>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW? >>>>> >>>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with >>>>>both root and leaf ACs set up two or one P2MP PW to other PEs (some >>>>>PE have both root and leaf AC and some only have leaf ACs)? >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Yuqun (Sam) Cao >>>>>E-mail: Yuqun.cao@gmail.com >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Daniel Cohn >>>>>[mailto:DanielC@orckit.com] >>>>>Sent: Tuesday, April 17, 2012 4:56 PM >>>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com>; Sam Cao >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>Adding Sam (as l2vpn@ is holding messages) >>>>> >>>>>DC >>>>> >>>>>-----Original Message----- >>>>>From: Lucy yong >>>>>[mailto:lucy.yong@huawei.com] >>>>>Sent: Tuesday, April 17, 2012 12:39 AM >>>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim); >>>>>giles.heron@gmail.com; >>>>>simon.delord@gmail.com; >>>>>Alexander.Vainshtein@ecitele.com>>>>com> >>>>>Cc: l2vpn@ietf.org; >>>>>Vladimir.Kleiner@ecitele.com; >>>>>Andrew.Sergeev@ecitele.com; >>>>>Idan.Kaspit@ecitele.com; >>>>>Mishael.Wexler@ecitele.com; >>>>>Rotem.Cohen@ecitele.com >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>> >>>>>Snipped, >>>>> >>>>>As we discussed extensively in the list, and as reflected in giles >>>>>slide, 2 pws are only needed between pes with both root and leaf >>>>>acs, which will typically be a small minority. >>>>>[[LY]] Don't know if the assumption is true. Even it is the case, >>>>>both approaches can benefit from it. I was off for a while and >>>>>captures some discussions now. >>>>> >>>>>Also as per giles slide, dual vlan can have scalability issues due >>>>>to additional lookup and double use of vlans in internal emulated >>>>>lan interface. Also there are potential backward compatibility >>>>>issues with silicon that doesn't support vlan mapping. >>>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. >>>>>I am not clear on all the issues. Could you be more specific? As I >>>>>mentioned in below, two PW approach makes VPLS transport >>>>>construction and packet forwarding more complex, I can see potential >>>>>backward compatibility issues with 2 PW solution. >>>>> >>>>>Regards, >>>>>Lucy >>>>> >>>>>Regards, >>>>> >>>>>Daniel >>>>> >>>>>Thumb typed - please be tolerant >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>>In my mind, the VLAN approach means dual vlan method. >>>>> >>>>>The main concern for CW approach is hardware support. >>>>> >>>>>Two PW approach can be complex too if the VPLS instance for E-Tree >>>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and >>>>>unknown unicast traffic, and some P2MP PWs for multicast traffic. It >>>>>may double all of them. >>>>> >>>>>E-tree is an Ethernet service and there is already VLAN based >>>>>solution in IEEE, can we just utilize it without complicating VPLS >>>>>transport construction? This also makes interworking with Eth only >>>>>network easier. >>>>> >>>>>Cheers, >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: Rogers, Josh >>>>>[mailto:josh.rogers@twcable.com] >>>>>Sent: Monday, April 16, 2012 8:35 AM >>>>>To: Lucy yong; Henderickx, Wim (Wim); >>>>>'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com' ; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: RE: The status of the approaches to the E-Tree solution? >>>>> >>>>>I believe the initial question was in regard to the CW method. Are >>>>>you saying that you no longer are interested in that method in >>>>>preference of the dual vlan method? >>>>> >>>>> >>>>> >>>>>Lucy yong > wrote: >>>>> >>>>> >>>>>Agree with Wim. VLAN approach is the best solution for E-Tree. >>>>> >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: l2vpn-bounces@ietf.org >>>>>[mailto:l2vpn-bounces@ietf.org] On >>>>>Behalf Of Henderickx, Wim (Wim) >>>>>Sent: Thursday, April 12, 2012 2:03 AM >>>>>To: 'giles.heron@gmail.com'; >>>>>'simon.delord@gmail.com'; >>>>>'Alexander.Vainshtein@ecitele.com>>>>e.c >>>>>om>' >>>>>Cc: 'l2vpn@ietf.org'; >>>>>'Vladimir.Kleiner@ecitele.com' ; >>>>>'Andrew.Sergeev@ecitele.com'; >>>>>'Idan.Kaspit@ecitele.com'; >>>>>'Mishael.Wexler@ecitele.com'; >>>>>'Rotem.Cohen@ecitele.com' >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>The vlan approach is superior as it also works for eth only >>>>>networks, etc. On top some vendors indicate hw issues with the cw >>>>>approach. As such we have dropped more or less the cw approach. >>>>> >>>>>Cheers, >>>>>Wim >>>>>_________________ >>>>>sent from blackberry >>>>> >>>>>----- Original Message ----- >>>>>From: Giles Heron >>>>>[mailto:giles.heron@gmail.com] >>>>>Sent: Thursday, April 12, 2012 08:22 AM >>>>>To: Simon Delord >>>>>>; Alexander >>>>>Vainshtein >>>>>>>>>e >>>>>.com>> >>>>>Cc: l2vpn@ietf.org >>>>>>; Vladimir Kleiner >>>>>> ; >>>>>Andrew Sergeev >>>>>>; >>>>>Idan Kaspit >>>>>>; >>>>>Mishael Wexler >>>>>>; >>>>>Rotem Cohen >>>>>> >>>>>Subject: Re: The status of the approaches to the E-Tree solution? >>>>> >>>>>Sorry - the "anonymous presentation" was mine. I should possibly >>>>>have put in a third column on the CW approach. And hopefully the >>>>>minutes will be posted soon. >>>>> >>>>>We had various discussions, as Simon stated, and consensus seemed to >>>>>be forming around the two alternatives of two PWEs or two VLANs. I >>>>>believe three of the authors of the CW approach are also authors of >>>>>the two VLAN approach and one is also an author of the two PWE >>>>>approach. So perhaps it's best to let those four individuals say >>>>>which approach they prefer and why? >>>>> >>>>>Giles >>>>> >>>>>On 10/04/2012 00:45, "Simon Delord" >>>>>> wrote: >>>>> >>>>>> Hi Alexander, >>>>>> >>>>>> You are right, no discussion on the WG mailing list recently, but >>>>>> there have been substantial discussions among the authors of >>>>>> various solution drafts off the mailing list. As far as I know, no >>>>>> consensus yet before ietf83, not sure the progress in the Paris WG >>>>>> meeting. I think the CW approach has not been rejected by the WG >>>>>> yet, or the WG has not yet decided on which one to adopt. >>>>>> >>>>>> Simon >>>>>> >>>>>> 2012/4/8 Alexander Vainshtein >>>>>> >>>>> e >>>>>> le.com>> >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Unfortunately I have not been able to attend the Paris IETF. >>>>>>> >>>>>>> However, looking up the L2VPN proceedings, I've found a short >>>>>>> anonymous presentation called "E-Tree Update" ( >>>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx). >>>>>>> This presentation discusses the differences of the E-Tree >>>>>>> approaches based on dedicated VLANs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1) and multiple PWs between the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw >>>>>>> / >>>>>>> ?in >>>>>>> clude_te >>>>>>> xt=3D1) >>>>>>> and completely ignores the solution based on usage of the CW in >>>>>>> the PWs connecting the PEs (as in >>>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?inclu >>>>>>> d >>>>>>> e_t >>>>>>> ext=3D1 >>>>>>> ). >>>>>>> >>>>>>> >>>>>>> >>>>>>> The Minutes of the Paris L2VPN session are not yet available, but >>>>>>> I wonder whether the WG has taken a decision to reject the >>>>>>> approach based on the CW usage? I do not remember any recent >>>>>>> discussion of this topic on the WG mailing list. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, and lots of thanks in advance, >>>>>>> >>>>>>> Sasha >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This e-mail message is intended for the recipient only and >>>>>>> contains information which is CONFIDENTIAL and which may be >>>>>>> proprietary to ECI >>>>> >>>>>>> Telecom. If you have received this transmission in error, please >>>>>>> inform us by e-mail, phone or fax, and then delete the original >>>>>>> and all copies thereof. >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>>proprietary information, which is privileged, confidential, or >>>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>>intended solely for the use of the individual or entity to which it >>>>>is addressed. >>>>>If you are not the intended recipient of this E-mail, you are hereby >>>>>notified that any dissemination, distribution, copying, or action >>>>>taken in relation to the contents of and attachments to this E-mail >>>>>is strictly prohibited and may be unlawful. If you have received >>>>>this E-mail in error, please notify the sender immediately and >>>>>permanently delete the original and any copy of this E-mail and any >>>>>printout. >>>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or >>>>subject to copyright belonging to Time Warner Cable. This E-mail is >>>>intended solely for the use of the individual or entity to which it >>>>is addressed. If you are not the intended recipient of this E-mail, >>>>you are hereby notified that any dissemination, distribution, >>>>copying, or action taken in relation to the contents of and >>>>attachments to this E-mail is strictly prohibited and may be >>>>unlawful. If you have received this E-mail in error, please notify >>>>the sender immediately and permanently delete the original and any >>>>copy of this E-mail and any printout. >>> >>> >>> This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to copyright belonging to Time Warner Cable. This E-mail is intended >>>solely for the use of the individual or entity to which it is addressed. >>>If you are not the intended recipient of this E-mail, you are hereby >>>notified that any dissemination, distribution, copying, or action >>>taken in relation to the contents of and attachments to this E-mail is >>>strictly prohibited and may be unlawful. If you have received this >>>E-mail in error, please notify the sender immediately and permanently >>>delete the original and any copy of this E-mail and any printout. >>> This e-mail message is intended for the recipient only and contains >>>information which is CONFIDENTIAL and which may be proprietary to ECI >>>Telecom. If you have received this transmission in error, please >>>inform us by e-mail, phone or fax, and then delete the original and >>>all copies thereof. >>> >>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> L2vpn mailing list >>> L2vpn@ietf.org >>> https://www.ietf.org/mailman/listinfo/l2vpn >>> >>> >>> End of L2vpn Digest, Vol 95, Issue 25 >>> *********************************** > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 95, Issue 101 ************************************** From lucy.yong@huawei.com Mon Apr 30 08:41:53 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE3921F8702 for ; Mon, 30 Apr 2012 08:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] 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 7mimubEDlyHh for ; Mon, 30 Apr 2012 08:41:52 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id F018721F86FF for ; Mon, 30 Apr 2012 08:41:51 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFS23295; Mon, 30 Apr 2012 11:41:51 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Apr 2012 08:38:57 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Mon, 30 Apr 2012 08:38:52 -0700 From: Lucy yong To: John E Drake , Mach Chen , Giles Heron , "l2vpn@ietf.org" Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAAcwK+MAAEDOFg Date: Mon, 30 Apr 2012 15:38:51 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDE9C5@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A56EEDE9C5@EMBX01-HQ.jnpr.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.14] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@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, 30 Apr 2012 15:41:53 -0000 John, IS-IS VPLS is completely different from TRILL and SPB although they all use= of IS-IS protocol in control plane. IS-IS VPLS data plane uses an IP/GRE t= unnel carrying VPN instances differentiated by MPLS labels. TRILL and SPB d= ata planes are Ethernet based, i.e. the frames are Ethernet frames. Isn't it good that one control plane protocol can apply to different data p= lanes?=20 I agree that VPLS has been well defined and used in Service Provider networ= ks. IS-IS VPLS provides the simplified version of VPLS that can apply to da= ta center networks. This may be better than developing something completely= new in data center.=20 Maybe we need consider another name for this, for example DC-VPN? In data c= enter, an VPN is not necessary to provide a service to an customer, the inf= rastructure need VPN capability. =20 Regards, Lucy=20 -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Monday, April 30, 2012 8:12 AM To: Mach Chen; Lucy yong; Giles Heron; l2vpn@ietf.org Subject: RE: Interest in IS-IS VPLS We already have TRILL and SPB. Why is yet another IS-IS variant necessary,= particularly one that is so completely under-specified?=20 Sent from my iPhone > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Mach Chen > Sent: Saturday, April 28, 2012 3:04 AM > To: Lucy yong; Giles Heron; l2vpn@ietf.org > Subject: RE: Interest in IS-IS VPLS >=20 > Fully agree with lucy here. >=20 > In addition, since the ISIS VPLS leverages a uniform protocol(ISIS) for > signaling and auto discovery, it would greatly simplify the deployment > and maintenance, especially for the DC networks that have already > deployed ISIS for IP routing. So I'd like to see the draft moving > forward. >=20 > Best regards, > Mach >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > > Of Lucy yong > > Sent: Saturday, April 28, 2012 2:43 AM > > To: Giles Heron; l2vpn@ietf.org > > Subject: RE: Interest in IS-IS VPLS > > > > Hi Giles, > > > > It seems that the IS-IS VPLS provides the solution for a scalable > data > > center network as mentioned in the draft. I am not sure it is proper > > to weight service providers more on this. I can see if a service > > provider already deployed existing VPLS, the gain from IS-IS VPLS is > > less than the cost on upgrading all the edge devices to support the > solution. > > > > However, for data center network, IS-IS VPLS could be a useful > > solution. It simplifies current VPLS mechanism, provides a good > > scalability, and requires IP only function on core switches. > > > > A vendor provides devices for both service provider network and data > > center network, the solution brings a synergy in leveraging VPLS > > solution into DC. > > > > Thus, I like to see this work moving forward. > > > > Regards, > > Lucy > > > > > > > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > > Of Giles Heron > > Sent: Friday, April 27, 2012 7:57 AM > > To: l2vpn@ietf.org > > Subject: Interest in IS-IS VPLS > > > > Hi, > > > > At the IETF meeting in Paris I took an action (as noted in the > > minutes) to poll the WG to see if there was any interest (other than > > by the authors of > > course) in progressing the IS-IS VPLS draft. > > > > Would you please respond to this email indicating whether or not you > > have interest in seeing this draft progress, ideally giving reasoning > > for your position. It'd be especially interesting to see responses > > from service providers of course. > > > > If there are no (or very few) responses to this email then Nabil and > I > > will probably interpret that as meaning there's insufficient interest > > to progress. Of course it may just mean that you all missed this > > email in the deluge of debate on E-Tree ;) > > > > Giles > > From jdrake@juniper.net Mon Apr 30 09:11:55 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771F821F8664 for ; Mon, 30 Apr 2012 09:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 UiBOyhzcbqCd for ; Mon, 30 Apr 2012 09:11:54 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 72E3821F8630 for ; Mon, 30 Apr 2012 09:11:54 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKT565xx+1PClXnD/aFJGGauy0qnxJG0hv@postini.com; Mon, 30 Apr 2012 09:11:54 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 30 Apr 2012 09:10:54 -0700 From: John E Drake To: Lucy yong , Mach Chen , Giles Heron , "l2vpn@ietf.org" Date: Mon, 30 Apr 2012 09:10:52 -0700 Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAAcwK+MAAEDOFgAAHPUXA= Message-ID: <5E893DB832F57341992548CDBB333163A56EEDEB30@EMBX01-HQ.jnpr.net> References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDE9C5@EMBX01-HQ.jnpr.net> <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> 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-BeenThere: l2vpn@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, 30 Apr 2012 16:11:55 -0000 Lucy, Comments inline. Thanks, John Sent from my iPhone > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Monday, April 30, 2012 8:39 AM > To: John E Drake; Mach Chen; Giles Heron; l2vpn@ietf.org > Subject: RE: Interest in IS-IS VPLS >=20 > John, >=20 > IS-IS VPLS is completely different from TRILL and SPB although they all > use of IS-IS protocol in control plane. IS-IS VPLS data plane uses an > IP/GRE tunnel carrying VPN instances differentiated by MPLS labels. > TRILL and SPB data planes are Ethernet based, i.e. the frames are > Ethernet frames. JD: From what I understand, both TRILL and SP can be used to provide the s= ame capabilities as IS-IS VPLS and they both exist today. =20 >=20 > Isn't it good that one control plane protocol can apply to different > data planes? JD: This is a rhetorical question, right? >=20 > I agree that VPLS has been well defined and used in Service Provider > networks. IS-IS VPLS provides the simplified version of VPLS that can > apply to data center networks. This may be better than developing > something completely new in data center. JD: Just because it has 'VPLS' in its name does not mean it isn't new. I = agree that we don't want to develop anything new for the data center, and t= hat therefore, IS-IS VPLS is a non-starter. >=20 > Maybe we need consider another name for this, for example DC-VPN? In > data center, an VPN is not necessary to provide a service to an > customer, the infrastructure need VPN capability. JD: This sounds like a tautology. >=20 > Regards, > Lucy >=20 >=20 >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Monday, April 30, 2012 8:12 AM > To: Mach Chen; Lucy yong; Giles Heron; l2vpn@ietf.org > Subject: RE: Interest in IS-IS VPLS >=20 > We already have TRILL and SPB. Why is yet another IS-IS variant > necessary, particularly one that is so completely under-specified? >=20 > Sent from my iPhone >=20 >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > > Of Mach Chen > > Sent: Saturday, April 28, 2012 3:04 AM > > To: Lucy yong; Giles Heron; l2vpn@ietf.org > > Subject: RE: Interest in IS-IS VPLS > > > > Fully agree with lucy here. > > > > In addition, since the ISIS VPLS leverages a uniform protocol(ISIS) > > for signaling and auto discovery, it would greatly simplify the > > deployment and maintenance, especially for the DC networks that have > > already deployed ISIS for IP routing. So I'd like to see the draft > > moving forward. > > > > Best regards, > > Mach > > > > > -----Original Message----- > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > > Behalf > > > Of Lucy yong > > > Sent: Saturday, April 28, 2012 2:43 AM > > > To: Giles Heron; l2vpn@ietf.org > > > Subject: RE: Interest in IS-IS VPLS > > > > > > Hi Giles, > > > > > > It seems that the IS-IS VPLS provides the solution for a scalable > > data > > > center network as mentioned in the draft. I am not sure it is > proper > > > to weight service providers more on this. I can see if a service > > > provider already deployed existing VPLS, the gain from IS-IS VPLS > is > > > less than the cost on upgrading all the edge devices to support the > > solution. > > > > > > However, for data center network, IS-IS VPLS could be a useful > > > solution. It simplifies current VPLS mechanism, provides a good > > > scalability, and requires IP only function on core switches. > > > > > > A vendor provides devices for both service provider network and > data > > > center network, the solution brings a synergy in leveraging VPLS > > > solution into DC. > > > > > > Thus, I like to see this work moving forward. > > > > > > Regards, > > > Lucy > > > > > > > > > > > > -----Original Message----- > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > > Behalf > > > Of Giles Heron > > > Sent: Friday, April 27, 2012 7:57 AM > > > To: l2vpn@ietf.org > > > Subject: Interest in IS-IS VPLS > > > > > > Hi, > > > > > > At the IETF meeting in Paris I took an action (as noted in the > > > minutes) to poll the WG to see if there was any interest (other > than > > > by the authors of > > > course) in progressing the IS-IS VPLS draft. > > > > > > Would you please respond to this email indicating whether or not > you > > > have interest in seeing this draft progress, ideally giving > > > reasoning for your position. It'd be especially interesting to see > > > responses from service providers of course. > > > > > > If there are no (or very few) responses to this email then Nabil > and > > I > > > will probably interpret that as meaning there's insufficient > > > interest to progress. Of course it may just mean that you all > > > missed this email in the deluge of debate on E-Tree ;) > > > > > > Giles > > > From lieven.levrau@alcatel-lucent.com Mon Apr 30 09:13:38 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136A621F8731 for ; Mon, 30 Apr 2012 09:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 EJ2W8aQPmSbH for ; Mon, 30 Apr 2012 09:13:37 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 221F321F872D for ; Mon, 30 Apr 2012 09:13:36 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3UGDUYc031948 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Apr 2012 18:13:30 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 30 Apr 2012 18:13:30 +0200 From: "LEVRAU, LIEVEN (LIEVEN)" To: Lucy yong , John E Drake , Mach Chen , Giles Heron , "l2vpn@ietf.org" Date: Mon, 30 Apr 2012 18:13:26 +0200 Subject: Re: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0m7C5xlqD1CJh8Scycuo50JQVt7w== Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 X-BeenThere: l2vpn@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, 30 Apr 2012 16:13:38 -0000 inline On 30/04/12 17:38, "Lucy yong" wrote: >John, > >IS-IS VPLS is completely different from TRILL and SPB although they all >use of IS-IS protocol in control plane. IS-IS VPLS data plane uses an >IP/GRE tunnel carrying VPN instances differentiated by MPLS labels. TRILL >and SPB data planes are Ethernet based, i.e. the frames are Ethernet >frames. > >Isn't it good that one control plane protocol can apply to different data >planes? No I don't think so - as that creates interop issues and gateway functions when connecting different control planes together. >=20 > >I agree that VPLS has been well defined and used in Service Provider >networks. IS-IS VPLS provides the simplified version of VPLS that can >apply to data center networks. This may be better than developing >something completely new in data center. > >Maybe we need consider another name for this, for example DC-VPN? In data >center, an VPN is not necessary to provide a service to an customer, the >infrastructure need VPN capability. Ok lets not - if there are tools out there that can be built upon, why introduce a new thing which there seems very little interest and retry by given the same new thing a different name. > >Regards, >Lucy=20 > > > >-----Original Message----- >From: John E Drake [mailto:jdrake@juniper.net] >Sent: Monday, April 30, 2012 8:12 AM >To: Mach Chen; Lucy yong; Giles Heron; l2vpn@ietf.org >Subject: RE: Interest in IS-IS VPLS > >We already have TRILL and SPB. Why is yet another IS-IS variant >necessary, particularly one that is so completely under-specified? > >Sent from my iPhone > > >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Mach Chen >> Sent: Saturday, April 28, 2012 3:04 AM >> To: Lucy yong; Giles Heron; l2vpn@ietf.org >> Subject: RE: Interest in IS-IS VPLS >>=20 >> Fully agree with lucy here. >>=20 >> In addition, since the ISIS VPLS leverages a uniform protocol(ISIS) for >> signaling and auto discovery, it would greatly simplify the deployment >> and maintenance, especially for the DC networks that have already >> deployed ISIS for IP routing. So I'd like to see the draft moving >> forward. >>=20 >> Best regards, >> Mach >>=20 >> > -----Original Message----- >> > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> Behalf >> > Of Lucy yong >> > Sent: Saturday, April 28, 2012 2:43 AM >> > To: Giles Heron; l2vpn@ietf.org >> > Subject: RE: Interest in IS-IS VPLS >> > >> > Hi Giles, >> > >> > It seems that the IS-IS VPLS provides the solution for a scalable >> data >> > center network as mentioned in the draft. I am not sure it is proper >> > to weight service providers more on this. I can see if a service >> > provider already deployed existing VPLS, the gain from IS-IS VPLS is >> > less than the cost on upgrading all the edge devices to support the >> solution. >> > >> > However, for data center network, IS-IS VPLS could be a useful >> > solution. It simplifies current VPLS mechanism, provides a good >> > scalability, and requires IP only function on core switches. >> > >> > A vendor provides devices for both service provider network and data >> > center network, the solution brings a synergy in leveraging VPLS >> > solution into DC. >> > >> > Thus, I like to see this work moving forward. >> > >> > Regards, >> > Lucy >> > >> > >> > >> > -----Original Message----- >> > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> Behalf >> > Of Giles Heron >> > Sent: Friday, April 27, 2012 7:57 AM >> > To: l2vpn@ietf.org >> > Subject: Interest in IS-IS VPLS >> > >> > Hi, >> > >> > At the IETF meeting in Paris I took an action (as noted in the >> > minutes) to poll the WG to see if there was any interest (other than >> > by the authors of >> > course) in progressing the IS-IS VPLS draft. >> > >> > Would you please respond to this email indicating whether or not you >> > have interest in seeing this draft progress, ideally giving reasoning >> > for your position. It'd be especially interesting to see responses >> > from service providers of course. >> > >> > If there are no (or very few) responses to this email then Nabil and >> I >> > will probably interpret that as meaning there's insufficient interest >> > to progress. Of course it may just mean that you all missed this >> > email in the deluge of debate on E-Tree ;) >> > >> > Giles >> > > From lucy.yong@huawei.com Mon Apr 30 09:47:34 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B2D21F87BA for ; Mon, 30 Apr 2012 09:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] 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 6QINBS7bSovd for ; Mon, 30 Apr 2012 09:47:33 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA7721F87B4 for ; Mon, 30 Apr 2012 09:47:33 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFS27007; Mon, 30 Apr 2012 12:47:32 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Apr 2012 09:45:07 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Mon, 30 Apr 2012 09:45:02 -0700 From: Lucy yong To: John E Drake , Mach Chen , Giles Heron , "l2vpn@ietf.org" Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAAcwK+MAAEDOFgAAHPUXAAAJfv8A== Date: Mon, 30 Apr 2012 16:45:01 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E5BFA@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDE9C5@EMBX01-HQ.jnpr.net> <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDEB30@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A56EEDEB30@EMBX01-HQ.jnpr.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.14] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@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, 30 Apr 2012 16:47:34 -0000 John, JD: From what I understand, both TRILL and SP can be used to provide the s= ame capabilities as IS-IS VPLS and they both exist today. LY: From the architecture perspective, the backbone implementation between = IS-IS VPLS and TRILL/SPB is completely different. IS-IS VPLS relies on IP f= orwarding in core, TRILL/SPB relies on Ethernet forwarding. Why did we deve= lop VPLS when there was provider bridging (PB) technology, they served the = same capability? >=20 > Isn't it good that one control plane protocol can apply to different > data planes? JD: This is a rhetorical question, right? LY: I guess that you agree it. :) all the work CCAMP does is to extend the = control plane protocol to other data planes. JD: Just because it has 'VPLS' in its name does not mean it isn't new. I = agree that we don't want to develop anything new for the data center, and t= hat therefore, IS-IS VPLS is a non-starter. LY: One argument we often to hear is that MPLS is too "complicated" for the= data center. We can see that some complexities have the history reasons an= d hardware limitation then. As the chip technology improving, these constra= ints no longer exist. We can simplify them for a new area. IS-IS VPLS is th= e starting point I see. Thanks, Lucy -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Monday, April 30, 2012 11:11 AM To: Lucy yong; Mach Chen; Giles Heron; l2vpn@ietf.org Subject: RE: Interest in IS-IS VPLS Lucy, Comments inline. Thanks, John Sent from my iPhone > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Monday, April 30, 2012 8:39 AM > To: John E Drake; Mach Chen; Giles Heron; l2vpn@ietf.org > Subject: RE: Interest in IS-IS VPLS >=20 > John, >=20 > IS-IS VPLS is completely different from TRILL and SPB although they all > use of IS-IS protocol in control plane. IS-IS VPLS data plane uses an > IP/GRE tunnel carrying VPN instances differentiated by MPLS labels. > TRILL and SPB data planes are Ethernet based, i.e. the frames are > Ethernet frames. JD: From what I understand, both TRILL and SP can be used to provide the s= ame capabilities as IS-IS VPLS and they both exist today. =20 >=20 > Isn't it good that one control plane protocol can apply to different > data planes? JD: This is a rhetorical question, right? >=20 > I agree that VPLS has been well defined and used in Service Provider > networks. IS-IS VPLS provides the simplified version of VPLS that can > apply to data center networks. This may be better than developing > something completely new in data center. JD: Just because it has 'VPLS' in its name does not mean it isn't new. I = agree that we don't want to develop anything new for the data center, and t= hat therefore, IS-IS VPLS is a non-starter. >=20 > Maybe we need consider another name for this, for example DC-VPN? In > data center, an VPN is not necessary to provide a service to an > customer, the infrastructure need VPN capability. JD: This sounds like a tautology. >=20 > Regards, > Lucy >=20 >=20 >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Monday, April 30, 2012 8:12 AM > To: Mach Chen; Lucy yong; Giles Heron; l2vpn@ietf.org > Subject: RE: Interest in IS-IS VPLS >=20 > We already have TRILL and SPB. Why is yet another IS-IS variant > necessary, particularly one that is so completely under-specified? >=20 > Sent from my iPhone >=20 >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > > Of Mach Chen > > Sent: Saturday, April 28, 2012 3:04 AM > > To: Lucy yong; Giles Heron; l2vpn@ietf.org > > Subject: RE: Interest in IS-IS VPLS > > > > Fully agree with lucy here. > > > > In addition, since the ISIS VPLS leverages a uniform protocol(ISIS) > > for signaling and auto discovery, it would greatly simplify the > > deployment and maintenance, especially for the DC networks that have > > already deployed ISIS for IP routing. So I'd like to see the draft > > moving forward. > > > > Best regards, > > Mach > > > > > -----Original Message----- > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > > Behalf > > > Of Lucy yong > > > Sent: Saturday, April 28, 2012 2:43 AM > > > To: Giles Heron; l2vpn@ietf.org > > > Subject: RE: Interest in IS-IS VPLS > > > > > > Hi Giles, > > > > > > It seems that the IS-IS VPLS provides the solution for a scalable > > data > > > center network as mentioned in the draft. I am not sure it is > proper > > > to weight service providers more on this. I can see if a service > > > provider already deployed existing VPLS, the gain from IS-IS VPLS > is > > > less than the cost on upgrading all the edge devices to support the > > solution. > > > > > > However, for data center network, IS-IS VPLS could be a useful > > > solution. It simplifies current VPLS mechanism, provides a good > > > scalability, and requires IP only function on core switches. > > > > > > A vendor provides devices for both service provider network and > data > > > center network, the solution brings a synergy in leveraging VPLS > > > solution into DC. > > > > > > Thus, I like to see this work moving forward. > > > > > > Regards, > > > Lucy > > > > > > > > > > > > -----Original Message----- > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > > Behalf > > > Of Giles Heron > > > Sent: Friday, April 27, 2012 7:57 AM > > > To: l2vpn@ietf.org > > > Subject: Interest in IS-IS VPLS > > > > > > Hi, > > > > > > At the IETF meeting in Paris I took an action (as noted in the > > > minutes) to poll the WG to see if there was any interest (other > than > > > by the authors of > > > course) in progressing the IS-IS VPLS draft. > > > > > > Would you please respond to this email indicating whether or not > you > > > have interest in seeing this draft progress, ideally giving > > > reasoning for your position. It'd be especially interesting to see > > > responses from service providers of course. > > > > > > If there are no (or very few) responses to this email then Nabil > and > > I > > > will probably interpret that as meaning there's insufficient > > > interest to progress. Of course it may just mean that you all > > > missed this email in the deluge of debate on E-Tree ;) > > > > > > Giles > > > From gregory.mirsky@ericsson.com Mon Apr 30 09:50:00 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E0021F882E for ; Mon, 30 Apr 2012 09:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 YkjLCofsZK5F for ; Mon, 30 Apr 2012 09:49:59 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7577621F882D for ; Mon, 30 Apr 2012 09:49:59 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3UGnsL2013274; Mon, 30 Apr 2012 11:49:55 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.10]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 30 Apr 2012 12:49:49 -0400 From: Gregory Mirsky To: Lucy yong , Giles Heron , "l2vpn@ietf.org" Date: Mon, 30 Apr 2012 12:49:48 -0400 Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAAcwK+MAAEDOFgAAFHrFA= Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDE9C5@EMBX01-HQ.jnpr.net> <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> 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-BeenThere: l2vpn@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, 30 Apr 2012 16:50:00 -0000 Dear Lucy, If authors believe that applicability area for the document is, primarily, = in DC VPNs, then, IMHO, NVO3 WG might be suitable WG to continue work assum= ing the proposal satisfies functional and performance, including scaling, r= equirements that been referenced in NVO3 WG charter and will be detailed in= framework and architectural documents. And I concur with Sasha, who reminded us, developers, that particular inter= est and value be paid to feedback from service providers. Regards, Greg -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of L= ucy yong Sent: Monday, April 30, 2012 8:39 AM To: John E Drake; Mach Chen; Giles Heron; l2vpn@ietf.org Subject: RE: Interest in IS-IS VPLS John, IS-IS VPLS is completely different from TRILL and SPB although they all use= of IS-IS protocol in control plane. IS-IS VPLS data plane uses an IP/GRE t= unnel carrying VPN instances differentiated by MPLS labels. TRILL and SPB d= ata planes are Ethernet based, i.e. the frames are Ethernet frames. Isn't it good that one control plane protocol can apply to different data p= lanes?=20 I agree that VPLS has been well defined and used in Service Provider networ= ks. IS-IS VPLS provides the simplified version of VPLS that can apply to da= ta center networks. This may be better than developing something completely= new in data center.=20 Maybe we need consider another name for this, for example DC-VPN? In data c= enter, an VPN is not necessary to provide a service to an customer, the inf= rastructure need VPN capability. =20 Regards, Lucy=20 -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Monday, April 30, 2012 8:12 AM To: Mach Chen; Lucy yong; Giles Heron; l2vpn@ietf.org Subject: RE: Interest in IS-IS VPLS We already have TRILL and SPB. Why is yet another IS-IS variant necessary,= particularly one that is so completely under-specified?=20 Sent from my iPhone > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf=20 > Of Mach Chen > Sent: Saturday, April 28, 2012 3:04 AM > To: Lucy yong; Giles Heron; l2vpn@ietf.org > Subject: RE: Interest in IS-IS VPLS >=20 > Fully agree with lucy here. >=20 > In addition, since the ISIS VPLS leverages a uniform protocol(ISIS)=20 > for signaling and auto discovery, it would greatly simplify the=20 > deployment and maintenance, especially for the DC networks that have=20 > already deployed ISIS for IP routing. So I'd like to see the draft=20 > moving forward. >=20 > Best regards, > Mach >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > > Of Lucy yong > > Sent: Saturday, April 28, 2012 2:43 AM > > To: Giles Heron; l2vpn@ietf.org > > Subject: RE: Interest in IS-IS VPLS > > > > Hi Giles, > > > > It seems that the IS-IS VPLS provides the solution for a scalable > data > > center network as mentioned in the draft. I am not sure it is proper=20 > > to weight service providers more on this. I can see if a service=20 > > provider already deployed existing VPLS, the gain from IS-IS VPLS is=20 > > less than the cost on upgrading all the edge devices to support the > solution. > > > > However, for data center network, IS-IS VPLS could be a useful=20 > > solution. It simplifies current VPLS mechanism, provides a good=20 > > scalability, and requires IP only function on core switches. > > > > A vendor provides devices for both service provider network and data=20 > > center network, the solution brings a synergy in leveraging VPLS=20 > > solution into DC. > > > > Thus, I like to see this work moving forward. > > > > Regards, > > Lucy > > > > > > > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > > Of Giles Heron > > Sent: Friday, April 27, 2012 7:57 AM > > To: l2vpn@ietf.org > > Subject: Interest in IS-IS VPLS > > > > Hi, > > > > At the IETF meeting in Paris I took an action (as noted in the > > minutes) to poll the WG to see if there was any interest (other than=20 > > by the authors of > > course) in progressing the IS-IS VPLS draft. > > > > Would you please respond to this email indicating whether or not you=20 > > have interest in seeing this draft progress, ideally giving=20 > > reasoning for your position. It'd be especially interesting to see=20 > > responses from service providers of course. > > > > If there are no (or very few) responses to this email then Nabil and > I > > will probably interpret that as meaning there's insufficient=20 > > interest to progress. Of course it may just mean that you all=20 > > missed this email in the deluge of debate on E-Tree ;) > > > > Giles > > From lucy.yong@huawei.com Mon Apr 30 09:52:21 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790C821E801E for ; Mon, 30 Apr 2012 09:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] 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 Y86Q1HRVgYQq for ; Mon, 30 Apr 2012 09:52:20 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E92A621F876A for ; Mon, 30 Apr 2012 09:52:19 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFK26258; Mon, 30 Apr 2012 12:52:19 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Apr 2012 09:50:34 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Mon, 30 Apr 2012 09:50:30 -0700 From: Lucy yong To: "LEVRAU, LIEVEN (LIEVEN)" , John E Drake , Mach Chen , Giles Heron , "l2vpn@ietf.org" Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAAcwK+MAAEDOFgABD+RQAADXDsIA== Date: Mon, 30 Apr 2012 16:50:30 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E5C19@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> 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.130.14] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@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, 30 Apr 2012 16:52:22 -0000 No I don't think so - as that creates interop issues and gateway functions when connecting different control planes together. [LY] Do you deny all the works in CCAMP? Lucy -----Original Message----- From: LEVRAU, LIEVEN (LIEVEN) [mailto:lieven.levrau@alcatel-lucent.com]=20 Sent: Monday, April 30, 2012 11:13 AM To: Lucy yong; John E Drake; Mach Chen; Giles Heron; l2vpn@ietf.org Subject: Re: Interest in IS-IS VPLS inline On 30/04/12 17:38, "Lucy yong" wrote: >John, > >IS-IS VPLS is completely different from TRILL and SPB although they all >use of IS-IS protocol in control plane. IS-IS VPLS data plane uses an >IP/GRE tunnel carrying VPN instances differentiated by MPLS labels. TRILL >and SPB data planes are Ethernet based, i.e. the frames are Ethernet >frames. > >Isn't it good that one control plane protocol can apply to different data >planes? No I don't think so - as that creates interop issues and gateway functions when connecting different control planes together. >=20 > >I agree that VPLS has been well defined and used in Service Provider >networks. IS-IS VPLS provides the simplified version of VPLS that can >apply to data center networks. This may be better than developing >something completely new in data center. > >Maybe we need consider another name for this, for example DC-VPN? In data >center, an VPN is not necessary to provide a service to an customer, the >infrastructure need VPN capability. Ok lets not - if there are tools out there that can be built upon, why introduce a new thing which there seems very little interest and retry by given the same new thing a different name. > >Regards, >Lucy=20 > > > >-----Original Message----- >From: John E Drake [mailto:jdrake@juniper.net] >Sent: Monday, April 30, 2012 8:12 AM >To: Mach Chen; Lucy yong; Giles Heron; l2vpn@ietf.org >Subject: RE: Interest in IS-IS VPLS > >We already have TRILL and SPB. Why is yet another IS-IS variant >necessary, particularly one that is so completely under-specified? > >Sent from my iPhone > > >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Mach Chen >> Sent: Saturday, April 28, 2012 3:04 AM >> To: Lucy yong; Giles Heron; l2vpn@ietf.org >> Subject: RE: Interest in IS-IS VPLS >>=20 >> Fully agree with lucy here. >>=20 >> In addition, since the ISIS VPLS leverages a uniform protocol(ISIS) for >> signaling and auto discovery, it would greatly simplify the deployment >> and maintenance, especially for the DC networks that have already >> deployed ISIS for IP routing. So I'd like to see the draft moving >> forward. >>=20 >> Best regards, >> Mach >>=20 >> > -----Original Message----- >> > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> Behalf >> > Of Lucy yong >> > Sent: Saturday, April 28, 2012 2:43 AM >> > To: Giles Heron; l2vpn@ietf.org >> > Subject: RE: Interest in IS-IS VPLS >> > >> > Hi Giles, >> > >> > It seems that the IS-IS VPLS provides the solution for a scalable >> data >> > center network as mentioned in the draft. I am not sure it is proper >> > to weight service providers more on this. I can see if a service >> > provider already deployed existing VPLS, the gain from IS-IS VPLS is >> > less than the cost on upgrading all the edge devices to support the >> solution. >> > >> > However, for data center network, IS-IS VPLS could be a useful >> > solution. It simplifies current VPLS mechanism, provides a good >> > scalability, and requires IP only function on core switches. >> > >> > A vendor provides devices for both service provider network and data >> > center network, the solution brings a synergy in leveraging VPLS >> > solution into DC. >> > >> > Thus, I like to see this work moving forward. >> > >> > Regards, >> > Lucy >> > >> > >> > >> > -----Original Message----- >> > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> Behalf >> > Of Giles Heron >> > Sent: Friday, April 27, 2012 7:57 AM >> > To: l2vpn@ietf.org >> > Subject: Interest in IS-IS VPLS >> > >> > Hi, >> > >> > At the IETF meeting in Paris I took an action (as noted in the >> > minutes) to poll the WG to see if there was any interest (other than >> > by the authors of >> > course) in progressing the IS-IS VPLS draft. >> > >> > Would you please respond to this email indicating whether or not you >> > have interest in seeing this draft progress, ideally giving reasoning >> > for your position. It'd be especially interesting to see responses >> > from service providers of course. >> > >> > If there are no (or very few) responses to this email then Nabil and >> I >> > will probably interpret that as meaning there's insufficient interest >> > to progress. Of course it may just mean that you all missed this >> > email in the deluge of debate on E-Tree ;) >> > >> > Giles >> > > From lucy.yong@huawei.com Mon Apr 30 10:00:42 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAFF21F87D6 for ; Mon, 30 Apr 2012 10:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] 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 iCe3yeYkrEUH for ; Mon, 30 Apr 2012 10:00:41 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A8BB921F87CB for ; Mon, 30 Apr 2012 10:00:41 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFS27780; Mon, 30 Apr 2012 13:00:41 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Apr 2012 09:58:26 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Mon, 30 Apr 2012 09:58:23 -0700 From: Lucy yong To: Gregory Mirsky , Giles Heron , "l2vpn@ietf.org" Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAAcwK+MAAEDOFgAAFHrFAAAmp48A== Date: Mon, 30 Apr 2012 16:58:23 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E5C27@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDE9C5@EMBX01-HQ.jnpr.net> <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> 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.130.14] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@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, 30 Apr 2012 17:00:42 -0000 Authors want to bring this work into NV03. However, NV03 just starts the pr= oblem statement and requirement. It is not in the stage of any solution yet= . IS-IS VPLS is just an evolution of VPLS, it fits L2VPN too. Lucy -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]=20 Sent: Monday, April 30, 2012 11:50 AM To: Lucy yong; Giles Heron; l2vpn@ietf.org Subject: RE: Interest in IS-IS VPLS Dear Lucy, If authors believe that applicability area for the document is, primarily, = in DC VPNs, then, IMHO, NVO3 WG might be suitable WG to continue work assum= ing the proposal satisfies functional and performance, including scaling, r= equirements that been referenced in NVO3 WG charter and will be detailed in= framework and architectural documents. And I concur with Sasha, who reminded us, developers, that particular inter= est and value be paid to feedback from service providers. Regards, Greg -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of L= ucy yong Sent: Monday, April 30, 2012 8:39 AM To: John E Drake; Mach Chen; Giles Heron; l2vpn@ietf.org Subject: RE: Interest in IS-IS VPLS John, IS-IS VPLS is completely different from TRILL and SPB although they all use= of IS-IS protocol in control plane. IS-IS VPLS data plane uses an IP/GRE t= unnel carrying VPN instances differentiated by MPLS labels. TRILL and SPB d= ata planes are Ethernet based, i.e. the frames are Ethernet frames. Isn't it good that one control plane protocol can apply to different data p= lanes?=20 I agree that VPLS has been well defined and used in Service Provider networ= ks. IS-IS VPLS provides the simplified version of VPLS that can apply to da= ta center networks. This may be better than developing something completely= new in data center.=20 Maybe we need consider another name for this, for example DC-VPN? In data c= enter, an VPN is not necessary to provide a service to an customer, the inf= rastructure need VPN capability. =20 Regards, Lucy=20 -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Monday, April 30, 2012 8:12 AM To: Mach Chen; Lucy yong; Giles Heron; l2vpn@ietf.org Subject: RE: Interest in IS-IS VPLS We already have TRILL and SPB. Why is yet another IS-IS variant necessary,= particularly one that is so completely under-specified?=20 Sent from my iPhone > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf=20 > Of Mach Chen > Sent: Saturday, April 28, 2012 3:04 AM > To: Lucy yong; Giles Heron; l2vpn@ietf.org > Subject: RE: Interest in IS-IS VPLS >=20 > Fully agree with lucy here. >=20 > In addition, since the ISIS VPLS leverages a uniform protocol(ISIS)=20 > for signaling and auto discovery, it would greatly simplify the=20 > deployment and maintenance, especially for the DC networks that have=20 > already deployed ISIS for IP routing. So I'd like to see the draft=20 > moving forward. >=20 > Best regards, > Mach >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > > Of Lucy yong > > Sent: Saturday, April 28, 2012 2:43 AM > > To: Giles Heron; l2vpn@ietf.org > > Subject: RE: Interest in IS-IS VPLS > > > > Hi Giles, > > > > It seems that the IS-IS VPLS provides the solution for a scalable > data > > center network as mentioned in the draft. I am not sure it is proper=20 > > to weight service providers more on this. I can see if a service=20 > > provider already deployed existing VPLS, the gain from IS-IS VPLS is=20 > > less than the cost on upgrading all the edge devices to support the > solution. > > > > However, for data center network, IS-IS VPLS could be a useful=20 > > solution. It simplifies current VPLS mechanism, provides a good=20 > > scalability, and requires IP only function on core switches. > > > > A vendor provides devices for both service provider network and data=20 > > center network, the solution brings a synergy in leveraging VPLS=20 > > solution into DC. > > > > Thus, I like to see this work moving forward. > > > > Regards, > > Lucy > > > > > > > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > > Of Giles Heron > > Sent: Friday, April 27, 2012 7:57 AM > > To: l2vpn@ietf.org > > Subject: Interest in IS-IS VPLS > > > > Hi, > > > > At the IETF meeting in Paris I took an action (as noted in the > > minutes) to poll the WG to see if there was any interest (other than=20 > > by the authors of > > course) in progressing the IS-IS VPLS draft. > > > > Would you please respond to this email indicating whether or not you=20 > > have interest in seeing this draft progress, ideally giving=20 > > reasoning for your position. It'd be especially interesting to see=20 > > responses from service providers of course. > > > > If there are no (or very few) responses to this email then Nabil and > I > > will probably interpret that as meaning there's insufficient=20 > > interest to progress. Of course it may just mean that you all=20 > > missed this email in the deluge of debate on E-Tree ;) > > > > Giles > > From lieven.levrau@alcatel-lucent.com Mon Apr 30 10:04:02 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E68521F87E2 for ; Mon, 30 Apr 2012 10:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 v7qZoUzunfJB for ; Mon, 30 Apr 2012 10:04:01 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5025E21F8749 for ; Mon, 30 Apr 2012 10:04:01 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3UH3sbh030533 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Apr 2012 19:03:54 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 30 Apr 2012 19:03:54 +0200 From: "LEVRAU, LIEVEN (LIEVEN)" To: Lucy yong , John E Drake , Mach Chen , Giles Heron , "l2vpn@ietf.org" Date: Mon, 30 Apr 2012 19:03:50 +0200 Subject: Re: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0m8zjbQtNBHDZmQ1qrgV6WshnP1w== Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D330E5C19@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 X-BeenThere: l2vpn@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, 30 Apr 2012 17:04:02 -0000 Hi Lucy - That is not the point The point is that we would need yet another interconnection model=8A. And t= o what benefit? ./ Lieven On 30/04/12 18:50, "Lucy yong" wrote: >No I don't think so - as that creates interop issues and gateway functions >when connecting different control planes together. > >[LY] Do you deny all the works in CCAMP? > >Lucy > >-----Original Message----- >From: LEVRAU, LIEVEN (LIEVEN) [mailto:lieven.levrau@alcatel-lucent.com] >Sent: Monday, April 30, 2012 11:13 AM >To: Lucy yong; John E Drake; Mach Chen; Giles Heron; l2vpn@ietf.org >Subject: Re: Interest in IS-IS VPLS > >inline > >On 30/04/12 17:38, "Lucy yong" wrote: > >>John, >> >>IS-IS VPLS is completely different from TRILL and SPB although they all >>use of IS-IS protocol in control plane. IS-IS VPLS data plane uses an >>IP/GRE tunnel carrying VPN instances differentiated by MPLS labels. TRILL >>and SPB data planes are Ethernet based, i.e. the frames are Ethernet >>frames. >> >>Isn't it good that one control plane protocol can apply to different data >>planes? >No I don't think so - as that creates interop issues and gateway functions >when connecting different control planes together. >>=20 >> >>I agree that VPLS has been well defined and used in Service Provider >>networks. IS-IS VPLS provides the simplified version of VPLS that can >>apply to data center networks. This may be better than developing >>something completely new in data center. >> >>Maybe we need consider another name for this, for example DC-VPN? In data >>center, an VPN is not necessary to provide a service to an customer, the >>infrastructure need VPN capability. >Ok lets not - if there are tools out there that can be built upon, why >introduce a new thing which there seems very little interest and retry by >given the same new thing a different name. > >> >>Regards, >>Lucy=20 >> >> >> >>-----Original Message----- >>From: John E Drake [mailto:jdrake@juniper.net] >>Sent: Monday, April 30, 2012 8:12 AM >>To: Mach Chen; Lucy yong; Giles Heron; l2vpn@ietf.org >>Subject: RE: Interest in IS-IS VPLS >> >>We already have TRILL and SPB. Why is yet another IS-IS variant >>necessary, particularly one that is so completely under-specified? >> >>Sent from my iPhone >> >> >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>> Of Mach Chen >>> Sent: Saturday, April 28, 2012 3:04 AM >>> To: Lucy yong; Giles Heron; l2vpn@ietf.org >>> Subject: RE: Interest in IS-IS VPLS >>>=20 >>> Fully agree with lucy here. >>>=20 >>> In addition, since the ISIS VPLS leverages a uniform protocol(ISIS) for >>> signaling and auto discovery, it would greatly simplify the deployment >>> and maintenance, especially for the DC networks that have already >>> deployed ISIS for IP routing. So I'd like to see the draft moving >>> forward. >>>=20 >>> Best regards, >>> Mach >>>=20 >>> > -----Original Message----- >>> > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>> Behalf >>> > Of Lucy yong >>> > Sent: Saturday, April 28, 2012 2:43 AM >>> > To: Giles Heron; l2vpn@ietf.org >>> > Subject: RE: Interest in IS-IS VPLS >>> > >>> > Hi Giles, >>> > >>> > It seems that the IS-IS VPLS provides the solution for a scalable >>> data >>> > center network as mentioned in the draft. I am not sure it is proper >>> > to weight service providers more on this. I can see if a service >>> > provider already deployed existing VPLS, the gain from IS-IS VPLS is >>> > less than the cost on upgrading all the edge devices to support the >>> solution. >>> > >>> > However, for data center network, IS-IS VPLS could be a useful >>> > solution. It simplifies current VPLS mechanism, provides a good >>> > scalability, and requires IP only function on core switches. >>> > >>> > A vendor provides devices for both service provider network and data >>> > center network, the solution brings a synergy in leveraging VPLS >>> > solution into DC. >>> > >>> > Thus, I like to see this work moving forward. >>> > >>> > Regards, >>> > Lucy >>> > >>> > >>> > >>> > -----Original Message----- >>> > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>> Behalf >>> > Of Giles Heron >>> > Sent: Friday, April 27, 2012 7:57 AM >>> > To: l2vpn@ietf.org >>> > Subject: Interest in IS-IS VPLS >>> > >>> > Hi, >>> > >>> > At the IETF meeting in Paris I took an action (as noted in the >>> > minutes) to poll the WG to see if there was any interest (other than >>> > by the authors of >>> > course) in progressing the IS-IS VPLS draft. >>> > >>> > Would you please respond to this email indicating whether or not you >>> > have interest in seeing this draft progress, ideally giving reasoning >>> > for your position. It'd be especially interesting to see responses >>> > from service providers of course. >>> > >>> > If there are no (or very few) responses to this email then Nabil and >>> I >>> > will probably interpret that as meaning there's insufficient interest >>> > to progress. Of course it may just mean that you all missed this >>> > email in the deluge of debate on E-Tree ;) >>> > >>> > Giles >>> > >> > From lucy.yong@huawei.com Mon Apr 30 10:10:39 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F02821F8819 for ; Mon, 30 Apr 2012 10:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] 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 JUXghFNALnFc for ; Mon, 30 Apr 2012 10:10:38 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id ADB8421F8813 for ; Mon, 30 Apr 2012 10:10:37 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFS28322; Mon, 30 Apr 2012 13:10:37 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Apr 2012 10:09:32 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Mon, 30 Apr 2012 10:09:26 -0700 From: Lucy yong To: "LEVRAU, LIEVEN (LIEVEN)" , John E Drake , Mach Chen , Giles Heron , "l2vpn@ietf.org" Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAAcwK+MAAEDOFgABD+RQAADXDsIP//oo0AgAB0JtA= Date: Mon, 30 Apr 2012 17:09:25 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E5C5B@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D330E5C19@dfweml505-mbx> 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.130.14] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@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, 30 Apr 2012 17:10:39 -0000 I guess that the benefit is to make the solution better and better. Lucy -----Original Message----- From: LEVRAU, LIEVEN (LIEVEN) [mailto:lieven.levrau@alcatel-lucent.com]=20 Sent: Monday, April 30, 2012 12:04 PM To: Lucy yong; John E Drake; Mach Chen; Giles Heron; l2vpn@ietf.org Subject: Re: Interest in IS-IS VPLS Hi Lucy - That is not the point The point is that we would need yet another interconnection model=A9. And t= o what benefit? ./ Lieven On 30/04/12 18:50, "Lucy yong" wrote: >No I don't think so - as that creates interop issues and gateway functions >when connecting different control planes together. > >[LY] Do you deny all the works in CCAMP? > >Lucy > >-----Original Message----- >From: LEVRAU, LIEVEN (LIEVEN) [mailto:lieven.levrau@alcatel-lucent.com] >Sent: Monday, April 30, 2012 11:13 AM >To: Lucy yong; John E Drake; Mach Chen; Giles Heron; l2vpn@ietf.org >Subject: Re: Interest in IS-IS VPLS > >inline > >On 30/04/12 17:38, "Lucy yong" wrote: > >>John, >> >>IS-IS VPLS is completely different from TRILL and SPB although they all >>use of IS-IS protocol in control plane. IS-IS VPLS data plane uses an >>IP/GRE tunnel carrying VPN instances differentiated by MPLS labels. TRILL >>and SPB data planes are Ethernet based, i.e. the frames are Ethernet >>frames. >> >>Isn't it good that one control plane protocol can apply to different data >>planes? >No I don't think so - as that creates interop issues and gateway functions >when connecting different control planes together. >>=20 >> >>I agree that VPLS has been well defined and used in Service Provider >>networks. IS-IS VPLS provides the simplified version of VPLS that can >>apply to data center networks. This may be better than developing >>something completely new in data center. >> >>Maybe we need consider another name for this, for example DC-VPN? In data >>center, an VPN is not necessary to provide a service to an customer, the >>infrastructure need VPN capability. >Ok lets not - if there are tools out there that can be built upon, why >introduce a new thing which there seems very little interest and retry by >given the same new thing a different name. > >> >>Regards, >>Lucy=20 >> >> >> >>-----Original Message----- >>From: John E Drake [mailto:jdrake@juniper.net] >>Sent: Monday, April 30, 2012 8:12 AM >>To: Mach Chen; Lucy yong; Giles Heron; l2vpn@ietf.org >>Subject: RE: Interest in IS-IS VPLS >> >>We already have TRILL and SPB. Why is yet another IS-IS variant >>necessary, particularly one that is so completely under-specified? >> >>Sent from my iPhone >> >> >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>> Of Mach Chen >>> Sent: Saturday, April 28, 2012 3:04 AM >>> To: Lucy yong; Giles Heron; l2vpn@ietf.org >>> Subject: RE: Interest in IS-IS VPLS >>>=20 >>> Fully agree with lucy here. >>>=20 >>> In addition, since the ISIS VPLS leverages a uniform protocol(ISIS) for >>> signaling and auto discovery, it would greatly simplify the deployment >>> and maintenance, especially for the DC networks that have already >>> deployed ISIS for IP routing. So I'd like to see the draft moving >>> forward. >>>=20 >>> Best regards, >>> Mach >>>=20 >>> > -----Original Message----- >>> > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>> Behalf >>> > Of Lucy yong >>> > Sent: Saturday, April 28, 2012 2:43 AM >>> > To: Giles Heron; l2vpn@ietf.org >>> > Subject: RE: Interest in IS-IS VPLS >>> > >>> > Hi Giles, >>> > >>> > It seems that the IS-IS VPLS provides the solution for a scalable >>> data >>> > center network as mentioned in the draft. I am not sure it is proper >>> > to weight service providers more on this. I can see if a service >>> > provider already deployed existing VPLS, the gain from IS-IS VPLS is >>> > less than the cost on upgrading all the edge devices to support the >>> solution. >>> > >>> > However, for data center network, IS-IS VPLS could be a useful >>> > solution. It simplifies current VPLS mechanism, provides a good >>> > scalability, and requires IP only function on core switches. >>> > >>> > A vendor provides devices for both service provider network and data >>> > center network, the solution brings a synergy in leveraging VPLS >>> > solution into DC. >>> > >>> > Thus, I like to see this work moving forward. >>> > >>> > Regards, >>> > Lucy >>> > >>> > >>> > >>> > -----Original Message----- >>> > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>> Behalf >>> > Of Giles Heron >>> > Sent: Friday, April 27, 2012 7:57 AM >>> > To: l2vpn@ietf.org >>> > Subject: Interest in IS-IS VPLS >>> > >>> > Hi, >>> > >>> > At the IETF meeting in Paris I took an action (as noted in the >>> > minutes) to poll the WG to see if there was any interest (other than >>> > by the authors of >>> > course) in progressing the IS-IS VPLS draft. >>> > >>> > Would you please respond to this email indicating whether or not you >>> > have interest in seeing this draft progress, ideally giving reasoning >>> > for your position. It'd be especially interesting to see responses >>> > from service providers of course. >>> > >>> > If there are no (or very few) responses to this email then Nabil and >>> I >>> > will probably interpret that as meaning there's insufficient interest >>> > to progress. Of course it may just mean that you all missed this >>> > email in the deluge of debate on E-Tree ;) >>> > >>> > Giles >>> > >> > From jdrake@juniper.net Mon Apr 30 10:14:28 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A71821F8831 for ; Mon, 30 Apr 2012 10:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 HcESNFhcsGYZ for ; Mon, 30 Apr 2012 10:14:27 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id CDD3921F882F for ; Mon, 30 Apr 2012 10:14:26 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKT57IcF+6D+5bXjTyCguyu4c0WYQStbjB@postini.com; Mon, 30 Apr 2012 10:14:26 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 30 Apr 2012 10:14:14 -0700 From: John E Drake To: Lucy yong Date: Mon, 30 Apr 2012 10:14:09 -0700 Subject: Re: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0m9KqlPxVAm0XISI6HHLVh8JGwjA== Message-ID: <13C6662F-E9D8-45D8-A57D-004650045B51@juniper.net> References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDE9C5@EMBX01-HQ.jnpr.net> <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDEB30@EMBX01-HQ.jnpr.net> <2691CE0099834E4A9C5044EEC662BB9D330E5BFA@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D330E5BFA@dfweml505-mbx> 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 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 30 Apr 2012 17:14:28 -0000 What part of 'Bad Idea' do we not understand? Sent from my iPhone On Apr 30, 2012, at 12:47 PM, "Lucy yong" wrote: > John, >=20 > JD: From what I understand, both TRILL and SP can be used to provide the= same capabilities as IS-IS VPLS and they both exist today. >=20 > LY: From the architecture perspective, the backbone implementation betwee= n IS-IS VPLS and TRILL/SPB is completely different. IS-IS VPLS relies on IP= forwarding in core, TRILL/SPB relies on Ethernet forwarding. Why did we de= velop VPLS when there was provider bridging (PB) technology, they served th= e same capability? >=20 >>=20 >> Isn't it good that one control plane protocol can apply to different >> data planes? >=20 > JD: This is a rhetorical question, right? >=20 > LY: I guess that you agree it. :) all the work CCAMP does is to extend th= e control plane protocol to other data planes. >=20 > JD: Just because it has 'VPLS' in its name does not mean it isn't new. = I agree that we don't want to develop anything new for the data center, and= that therefore, IS-IS VPLS is a non-starter. >=20 > LY: One argument we often to hear is that MPLS is too "complicated" for t= he data center. We can see that some complexities have the history reasons = and hardware limitation then. As the chip technology improving, these const= raints no longer exist. We can simplify them for a new area. IS-IS VPLS is = the starting point I see. >=20 >=20 > Thanks, > Lucy >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net]=20 > Sent: Monday, April 30, 2012 11:11 AM > To: Lucy yong; Mach Chen; Giles Heron; l2vpn@ietf.org > Subject: RE: Interest in IS-IS VPLS >=20 > Lucy, >=20 > Comments inline. >=20 > Thanks, >=20 > John >=20 > Sent from my iPhone >=20 >=20 >> -----Original Message----- >> From: Lucy yong [mailto:lucy.yong@huawei.com] >> Sent: Monday, April 30, 2012 8:39 AM >> To: John E Drake; Mach Chen; Giles Heron; l2vpn@ietf.org >> Subject: RE: Interest in IS-IS VPLS >>=20 >> John, >>=20 >> IS-IS VPLS is completely different from TRILL and SPB although they all >> use of IS-IS protocol in control plane. IS-IS VPLS data plane uses an >> IP/GRE tunnel carrying VPN instances differentiated by MPLS labels. >> TRILL and SPB data planes are Ethernet based, i.e. the frames are >> Ethernet frames. >=20 > JD: From what I understand, both TRILL and SP can be used to provide the= same capabilities as IS-IS VPLS and they both exist today. >=20 >>=20 >> Isn't it good that one control plane protocol can apply to different >> data planes? >=20 > JD: This is a rhetorical question, right? >=20 >>=20 >> I agree that VPLS has been well defined and used in Service Provider >> networks. IS-IS VPLS provides the simplified version of VPLS that can >> apply to data center networks. This may be better than developing >> something completely new in data center. >=20 > JD: Just because it has 'VPLS' in its name does not mean it isn't new. = I agree that we don't want to develop anything new for the data center, and= that therefore, IS-IS VPLS is a non-starter. >=20 >=20 >>=20 >> Maybe we need consider another name for this, for example DC-VPN? In >> data center, an VPN is not necessary to provide a service to an >> customer, the infrastructure need VPN capability. >=20 > JD: This sounds like a tautology. >=20 >>=20 >> Regards, >> Lucy >>=20 >>=20 >>=20 >> -----Original Message----- >> From: John E Drake [mailto:jdrake@juniper.net] >> Sent: Monday, April 30, 2012 8:12 AM >> To: Mach Chen; Lucy yong; Giles Heron; l2vpn@ietf.org >> Subject: RE: Interest in IS-IS VPLS >>=20 >> We already have TRILL and SPB. Why is yet another IS-IS variant >> necessary, particularly one that is so completely under-specified? >>=20 >> Sent from my iPhone >>=20 >>=20 >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> Behalf >>> Of Mach Chen >>> Sent: Saturday, April 28, 2012 3:04 AM >>> To: Lucy yong; Giles Heron; l2vpn@ietf.org >>> Subject: RE: Interest in IS-IS VPLS >>>=20 >>> Fully agree with lucy here. >>>=20 >>> In addition, since the ISIS VPLS leverages a uniform protocol(ISIS) >>> for signaling and auto discovery, it would greatly simplify the >>> deployment and maintenance, especially for the DC networks that have >>> already deployed ISIS for IP routing. So I'd like to see the draft >>> moving forward. >>>=20 >>> Best regards, >>> Mach >>>=20 >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>> Behalf >>>> Of Lucy yong >>>> Sent: Saturday, April 28, 2012 2:43 AM >>>> To: Giles Heron; l2vpn@ietf.org >>>> Subject: RE: Interest in IS-IS VPLS >>>>=20 >>>> Hi Giles, >>>>=20 >>>> It seems that the IS-IS VPLS provides the solution for a scalable >>> data >>>> center network as mentioned in the draft. I am not sure it is >> proper >>>> to weight service providers more on this. I can see if a service >>>> provider already deployed existing VPLS, the gain from IS-IS VPLS >> is >>>> less than the cost on upgrading all the edge devices to support the >>> solution. >>>>=20 >>>> However, for data center network, IS-IS VPLS could be a useful >>>> solution. It simplifies current VPLS mechanism, provides a good >>>> scalability, and requires IP only function on core switches. >>>>=20 >>>> A vendor provides devices for both service provider network and >> data >>>> center network, the solution brings a synergy in leveraging VPLS >>>> solution into DC. >>>>=20 >>>> Thus, I like to see this work moving forward. >>>>=20 >>>> Regards, >>>> Lucy >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>> Behalf >>>> Of Giles Heron >>>> Sent: Friday, April 27, 2012 7:57 AM >>>> To: l2vpn@ietf.org >>>> Subject: Interest in IS-IS VPLS >>>>=20 >>>> Hi, >>>>=20 >>>> At the IETF meeting in Paris I took an action (as noted in the >>>> minutes) to poll the WG to see if there was any interest (other >> than >>>> by the authors of >>>> course) in progressing the IS-IS VPLS draft. >>>>=20 >>>> Would you please respond to this email indicating whether or not >> you >>>> have interest in seeing this draft progress, ideally giving >>>> reasoning for your position. It'd be especially interesting to see >>>> responses from service providers of course. >>>>=20 >>>> If there are no (or very few) responses to this email then Nabil >> and >>> I >>>> will probably interpret that as meaning there's insufficient >>>> interest to progress. Of course it may just mean that you all >>>> missed this email in the deluge of debate on E-Tree ;) >>>>=20 >>>> Giles >>>>=20 >=20 From sajassi@cisco.com Mon Apr 30 10:18:17 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9B721F8802 for ; Mon, 30 Apr 2012 10:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.704 X-Spam-Level: X-Spam-Status: No, score=-9.704 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 EYsRU8R4NoSe for ; Mon, 30 Apr 2012 10:18:16 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 06D1E21F87FA for ; Mon, 30 Apr 2012 10:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sajassi@cisco.com; l=926; q=dns/txt; s=iport; t=1335806289; x=1337015889; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=aHE2EEgQxQxRPLZBwFXzvjX7+ZcBaCPBPH9QdgBhOZU=; b=CydW4I8biupnyUEbqZmvKDplr4QbqOl9JtpgyxQYD+jimgU2ceV/yvnT iOEkG1uCY0HoK8ivumPnX7p0WhsU71KF4mLlDhfKR63gX/8Wgl+k7aC+i eHriX4J56G9UKwmpueCrLlgf4GhskE+0l//LllZTfm8pmAYU9jeQq6W0r U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAETInk+rRDoG/2dsb2JhbABEr06DAIEHggkBAQEDARIBJwIBQQ0BCAleNgEBBAESIoddAwYEAZovlhkNiVOKDIcWBIhihS+HbYs/gxqBaYJ3gU0 X-IronPort-AV: E=Sophos;i="4.75,505,1330905600"; d="scan'208";a="39709886" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 30 Apr 2012 17:18:09 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3UHI9C9016749; Mon, 30 Apr 2012 17:18:09 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Apr 2012 10:18:09 -0700 Received: from 10.128.2.31 ([10.128.2.31]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Mon, 30 Apr 2012 17:18:08 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 30 Apr 2012 10:18:08 +0900 Subject: Re: Interest in IS-IS VPLS From: sajassi To: Giles Heron , Message-ID: Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugCf+7FU In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Apr 2012 17:18:09.0623 (UTC) FILETIME=[370FAE70:01CD26F5] X-BeenThere: l2vpn@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, 30 Apr 2012 17:18:17 -0000 Not interested. I provided my reasons both at the mic and w/ follow-up emails. -Ali On 4/27/12 9:57 PM, "Giles Heron" wrote: > Hi, > > At the IETF meeting in Paris I took an action (as noted in the minutes) to > poll the WG to see if there was any interest (other than by the authors of > course) in progressing the IS-IS VPLS draft. > > Would you please respond to this email indicating whether or not you have > interest in seeing this draft progress, ideally giving reasoning for your > position. It'd be especially interesting to see responses from service > providers of course. > > If there are no (or very few) responses to this email then Nabil and I will > probably interpret that as meaning there's insufficient interest to > progress. Of course it may just mean that you all missed this email in the > deluge of debate on E-Tree ;) > > Giles > > From wim.henderickx@alcatel-lucent.com Mon Apr 30 10:19:38 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9748B21F8852 for ; Mon, 30 Apr 2012 10:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.954 X-Spam-Level: X-Spam-Status: No, score=-9.954 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 eTNPqMCKfVRB for ; Mon, 30 Apr 2012 10:19:38 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 91E1F21F8850 for ; Mon, 30 Apr 2012 10:19:37 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3UHJZf8021294 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Apr 2012 19:19:35 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 30 Apr 2012 19:19:35 +0200 From: "Henderickx, Wim (Wim)" To: Giles Heron , "l2vpn@ietf.org" Date: Mon, 30 Apr 2012 19:19:34 +0200 Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugCgBXHQ Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D67023EBC82CC@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 X-BeenThere: l2vpn@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, 30 Apr 2012 17:19:38 -0000 Not interested. If the problem needs to be solved it should be discussed in= NVO3 -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of G= iles Heron Sent: vrijdag 27 april 2012 14:57 To: l2vpn@ietf.org Subject: Interest in IS-IS VPLS Hi, At the IETF meeting in Paris I took an action (as noted in the minutes) to poll the WG to see if there was any interest (other than by the authors of course) in progressing the IS-IS VPLS draft. Would you please respond to this email indicating whether or not you have interest in seeing this draft progress, ideally giving reasoning for your position. It'd be especially interesting to see responses from service providers of course. If there are no (or very few) responses to this email then Nabil and I will probably interpret that as meaning there's insufficient interest to progress. Of course it may just mean that you all missed this email in the deluge of debate on E-Tree ;) Giles From lieven.levrau@alcatel-lucent.com Mon Apr 30 10:21:13 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570B011E8073 for ; Mon, 30 Apr 2012 10:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 Kgke18x37xsT for ; Mon, 30 Apr 2012 10:21:12 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id E9E4511E8074 for ; Mon, 30 Apr 2012 10:21:11 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3UHL00H000427 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Apr 2012 19:21:00 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 30 Apr 2012 19:21:00 +0200 From: "LEVRAU, LIEVEN (LIEVEN)" To: Lucy yong , John E Drake , Mach Chen , Giles Heron , "l2vpn@ietf.org" Date: Mon, 30 Apr 2012 19:20:48 +0200 Subject: Re: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0m9ZyM62ZxRUubQgWZ2O7pm9I0ew== Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D330E5C5B@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 X-BeenThere: l2vpn@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, 30 Apr 2012 17:21:13 -0000 Hmm interesting by adding more protocols to the mix and hope that things will work out? Not sure I can follow that trail of thought - how entertaining it might look. ./ Lieven On 30/04/12 19:09, "Lucy yong" wrote: >I guess that the benefit is to make the solution better and better. >Lucy > >-----Original Message----- >From: LEVRAU, LIEVEN (LIEVEN) [mailto:lieven.levrau@alcatel-lucent.com] >Sent: Monday, April 30, 2012 12:04 PM >To: Lucy yong; John E Drake; Mach Chen; Giles Heron; l2vpn@ietf.org >Subject: Re: Interest in IS-IS VPLS > >Hi Lucy - That is not the point > >The point is that we would need yet another interconnection model=A9. And = to >what benefit? > >./ >Lieven > >On 30/04/12 18:50, "Lucy yong" wrote: > >>No I don't think so - as that creates interop issues and gateway >>functions >>when connecting different control planes together. >> >>[LY] Do you deny all the works in CCAMP? >> >>Lucy >> >>-----Original Message----- >>From: LEVRAU, LIEVEN (LIEVEN) [mailto:lieven.levrau@alcatel-lucent.com] >>Sent: Monday, April 30, 2012 11:13 AM >>To: Lucy yong; John E Drake; Mach Chen; Giles Heron; l2vpn@ietf.org >>Subject: Re: Interest in IS-IS VPLS >> >>inline >> >>On 30/04/12 17:38, "Lucy yong" wrote: >> >>>John, >>> >>>IS-IS VPLS is completely different from TRILL and SPB although they all >>>use of IS-IS protocol in control plane. IS-IS VPLS data plane uses an >>>IP/GRE tunnel carrying VPN instances differentiated by MPLS labels. >>>TRILL >>>and SPB data planes are Ethernet based, i.e. the frames are Ethernet >>>frames. >>> >>>Isn't it good that one control plane protocol can apply to different >>>data >>>planes? >>No I don't think so - as that creates interop issues and gateway >>functions >>when connecting different control planes together. >>>=20 >>> >>>I agree that VPLS has been well defined and used in Service Provider >>>networks. IS-IS VPLS provides the simplified version of VPLS that can >>>apply to data center networks. This may be better than developing >>>something completely new in data center. >>> >>>Maybe we need consider another name for this, for example DC-VPN? In >>>data >>>center, an VPN is not necessary to provide a service to an customer, the >>>infrastructure need VPN capability. >>Ok lets not - if there are tools out there that can be built upon, why >>introduce a new thing which there seems very little interest and retry by >>given the same new thing a different name. >> >>> >>>Regards, >>>Lucy=20 >>> >>> >>> >>>-----Original Message----- >>>From: John E Drake [mailto:jdrake@juniper.net] >>>Sent: Monday, April 30, 2012 8:12 AM >>>To: Mach Chen; Lucy yong; Giles Heron; l2vpn@ietf.org >>>Subject: RE: Interest in IS-IS VPLS >>> >>>We already have TRILL and SPB. Why is yet another IS-IS variant >>>necessary, particularly one that is so completely under-specified? >>> >>>Sent from my iPhone >>> >>> >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>> Of Mach Chen >>>> Sent: Saturday, April 28, 2012 3:04 AM >>>> To: Lucy yong; Giles Heron; l2vpn@ietf.org >>>> Subject: RE: Interest in IS-IS VPLS >>>>=20 >>>> Fully agree with lucy here. >>>>=20 >>>> In addition, since the ISIS VPLS leverages a uniform protocol(ISIS) >>>>for >>>> signaling and auto discovery, it would greatly simplify the deployment >>>> and maintenance, especially for the DC networks that have already >>>> deployed ISIS for IP routing. So I'd like to see the draft moving >>>> forward. >>>>=20 >>>> Best regards, >>>> Mach >>>>=20 >>>> > -----Original Message----- >>>> > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>>> Behalf >>>> > Of Lucy yong >>>> > Sent: Saturday, April 28, 2012 2:43 AM >>>> > To: Giles Heron; l2vpn@ietf.org >>>> > Subject: RE: Interest in IS-IS VPLS >>>> > >>>> > Hi Giles, >>>> > >>>> > It seems that the IS-IS VPLS provides the solution for a scalable >>>> data >>>> > center network as mentioned in the draft. I am not sure it is proper >>>> > to weight service providers more on this. I can see if a service >>>> > provider already deployed existing VPLS, the gain from IS-IS VPLS is >>>> > less than the cost on upgrading all the edge devices to support the >>>> solution. >>>> > >>>> > However, for data center network, IS-IS VPLS could be a useful >>>> > solution. It simplifies current VPLS mechanism, provides a good >>>> > scalability, and requires IP only function on core switches. >>>> > >>>> > A vendor provides devices for both service provider network and data >>>> > center network, the solution brings a synergy in leveraging VPLS >>>> > solution into DC. >>>> > >>>> > Thus, I like to see this work moving forward. >>>> > >>>> > Regards, >>>> > Lucy >>>> > >>>> > >>>> > >>>> > -----Original Message----- >>>> > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>>> Behalf >>>> > Of Giles Heron >>>> > Sent: Friday, April 27, 2012 7:57 AM >>>> > To: l2vpn@ietf.org >>>> > Subject: Interest in IS-IS VPLS >>>> > >>>> > Hi, >>>> > >>>> > At the IETF meeting in Paris I took an action (as noted in the >>>> > minutes) to poll the WG to see if there was any interest (other than >>>> > by the authors of >>>> > course) in progressing the IS-IS VPLS draft. >>>> > >>>> > Would you please respond to this email indicating whether or not you >>>> > have interest in seeing this draft progress, ideally giving >>>>reasoning >>>> > for your position. It'd be especially interesting to see responses >>>> > from service providers of course. >>>> > >>>> > If there are no (or very few) responses to this email then Nabil and >>>> I >>>> > will probably interpret that as meaning there's insufficient >>>>interest >>>> > to progress. Of course it may just mean that you all missed this >>>> > email in the deluge of debate on E-Tree ;) >>>> > >>>> > Giles >>>> > >>> >> > From yaakov_s@rad.com Mon Apr 30 10:55:24 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1388921F88C2 for ; Mon, 30 Apr 2012 10:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 TSr+YM2lPtgU for ; Mon, 30 Apr 2012 10:55:20 -0700 (PDT) Received: from rad.co.il (mailrelay02-q.rad.co.il [94.188.133.159]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACAC21F88BF for ; Mon, 30 Apr 2012 10:55:16 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 30 Apr 2012 20:38:30 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.01.0323.003; Mon, 30 Apr 2012 20:55:11 +0300 From: Yaakov Stein To: "stbryant@cisco.com" , "l2vpn@ietf.org" , pwe3 Subject: RE: IPR Statements concerning etree Thread-Topic: IPR Statements concerning etree Thread-Index: AQHNHwM0TCn7gW/V0UuYebtPmzR2Kpazsu9w Date: Mon, 30 Apr 2012 17:55:10 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9043C1CCE@EXRAD5.ad.rad.co.il> References: <51AC216A-75C8-4075-AA23-D80081CB61CA@vigilsec.com> <4F9174A3.6000102@cisco.com> In-Reply-To: <4F9174A3.6000102@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.140.53] Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC9043C1CCEEXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090209.4F9ED200.0069,ss=1,fgs=0 X-BeenThere: l2vpn@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, 30 Apr 2012 17:55:24 -0000 --_000_07F7D7DED63154409F13298786A2ADC9043C1CCEEXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You needn't all seven disclosures - they all refer to the same US application (11/508,599) and its family. If you are experiencing difficulties in finding this application, it is simply because the distinguished IPR disclosure submitter seems to ha= ve forgotten that this application was granted in early 2010, and is now US 7,660,303 "POINT-TO-MULTIPOINT FUNCTIONALITY IN A BRIDGED NET= WORK". The priority date seems to be 22 Aug 2006. Y(J)S From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of S= tewart Bryant Sent: Friday, April 20, 2012 17:37 To: l2vpn@ietf.org; l2vpn-chairs@tools.ietf.org; pwe3; pwe3-chairs@tools.ie= tf.org Subject: Fwd: IPR Statements concerning etree WGs, You may wish to look at the following IPR statements that were received yesterday. They all relate to etree. The stated terms appear to require payment of a royalty. Stewart -------- Original Message -------- Subject: IPR Statements Date: Thu, 19 Apr 2012 13:04:27 -0400 From: Russ Housley To: Stewart Bryant Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:14:30 PM EDT > To: simon.delord@gmail.com, raymond.key@ie= ee.org, wim.henderickx@alcatel-lucent.com, lucy.yong@huawei.com, lizhong.jin@zte.com.cn, frede= ric.jounay@orange.ch > Cc: housley@vigilsec.com, ipr-announce@ietf.= org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR relat= ed to draft-delord-pwe3-cw-bit-etree-07 > > > Dear Simon DeLord, Raymond Key, Wim Henderickx, Lucy Yong, Lizhong Jin, F= rederic JOUNAY: > > An IPR disclosure that pertains to your Internet-Draft entitled "Control = Word > Reserved bit for use in E-Tree" (draft-delord-pwe3-cw-bit-etree) was subm= itted > to the IETF Secretariat on 2012-04-19 and has been posted on the "IETF Pa= ge of > Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/i= pr/1760/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's State= ment about IPR related to draft-delord-pwe3-cw-bit-etree-07.""); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:15:08 PM EDT > To: yuqun.cao@gmail.com > Cc: housley@vigilsec.com, ipr-announce@ietf.= org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR relat= ed to draft-cao-l2vpn-vpls-etree-02 > > > Dear Yuqun Cao: > > An IPR disclosure that pertains to your Internet-Draft entitled "Extensio= n to > VPLS for E-Tree" (draft-cao-l2vpn-vpls-etree) was submitted to the IETF > Secretariat on 2012-04-19 and has been posted on the "IETF Page of Intell= ectual > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1759/). Th= e title > of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR rela= ted to > draft-cao-l2vpn-vpls-etree-02."); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:15:34 PM EDT > To: chen.ran@zte.com.cn > Cc: housley@vigilsec.com, ipr-announce@ietf.= org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR relat= ed to draft-chen-l2vpn-vpls-etree-vlan-01 > > > Dear Ran Chen: > > An IPR disclosure that pertains to your Internet-Draft entitled "Automati= c VLAN > allocation in E-tree" (draft-chen-l2vpn-vpls-etree-vlan) was submitted to= the > IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of > Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/i= pr/1758/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's State= ment about IPR related to draft-chen-l2vpn-vpls-etree-vlan-01."); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:16:29 PM EDT > To: jiangyuanlong@huawei.com, lucyyong@h= uawei.com, Manuel.Paul@telekom.de, frederic.jounay@orange.ch, florin.balus@alcatel-lucent.com, wim.henderickx@alcatel-lucent.com, sajassi@cisco.com > Cc: housley@vigilsec.com, ipr-announce@ietf.= org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR relat= ed to draft-jiang-l2vpn-etree-bgp-00 > > > Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Balu= s, Wim Henderickx, Ali Sajassi: > > An IPR disclosure that pertains to your Internet-Draft entitled "E-Tree S= upport > in VPLS with BGP Signaling" (draft-jiang-l2vpn-etree-bgp) was submitted t= o the > IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of > Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/i= pr/1757/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's State= ment about IPR related to draft-jiang-l2vpn-etree-bgp-00."); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:17:02 PM EDT > To: yljiang@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.de, frederic.jounay@orange-ftgroup.com, florin.balus@alcatel-lucent.com, wim.henderickx@alcatel-lucent.com > Cc: housley@vigilsec.com, ipr-announce@ietf.= org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR relat= ed to draft-jiang-l2vpn-vpls-pe-etree-05 > > > Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Balu= s, Wim Henderickx: > > An IPR disclosure that pertains to your Internet-Draft entitled "VPLS PE = Model > for E-Tree Support" (draft-jiang-l2vpn-vpls-pe-etree) was submitted to th= e IETF > Secretariat on 2012-04-19 and has been posted on the "IETF Page of Intell= ectual > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1756/). Th= e title > of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR rela= ted to > draft-jiang-l2vpn-vpls-pe-etree-05.""); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:17:48 PM EDT > To: danielc@orckit.com, rafir@orckit.com, pagarwal@broadcom.com, r= aymond.key@team.telstra.com > Cc: housley@vigilsec.com, ipr-announce@ietf.= org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR relat= ed to draft-ram-l2vpn-ldp-vpls-etree-2pw-02 > > > Dear Daniel Cohn, Rafi Ram, Puneet Agarwal, Raymond Key: > > An IPR disclosure that pertains to your Internet-Draft entitled "Extensio= n to > LDP-VPLS for E-Tree Using Two PW" (draft-ram-l2vpn-ldp-vpls-etree-2pw) wa= s > submitted to the IETF Secretariat on 2012-04-19 and has been posted on th= e "IETF Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1755/). The title of the IPR disclosure= is > "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-ld= p-vpls- > etree-2pw-02.""); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:18:32 PM EDT > To: rafir@orckit.com, danielc@orckit.com, raymond.key@ieee.org, pag= arwal@broadcom.com, josh.rogers@twcable.com > Cc: housley@vigilsec.com, ipr-announce@ietf.= org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR relat= ed to draft-ram-l2vpn-etree-multiple-pw-01 > > > Dear Rafi Ram, Daniel Cohn, Raymond Key, Puneet Agarwal, Joshua Rogers: > > An IPR disclosure that pertains to your Internet-Draft entitled "Extensio= n to > VPLS for E-Tree Using Multiple PWs" (draft-ram-l2vpn-etree-multiple-pw) w= as > submitted to the IETF Secretariat on 2012-04-19 and has been posted on th= e "IETF > Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1754/). The title of the IPR disclosure= is > "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-et= ree- > multiple-pw-01.""); > > The IETF Secretariat > --_000_07F7D7DED63154409F13298786A2ADC9043C1CCEEXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

You needn't all seven disclosures -

they all refer to the same US application (11/508,599) and i= ts family.

 

If you are experiencing difficulties in finding this applica= tion,

it is simply because the distinguished IPR disclosure submit= ter seems to have forgotten

that this application was granted in early 2010,<= /span>

and is now US 7,660,303 "POINT-TO-MULTIPOINT FUNCTIONAL= ITY IN A BRIDGED NETWORK".

The priority date seems to be 22 Aug 2006.=

 

Y(J)S

 

 

From: l2vpn-bounces@= ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Friday, April 20, 2012 17:37
To: l2vpn@ietf.org; l2vpn-chairs@tools.ietf.org; pwe3; pwe3-chairs@t= ools.ietf.org
Subject: Fwd: IPR Statements concerning etree

 


WGs,

You may wish to look at the following IPR statements that were
received yesterday.

They all relate to etree.

The stated terms appear to require payment of a royalty.

Stewart


-------- Original Message --------

Subjec= t:

IPR Statements

Date: =

Thu, 19 Apr 2012 13:04:27 -0400

From: =

Russ Housley <housley@vigilsec.com>

To:

Stewart Bryant <stbryant@cisco.com>

 

 
Begin forwarded message:
 
> From: IETF Secretariat <i=
etf-ipr@ietf.org>
> Date: April 19, 2012 12:14:30 PM EDT
> To: simon.delord@gmail.=
com, raymond.key@ieee.org, =
wim.henderickx@alcatel=
-lucent.com, lucy.yong@huawei.c=
om, lizhong.jin@zte.com.cn, frederic.jounay@orange.ch
> Cc: housley@vigilsec.com<=
/a>, ipr-announce@ietf.org
> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about I=
PR related to draft-delord-pwe3-cw-bit-etree-07
> 
> 
> Dear Simon DeLord, Raymond Key, Wim Henderickx, Lucy Yong, Lizhon=
g Jin, Frederic JOUNAY:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled &=
quot;Control Word
> Reserved bit for use in E-Tree" (draft-delord-pwe3-cw-bit-et=
ree) was submitted
> to the IETF Secretariat on 2012-04-19 and has been posted on the =
"IETF Page of
> Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1760/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Stateme=
nt about IPR related to draft-delord-pwe3-cw-bit-etree-07."");
> 
> The IETF Secretariat
> 
Begin forwarded message:
 
> From: IETF Secretariat <i=
etf-ipr@ietf.org>
> Date: April 19, 2012 12:15:08 PM EDT
> To: yuqun.cao@gmail.com
> Cc: housley@vigilsec.com<=
/a>, ipr-announce@ietf.org
> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about I=
PR related to draft-cao-l2vpn-vpls-etree-02
> 
> 
> Dear Yuqun Cao:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled &=
quot;Extension to
> VPLS for E-Tree" (draft-cao-l2vpn-vpls-etree) was submitted =
to the IETF
> Secretariat on 2012-04-19 and has been posted on the "IETF P=
age of Intellectual
> Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1759/). The title=

> of the IPR disclosure is "Orckit-Corrigent Ltd's Statement a=
bout IPR related to
> draft-cao-l2vpn-vpls-etree-02.");
> 
> The IETF Secretariat
> 
Begin forwarded message:
 
> From: IETF Secretariat <i=
etf-ipr@ietf.org>
> Date: April 19, 2012 12:15:34 PM EDT
> To: chen.ran@zte.com.cn
> Cc: housley@vigilsec.com<=
/a>, ipr-announce@ietf.org
> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about I=
PR related to draft-chen-l2vpn-vpls-etree-vlan-01
> 
> 
> Dear Ran Chen:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled &=
quot;Automatic VLAN
> allocation in E-tree" (draft-chen-l2vpn-vpls-etree-vlan) was=
 submitted to the
> IETF Secretariat on 2012-04-19 and has been posted on the "I=
ETF Page of
> Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1758/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Stateme=
nt about IPR related to draft-chen-l2vpn-vpls-etree-vlan-01.");
> 
> The IETF Secretariat
> 
Begin forwarded message:
 
> From: IETF Secretariat <i=
etf-ipr@ietf.org>
> Date: April 19, 2012 12:16:29 PM EDT
> To: jiangyuanlong@hua=
wei.com, lucyyong@huawei.com=
, Manuel.Paul@telekom.de, frederic.jounay@orange.ch, florin.balus@alcatel-lucen=
t.com, wim.henderi=
ckx@alcatel-lucent.com, sajassi@ci=
sco.com
> Cc: housley@vigilsec.com<=
/a>, ipr-announce@ietf.org
> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about I=
PR related to draft-jiang-l2vpn-etree-bgp-00
> 
> 
> Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Flo=
rin Balus, Wim Henderickx, Ali Sajassi:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled &=
quot;E-Tree Support
> in VPLS with BGP Signaling" (draft-jiang-l2vpn-etree-bgp) wa=
s submitted to the
> IETF Secretariat on 2012-04-19 and has been posted on the "I=
ETF Page of
> Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1757/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Stateme=
nt about IPR related to draft-jiang-l2vpn-etree-bgp-00.");<=
/pre>

> 


> The IETF Secretariat


> 


Begin forwarded message:


 


> From: IETF Secretariat <i=
etf-ipr@ietf.org>


> Date: April 19, 2012 12:17:02 PM EDT


> To: yljiang@huawei.com,=
 lucyyong@huawei.com, Manuel.Paul@telekom.de, frederic.jounay@orange-ftgroup.com, florin.balus@alcatel=
-lucent.com, wim.h=
enderickx@alcatel-lucent.com


> Cc: housley@vigilsec.com<=
/a>, ipr-announce@ietf.org


> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about I=
PR related to draft-jiang-l2vpn-vpls-pe-etree-05


> 


> 


> Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Flo=
rin Balus, Wim Henderickx:


> 


> An IPR disclosure that pertains to your Internet-Draft entitled &=
quot;VPLS PE Model


> for E-Tree Support" (draft-jiang-l2vpn-vpls-pe-etree) was su=
bmitted to the IETF


> Secretariat on 2012-04-19 and has been posted on the "IETF P=
age of Intellectual


> Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1756/). The title=



> of the IPR disclosure is "Orckit-Corrigent Ltd's Statement a=
bout IPR related to


> draft-jiang-l2vpn-vpls-pe-etree-05."");

> 


> The IETF Secretariat


> 


Begin forwarded message:


 


> From: IETF Secretariat <i=
etf-ipr@ietf.org>


> Date: April 19, 2012 12:17:48 PM EDT


> To: danielc@orckit.com,=
 rafir@orckit.com, pagarwal@broadcom.com, raymond.key@team.telstra.com


> Cc: housley@vigilsec.com<=
/a>, ipr-announce@ietf.org


> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about I=
PR related to draft-ram-l2vpn-ldp-vpls-etree-2pw-02


> 


> 


> Dear Daniel Cohn, Rafi Ram, Puneet Agarwal, Raymond Key:


> 


> An IPR disclosure that pertains to your Internet-Draft entitled &=
quot;Extension to


> LDP-VPLS for E-Tree Using Two PW" (draft-ram-l2vpn-ldp-vpls-=
etree-2pw) was


> submitted to the IETF Secretariat on 2012-04-19 and has been post=
ed on the "IETF Page of Intellectual Property Rights Disclosures"=



> (https://datat=
racker.ietf.org/ipr/1755/). The title of the IPR disclosure is


> "Orckit-Corrigent Ltd's Statement about IPR related to draft=
-ram-l2vpn-ldp-vpls-


> etree-2pw-02."");


> 


> The IETF Secretariat


> 


Begin forwarded message:


 


> From: IETF Secretariat <i=
etf-ipr@ietf.org>


> Date: April 19, 2012 12:18:32 PM EDT


> To: rafir@orckit.com, danielc@orckit.com, raymond.key@ieee.org, pagarwal@broadcom.com, josh.rogers@twcable.com


> Cc: housley@vigilsec.com<=
/a>, ipr-announce@ietf.org


> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about I=
PR related to draft-ram-l2vpn-etree-multiple-pw-01


> 


> 


> Dear Rafi Ram, Daniel Cohn, Raymond Key, Puneet Agarwal, Joshua R=
ogers:


> 


> An IPR disclosure that pertains to your Internet-Draft entitled &=
quot;Extension to


> VPLS for E-Tree Using Multiple PWs" (draft-ram-l2vpn-etree-m=
ultiple-pw) was


> submitted to the IETF Secretariat on 2012-04-19 and has been post=
ed on the "IETF


> Page of Intellectual Property Rights Disclosures"=



> (https://datat=
racker.ietf.org/ipr/1754/). The title of the IPR disclosure is


> "Orckit-Corrigent Ltd's Statement about IPR related to draft=
-ram-l2vpn-etree-


> multiple-pw-01."");


> 


> The IETF Secretariat


> 


 


 
--_000_07F7D7DED63154409F13298786A2ADC9043C1CCEEXRAD5adradcoil_-- From linda.dunbar@huawei.com Mon Apr 30 11:04:18 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8731811E8086 for ; Mon, 30 Apr 2012 11:04:18 -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] 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 Dxk8KyGRYALm for ; Mon, 30 Apr 2012 11:04:17 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 31DD411E8073 for ; Mon, 30 Apr 2012 11:04:16 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFK29794; Mon, 30 Apr 2012 14:04:15 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Apr 2012 11:02:02 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Mon, 30 Apr 2012 11:01:52 -0700 From: Linda Dunbar To: Lucy yong , John E Drake , Mach Chen , Giles Heron , "l2vpn@ietf.org" Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAAcwK+MAAEDOFgAAYZkLA= Date: Mon, 30 Apr 2012 18:01:51 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F6339049E4@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDE9C5@EMBX01-HQ.jnpr.net> <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@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, 30 Apr 2012 18:04:18 -0000 Agree with Lucy, DC-VPN might be a better name.=20 Linda > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Lucy yong > Sent: Monday, April 30, 2012 10:39 AM > To: John E Drake; Mach Chen; Giles Heron; l2vpn@ietf.org > Subject: RE: Interest in IS-IS VPLS >=20 > John, >=20 > IS-IS VPLS is completely different from TRILL and SPB although they all > use of IS-IS protocol in control plane. IS-IS VPLS data plane uses an > IP/GRE tunnel carrying VPN instances differentiated by MPLS labels. > TRILL and SPB data planes are Ethernet based, i.e. the frames are > Ethernet frames. >=20 > Isn't it good that one control plane protocol can apply to different > data planes? >=20 > I agree that VPLS has been well defined and used in Service Provider > networks. IS-IS VPLS provides the simplified version of VPLS that can > apply to data center networks. This may be better than developing > something completely new in data center. >=20 > Maybe we need consider another name for this, for example DC-VPN? In > data center, an VPN is not necessary to provide a service to an > customer, the infrastructure need VPN capability. >=20 > Regards, > Lucy >=20 >=20 >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Monday, April 30, 2012 8:12 AM > To: Mach Chen; Lucy yong; Giles Heron; l2vpn@ietf.org > Subject: RE: Interest in IS-IS VPLS >=20 > We already have TRILL and SPB. Why is yet another IS-IS variant > necessary, particularly one that is so completely under-specified? >=20 > Sent from my iPhone >=20 >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > > Of Mach Chen > > Sent: Saturday, April 28, 2012 3:04 AM > > To: Lucy yong; Giles Heron; l2vpn@ietf.org > > Subject: RE: Interest in IS-IS VPLS > > > > Fully agree with lucy here. > > > > In addition, since the ISIS VPLS leverages a uniform protocol(ISIS) > for > > signaling and auto discovery, it would greatly simplify the > deployment > > and maintenance, especially for the DC networks that have already > > deployed ISIS for IP routing. So I'd like to see the draft moving > > forward. > > > > Best regards, > > Mach > > > > > -----Original Message----- > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > > Behalf > > > Of Lucy yong > > > Sent: Saturday, April 28, 2012 2:43 AM > > > To: Giles Heron; l2vpn@ietf.org > > > Subject: RE: Interest in IS-IS VPLS > > > > > > Hi Giles, > > > > > > It seems that the IS-IS VPLS provides the solution for a scalable > > data > > > center network as mentioned in the draft. I am not sure it is > proper > > > to weight service providers more on this. I can see if a service > > > provider already deployed existing VPLS, the gain from IS-IS VPLS > is > > > less than the cost on upgrading all the edge devices to support the > > solution. > > > > > > However, for data center network, IS-IS VPLS could be a useful > > > solution. It simplifies current VPLS mechanism, provides a good > > > scalability, and requires IP only function on core switches. > > > > > > A vendor provides devices for both service provider network and > data > > > center network, the solution brings a synergy in leveraging VPLS > > > solution into DC. > > > > > > Thus, I like to see this work moving forward. > > > > > > Regards, > > > Lucy > > > > > > > > > > > > -----Original Message----- > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > > Behalf > > > Of Giles Heron > > > Sent: Friday, April 27, 2012 7:57 AM > > > To: l2vpn@ietf.org > > > Subject: Interest in IS-IS VPLS > > > > > > Hi, > > > > > > At the IETF meeting in Paris I took an action (as noted in the > > > minutes) to poll the WG to see if there was any interest (other > than > > > by the authors of > > > course) in progressing the IS-IS VPLS draft. > > > > > > Would you please respond to this email indicating whether or not > you > > > have interest in seeing this draft progress, ideally giving > reasoning > > > for your position. It'd be especially interesting to see responses > > > from service providers of course. > > > > > > If there are no (or very few) responses to this email then Nabil > and > > I > > > will probably interpret that as meaning there's insufficient > interest > > > to progress. Of course it may just mean that you all missed this > > > email in the deluge of debate on E-Tree ;) > > > > > > Giles > > > From jdrake@juniper.net Mon Apr 30 11:33:38 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF95621F88FF for ; Mon, 30 Apr 2012 11:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 RZh6+8DVfBIV for ; Mon, 30 Apr 2012 11:33:38 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id D986821F88FC for ; Mon, 30 Apr 2012 11:33:37 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKT57a/nTWTzXOLBuP6RnObCiFcZ8xc37h@postini.com; Mon, 30 Apr 2012 11:33:37 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 30 Apr 2012 11:32:52 -0700 From: John E Drake To: Linda Dunbar , Lucy yong , Mach Chen , Giles Heron , "l2vpn@ietf.org" Date: Mon, 30 Apr 2012 11:32:51 -0700 Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAAcwK+MAAEDOFgAAYZkLAAARDbgA== Message-ID: <5E893DB832F57341992548CDBB333163A56EEDED4C@EMBX01-HQ.jnpr.net> References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDE9C5@EMBX01-HQ.jnpr.net> <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> <4A95BA014132FF49AE685FAB4B9F17F6339049E4@dfweml505-mbx> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6339049E4@dfweml505-mbx> 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-BeenThere: l2vpn@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, 30 Apr 2012 18:33:38 -0000 How about DOA? (Dead On Arrival) Sent from my iPhone > -----Original Message----- > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > Sent: Monday, April 30, 2012 11:02 AM > To: Lucy yong; John E Drake; Mach Chen; Giles Heron; l2vpn@ietf.org > Subject: RE: Interest in IS-IS VPLS >=20 > Agree with Lucy, DC-VPN might be a better name. >=20 > Linda >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > > Of Lucy yong > > Sent: Monday, April 30, 2012 10:39 AM > > To: John E Drake; Mach Chen; Giles Heron; l2vpn@ietf.org > > Subject: RE: Interest in IS-IS VPLS > > > > John, > > > > IS-IS VPLS is completely different from TRILL and SPB although they > > all use of IS-IS protocol in control plane. IS-IS VPLS data plane > uses > > an IP/GRE tunnel carrying VPN instances differentiated by MPLS > labels. > > TRILL and SPB data planes are Ethernet based, i.e. the frames are > > Ethernet frames. > > > > Isn't it good that one control plane protocol can apply to different > > data planes? > > > > I agree that VPLS has been well defined and used in Service Provider > > networks. IS-IS VPLS provides the simplified version of VPLS that can > > apply to data center networks. This may be better than developing > > something completely new in data center. > > > > Maybe we need consider another name for this, for example DC-VPN? In > > data center, an VPN is not necessary to provide a service to an > > customer, the infrastructure need VPN capability. > > > > Regards, > > Lucy > > > > > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Monday, April 30, 2012 8:12 AM > > To: Mach Chen; Lucy yong; Giles Heron; l2vpn@ietf.org > > Subject: RE: Interest in IS-IS VPLS > > > > We already have TRILL and SPB. Why is yet another IS-IS variant > > necessary, particularly one that is so completely under-specified? > > > > Sent from my iPhone > > > > > > > -----Original Message----- > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > > Behalf > > > Of Mach Chen > > > Sent: Saturday, April 28, 2012 3:04 AM > > > To: Lucy yong; Giles Heron; l2vpn@ietf.org > > > Subject: RE: Interest in IS-IS VPLS > > > > > > Fully agree with lucy here. > > > > > > In addition, since the ISIS VPLS leverages a uniform protocol(ISIS) > > for > > > signaling and auto discovery, it would greatly simplify the > > deployment > > > and maintenance, especially for the DC networks that have already > > > deployed ISIS for IP routing. So I'd like to see the draft moving > > > forward. > > > > > > Best regards, > > > Mach > > > > > > > -----Original Message----- > > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > > > Behalf > > > > Of Lucy yong > > > > Sent: Saturday, April 28, 2012 2:43 AM > > > > To: Giles Heron; l2vpn@ietf.org > > > > Subject: RE: Interest in IS-IS VPLS > > > > > > > > Hi Giles, > > > > > > > > It seems that the IS-IS VPLS provides the solution for a scalable > > > data > > > > center network as mentioned in the draft. I am not sure it is > > proper > > > > to weight service providers more on this. I can see if a service > > > > provider already deployed existing VPLS, the gain from IS-IS VPLS > > is > > > > less than the cost on upgrading all the edge devices to support > > > > the > > > solution. > > > > > > > > However, for data center network, IS-IS VPLS could be a useful > > > > solution. It simplifies current VPLS mechanism, provides a good > > > > scalability, and requires IP only function on core switches. > > > > > > > > A vendor provides devices for both service provider network and > > data > > > > center network, the solution brings a synergy in leveraging VPLS > > > > solution into DC. > > > > > > > > Thus, I like to see this work moving forward. > > > > > > > > Regards, > > > > Lucy > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > > > Behalf > > > > Of Giles Heron > > > > Sent: Friday, April 27, 2012 7:57 AM > > > > To: l2vpn@ietf.org > > > > Subject: Interest in IS-IS VPLS > > > > > > > > Hi, > > > > > > > > At the IETF meeting in Paris I took an action (as noted in the > > > > minutes) to poll the WG to see if there was any interest (other > > than > > > > by the authors of > > > > course) in progressing the IS-IS VPLS draft. > > > > > > > > Would you please respond to this email indicating whether or not > > you > > > > have interest in seeing this draft progress, ideally giving > > reasoning > > > > for your position. It'd be especially interesting to see > > > > responses from service providers of course. > > > > > > > > If there are no (or very few) responses to this email then Nabil > > and > > > I > > > > will probably interpret that as meaning there's insufficient > > interest > > > > to progress. Of course it may just mean that you all missed this > > > > email in the deluge of debate on E-Tree ;) > > > > > > > > Giles > > > > From lucy.yong@huawei.com Mon Apr 30 12:12:54 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA6621F88A0 for ; Mon, 30 Apr 2012 12:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] 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 24X5DGFDyfCx for ; Mon, 30 Apr 2012 12:12:53 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 361A521F889B for ; Mon, 30 Apr 2012 12:12:53 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFS34334; Mon, 30 Apr 2012 15:12:52 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Apr 2012 12:11:59 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Mon, 30 Apr 2012 12:11:53 -0700 From: Lucy yong To: John E Drake , Linda Dunbar , Mach Chen , Giles Heron , "l2vpn@ietf.org" Subject: RE: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0kdUdSO48LuIhSPkS8Et2e3RTHugAJ0cmQABqEpVAAcwK+MAAEDOFgAAYZkLAAARDbgAABWobw Date: Mon, 30 Apr 2012 19:11:51 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E7D47@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDE9C5@EMBX01-HQ.jnpr.net> <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> <4A95BA014132FF49AE685FAB4B9F17F6339049E4@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDED4C@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A56EEDED4C@EMBX01-HQ.jnpr.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.14] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@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, 30 Apr 2012 19:12:54 -0000 Execute me. This is a bit of assault. We all need be professional. Lucy -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Monday, April 30, 2012 1:33 PM To: Linda Dunbar; Lucy yong; Mach Chen; Giles Heron; l2vpn@ietf.org Subject: RE: Interest in IS-IS VPLS How about DOA? (Dead On Arrival) Sent from my iPhone > -----Original Message----- > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > Sent: Monday, April 30, 2012 11:02 AM > To: Lucy yong; John E Drake; Mach Chen; Giles Heron; l2vpn@ietf.org > Subject: RE: Interest in IS-IS VPLS >=20 > Agree with Lucy, DC-VPN might be a better name. >=20 > Linda >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > > Of Lucy yong > > Sent: Monday, April 30, 2012 10:39 AM > > To: John E Drake; Mach Chen; Giles Heron; l2vpn@ietf.org > > Subject: RE: Interest in IS-IS VPLS > > > > John, > > > > IS-IS VPLS is completely different from TRILL and SPB although they > > all use of IS-IS protocol in control plane. IS-IS VPLS data plane > uses > > an IP/GRE tunnel carrying VPN instances differentiated by MPLS > labels. > > TRILL and SPB data planes are Ethernet based, i.e. the frames are > > Ethernet frames. > > > > Isn't it good that one control plane protocol can apply to different > > data planes? > > > > I agree that VPLS has been well defined and used in Service Provider > > networks. IS-IS VPLS provides the simplified version of VPLS that can > > apply to data center networks. This may be better than developing > > something completely new in data center. > > > > Maybe we need consider another name for this, for example DC-VPN? In > > data center, an VPN is not necessary to provide a service to an > > customer, the infrastructure need VPN capability. > > > > Regards, > > Lucy > > > > > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Monday, April 30, 2012 8:12 AM > > To: Mach Chen; Lucy yong; Giles Heron; l2vpn@ietf.org > > Subject: RE: Interest in IS-IS VPLS > > > > We already have TRILL and SPB. Why is yet another IS-IS variant > > necessary, particularly one that is so completely under-specified? > > > > Sent from my iPhone > > > > > > > -----Original Message----- > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > > Behalf > > > Of Mach Chen > > > Sent: Saturday, April 28, 2012 3:04 AM > > > To: Lucy yong; Giles Heron; l2vpn@ietf.org > > > Subject: RE: Interest in IS-IS VPLS > > > > > > Fully agree with lucy here. > > > > > > In addition, since the ISIS VPLS leverages a uniform protocol(ISIS) > > for > > > signaling and auto discovery, it would greatly simplify the > > deployment > > > and maintenance, especially for the DC networks that have already > > > deployed ISIS for IP routing. So I'd like to see the draft moving > > > forward. > > > > > > Best regards, > > > Mach > > > > > > > -----Original Message----- > > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > > > Behalf > > > > Of Lucy yong > > > > Sent: Saturday, April 28, 2012 2:43 AM > > > > To: Giles Heron; l2vpn@ietf.org > > > > Subject: RE: Interest in IS-IS VPLS > > > > > > > > Hi Giles, > > > > > > > > It seems that the IS-IS VPLS provides the solution for a scalable > > > data > > > > center network as mentioned in the draft. I am not sure it is > > proper > > > > to weight service providers more on this. I can see if a service > > > > provider already deployed existing VPLS, the gain from IS-IS VPLS > > is > > > > less than the cost on upgrading all the edge devices to support > > > > the > > > solution. > > > > > > > > However, for data center network, IS-IS VPLS could be a useful > > > > solution. It simplifies current VPLS mechanism, provides a good > > > > scalability, and requires IP only function on core switches. > > > > > > > > A vendor provides devices for both service provider network and > > data > > > > center network, the solution brings a synergy in leveraging VPLS > > > > solution into DC. > > > > > > > > Thus, I like to see this work moving forward. > > > > > > > > Regards, > > > > Lucy > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > > > Behalf > > > > Of Giles Heron > > > > Sent: Friday, April 27, 2012 7:57 AM > > > > To: l2vpn@ietf.org > > > > Subject: Interest in IS-IS VPLS > > > > > > > > Hi, > > > > > > > > At the IETF meeting in Paris I took an action (as noted in the > > > > minutes) to poll the WG to see if there was any interest (other > > than > > > > by the authors of > > > > course) in progressing the IS-IS VPLS draft. > > > > > > > > Would you please respond to this email indicating whether or not > > you > > > > have interest in seeing this draft progress, ideally giving > > reasoning > > > > for your position. It'd be especially interesting to see > > > > responses from service providers of course. > > > > > > > > If there are no (or very few) responses to this email then Nabil > > and > > > I > > > > will probably interpret that as meaning there's insufficient > > interest > > > > to progress. Of course it may just mean that you all missed this > > > > email in the deluge of debate on E-Tree ;) > > > > > > > > Giles > > > > From jdrake@juniper.net Mon Apr 30 12:41:17 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F94921F8893 for ; Mon, 30 Apr 2012 12:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 bwyAthNJpIZn for ; Mon, 30 Apr 2012 12:41:16 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7081B21F8892 for ; Mon, 30 Apr 2012 12:41:16 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKT57q1ZEFQkky1tHF1p4Vm3zwvuzmgHO+@postini.com; Mon, 30 Apr 2012 12:41:16 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 30 Apr 2012 12:40:01 -0700 From: John E Drake To: Lucy yong Date: Mon, 30 Apr 2012 12:39:57 -0700 Subject: Re: Interest in IS-IS VPLS Thread-Topic: Interest in IS-IS VPLS Thread-Index: Ac0nCQgxNund3Bl0SvuSaH7bC9vsrw== Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D3264C7F8@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDE9C5@EMBX01-HQ.jnpr.net> <2691CE0099834E4A9C5044EEC662BB9D330E4B68@dfweml505-mbx> <4A95BA014132FF49AE685FAB4B9F17F6339049E4@dfweml505-mbx> <5E893DB832F57341992548CDBB333163A56EEDED4C@EMBX01-HQ.jnpr.net> <2691CE0099834E4A9C5044EEC662BB9D330E7D47@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D330E7D47@dfweml505-mbx> 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 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@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, 30 Apr 2012 19:41:17 -0000 Lucy, I'm sorry, I was proposing an alternate name for the draft. John Sent from my iPhone On Apr 30, 2012, at 3:12 PM, "Lucy yong" wrote: > Execute me. This is a bit of assault. We all need be professional. > Lucy >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net]=20 > Sent: Monday, April 30, 2012 1:33 PM > To: Linda Dunbar; Lucy yong; Mach Chen; Giles Heron; l2vpn@ietf.org > Subject: RE: Interest in IS-IS VPLS >=20 > How about DOA? (Dead On Arrival) >=20 > Sent from my iPhone >=20 >=20 >> -----Original Message----- >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >> Sent: Monday, April 30, 2012 11:02 AM >> To: Lucy yong; John E Drake; Mach Chen; Giles Heron; l2vpn@ietf.org >> Subject: RE: Interest in IS-IS VPLS >>=20 >> Agree with Lucy, DC-VPN might be a better name. >>=20 >> Linda >>=20 >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> Behalf >>> Of Lucy yong >>> Sent: Monday, April 30, 2012 10:39 AM >>> To: John E Drake; Mach Chen; Giles Heron; l2vpn@ietf.org >>> Subject: RE: Interest in IS-IS VPLS >>>=20 >>> John, >>>=20 >>> IS-IS VPLS is completely different from TRILL and SPB although they >>> all use of IS-IS protocol in control plane. IS-IS VPLS data plane >> uses >>> an IP/GRE tunnel carrying VPN instances differentiated by MPLS >> labels. >>> TRILL and SPB data planes are Ethernet based, i.e. the frames are >>> Ethernet frames. >>>=20 >>> Isn't it good that one control plane protocol can apply to different >>> data planes? >>>=20 >>> I agree that VPLS has been well defined and used in Service Provider >>> networks. IS-IS VPLS provides the simplified version of VPLS that can >>> apply to data center networks. This may be better than developing >>> something completely new in data center. >>>=20 >>> Maybe we need consider another name for this, for example DC-VPN? In >>> data center, an VPN is not necessary to provide a service to an >>> customer, the infrastructure need VPN capability. >>>=20 >>> Regards, >>> Lucy >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: John E Drake [mailto:jdrake@juniper.net] >>> Sent: Monday, April 30, 2012 8:12 AM >>> To: Mach Chen; Lucy yong; Giles Heron; l2vpn@ietf.org >>> Subject: RE: Interest in IS-IS VPLS >>>=20 >>> We already have TRILL and SPB. Why is yet another IS-IS variant >>> necessary, particularly one that is so completely under-specified? >>>=20 >>> Sent from my iPhone >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>> Behalf >>>> Of Mach Chen >>>> Sent: Saturday, April 28, 2012 3:04 AM >>>> To: Lucy yong; Giles Heron; l2vpn@ietf.org >>>> Subject: RE: Interest in IS-IS VPLS >>>>=20 >>>> Fully agree with lucy here. >>>>=20 >>>> In addition, since the ISIS VPLS leverages a uniform protocol(ISIS) >>> for >>>> signaling and auto discovery, it would greatly simplify the >>> deployment >>>> and maintenance, especially for the DC networks that have already >>>> deployed ISIS for IP routing. So I'd like to see the draft moving >>>> forward. >>>>=20 >>>> Best regards, >>>> Mach >>>>=20 >>>>> -----Original Message----- >>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>>> Behalf >>>>> Of Lucy yong >>>>> Sent: Saturday, April 28, 2012 2:43 AM >>>>> To: Giles Heron; l2vpn@ietf.org >>>>> Subject: RE: Interest in IS-IS VPLS >>>>>=20 >>>>> Hi Giles, >>>>>=20 >>>>> It seems that the IS-IS VPLS provides the solution for a scalable >>>> data >>>>> center network as mentioned in the draft. I am not sure it is >>> proper >>>>> to weight service providers more on this. I can see if a service >>>>> provider already deployed existing VPLS, the gain from IS-IS VPLS >>> is >>>>> less than the cost on upgrading all the edge devices to support >>>>> the >>>> solution. >>>>>=20 >>>>> However, for data center network, IS-IS VPLS could be a useful >>>>> solution. It simplifies current VPLS mechanism, provides a good >>>>> scalability, and requires IP only function on core switches. >>>>>=20 >>>>> A vendor provides devices for both service provider network and >>> data >>>>> center network, the solution brings a synergy in leveraging VPLS >>>>> solution into DC. >>>>>=20 >>>>> Thus, I like to see this work moving forward. >>>>>=20 >>>>> Regards, >>>>> Lucy >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>>> Behalf >>>>> Of Giles Heron >>>>> Sent: Friday, April 27, 2012 7:57 AM >>>>> To: l2vpn@ietf.org >>>>> Subject: Interest in IS-IS VPLS >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> At the IETF meeting in Paris I took an action (as noted in the >>>>> minutes) to poll the WG to see if there was any interest (other >>> than >>>>> by the authors of >>>>> course) in progressing the IS-IS VPLS draft. >>>>>=20 >>>>> Would you please respond to this email indicating whether or not >>> you >>>>> have interest in seeing this draft progress, ideally giving >>> reasoning >>>>> for your position. It'd be especially interesting to see >>>>> responses from service providers of course. >>>>>=20 >>>>> If there are no (or very few) responses to this email then Nabil >>> and >>>> I >>>>> will probably interpret that as meaning there's insufficient >>> interest >>>>> to progress. Of course it may just mean that you all missed this >>>>> email in the deluge of debate on E-Tree ;) >>>>>=20 >>>>> Giles >>>>>=20 >=20 From david.i.allan@ericsson.com Mon Apr 30 14:27:05 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266A621E802A for ; Mon, 30 Apr 2012 14:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 2g6afTriVhs4 for ; Mon, 30 Apr 2012 14:27:03 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C83E321E8083 for ; Mon, 30 Apr 2012 14:27:02 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3ULR0U6000357 for ; Mon, 30 Apr 2012 16:27:02 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.69]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 30 Apr 2012 17:27:01 -0400 From: David Allan I To: "l2vpn@ietf.org" Date: Mon, 30 Apr 2012 17:26:59 -0400 Subject: Minor nit with draft-jiang-l2vpn-vpls-pe-etree-05 Thread-Topic: Minor nit with draft-jiang-l2vpn-vpls-pe-etree-05 Thread-Index: Ac0nF/nul5KYq9VKTaWkKbvwH0EvhA== Message-ID: <60C093A41B5E45409A19D42CF7786DFD523264F414@EUSAACMS0703.eamcs.ericsson.se> 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_60C093A41B5E45409A19D42CF7786DFD523264F414EUSAACMS0703e_" MIME-Version: 1.0 X-BeenThere: l2vpn@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, 30 Apr 2012 21:27:05 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD523264F414EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI: There is a few inaccuracies in the description of ETREE with 802.1aq SPB on= page 2 of the document. 1) Asymmetic VLAN was introduced with 802.1ad, long ago. 2) It refers to 802.1ad assymetric VLAN behavior but the description associ= ates it and its artifacts with 802.1aq. It suggests that the VLANs are use= d as a filtering mechanism at root and leaf nodes (which would be true for = 802.1ad), suggesting frames are delivered to a superset of the intended rec= ipients as an artifact of the ETREE implementation. This is not true for 80= 2.1aq, the forwarding tree construction in SPB ensures frames are only deli= vered to intended recipients... leaves to roots and roots to all. I'd suggest changing the paragraph: IEEE 802.1 originally specified a generic E-Tree solution in 802.1ad(2005).= In the solution, VLANs are used to indicate root/leaf source of a packet: = one VLAN ID is used to indicate the frames originated from the roots and an= other VLAN ID is used to indicate the frames originated from the leaves. At= a leaf port, the bridge can then filter out all the frames from other leaf= ports based on the VLAN ID. 802.1aq(2012) improved upon this by eliminatin= g the filtering requirement and associated discard by properly scoping the = forwarding trees for an ETREE from leaf to root and from root to all. It wo= uld be desirable that any VPLS solution reflected this improvement. Cheers Dave --_000_60C093A41B5E45409A19D42CF7786DFD523264F414EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
HI:
 
There is a few inaccuracies in the description of ETREE with 802.1aq S= PB on page 2 of the document.
 
1) Asymmetic VLAN was introduced with 802.1ad, long ago.
 
2) It refers to 802.1ad assymetric VLAN behavior but the description a= ssociates it and its artifacts with 802.1aq.  It suggests that the VLA= Ns are used as a filtering mechanism at root and leaf nodes (which would be= true for 802.1ad), suggesting frames are delivered to a superset of the intended recipients as an artifact of th= e ETREE implementation. This is not true for 802.1aq, the forwarding tree c= onstruction in SPB ensures frames are only delivered to intended recipients= … leaves to roots and roots to all.
 
I'd suggest changing the paragraph:
 
IEEE 802.1 originally specified a generic E-Tree sol= ution in 802.1ad(2005). In the solution, VLANs are used to indicate root/le= af source of a packet: one VLAN ID is used to indicate the frames originated from the roots and another VLAN ID i= s used to indicate the frames originated from the leaves. At a leaf port, t= he bridge can then filter out all the frames from other leaf ports based on= the VLAN ID. 802.1aq(2012) improved upon this by eliminating the filtering requirement and associated discard b= y properly scoping the forwarding trees for an ETREE from leaf to root and = from root to all. It would be desirable that any VPLS solution reflected th= is improvement.
 
Cheers Dave
 
 
 
 
 
 --_000_60C093A41B5E45409A19D42CF7786DFD523264F414EUSAACMS0703e_-- From david.i.allan@ericsson.com Mon Apr 30 14:39:49 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8576E21E8099 for ; Mon, 30 Apr 2012 14:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 BRaQ9vLchmyj for ; Mon, 30 Apr 2012 14:39:48 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0D09111E8072 for ; Mon, 30 Apr 2012 14:39:48 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3ULdkum002042 for ; Mon, 30 Apr 2012 16:39:47 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.69]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 30 Apr 2012 17:39:40 -0400 From: David Allan I To: David Allan I , "l2vpn@ietf.org" Date: Mon, 30 Apr 2012 17:39:39 -0400 Subject: RE: Minor nit with draft-jiang-l2vpn-vpls-pe-etree-05 Thread-Topic: Minor nit with draft-jiang-l2vpn-vpls-pe-etree-05 Thread-Index: Ac0nF/nul5KYq9VKTaWkKbvwH0EvhAAAaTbA Message-ID: <60C093A41B5E45409A19D42CF7786DFD523264F443@EUSAACMS0703.eamcs.ericsson.se> References: <60C093A41B5E45409A19D42CF7786DFD523264F414@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD523264F414@EUSAACMS0703.eamcs.ericsson.se> 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_60C093A41B5E45409A19D42CF7786DFD523264F443EUSAACMS0703e_" MIME-Version: 1.0 X-BeenThere: l2vpn@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, 30 Apr 2012 21:39:49 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD523264F443EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ignore the comment below, it is not exactly timely... my bad! Dave ________________________________ From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= avid Allan I Sent: Monday, April 30, 2012 2:27 PM To: l2vpn@ietf.org Subject: Minor nit with draft-jiang-l2vpn-vpls-pe-etree-05 HI: There is a few inaccuracies in the description of ETREE with 802.1aq SPB on= page 2 of the document. 1) Asymmetic VLAN was introduced with 802.1ad, long ago. 2) It refers to 802.1ad assymetric VLAN behavior but the description associ= ates it and its artifacts with 802.1aq. It suggests that the VLANs are use= d as a filtering mechanism at root and leaf nodes (which would be true for = 802.1ad), suggesting frames are delivered to a superset of the intended rec= ipients as an artifact of the ETREE implementation. This is not true for 80= 2.1aq, the forwarding tree construction in SPB ensures frames are only deli= vered to intended recipients... leaves to roots and roots to all. I'd suggest changing the paragraph: IEEE 802.1 originally specified a generic E-Tree solution in 802.1ad(2005).= In the solution, VLANs are used to indicate root/leaf source of a packet: = one VLAN ID is used to indicate the frames originated from the roots and an= other VLAN ID is used to indicate the frames originated from the leaves. At= a leaf port, the bridge can then filter out all the frames from other leaf= ports based on the VLAN ID. 802.1aq(2012) improved upon this by eliminatin= g the filtering requirement and associated discard by properly scoping the = forwarding trees for an ETREE from leaf to root and from root to all. It wo= uld be desirable that any VPLS solution reflected this improvement. Cheers Dave --_000_60C093A41B5E45409A19D42CF7786DFD523264F443EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ignore the comment below, it is not exactly=20 timely...
 
my=20 bad!
Dave

From: l2vpn-bounces@ietf.org=20 [mailto:l2vpn-bounces@ietf.org] On Behalf Of David Allan=20 I
Sent: Monday, April 30, 2012 2:27 PM
To:=20 l2vpn@ietf.org
Subject: Minor nit with=20 draft-jiang-l2vpn-vpls-pe-etree-05

HI:
 
There is a few inaccuracies in the description of ETREE with 802.1aq S= PB on=20 page 2 of the document.
 
1) Asymmetic VLAN was introduced with 802.1ad, long ago.
 
2) It refers to 802.1ad assymetric VLAN behavior but the description=20 associates it and its artifacts with 802.1aq.  It suggests that the VL= ANs=20 are used as a filtering mechanism at root and leaf nodes (which would be tr= ue=20 for 802.1ad), suggesting frames are delivered to a superset of the intended= =20 recipients as an artifact of the ETREE implementation. This is not true for= =20 802.1aq, the forwarding tree construction in SPB ensures frames are only=20 delivered to intended recipients… leaves to roots and roots to all.
 
I'd suggest changing the paragraph:
 
IEEE 802.1 originally specified a generic E-Tre= e=20 solution in 802.1ad(2005). In the solution, VLANs are used to indicate root= /leaf=20 source of a packet: one VLAN ID is used to indicate the frames originated f= rom=20 the roots and another VLAN ID is used to indicate the frames originated fro= m the=20 leaves. At a leaf port, the bridge can then filter out all the frames from = other=20 leaf ports based on the VLAN ID. 802.1aq(2012) improved upon this by elimin= ating=20 the filtering requirement and associated discard by properly scoping the=20 forwarding trees for an ETREE from leaf to root and from root to all. It wo= uld=20 be desirable that any VPLS solution reflected this improvement.
 
Cheers Dave
 
 
 
 
 
 --_000_60C093A41B5E45409A19D42CF7786DFD523264F443EUSAACMS0703e_--